Oracle 19C Data Guard 实战：RHEL 7.6+ASM 备库搭建与切换全解析

简介：面向Oracle DBA及运维工程师的实操型部署指南，聚焦在RHEL 7.6（Maipo）环境下搭建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 /u01

cat /etc/redhat-release 应该输出 Red Hat Enterprise Linux Server release 7.6；uname -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 识别，而不是依赖盘符。下面是推荐布局：

如果只有一块 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 --system

kernel.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 grid

GID/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-devel

RHEL 7.6 的默认 yum 源里 compat-libcap1 可能找不到，从系统 ISO 的 Packages 目录装 rpm 也能解决，不用纠结必须 yum 成功。还有个细节：Oracle 19C 在 RHEL 7 上建议关闭 Transparent HugePages，否则大页内存管理会对数据库性能和稳定性产生莫名影响：

grubby --update-kernel=ALL --args="transparent_hugepage=never"

重启后验证 /sys/kernel/mm/transparent_hugepage/enabled 输出 should always be never，这一步忘了，后面总会觉得实例卡得没道理。

2.3 网络与主机名：Data Guard 的隐形门槛

Data Guard 主备通信依赖主机名和监听解析，很多坑是前期网络没理清楚。主机名不要用带下划线的名字，历史教训是 broker 和 tnsnames 解析会行为诡异。/etc/hosts 里把主备两台机器都写进去，用静态 IP 不用 DHCP：

cat >> /etc/hosts <<'EOF' 172.16.1.10 primary.example.com primary 172.16.1.11 standby.example.com standby EOF

防火墙策略看现场环境。生产环境不要图省事直接关 iptables，按 org 的端口放行 1521 即可；测试环境可以直接停 firewalld：

systemctl stop firewalld systemctl disable firewalld

Data 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' KERNEL=="sd*", SUBSYSTEM=="block", PROGRAM=="/usr/lib/udev/scsi_id -g -u -d /dev/$name", RESULT=="36000c293092a381a1a75f4d6f6d22819", OWNER="grid", GROUP="asmadmin", MODE="0660" EOF udevadm control --reload-rules udevadm trigger ls -l /dev/sdb

ls -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_SID=+ASM 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.rsp

response file 里安装类型选 Standalone Server（Oracle 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 命令”，实际分两种方式。第一种是 asmcmd：

su - grid export ORACLE_SID=+ASM asmcmd ASMCMD> ls ASMCMD> lsdg

ls 输出里能看到 DATA 和 FRA，说明磁盘组已经在线。第二种是 sqlplus：

sqlplus / 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 到底怎么选

生产环境如果存储层已经有 RAID5 或 RAID10，EXTERNAL 是清爽的选择。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.rsp

db_install.rsp 关键参数如下：

oracle.install.option=INSTALL_DB_SWONLY UNIX_GROUP_NAME=oinstall INVENTORY_LOCATION=/u01/app/oraInventory ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1 ORACLE_BASE=/u01/app/oracle oracle.install.db.InstallEdition=EE oracle.install.db.OSDBA=dba oracle.install.db.OSOPER=oper oracle.install.db.OSBACKUPDBA=backupdba oracle.install.db.OSDGDBA=dgdba oracle.install.db.OSKMDBA=kmdba oracle.install.db.OSRACDBA=racdba SECURITY_UPDATES_VIA_METALINK=false

INSTALL_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 backupset，format 指定 +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_name：

sqlplus / as sysdba alter database force logging; alter system set db_unique_name='orcl_p' scope=spfile; alter system set log_archive_config='DG_CONFIG=(orcl_p,orcl_s)' scope=both; alter system set log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=orcl_p' scope=both; alter system set log_archive_dest_2='SERVICE=orcl_s LGWR SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcl_s COMPRESSION=ENABLE' scope=both; alter system set log_archive_dest_state_2='ENABLE' scope=both; alter system set fal_client='orcl_p' scope=both; alter system set fal_server='orcl_s' scope=both; alter system set standby_file_management='AUTO' scope=both; shutdown immediate; startup;

db_unique_name 是 Data Guard 里最重要的身份标识，主备必须不同。log_archive_dest_2 里的 SERVICE=orcl_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 redo，Data Guard 也可以工作，但会退化为在备库直接归档，apply 延迟会明显变大。

tnsnames.ora 主备两边都要写全两个别名。注意 SERVICE_NAME 写 db_unique_name，不是原库名：

# 主备的 $ORACLE_HOME/network/admin/tnsnames.ora orcl_p = (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=172.16.1.10)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=orcl_p))) orcl_s = (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=172.16.1.11)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=orcl_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=(PROTOCOL=TCP)(HOST=172.16.1.11)(PORT=1521)))

lsnrctl reload 之后，从主库执行 tnsping orcl_s 应该能 Ping 通。备库实例此时是空的，sqlplus / as sysdba 连接会进入 idle 状态，这正常。

然后在主库侧执行 rman duplicate：

rman target sys/'Oracle123'@orcl_p auxiliary sys/'Oracle123'@orcl_s

RMAN> duplicate target database for standby from active database spfile parameter_value_convert 'DB_UNIQUE_NAME=orcl_p','orcl_s' set db_unique_name='orcl_s' set control_files='+DATA' set db_recovery_file_dest='+FRA' nofilenamecheck;

from active database 会通过网络从主库直接拉数据文件，不需要先做一次备份。spfile 子句让备库从主库复制参数文件并做替换，这里有很多细节点：set control_files='+DATA' 必须写，否则备库控制文件会落到本地文件系统，起来之后状态就不是 standby control file，Data 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。主备库先启用 broker：

alter system set dg_broker_start=true scope=both;

然后建配置：

dgmgrl sys/'Oracle123'@orcl_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/'Oracle123'@orcl_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 process='MRP0';

第一条里 transport lag 是日志从主库生成到传出的延迟，apply lag 是传到备库到应用完成的延迟，两个值都是 0 才说明主备在实时同步。第二条确认 MRP0 正在工作，status 为 WAIT_FOR_LOG 或 APPLYING_LOG 都正常，为 STOP 就是应用停了。

主库侧查：

select dest_name, status, error from v$archive_dest where dest_id=2;

status 为 VALID 且 error 为空，说明日志传输通道健康。error 里有 ORA- 开头的文字，基本可以直接照报错去定位是网络还是空间问题。

6.3 把 switchover 演练定成季度任务

个人习惯是每季度做一次完整的 switchover 再切回来。Data Guard 平时再健康，不真正演练就永远不知道监听解析、角色切换时应用会话残留这些黑匣子问题。show configuration 显示 SUCCESS 只能说明配置没问题，不能证明切换流程没人敢动。每次演练完，把 dgmgrl 的输出和切换时间点记到值班手册里，下次故障做 failover 时就有底。希望帮到你。

本文还有配套的精品资源，点击获取