简介面向需要在 RHEL 7.6 上搭建 Oracle 19C 高可用数据库环境的中高级 DBA这份指南完整覆盖 ASM 存储与 DataGuard 主从复制的部署全流程。内容从硬件最低要求4 核/20G 内存/200G 存储、软件版本Oracle 软件 V981623-01、GI 软件 V981627-01到双节点部署规划node2 主库与 node2dg 备库、GI 与 ORACLE_HOME 目录结构、网络 IP 配置均有明确说明还包含安装前系统包检查命令、内核与 SWAP 验证、网络文件权限调整等细节。针对 Oracle 19C 软件安装、ASM 磁盘组配置、DataGuard 主备同步与网络环境设置提供逐步操作指引可帮助读者规避路径检测、权限设置等常见坑点。资源为 1 个 PDF 文档压缩包大小约 4.68MB排版清晰、命令可复制。已有 702 人学习下载既适合生产环境部署前的快速参考也适合希望掌握 Oracle 19C 高可用架构的读者按步骤实验。1. RHEL 7.6 装 Oracle 19C ASM DataGuard这套文档到底值不值得照着做一台 4 核 20G 内存的 x86 服务器跑 RHEL 7.6要用 Oracle 19c 做一套主备容灾存储走 ASM。听起来标准但真正动手的人都知道卡点根本不在 Oracle 软件本身而在环境准备阶段内核参数、UDEV 绑定、CTSS 时间同步、GI 安装时的磁盘发现。这套下载资源把 node2主库和 node2dg备库从零到 DataGuard 的完整操作都记录下来了包括硬件需求、软件版本Oracle 软件 V981623-01.zip、GI 软件 V981627-01.zip、目录规划、磁盘绑定规则、甚至 grid 和 oracle 两个用户的环境变量全文。如果你是 DBA 或运维工程师想在这套组合上一次装通别照着官方文档硬啃直接按这个文档的路径走。2. 动手前的系统改造目录、用户组、内核参数一个都不能省Oracle 19c 的安装失败十有八九不是软件问题而是基础环境没做对。这套文档在前面花了大量篇幅做系统准备这部分才是整个安装的真正难点。2.1 目录与用户组规划grid 和 oracle 的职责边界在 RHEL 7.6 上装 Oracle 19c ASM第一件事不是解压安装包而是把文件系统和账号体系先立好。文档里规划的路径是典型的双 HOME 结构GIGrid Infrastructure安装在 /app/product/19.2.0/crsOracle 数据库软件安装在 /app/oracle/product/19.2.0/dbhome_1各自的 ORACLE_BASE 分别是 /app/grid 和 /app/oracle。mkdir -p /app/grid mkdir -p /app/product/19.2.0/crs mkdir -p /app/oraInventory mkdir -p /app/oracle/product/19.2.0/dbhome_1这个步骤里最容易翻车的点Oracle 的安装程序不会自动创建 ORACLE_HOME 的上级目录路径不存在的时候 OUI 直接报错或者检测不到软件目录。所以先建全路径再运行安装脚本。另外注意GI 和 DB 的 ORACLE_HOME 不能放在同一个目录树的下级否则两个软件的 inventory 会打架后面升级或打补丁的时候会非常痛苦。用户和组的创建是更前置的一步文档里用的 GID/UID 是 54321~54330 这段。这段数字不是随手写的是 Oracle 官方在 Linux 上推荐的保留段避免和系统已有用户冲突。完整命令是这样的/usr/sbin/groupadd -g 54321 asmadmin /usr/sbin/groupadd -g 54322 asmdba /usr/sbin/groupadd -g 54323 asmoper /usr/sbin/groupadd -g 54324 dba /usr/sbin/groupadd -g 54325 oper /usr/sbin/groupadd -g 54326 oinstall /usr/sbin/groupadd -g 54327 backupdba /usr/sbin/groupadd -g 54328 dgdba /usr/sbin/groupadd -g 54329 kmdba /usr/sbin/groupadd -g 54330 racdba /usr/sbin/useradd -u 54321 -g oinstall -G dba,asmdba,backupdba,dgdba,kmdba,racdba,oper oracle /usr/sbin/useradd -u 54322 -g oinstall -G asmadmin,asmdba,asmoper,dba grid组名的职责边界asmadmin 是 ASM 实例的管理员组只有 grid 用户在里头asmdba 是能读写 ASM 文件的组grid 和 oracle 都在backupdba、dgdba、kmdba、racdba 是 19c 新增的角色组分别对应备份、DataGuard、密钥管理和 RAC 管理这些只需要 oracle 用户进grid 不用。这里有个很多文档没讲明白的原则grid 用户只管 ASM 和集群件oracle 用户管数据库本身两边权限隔离grid 不需要 backupdba 这种数据库角色组。反过来grid 需要 dba 组是因为 ASM 实例的 sysdba 和数据库的 sysdba 是打通的连 ASM 做诊断操作时需要 dba 权限。2.2 内核参数配置一份可以照着抄的 sysctl.conf19c 的 OUI 在安装前会检查一批内核参数任何一个不达标都会在 prerequisite check 阶段标红。文档给出的 /etc/sysctl.conf 配置是经过验证能一次通过的组合我建议直接照抄但抄之前最好知道每个参数在干什么。fs.aio-max-nr 1048576 fs.file-max 6815744 kernel.shmall 4294967296 kernel.shmmax 12640516096 kernel.shmmni 4096 kernel.sem 250 32000 100 128 net.ipv4.ip_local_port_range 9000 65500 net.core.rmem_default 262144 net.core.rmem_max 4194304 net.core.wmem_default 262144 net.core.wmem_max 1048576逐条说fs.aio-max-nr 是异步 IO 请求的并发上限Oracle 的 dbwr 和 ASM 的重平衡操作都在用 AIO设到 1048576 是为了防止高并发下出现 aio 资源耗尽fs.file-max 是系统级文件句柄上限6815744 是官方推荐值。kernel.shm 三个参数是共享内存段配置这里有一个常见的抄作业翻车点——shmmax 的单位是字节shmall 的单位是页Page通常 4096 字节。文档里 shmmax12640516096 对应约 11.8GB接近物理内存 20GB 的一半而 shmall4294967296 是 4G 页换算成字节是 16TB远远大于 shmmax。所以如果看到老文档里 shmall 和 shmmax 填同一个数那说明他们单位没搞清楚会引发 ORA-27102 之类的共享内存分配失败。修改完直接用 root 执行 sysctl -p 让参数生效然后用 sysctl -a 抽查几个关键项确认没写错。kernel.sem 的四个值 250 32000 100 128 对应 SEMMSL、SEMMNS、SEMOPM、SEMMNI也是 19c 官方文档的标准值不用动。2.3 环境变量与 Shell 限制ORACLE_SID 是第一个坑环境变量这块文档给的是两套完整 .bash_profile。grid 用户的关键配置是 ORACLE_SIDASM这是 ASM 实例的固定 SID不能改成别的oracle 用户的 ORACLE_SID 则是数据库实例名。这里我吃过不少亏oracle 用户的环境变量如果按主库的 SID 直接复制到备库不修改备库 sqlplus 起来之后连接的还是主库的逻辑排查问题时很容易被误导。# grid 用户 ~/.bash_profile 关键行 ORACLE_SIDASM; export ORACLE_SID ORACLE_BASE/app/grid; export ORACLE_BASE ORACLE_HOME/app/product/19.2.0/crs; export ORACLE_HOME PATH.:${JAVA_HOME}/bin:${PATH}:$HOME/bin:$ORACLE_HOME/bin:$ORA_CRS_HOME/bin LD_LIBRARY_PATH$ORACLE_HOME/lib LD_LIBRARY_PATH${LD_LIBRARY_PATH}:$ORACLE_HOME/oracm/lib export LD_LIBRARY_PATH CLASSPATH THREADS_FLAGnative TEMP/app/tmp TMPDIR/app/tmp umask 022 export DISPLAY10.6.0.243:0.0这套配置里值得注意的点有三个。第一LD_LIBRARY_PATH 必须把 $ORACLE_HOME/lib 放最前面后面再拼系统 lib顺序错了会导致 ASM 实例加载错版本的 libclntsh。第二TEMP 和 TMPDIR 指向 /app/tmp这个目录要先建好并给 grid 写权限否则 OUI 在检查阶段会报 /tmp 空间不足。第三DISPLAY 指向的是发起图形安装的客户端机器 IP不是服务器本机这个在无桌面服务器上装 Oracle 是必经环节配错了 gridSetup.sh 起不来图形界面。Shell 限制写入 /etc/security/limits.conf 和 /etc/pam.d/login文档里给 grid 和 oracle 都设了 nproc、nofile、stack、memlock。其中 memlock 3145728 的单位是 KB也就是 3GB用来锁住 SGA 的关键内存段防止被 swap 出去。如果 20G 内存环境下分配了 8G SGA这个值要往上调否则实例启动时可能报 memlock 不足。系统层面还有最后一个环节时间同步。文档直接建议停掉 chronyd让 Oracle 自己的 CTSS 接管。这个决策在实验环境是对的在生产环境如果已经有企业级 NTP 体系则不要动 chrony而是把 CTSS 关掉两种模式只能选一种两边同时开会导致时间源冲突。3. ASM 磁盘绑定UDEV 规则文件逐行拆解共享存储的规划是整个安装里另一个高频翻车点。文档把四块盘的绑定过程写得很完整这里我把它拆开讲清楚为什么这么干。3.1 为什么旧方案都翻车了最后选了 UDEVASM 磁盘在 Linux 上的设备绑定方式经历过几个阶段早期用 ASMLIB后来 19c 官方已经不再推荐因为 ASMLIB 在 RHEL 7 上的兼容性不好还要求装内核匹配的驱动包中间很多人用 udev 规则给 /dev/sd* 设备做别名再往后是 multipath udev 或者直接用磁盘的 WWID 匹配。文档采用的是 udev 规则方案也就是每块裸盘在系统启动时被 udev 识别自动创建 /dev/asmdiskXX 设备节点并赋予 grid:asmadmin 属主。三个方案的取舍如下表方案优点缺点ASMLIB配置简单一个命令搞定RHEL7 兼容性差官方已停更UDEV 规则系统自带机制稳定可控规则写错排查略繁琐直接使用 /dev/sdX无需配置重启后盘符可能漂移权限默认 root:disk这里要理解一个关键点ASM 不用文件系统它直接管理裸设备所以设备节点的稳定性和属主权限就是一切。盘符在重启后可能从 sdc 变成 sdd但磁盘的 WWIDSCSI 唯一标识不会变所以 udev 规则用 WWID 做匹配条件而不是用盘符。3.2 规则文件逐行拆解先在目标机器上看磁盘的 WWID然后把这个值填进规则文件。文档里的命令是/usr/lib/udev/scsi_id -g -u /dev/sdc /usr/lib/udev/scsi_id -g -u /dev/sdd /usr/lib/udev/scsi_id -g -u /dev/sde /usr/lib/udev/scsi_id -g -u /dev/sdf在 RHEL 7 里scsi_id 的路径是 /usr/lib/udev/scsi_id这一点要特别注意很多教程写的是 /sbin/scsi_idRHEL 7 根本没有这个路径直接抄会报 command not found。命令输出是每块盘的 WWID比如 36000c291ca220c52c813c595ffdf14f4 这种 32 位十六进制串把每块盘的 WWID 和它对应的盘符记下来接下来写规则文件。vi /etc/udev/rules.d/99-my-asmdevices.rules # 内容模板每块盘一段 KERNELsd*[!0-9], ENV{DEVTYPE}disk, SUBSYSTEMblock, PROGRAM/usr/lib/udev/scsi_id -g -u -d $devnode, RESULT36000c291ca220c52c813c595ffdf14f4, RUN/bin/sh -c mknod /dev/asmdisk01 b $major $minor; chown grid:asmadmin /dev/asmdisk01; chmod 0660 /dev/asmdisk01逐段解释这段规则KERNELsd*[!0-9] 是匹配 sda、sdb、sdc 这种整盘设备中括号里的 [!0-9] 表示名字以字母结尾确保不会匹配到 sda1、sdb2 这些分区设备ASM 磁盘必须是整块盘不能是分区ENV{DEVTYPE}disk 进一步确认是磁盘类型SUBSYSTEMblock 限定块设备子系统避免和字符设备混淆。PROGRAM 是让 udev 调 scsi_id 去读当前盘的实际 WWIDRESULT 是刚才记下来的值。整条规则的逻辑就是如果系统识别到的盘它的 WWID 等于我写死的这个值那么执行 RUN 里的命令。RUN 里做的事情是 mknod 创建设备节点然后 chown 和 chmod。注意这里的 $major $minor 是 udev 自动展开的内核主次设备号不需要手写数字。mknod 之后 chown grid:asmadmin 和 chmod 0660 保证 ASM 实例能读写这个设备。四块盘就按同样模板写四段。写完后执行/sbin/udevadm trigger --typedevices --actionchange ls -l /dev/asmdisk*udevadm trigger 是让系统立即重放一次设备事件不用重启就能把 /dev/asmdisk01 等节点创建出来。如果这一步执行完 ls 看不到节点优先检查 RESULT 的字符串有没有抄错或者有没有多复制了一个空格。还有个更稳妥的验证方法单独对一块盘做测试查看规则是否被正确解析udevadm test /dev/sdc 21 | grep -E asmdisk|RUNudevadm test 会真的执行一部分 RUN 动作需要在 root 下执行输出里能看到匹配到的规则和执行的命令。这个方法我一般只在规则死活不生效的时候用平时能少碰就少碰输出太噪。3.3 磁盘权限和属主检查规则生效后验证环节不能只停留在 ls 能看到节点。ASM 在创建磁盘组的时候会要求磁盘的属主和权限完全正确否则磁盘组创建失败或者只能以 restricted 模式装入。ls -l /dev/asmdisk* # 期望输出brw-rw---- grid asmadmin /dev/asmdisk01每块盘一致 /usr/lib/udev/scsi_id -g -u /dev/sdc # 检查这个输出和规则里的 RESULT 是否完全一致文档里四块盘对应四个 WWID分布在主备两个节点上时两边磁盘的 WWID 必须一致。主备两个节点的 /dev/asmdisk* 设备节点、属主、权限要保持完全相同的命名顺序不然 DG 的日志传输和 ASM 元数据同步会出现“磁盘组找不到”的困惑。到这里基础环境就绪可以开始装 GI 了。4. 安装 Grid Infrastructure单实例 ASM 的正确姿势GI 的安装是整套流程里最容易迷路的环节因为 19c 的安装界面和 11g、12c 都有区别选项也更多。文档在这一步给的方案很明确单实例数据库配 standalone server 模式的 ASM。4.1 解压与 gridSetup.sh 启动19c 的安装包是两个 zipGI 软件 V981627-01.zip 负责 ASM 和集群件Oracle 数据库软件 V981623-01.zip 才是数据库本体。顺序上必须先装 GI再装数据库软件这个顺序反不了。# 切换到 grid 用户 su - grid export ORACLE_BASE/app/grid export ORACLE_HOME/app/product/19.2.0/crs # 解压 GI 软件到 ORACLE_HOME unzip V981627-01.zip -d /app/product/19.2.0/crs # 启动 GUI 安装需要在能连到 X server 的终端里执行 cd /app/product/19.2.0/crs ./gridSetup.sh解压这一步有个细节V981627-01.zip 解压出来的内容直接放在 ORACLE_HOME 目录本身gridSetup.sh 就在解压后的根路径下不需要再建子目录。另一种常见做法是把 zip 解压到一个 stage 目录再运行但文档采用的方式是直接解压到目标 HOME好处是路径短坏处是如果解压目录不对重装时要先把 ORACLE_HOME 清干净。gridSetup.sh 启动后在配置类型的选择上文档明确选择了 standalone server。这一步要看清我们只有主备两个节点各自是单实例不是 RAC所以不要选 Oracle Real Application Clusters。选 standalone server 会在本机创建一个单独的 ASM 实例和管理这个节点的集群件这就是 DataGuard 主备各自独立 ASM 的基础。4.2 磁盘组创建Normal 冗余的代价进入图形界面后关键选择在磁盘组那一屏。文档的磁盘组名称叫 DATA点 Change Discovery Path 让它去扫描 /dev/asmdisk*Redundancy 选的 Normal。三个冗余级别的差别冗余级别最少磁盘数可用容量适合场景External1100%有存储 RAID 保护或者数据本身有备份副本Normal250%单块盘故障不丢数据但容量减半High333%要求极高的场景一般不常用文档这套环境是有 DataGuard 的备库本身就是主库的完整副本。所以一个值得讨论的点是如果底层是 VMware 虚拟盘或者有 RAID 卡承担了数据保护ASM 层选 External 更实用容量利用率高一倍选 Normal 虽然抗单盘故障但四块盘只有两块的有效容量。我当时第一次搭这种环境选了 Normal后来发现底层存储本身已经做了 RAID10ASM 层再做一层镜像纯属浪费空间。这个决策看的是你所在的存储环境没有绝对的对错但要理解代价是什么。这一屏还有一个密码设置ASM 的管理员sysasm密码文档里统一用的是 oracle生产环境自然不能用这种弱口令。密码记不住的话后面 ASM 实例起不来你只能重装 GI重置密码的成本远高于一开始设一个能记住的强密码。4.3 GI 安装后的自检清单GI 装完会要求用 root 执行两个脚本orainstRoot.sh 和 root.sh。这个环节很多人会跳过或者执行时报错比如 root.sh 在最后一步起 CSS 进程失败。遇到这种情况先看 /app/product/19.2.0/crs/install/root.sh 的日志常见原因是 /etc/inittab 被改过或者 cvuqdisk 包没装。# 验证集群件状态 /app/product/19.2.0/crs/bin/crsctl check cluster /app/product/19.2.0/crs/bin/crsctl stat res -t # 验证 ASM 实例和磁盘组 /app/product/19.2.0/crs/bin/asmcmd lsdg /app/product/19.2.0/crs/bin/sqlplus / as sysasmcrsctl stat res -t 的输出里ora.asm 和 ora.DATA.dg 的 STATE 应该是 ONLINE如果显示 OFFLINE优先检查 ASM 实例的 alert 日志。asmcmd lsdg 能列出磁盘组的名字、冗余级别、总容量和可用容量。正常情况 DATA 磁盘组已经挂上状态为 MOUNTED。GI 就绪后数据库软件安装是相对常规的步骤。解压 V981623-01.zip以 oracle 用户执行 runInstaller选择 Install database software only把 ORACLE_HOME 指到 /app/oracle/product/19.2.0/dbhome_1到 root.sh 脚本那一步照常执行。执行完之后用 dbca 建库存储类型选 ASM磁盘组选 DATA。dbca 建库有一个容易忽略的选项内存分配。如果之前没有规划好 SGAdbca 会按物理内存的比例自动算默认值在 20G 内存的文档环境里给 Oracle 分 8G SGA 是比较稳妥的同时把 AMMAutomatic Memory Management关掉避免 MEMORY_TARGET 和 ASM 的共享内存段互相挤压。这属于个人习惯目的是让内存分配路径更可控。5. 避坑记录这五个坑我踩的时候都想砸键盘环境准备到 GI 安装这个过程每一层都有坑。我把这套文档落地时遇到过的五个比较典型的故障现象整理出来供你排查时对照。5.1 现象gridSetup.sh 里 Change Discovery Path 扫不到任何磁盘两台节点都配好了 UDEV规则文件也在可界面上磁盘列表就是空的这几乎是我见过安装 19c 时排第一的翻车点。原因三种情况最常见一是 udevadm trigger 之后设备节点没重新生成属主还是 root:disk二是规则的 RESULT 值和 scsi_id 实际输出不一致多是复制时候多了空格或漏了字符三是在虚拟机环境里新增的磁盘没让系统重新扫描sdc、sdd 这些设备还没出现在内核里。解决先在目标盘上重新跑/usr/lib/udev/scsi_id -g -u /dev/sdc注意实际盘符把输出和规则文件逐字符比对然后udevadm trigger --typedevices --actionchange再 ls -l /dev/asmdisk* 看属主。如果设备节点完全不存在还要确认有没有做磁盘扫描。另外如果两个节点的 WWID 不一致把主备两边都列出来逐一比对别想当然认为虚拟机克隆出来的盘 UUID 也一样。还要注意scsi_id 在不同虚拟化平台上的行为差异比较大VMware 环境下磁盘 WWID 以 36000c29 开头KVM/QEMU 环境可能显示为其他格式。如果你的盘是 iSCSI还要考虑 multipath 的情况这些都要提前确认。5.2 现象GI 安装最后一步 root.sh 报 PRVH-1017集群件起不来root.sh 执行到一半报错日志里看到 time synchronization 相关的关键字或者说 CTSS 无法启动。原因系统里 chronyd 还在运行而 Oracle CTSS 检测到外部时间同步服务存在时会自动进入观望模式observer不再提供时间同步两个节点时间一旦有偏差集群件基础栈就起不来。文档在安装前特意做了关闭 chrony 的操作就是防这个。解决按文档执行 systemctl disable chronyd 和 systemctl stop chronyd然后把 /etc/chrony.conf 改名备份重新执行 root.sh。如果是生产环境有 NTP 需求正确做法是保留 chrony 并让 CTSS 进入 observer 模式两节点时间由 NTP 保证不要两边都抢。5.3 现象图形界面闪退gridSetup.sh 一启动就报 cannot open display服务器上跑 GUI 安装DISPLAY 没设对是最常见的启动失败原因尤其在没有桌面环境的 RHEL 7 服务器上。原因DISPLAY 变量指向的地址不是发起 X 连接的客户端机器。文档里写的是 DISPLAY10.6.0.243:0.0这是从哪台机器发起图形界面就写哪台机器的 IP如果在服务器本地用普通账号跑图形界面需要先 xhost 授权。解决在客户端机器上确认 X server 在监听在服务器上执行 echo $DISPLAY 确认格式是 客户端IP:0.0root 下执行 xhost 放行。如果公司网络禁了 X 端口可以用 VNC 方案替代但注意在安全策略允许的前提下操作。5.4 现象包检查阶段 compat-libstdc 提示缺失而且 yum 装不上安装前检查清单里有 compat-libstdc-33用 yum 安装报找不到这个包。原因RHEL 7.6 的 ISO 镜像仓库里根本没有这个包它是 RHEL 6 时代留下来的兼容库Oracle 19c 的 OUI 却还在做检查。文档明确说了需要手动下载两个 rpmcompat-libstdc-33-3.2.3-72.el7.i686.rpm 和同版本的 x86_64 包。解决直接从可信 rpm 源下载两个文件然后 rpm -ivh 顺序安装先 i686 后 x86_64或者直接和其他包一起放到本地 yum 仓库里。这个包只影响 OUI 的预检查如果实在找不到也可以临时跳过检查项但不建议因为后续 gdb 之类工具调试时缺了 32 位库会很难受。5.5 现象OUI 或 dbca 报内存不足swap 和 /dev/shm 双双亮红安装 GI 前的硬件检查里文档给出的是 20G 内存配 20G swap/dev/shm 9.8G。如果服务器实际内存偏小或者 /dev/shm 被配成了默认的物理内存一半OUI 会警告。原因Oracle 19c 在 Linux 上运行时/dev/shm 过小会导致 AMM 无法正常工作数据库启动时报 ORA-00845: MEMORY_TARGET_NOT_SUPPORTED。这是 /dev/shm 不够的直接信号。解决给 /dev/shm 扩容在 fstab 里重新挂载 tmpfs常见配置是占物理内存的 50-60% 或者直接 10G。sysctl 里 kernel.shmmax 和 shmall 也要和它匹配shmmax 别超过 /dev/shm 的大小否则 SGA 分配时照样失败。文档里机器 20G 内存、shm 9.8G就是按这个思路配的。6. DataGuard 上线前的身体检查三分钟验证同步状态GI 和数据库都装好后真正体现这套环境价值的是 DataGuard 能不能在主库故障时顶上。我见过太多人装完环境就认为 DG 配好了备库实际上早就断开了日志应用。这里分享一个我每次都会做的最小验证流程不需要停机三分钟内能给主备状态做一个完整的体检。第一步在备库上确认 MRPManaged Recovery Process在跑# 备库执行 sqlplus / as sysdba SELECT process, status, thread#, sequence# FROM v$managed_standby;正常输出里应该有 RFS 和 MRP0 进程MRP0 的 status 是 APPLYING_LOG如果只有 RFS 没有 MRP0说明备库处于 mount 状态但没有开始应用日志这时候需要手动启动恢复ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; 注意 FROM SESSION 是让恢复进程在后台跑没有这个关键字会话一断恢复就停。第二步检查日志应用延迟。看 V$DATAGUARD_STATS 里的 apply lagSELECT name, value, unit FROM v$dataguard_stats WHERE name IN (apply lag,transport lag);正常情况下 value 显示 00 00:00:00 或者秒级数值。如果 apply lag 持续增大优先查网络传输而不是数据库本身文档里两节点间是直连 IP网络抖动多数时候是过防火墙或交换机限速导致。第三步在备库上做一个只读打开的数据一致性抽查。先取消恢复把备库打开成 read only查一张业务表再恢复原状ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; ALTER DATABASE OPEN READ ONLY; -- 这里查业务表比如 select count(*) from scott.emp; ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;这里有个细节备库 cancel 恢复变成 read only重开 MRP 之前需要先关闭实例再 mount。我习惯的顺序是先 shutdown immediate 再 startup mount 再启动恢复虽然多两步但状态最干净。这套最小体检流程的价值在于它能在 5 分钟内暴露 DG 配置里的绝大多数问题包括日志传输断链、备库 SID 错误、密码文件不一致。从那次在 switchover 演练时当场发现备库无法切主以后我每次装完这套 RHEL 7.6 Oracle 19C ASM 的环境都会强制走一遍上面的三步流程确认 MRP 在跑、apply lag 归零、业务表能查到数据然后才敢把环境交付出去。希望帮到你。本文还有配套的精品资源点击获取