简介面向Oracle DBA及运维工程师的实操型部署指南聚焦在RHEL 7.6Maipo环境下搭建Oracle 19C ASM与DataGuard一体化高可用架构解决双节点物理备库部署中路径规划、网络配置、依赖包检查等常见问题。资料为一份PDF文档压缩包大小4.68MB目前已有702人学习下载。文档从硬件配置要求和软件版本选择入手详细说明节点与目录规划、网络环境配置、RPM依赖包校验并逐步演示Oracle 19C软件安装、ASM磁盘组配置和DataGuard物理备库搭建。内容还特别强调预先创建全路径、修改/etc/sysconfig/network权限、确认swap与shm大小等关键细节配有node2、node2dg两节点的实际磁盘输出便于对照验证。无论刚入门还是有一定基础均可按照这套方案快速复现高可用数据库环境节省排错时间。1. 为什么 RHEL 7.6 Oracle 19C ASM Data Guard 这套方案卡点不在 Data Guard 本身看到标题里的 RHEL 7.6、Oracle 19C、ASM、Data Guard多数人默认最难的环节是备库切换。我做完几套之后的体验正好相反真正让人熬夜重装的是 ASM 磁盘权限、grid 监听和备库解析这些最不起眼的“地基”。这套方案适合给业务准备一套数据文件落在 ASM、再配一个物理备库做容灾的环境。下面从主机准备开始把 grid/ASM、19C 建库、Data Guard 搭建和排障串成一条可以照着抄的路线。命令按 19.3 版本写参数给到能直接落地的粒度尽可能让新手少踩坑、熟手能直接查边界。2. RHEL 7.6 主机准备内核参数、用户组与磁盘布局一次到位RHEL 7.6 搭配 Oracle 19C 是官方支持列表里的常见组合内核 3.10.0-957 配合 19.3 的 db_home 和 grid_home安装过程相对平顺。这个阶段多花半小时做规划和验证后面 asmca、dbca、duplicate 会顺畅很多。2.1 先确认系统版本与磁盘布局三条命令和一个反直觉建议拿到一台机器先别急着装先确认底子cat /etc/redhat-release uname -r df -h /u01cat /etc/redhat-release 应该输出 Red Hat Enterprise Linux Server release 7.6uname -r 应该是 3.10.0-957 开头的内核。这两个对不上后面 cvu 检查会直接拦下来。df -h /u01 是确认 /u01 有足够空间数据文件不在 /u01 里但 grid、oracle 软件和数据库软件都装在 /u01至少要留 80G 到 100G。磁盘布局这里有个反直觉建议不要把 ASM 磁盘和 /u01 做在同一块物理盘的 LVM 里。常见做法是两块盘做成一个 vg分一个 lv 给 /u01再把剩下的 lv 丢给 ASM结果磁盘故障时系统和 ASM 一起挂。ASM 盘应该用独立的物理盘或独立分区并且让 udev 按 WWID 识别而不是依赖盘符。下面是推荐布局用途位置最低容量说明软件目录 /u01本地文件系统80G~100G放 grid_home 和 db_homeDATA 磁盘组独立盘 sdb、sdc每块 100G放数据文件、控制文件、redoFRA 磁盘组独立盘 sdd300G 起放归档、闪回日志、备份如果只有一块 1.8T 大盘也可以分成三个独立分区但每个分区都要用 scsi_id 算出独立 WWID 再写 udev 规则不要直接拿 /dev/sdb1、/dev/sdc1 这种名字用重启后盘符顺序变化是虚拟机环境最常见的玄学问题。2.2 内核参数、用户组与 limits一份可以直接抄的配置内核参数我习惯放到 /etc/sysctl.d/99-oracle.conf避免直接改 /etc/sysctl.conf升级系统时不容易被覆盖cat /etc/sysctl.d/99-oracle.conf EOF fs.aio-max-nr 1048576 fs.file-max 6815744 kernel.sem 250 32000 100 128 kernel.shmmni 4096 kernel.shmall 1073741824 kernel.shmmax 4398046511104 net.core.rmem_default 262144 net.core.rmem_max 4194304 net.core.wmem_default 262144 net.core.wmem_max 1048576 net.ipv4.ip_local_port_range 9000 65500 EOF sysctl --systemkernel.shmmax 和 kernel.shmall 是按物理内存调的。上面给的 4T 对应物理内存 64G 左右的机器内存更大的服务器建议把 shmmax 设为物理内存的一半以上。ip_local_port_range 从 9000 开始是为了避免和常见服务端口冲突Data Guard 主备之间大量短连接时这个范围很关键。用户组和用户按 19C 官方推荐来建注意 OSDGDBA、OSKMDBA、OSRACDBA 这些 12.2 之后新增的组别不能漏groupadd -g 54321 oinstall groupadd -g 54322 dba groupadd -g 54323 oper groupadd -g 54324 backupdba groupadd -g 54325 dgdba groupadd -g 54326 kmdba groupadd -g 54327 asmdba groupadd -g 54328 asmoper groupadd -g 54329 asmadmin useradd -u 54321 -g oinstall -G dba,oper,backupdba,dgdba,kmdba,asmdba oracle useradd -u 54322 -g oinstall -G dba,asmdba,asmoper,asmadmin gridGID/UID 数字可以自己定但主备两台机器的用户 ID 最好保持一致的基准后面 rman duplicate 和 dgmgrl 跨机操作时文件属主关系会少很多麻烦。oracle 用户要加入 asmdba这样 dbca 建库时才能访问 ASM 磁盘组。limits 配置放到独立文件里cat /etc/security/limits.d/99-grid-oracle-limits.conf EOF oracle soft nofile 1024 oracle hard nofile 65536 oracle soft nproc 2047 oracle hard nproc 16384 oracle soft stack 10240 oracle hard stack 32768 grid soft nofile 1024 grid hard nofile 65536 grid soft nproc 2047 grid hard nproc 16384 grid soft stack 10240 grid hard stack 32768 EOF依赖包这一块RHEL 7.6 最小化安装会缺不少东西。我一般在装完系统后顺手装一组yum install -y bc binutils compat-libcap1 compat-libstdc-33 \ elfutils-libelf elfutils-libelf-devel gcc gcc-c glibc glibc-devel \ ksh libaio libaio-devel libgcc libstdc libstdc-devel libxcb \ libX11 libXau libXi libXtst libXrender libXrender-devel make \ net-tools nfs-utils smartmontools sysstat unixODBC unixODBC-develRHEL 7.6 的默认 yum 源里 compat-libcap1 可能找不到从系统 ISO 的 Packages 目录装 rpm 也能解决不用纠结必须 yum 成功。还有个细节Oracle 19C 在 RHEL 7 上建议关闭 Transparent HugePages否则大页内存管理会对数据库性能和稳定性产生莫名影响grubby --update-kernelALL --argstransparent_hugepagenever重启后验证 /sys/kernel/mm/transparent_hugepage/enabled 输出 should always be never这一步忘了后面总会觉得实例卡得没道理。2.3 网络与主机名Data Guard 的隐形门槛Data Guard 主备通信依赖主机名和监听解析很多坑是前期网络没理清楚。主机名不要用带下划线的名字历史教训是 broker 和 tnsnames 解析会行为诡异。/etc/hosts 里把主备两台机器都写进去用静态 IP 不用 DHCPcat /etc/hosts EOF 172.16.1.10 primary.example.com primary 172.16.1.11 standby.example.com standby EOF防火墙策略看现场环境。生产环境不要图省事直接关 iptables按 org 的端口放行 1521 即可测试环境可以直接停 firewalldsystemctl stop firewalld systemctl disable firewalldData Guard 对网络的要求是备库能主动连主库的 1521主库也能连备库的 1521。不要只放单向切到备库之后角色互换反向不通就是另一个故障。3. ASM 磁盘组grid 安装、udev 规则与 asmca 静默建组ASM 这套要承担数据文件、控制文件、redo 的存放所以 grid 安装是地基中的地基。单实例加 ASM 和 Data Guard 的场景grid 用 Oracle Restart 模式Standalone Server不是为了 RAC别选集群模式给自己加戏。3.1 让系统在重启后认得出 ASM 盘udev 规则是主要内容ASM 磁盘不能用 /dev/sdb 这种动态名要用 scsi_id 的 WWID。先看一块盘的稳定标识/usr/lib/udev/scsi_id -g -u -d /dev/sdb输出一串类似 36000c293092a381a1a75f4d6f6d22819 的字符串这就是该盘的 WWID。然后写 udev 规则cat /etc/udev/rules.d/99-oracle-asm.rules EOF KERNELsd*, SUBSYSTEMblock, PROGRAM/usr/lib/udev/scsi_id -g -u -d /dev/$name, RESULT36000c293092a381a1a75f4d6f6d22819, OWNERgrid, GROUPasmadmin, MODE0660 EOF udevadm control --reload-rules udevadm trigger ls -l /dev/sdbls -l /dev/sdb 的输出应该是 grid asmadmin 0 号设备组成员属主对不上就继续排查。RESULT 必须和 scsi_id 输出的完整串一致少一位都不行。有几块盘就写几行规则每行对应一个 WWID。规则里不要写 /dev/sdb那是动态名重启后盘符可能互换。云环境如果是 virtio 磁盘设备名是 /dev/vdb 而非 /dev/sdb规则里的 KERNEL 改成 vd*。另外虚拟机快照回滚后 WWID 一般不变但物理机更换 HBA 卡或磁盘后 WWID 可能变需要重新校验。3.2 grid 静默安装与 asmca 静默建组进入 asm 命令怎么用grid 用户的 .bash_profile 要先把环境指清楚我一般这样写cat /home/grid/.bash_profile EOF export ORACLE_BASE/u01/app/grid export ORACLE_HOME/u01/app/19.3.0/grid export ORACLE_SIDASM export PATH$ORACLE_HOME/bin:$ORACLE_HOME/OPatch:$PATH EOF这里 ORACLE_SID 固定为 ASM进入 asm 命令就靠它。grid 安装用静默 response file 方式避免图形界面在远程终端下卡死cd /u01/software unzip -q LINUX.X64_193000_grid_home.zip -d /u01/app/19.3.0/grid chown -R grid:oinstall /u01/app/19.3.0/grid /u01/app su - grid cd /u01/app/19.3.0/grid ./gridSetup.sh -silent -responseFile /home/grid/grid_install.rspresponse file 里安装类型选 Standalone ServerOracle Restart磁盘组相关的参数先留空等 grid 装完用 asmca 单独建组比在 response file 里一次写对要容易排查。gridSetup 跑完会提示用 root 执行 root.sh这步别跳过。装完确认集群资源在线crsctl stat res -t如果 oracle.restart 相关 resource 是 OFFLINE要看 $ORACLE_BASE/cfgtoollogs/crs/ 下的日志。这里也说明一点19C 的 grid 安装包同时支持 RAC 和单机 ASM装 RAC 时选择 cluster 配置即可磁盘组和后续数据库安装路径是一致的不冲突。接着用 asmca 静默建 DATA 磁盘组su - grid asmca -silent -createDiskGroup \ -diskGroupName DATA \ -disk /dev/sdb,/dev/sdc \ -redundancy EXTERNAL \ -compatible.asm 19.0.0.0 \ -compatible.rdbms 19.0.0.0-disk 参数后面跟的是 udev 规则里确定的盘路径-redundancy EXTERNAL 表示 ASM 层不镜像冗余交给存储-compatible 版本写 19.0.0.0如果以后需要把 12.2 的备库加入同一个磁盘组compatible.rdbms 要调低到 12.2。建完 FRA 磁盘组同理大小按归档量和备份周期估算300G 起步。建完磁盘组后很多人搜“oracle 进入 asm 命令”实际分两种方式。第一种是 asmcmdsu - grid export ORACLE_SIDASM asmcmd ASMCMD ls ASMCMD lsdgls 输出里能看到 DATA 和 FRA说明磁盘组已经在线。第二种是 sqlplussqlplus / as sysasm SQL select name, state from v$asm_diskgroup;sqlplus 方式看到 STATE 为 MOUNTED和 asmcmd 的 ls 结果一致即可。asmca 建组失败时日志在 /u01/app/grid/cfgtoollogs/asmca/asmca.log报错大多是磁盘属主不对或者 ASM_DISKSTRING 没找到候选盘。3.3 磁盘组选型EXTERNAL、NORMAL 与 AU_SIZE 到底怎么选冗余模式最少盘数适用场景可用容量EXTERNAL1 块有硬件 RAID 或测试环境全部NORMAL2 块无 RAID本地盘冗余约一半HIGH3 块仅本地盘且要求高可靠约三分之一生产环境如果存储层已经有 RAID5 或 RAID10EXTERNAL 是清爽的选择。ASM 层再开 NORMAL 会浪费一半容量日常维护还要处理 rebalance收益有限。如果只有两台机器各自带本地盘没有共享存储NORMAL 至少能挡住单盘故障。AU_SIZE 这个参数我一般不动默认值对绝大多数 OLTP 负载都够用。AU_SIZE 在磁盘组创建后不能在线更改改动意味着重建磁盘组所以初次建组时别为了“优化”随手调大。如果确实要调数据仓库类大批量扫描场景可以选 4M 或 8M小事务为主的 OLTP 保持默认更稳。4. Oracle 19C 数据库软件安装步骤与 dbca 静默建库把数据文件放进 DATA数据库软件和 grid 是两套 home目录别混。dbca 静默建库是少走弯路的做法图形界面容易出现一个低级错误数据库区域选成本地文件系统数据文件没有落到 ASM。4.1 数据库软件静默安装一份可以抄的 db_install.rsp先解压官方 db_home zip再用 runInstaller 静默安装cd /u01/software unzip -q LINUX.X64_193000_db_home.zip -d /u01/app/oracle/product/19.0.0/dbhome_1 chown -R oracle:oinstall /u01/app/oracle su - oracle cd /u01/app/oracle/product/19.0.0/dbhome_1 ./runInstaller -silent -responseFile /home/oracle/db_install.rspdb_install.rsp 关键参数如下oracle.install.optionINSTALL_DB_SWONLY UNIX_GROUP_NAMEoinstall INVENTORY_LOCATION/u01/app/oraInventory ORACLE_HOME/u01/app/oracle/product/19.0.0/dbhome_1 ORACLE_BASE/u01/app/oracle oracle.install.db.InstallEditionEE oracle.install.db.OSDBAdba oracle.install.db.OSOPERoper oracle.install.db.OSBACKUPDBAbackupdba oracle.install.db.OSDGDBAdgdba oracle.install.db.OSKMDBAkmdba oracle.install.db.OSRACDBAracdba SECURITY_UPDATES_VIA_METALINKfalseINSTALL_DB_SWONLY 表示只装软件不建库库交给 dbca。ORACLE_HOME 与 grid 的 home 分开避免权限和 PATH 互相干扰。OSDGDBA、OSKMDBA、OSRACDBA 这些组在上一章已经建好少任何一个 runInstaller 都会在 precheck 处报错。安装结束记得用 root 执行 root.sh。然后验证 sqlplus 可用su - oracle sqlplus / as sysdba此时没有数据库实例SQL*Plus 能起来就说明软件安装成功。连接时显示一个 idle instance 是正常的不用慌。4.2 dbca -silent 建库到 ASM 的最小命令dbca 静默建库一条命令到位su - oracle export ORACLE_HOME/u01/app/oracle/product/19.0.0/dbhome_1 export PATH$ORACLE_HOME/bin:$PATH dbca -silent -createDatabase \ -templateName General_Purpose.dbc \ -gdbName orcl \ -sid orcl \ -createAsContainerDatabase false \ -storageType ASM \ -diskGroupName DATA \ -recoveryAreaName FRA \ -recoveryAreaSize 300G \ -totalMemory 8192 \ -sysPassword Oracle123 \ -systemPassword Oracle123 \ -characterSet AL32UTF8 \ -nationalCharacterSet AL16UTF16 \ -emConfiguration NONE-createAsContainerDatabase false 创建的是非 CDB。19C 里非 CDB 已经标记为不建议新用但对于单实例测试库和从 11g/12c 迁移过来的场景它更省事。-storageType ASM 加 -diskGroupName DATA 决定数据文件落在 DATA这是“文件真正进 ASM”的关键。-recoveryAreaName FRA 启用闪回区后面 Data Guard 的归档和备库接收文件都会用到 FRA。密码复杂度是这里最容易翻车的地方。sysPassword 和 systemPassword 不能相同且必须同时包含大写、小写和数字长度至少 8 位。报错信息里会直接提示密码复杂度不符合要求不用反复试按这个规则改就行。建库失败时看 $ORACLE_BASE/cfgtoollogs/dbca/orcl/ 下的日志不要只盯着终端输出。我遇到过的静默建库失败大多是 ASM 磁盘组的兼容版本和 19C dbca 不匹配或者磁盘组空间不足。4.3 建库后验证数据文件和控制文件都在 ASM 里建完库后用 sqlplus 验证文件位置sqlplus / as sysdba SQL show parameter db_recovery_file_dest; SQL show parameter spfile; SQL select name from v$datafile;show parameter spfile 是 Oracle 19C sql plus show 命令里实用性很高的一条。如果输出显示 DATA/ORCL/PARAMETERFILE/spfile.xxx.xxx说明参数文件已经在 ASM 里。v$datafile 的 name 字段开头是 DATA/ORCL/DATAFILE说明数据文件也正确落到了 ASM。这里补一句经验数据库文件一旦落到 ASM就要彻底放弃从文件系统直接维护的思路不要在 Linux 层面对 ASM 文件做 cp。备份走 rman 的 backup as backupsetformat 指定 FRA 或者本地磁盘都行。5. Data Guard 主备搭建与常见问题排查duplicate、redo 传输与 switchover 的典型坑Data Guard 搭建本身不算难主库准备参数和 redo备库只装软件rman duplicate from active database 半小时内就能把备库拉起来。真正花时间的是监听解析、db_unique_name 和 broker 状态这些隐藏项。5.1 主库准备force logging、standby redo 与 log_archive_dest_2先给主库一个独立的 db_unique_namesqlplus / as sysdba alter database force logging; alter system set db_unique_nameorcl_p scopespfile; alter system set log_archive_configDG_CONFIG(orcl_p,orcl_s) scopeboth; alter system set log_archive_dest_1LOCATIONUSE_DB_RECOVERY_FILE_DEST VALID_FOR(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAMEorcl_p scopeboth; alter system set log_archive_dest_2SERVICEorcl_s LGWR SYNC VALID_FOR(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAMEorcl_s COMPRESSIONENABLE scopeboth; alter system set log_archive_dest_state_2ENABLE scopeboth; alter system set fal_clientorcl_p scopeboth; alter system set fal_serverorcl_s scopeboth; alter system set standby_file_managementAUTO scopeboth; shutdown immediate; startup;db_unique_name 是 Data Guard 里最重要的身份标识主备必须不同。log_archive_dest_2 里的 SERVICEorcl_s 不是数据库名是 tnsnames.ora 里的别名解析不到就传不了日志。LGWR SYNC 对应零数据丢失同步模式主库提交要等备库确认如果主备机房相距较远、网络 RTT 大于 5ms改成 LGWR ASYNC 能明显降低提交延迟。再创建 standby redo log。组数建议比在线 redo 多一组select group#, bytes from v$log; alter database add standby logfile group 11 (DATA) size 2G; alter database add standby logfile group 12 (DATA) size 2G; alter database add standby logfile group 13 (DATA) size 2G; alter database add standby logfile group 14 (DATA) size 2G;standby redo 放在 DATA 而不是 FRA避免备库在接收日志时频繁写闪回区导致空间水位异常。如果没有 standby redoData Guard 也可以工作但会退化为在备库直接归档apply 延迟会明显变大。tnsnames.ora 主备两边都要写全两个别名。注意 SERVICE_NAME 写 db_unique_name不是原库名# 主备的 $ORACLE_HOME/network/admin/tnsnames.ora orcl_p (DESCRIPTION(ADDRESS(PROTOCOLTCP)(HOST172.16.1.10)(PORT1521))(CONNECT_DATA(SERVICE_NAMEorcl_p))) orcl_s (DESCRIPTION(ADDRESS(PROTOCOLTCP)(HOST172.16.1.11)(PORT1521))(CONNECT_DATA(SERVICE_NAMEorcl_s)))配完用 tnsping orcl_s 验证两边都能解析这一步不过后面 duplicate 必然报错。5.2 备库端软件只装不建库再用 rman duplicate备库只安装数据库软件跑 db_install.rsp 之后不建库。然后配置 listener.ora 静态注册这里容易漏# 备库的 $ORACLE_HOME/network/admin/listener.ora SID_LIST_LISTENER (SID_LIST (SID_DESC (GLOBAL_DBNAME orcl_s) (ORACLE_HOME /u01/app/oracle/product/19.0.0/dbhome_1) (SID_NAME orcl) ) ) LISTENER (DESCRIPTION(ADDRESS(PROTOCOLTCP)(HOST172.16.1.11)(PORT1521)))lsnrctl reload 之后从主库执行 tnsping orcl_s 应该能 Ping 通。备库实例此时是空的sqlplus / as sysdba 连接会进入 idle 状态这正常。然后在主库侧执行 rman duplicaterman target sys/Oracle123orcl_p auxiliary sys/Oracle123orcl_sRMAN duplicate target database for standby from active database spfile parameter_value_convert DB_UNIQUE_NAMEorcl_p,orcl_s set db_unique_nameorcl_s set control_filesDATA set db_recovery_file_destFRA nofilenamecheck;from active database 会通过网络从主库直接拉数据文件不需要先做一次备份。spfile 子句让备库从主库复制参数文件并做替换这里有很多细节点set control_filesDATA 必须写否则备库控制文件会落到本地文件系统起来之后状态就不是 standby control fileData Guard 会一直报错。ASM 环境下 nofilenamecheck 也要带因为文件由 OMF 管理不需要也不允许做 db_file_name_convert 这类目录替换。duplicate 完成后在备库启动日志应用sqlplus / as sysdba alter database recover managed standby database using current logfile disconnect from session; select process, status from v$managed_standby;看到 MRP0 进程且状态为 WAIT_FOR_LOG 或 APPLYING_LOG说明同步已经开始。5.3 switchover 演练用 dgmgrl 而不是手工 SQL手工 SQL 做 switchover 很容易漏掉 with session shutdown导致切换后会话残留。建议直接用 broker。主备库先启用 brokeralter system set dg_broker_starttrue scopeboth;然后建配置dgmgrl sys/Oracle123orcl_p DGMGRL create configuration dg_orcl as primary database is orcl_p connect identifier is orcl_p; DGMGRL add database orcl_s as connect identifier is orcl_s maintained as physical; DGMGRL enable configuration; DGMGRL show configuration;show configuration 的输出里Primary 和 Physical Standby 两行的 Database Status 都应该是 SUCCESS。有任何一行不是先解决再往后走。switchover 演练一条命令DGMGRL switchover to orcl_s;broker 会处理日志传输方向切换、原主库转为备库不用手动停 MRP。failover 演练是另一条命令DGMGRL failover to orcl_s;failover 后原主库会从配置里被剔除恢复时需要重新 reinitialize所以生产上做 failover 演练要预留足够时间。5.4 现象、原因、解决5 条 Data Guard 踩坑记录第一条备库同步中断v$archive_gap 有断层序列号。现象是 MRP0 停住select * from v$archive_gap 返回记录。原因大多是 FRA 空间写满或主库的 log_archive_dest_state_2 被人为 disable。解决是先清备库旧归档释放空间主库执行 alter system switch logfile 推动日志然后备库重新执行 recover managed standby database等 FETCH 进程把 gap 补上。第二条rman duplicate 报 ORA-17627。现象是连接 auxiliary 实例失败duplicate 一开始就退出。原因多数是备库监听没有启动或者 tnsnames.ora 里的 orcl_s 指向的 HOST 写成了主库 IP。解决是备库执行 lsnrctl status 确实监听正常主库执行 tnsping orcl_s 确认解析到 172.16.1.11改完 listener 后重新 lsnrctl reload。第三条asmca 里看不到任何 ASM 磁盘。现象是 asmca 候选盘列表为空或者 /dev/sdb 的属主是 root:disk 而不是 grid:asmadmin。原因是 udev 规则没有生效也可能是虚拟机重启后 WWID 变化导致 RESULT 匹配不上。解决是重新跑 scsi_id 拿新 WWID 更新 99-oracle-asm.rules再 udevadm control --reload-rules 和 udevadm trigger。第四条switchover 之后新备库 apply 延迟持续上涨。现象是角色切换正常但新备库的 transport lag 和 apply lag 一直不降。原因是新备库的 log_archive_dest_2 配置里 SERVICE 仍然指向自己。解决是在新备库执行 alter system set log_archive_dest_2 指向新主库的 SERVICE 别名同时把 fal_server 改成新主库。第五条dgmgrl show configuration 报 ORA-12514 或 Database Status 为 ERROR。现象是配置里备库连接失败。原因是 listener.ora 静态注册里 SID_NAME 或 GLOBAL_DBNAME 与 db_unique_name 不一致broker 无法用服务名连上备库。解决是核对 listener.ora 里的 GLOBAL_DBNAME 与 db_unique_name 一致lsnrctl reload 后重新 show configuration。6. 验证与进阶用 dgmgrl 和两条 SQL 把 Data Guard 体检一遍6.1 show configuration 与 v$dataguard_stats 组合验证日常巡检我习惯先跑一次 dgmgrl show configuration确认 Broker 视角整体健康再进备库查 v$dataguard_stats 看真实延迟dgmgrl sys/Oracle123orcl_p DGMGRL show configuration; DGMGRL show database orcl_s;show database orcl_s 的输出里重点看 LogXptMode、ApplyLagTime、TransportLagTime。如果 ApplyLagTime 显示为 0 秒说明备库追日志到达当前实时位置。生产环境把 warning 阈值设成 1 分钟超过这个值基本可以判定网络或归档链路出了问题。6.2 两条 SQL 判断真实同步状态备库执行select name, value, unit from v$dataguard_stats where name in (transport lag,apply lag); select process, status, sequence# from v$managed_standby where processMRP0;第一条里 transport lag 是日志从主库生成到传出的延迟apply lag 是传到备库到应用完成的延迟两个值都是 0 才说明主备在实时同步。第二条确认 MRP0 正在工作status 为 WAIT_FOR_LOG 或 APPLYING_LOG 都正常为 STOP 就是应用停了。主库侧查select dest_name, status, error from v$archive_dest where dest_id2;status 为 VALID 且 error 为空说明日志传输通道健康。error 里有 ORA- 开头的文字基本可以直接照报错去定位是网络还是空间问题。6.3 把 switchover 演练定成季度任务个人习惯是每季度做一次完整的 switchover 再切回来。Data Guard 平时再健康不真正演练就永远不知道监听解析、角色切换时应用会话残留这些黑匣子问题。show configuration 显示 SUCCESS 只能说明配置没问题不能证明切换流程没人敢动。每次演练完把 dgmgrl 的输出和切换时间点记到值班手册里下次故障做 failover 时就有底。希望帮到你。本文还有配套的精品资源点击获取