简介面向数据库运维与架构实施人员提供 RHEL 7.6 环境下 Oracle 19C 数据库与 ASM Data Guard 的完整安装指南。内容覆盖最低硬件要求4核 CPU、20G 内存、200G 存储、双节点部署规划、安装目录与网络地址配置、系统依赖包检查、GI 与 Oracle 软件安装、ASM 磁盘组配置及 Data Guard 主从复制等关键环节配有命令示例和检查清单可帮助读者按步骤落地高可用数据库环境规避路径创建、权限设置等常见前置问题。文档为单份 PDF压缩包大小 4.68MB内容紧凑便于查阅。目前已有 702 人学习下载适合需要从零搭建 Oracle 19CASMData Guard 的工程师作为操作参考。1. RHEL 7.6 上装一套带 ASM 的 Oracle 19C DG这套组合到底解决什么问题如果你要在 RHEL 7.6 上部署 Oracle 19C同时希望数据文件落到 ASM 而不是文件系统并且给数据库配一个真正的容灾备库那这篇笔记就是冲这个组合来的。这里说的不是单机装个库跑测试而是一条完整链路RHEL 7.6 系统准备、Grid Infrastructure 装 ASM、19C 静默建主库、再用 DataGuard 把库克隆到备库。RHEL 7.6 和 19C 的组合在电网、金融、制造行业存量环境里非常常见这套东西装完你等于把生产环境最常见的一套高可用架构在本地完整复现了一遍。直接说结论这套安装链路里最耗时间的不是数据库软件本身而是 ASM 的磁盘权限、内核参数和 DG 的参数匹配。很多人卡在 crsctl 起不来、RMAN duplicate 报 ORA-17503、备库日志不应用全部是前期细节没对齐。下面按我实际安装的顺序写每一步给命令、给参数、给翻车现场照着敲基本能一次走通。2. RHEL 7.6 系统准备依赖包、内核参数与用户配置一次到位2.1 先解决 RHEL 7.6 的兼容性为什么 libnsl 决定安装成败RHEL 7.6 内置的 glibc 版本是 2.17Oracle 19C 的官方要求是 RHEL 7.5 以上理论上满足但有个细节折腾过很多人19C 的安装程序在检查阶段会去调 libnsl 和 libaio。RHEL 7.6 的最小化安装默认不带 libnsl而 Oracle 的 sqlplus、监听器在运行时要链接这个库。你如果直接跑 runInstaller会看到类似libnsl.so.1 cannot open shared object file的报错然后安装程序停在 prerequisite 检查那一步。常见做法是先装oracle-database-preinstall-19c这个包它会一次性带上 19C 需要的所有依赖。但 RHEL 7.6 上这个包不一定在默认源里所以我更习惯手动 yum 安装关键包顺手把 libnsl 一起装掉yum install -y binutils compat-libcap1 compat-libstdc-33 \ gcc gcc-c glibc glibc-devel ksh libaio libaio-devel \ libgcc libstdc libstdc-devel libXi libXtst make sysstat \ unixODBC unixODBC-devel libnsl libnsl-devel这段命令里的libnsl和libnsl-devel是 RHEL 7.6 最容易漏的两个包。判断标准很简单安装完成后在命令行敲一句rpm -qa | grep libnsl能查到libnsl-2.17-...el7_6.6就算过了。还有一个隐藏坑是compat-libstdc-33这个包装不上也不影响数据库启动但 19C 的relink阶段会慢所以尽量装上。2.2 内核参数、limits 与目录规划内核参数的套路是固定的但数值别凭感觉写。Oracle 建议值里最容易被忽略的是vm.swappinessRHEL 7.6 默认 30数据库服务器建议 10 以下否则系统空闲内存会被换到 swapASM 实例和数据库实例的响应都会变差。下面是我每次装 19C 都会写进/etc/sysctl.conf的完整参数fs.aio-max-nr1048576 fs.file-max6815744 kernel.sem250 32000 100 128 net.ipv4.ip_local_port_range9000 65500 net.core.rmem_default262144 net.core.rmem_max4194304 net.core.wmem_default262144 net.core.wmem_max1048576 vm.swappiness10 vm.dirty_background_ratio3 vm.dirty_ratio80这里三个参数要单独说。kernel.sem四个值分别对应信号量每个集合最大值、系统最大信号量数、每个信号量最大操作数、系统最大集合数照抄就好。net.core.rmem_max和wmem_max影响的是 DG 场景下主备库之间的网络传输如果备库应用日志经常延迟先看这两个值是不是太小。vm.dirty_ratio80是让内核尽量攒够脏页再写盘对大批量日志写入有好处但别在机械盘上配得过大数据落盘延迟反而明显。limits.conf 也一起配掉不然数据库跑几天就会出现ORA-12518: TNS:listener could not hand off client connectioncat /etc/security/limits.conf EOF grid soft nproc 2047 grid hard nproc 16384 grid soft nofile 1024 grid hard nofile 65536 oracle soft nproc 2047 oracle hard nproc 16384 oracle soft nofile 1024 oracle hard nofile 65536 oracle soft stack 10240 oracle hard stack 32768 EOF目录规划上我习惯把 Grid 和 Oracle 的基目录分开Grid 装在/u01/app/gridOracle 软件装在/u01/app/oracle。两个目录的属主不要搞混rhel 7.6 里 Grid 目录属主是grid:oinstallOracle 基目录属主是oracle:oinstall。这两个目录下的admin、cfgtoollogs、product子目录权限错乱后面 root.sh 会直接报错。2.3 创建用户和 ASM 磁盘的 udev 规则RHEL 7.6 上做 ASM我一律建议用 udev 而不是 asmlib。asmlib 在 RHEL 7 上需要额外装内核模块版本跟不上内核就白搭Oracle 官方在 19C 里对 asmlib 的支持也在弱化。用 udev 的话磁盘是谁的、权限多少完全由规则文件控制出问题也好查。先建用户和组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,asmdba,backupdba,dgdba,kmdba,oper oracle useradd -u 54322 -g oinstall -G dba,asmdba,asmoper,asmadmin grid注意grid用户的组的顺序asmadmin必须出现在组列表里因为 Grid Infrastructure 安装时要检查 grid 用户是否有 asmadmin 权限否则 asmca 创建磁盘组那一步会直接报权限不足。ASM 磁盘规则针对块设备用KERNEL匹配下面是一个典型的三块盘配置按/dev/sdb、/dev/sdc、/dev/sdd三个设备写vi /etc/udev/rules.d/99-oracle-asm.rulesKERNELsdb1, OWNERgrid, GROUPasmadmin, MODE0660 KERNELsdc1, OWNERgrid, GROUPasmadmin, MODE0660 KERNELsdd1, OWNERgrid, GROUPasmadmin, MODE0660写完规则后执行/sbin/udevadm control --reload-rules /sbin/udevadm trigger --typedevices --actionchange这里有个很现实的坑如果磁盘还没有分区只写了/dev/sdb这种整盘设备规则匹配不到。我一般先fdisk /dev/sdb建一个分区把分区做成8eLinux LVM 也可以Oracle 不关心是不是 LVM 卷再按sdb1这样的分区名写规则。检查规则是否生效执行ls -l /dev/sdb1看到属主是grid:asmadmin而不是root:disk就成功了。权限不对后面asmca建磁盘组时磁盘盘符列表就是空的你会以为磁盘没插好其实只是 udev 没触发。3. 安装 Grid Infrastructure 并完成 ASM把存储底座装到 RHEL 7.6 上3.1 磁盘组规划和 gridSetup.sh 静默参数Grid Infrastructure 装的是 ASM 实例和集群资源管理19C 支持单节点集群和 RAC 两种部署。本文场景是 DataGuard主备各一套单实例 ASM 就够了但 ASM 实例仍然是靠集群件CRS拉起来的。磁盘组规划上我的建议是至少三个组CRS放 OCR 和 Voting FileDATA放数据文件FRA放归档日志和闪回区。别把 OCR 和数据库文件混在一个磁盘组里生产环境一旦 OCR 磁盘组 IO 抖动整个集群资源都会受影响。磁盘组用途冗余策略建议大小CRSOCR、Voting FileEXTERNAL1 块 20GDATA数据文件、控制文件、redoEXTERNAL2 块 50GFRA归档日志、闪回区EXTERNAL1 块 100G冗余策略这里用 EXTERNAL 是因为测试环境没有真正的硬件 RAID 之外的冗余。如果服务器本身带 RAID 卡EXTERNAL 没问题裸盘场景想防坏盘就选 NORMAL但 NORMAL 至少要 3 块盘且空间翻倍别在空间紧张时硬上。gridSetup.sh 静默安装的 responseFile 是安装介质里GridSetup.rsp模板改出来的核心参数如下./gridSetup.sh -silent -responseFile /u01/app/grid/grid.rspgrid.rsp里必须改的这一段我做成了最小可用版本oracle.install.optionCRS_CONFIG ORACLE_BASE/u01/app/grid ORACLE_HOME/u01/app/19.0.0/grid oracle.install.asm.OSDBAasmdba oracle.install.asm.OSOPERasmoper oracle.install.asm.OSASMasmadmin oracle.install.asm.diskGroup.nameCRS oracle.install.asm.diskGroup.redundancyEXTERNAL oracle.install.asm.diskGroup.disks/dev/sdb1 oracle.install.asm.diskGroup.disksDiscoveryString/dev/sd* oracle.install.asm.monitorPasswordoracle oracle.install.asm.SYSASMPasswordoracledisksDiscoveryString这个参数建 CRS 磁盘组时一定不能被/dev/sdb1精确路径迷惑它对后面的 ASM 实例发现磁盘至关重要/dev/sd*才能保证 asmca 后续创建 DATA、FRA 时能扫到同一组设备。SYSASMPassword和monitorPassword如果这里不设安装程序会在最后停下来让你交互输入所以静默模式这两个必须给。root.sh 是整个安装过程最容易卡住的环节。执行root.sh前确认/etc/hosts里本机主机名解析和hostname输出一致。RHEL 7.6 上如果出现Oracle Grid Infrastructure 19c has not been configured或者 root.sh 卡在Creating CRS-OCR keys八成是 hosts 文件把主机名解析到了127.0.0.1而监听和 GNS 在尝试解析实际 IP。把主机名对应到实际 IP放在 hosts 第一行然后重新跑 root.sh 的-execute参数。3.2 用 asmca 命令创建 DATA 和 FRA 磁盘组CRS 组建好之后ASM 实例已经在跑了。DATA 和 FRA 两个组不要再用图形界面慢慢点asmca 提供了静默建组的参数命令格式很固定asmca -silent -createDiskGroup \ -diskGroupName DATA \ -disk /dev/sdc1,/dev/sdd1 \ -redundancy EXTERNAL \ -compatible.asm 19.0.0 \ -compatible.rdbms 19.0.0这条命令创建DATA组把/dev/sdc1和/dev/sdd1两块盘划进去。-compatible.asm和-compatible.rdbms两个参数要显式指定不指定的话 asmca 默认按当前版本写倒也不会出问题但二进制兼容性没有显式设置稳妥。FRA 组同理asmca -silent -createDiskGroup \ -diskGroupName FRA \ -disk /dev/sde1 \ -redundancy EXTERNAL \ -compatible.asm 19.0.0 \ -compatible.rdbms 19.0.0如果asmca扫不到磁盘先执行/usr/sbin/asmcmd afd_scan或者ls -l /dev/sd*看 udev 结果再确认 grid 用户对设备有没有 0660 权限。这块翻车概率极高九成 ASM 建组失败都是权限链断了。3.3 验证 ASM 状态crsctl、asmcmd 与常见状态解读安装完最怕的是看起来装完了实际集群资源没起来。我的验证顺序是先看 CRS 再看 ASM 磁盘组crsctl stat res -t输出里ora.asm、ora.cssd、ora.diskmon三个资源状态应为ONLINE。如果ora.asm是 OFFLINE直接看 ASM 告警日志路径在/u01/app/grid/diag/asm/asm/ASM1/trace/alert_asm1.log。我的血泪经验是grid 用户的环境变量里ORACLE_SIDASM1如果没设sqlplus 连进去都不知道连的是哪个实例。磁盘组状态用 asmcmd 看asmcmd lsdg asmcmd lsblklsdg输出里重点关注State列MOUNTED才是正常。lsblk能直观看到每个磁盘组下挂了哪些盘、盘的大小和空闲空间。这套命令在主库和备库都要跑一遍DG 配置完成后备库的 DATA 组和 FRA 组的挂载状态直接决定日志能否应用。4. 19C 数据库安装与建库主库起来备库才有得复制4.1 19C 数据库软件静默安装与 DBCA 建库Grid 装完后数据库软件单独装。19C 的runInstaller走静默模式responseFile 模板在安装介质database/response/db_install.rsp我习惯先拷出来改。最小参数如下./runInstaller -silent -responseFile /u01/app/oracle/db19c.rsp -ignorePrereqoracle.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.OSDBA_GROUPdba oracle.install.db.OSBACKUPDBA_GROUPbackupdba oracle.install.db.OSDGDBA_GROUPdgdba oracle.install.db.OSKMDBA_GROUPkmdba oracle.install.db.OSRACDBA_GROUPdba-ignorePrereq不是随便加的。RHEL 7.6 的 glibc 版本在 19C 官方列表里是“已认证”但个别补丁包缺失会导致 prerequisite 检查不过比如compat-libstdc-33在有些最小化安装上就是装不上。加上-ignorePrereq可以在确认依赖基本满足的情况下跳过代价是后面 relink 阶段如果报错你得回头补包。装完记得以 root 执行$ORACLE_HOME/root.sh漏了这一步数据库软件永远起不来。建库用 DBCA 静默模式存储类型直接选 ASMdbca -silent -createDatabase \ -templateName General_Purpose.dbc \ -gdbname ORCL -sid ORCL \ -storageType ASM \ -diskGroupName DATA \ -recoveryAreaDestination FRA \ -recoveryAreaSize 102400 \ -characterSet AL32UTF8 \ -memoryPercentage 40 \ -emConfiguration NONE \ -sampleSchema false-memoryPercentage 40是让 DBCA 按物理内存的 40% 自动设置SGA_TARGET和PGA_AGGREGATE_TARGET。这里要提前确认/dev/shm大小至少得大于这个 SGA 目标值。RHEL 7.6 默认/dev/shm是物理内存一半如果机器内存 32G、SGA 给了 12G 以上shm 不够就报ORA-00845。建库时间大概十分钟日志尾部看到Database creation complete才算结束。4.2 主库归档开启与 DG 参数准备DataGuard 的底座是归档日志主库必须开归档否则 DG 配置无从谈起SQL startup mount; SQL alter database archivelog; SQL alter database open; SQL archive log list;archive log list输出里Automatic archival应为Enabled。接下来改一系统的 DG 参数。主库上先设置db_unique_name默认就是ORCL为了清晰我保持它不变SQL alter system set db_unique_nameORCL scopespfile; SQL alter system set log_archive_configDG_CONFIG(ORCL,ORCLDG) scopeboth; SQL alter system set log_archive_dest_1LOCATIONUSE_DB_RECOVERY_FILE_DEST VALID_FOR(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAMEORCL scopeboth; SQL alter system set log_archive_dest_2SERVICEorcldg LGWR SYNC VALID_FOR(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAMEORCLDG scopeboth; SQL alter system set standby_file_managementAUTO scopeboth; SQL alter system set fal_serverORCLDG scopeboth;log_archive_dest_2里的SERVICEorcldg是 tnsnames.ora 里的网络服务名不是 SID也不是数据库名。LGWR SYNC表示主库日志写进程同步传送到备库这是 DataGuard 最大保护模式的基础设置如果网络延迟超过几毫秒主库提交会受传输影响测试环境用LGWR ASYNC更稳。fal_server是备库拉取归档时连接的主库服务名这里先填上后面备库 pfile 里还会再出现一次。主库参数是写进 spfile 的alter system set ... scopespfile的参数要重启实例才生效。所以建议先把下面要做的 pfile 导出和这两档参数一起操作减少重启次数。4.3 备库安装与初始化参数pfile 修改是 DG 成败分水岭备库不是重新安装一遍主库而是复刻主库的软件、设置不同的db_unique_name。备库的 Grid 和 19C 软件安装路径要跟主库一致磁盘组名也要一致否则后面RMAN duplicate时路径解析会乱。备库软件装好后用主库生成的 pfile 作为模板。在主库执行SQL create pfile/tmp/initORCL.ora from spfile;把/tmp/initORCL.ora拷贝到备库的$ORACLE_HOME/dbs/initORCLDG.ora然后改这几个关键参数。备库 pfile 必须是initORCLDG.ora而不是initORCL.ora因为备库的实例名不一样Oracle 启动时按ORACLE_SID找对应的 pfile# 只列出需要改的部分 *.db_unique_nameORCLDG *.db_nameORCL *.log_archive_configDG_CONFIG(ORCL,ORCLDG) *.log_archive_dest_1LOCATIONUSE_DB_RECOVERY_FILE_DEST VALID_FOR(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAMEORCLDG *.log_archive_dest_2SERVICEorcl LGWR SYNC VALID_FOR(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAMEORCL *.fal_serverORCL *.standby_file_managementAUTO *.control_filesDATA/ORCLDG/controlfile/current.260.1234567891 *.db_create_file_destDATA *.db_recovery_file_destFRAcontrol_files这里不要直接抄主库的路径主库控制文件路径在备库上对应的 ASM 磁盘组有相同的目录结构。更稳妥的做法是设好db_create_file_dest让备库自己创建控制文件路径。备库启动到 nomount 状态验证 pfile 能被正确读取export ORACLE_SIDORCLDG sqlplus / as sysdba SQL startup nomount;能顺利nomountpfile 语法和路径解析就没问题。这里报ORA-01565基本都是控制文件路径写死导致去掉control_files靠db_create_file_dest自动解决。4.4 RMAN duplicate from active database一条命令把主库变备库备库 pfile 就绪后最后一步就是 RMAN 克隆。这种在线克隆方式不依赖备份集直接从运行中的主库拉数据文件是 19C 下搭 DG 最推荐的做法。先在备库的 listener.ora 里加上静态注册保证 RMAN 通过网络服务名连到备库SID_LIST_LISTENER (SID_LIST (SID_DESC (GLOBAL_DBNAME orcldg) (ORACLE_HOME /u01/app/oracle/product/19.0.0/dbhome_1) (SID_NAME ORCLDG) ) )主备库的 tnsnames.ora 里要互配两个服务名主库能连orcldg备库能连orcl。两边的 listener 都重载后用tnsping双向测通。很多 duplicate 卡在ORA-12514就是因为备库静态监听没配动态注册又没起来。执行 RMAN duplicateexport ORACLE_SIDORCL rman target sys/oracleorcl auxiliary sys/oracleorcldgRMAN 里执行RMAN duplicate target database for standby from active database;注意这里不加nofilenamecheck前提是主备库的 ASM 磁盘组路径完全一致DATA 组都在DATA下。如果主备磁盘组不同名必须加spfile parameter_value_convertDATA_MAIN,DATA_BAK和db_file_name_convert否则 duplicate 会在文件路径解析时报ORA-17503。命令执行完后备库实例会自动启动到 mountRMAN 会把 standby control file 一并创建。复制完成后在备库执行SQL alter database recover managed standby database using current logfile disconnect from session;先确认同步开启再启用 Broker。Broker 是 DG 的集中管理入口切换演练、状态巡检都靠它dgmgrl sys/oracleorcl DGMGRL create configuration dgtest as primary database is orcl connect identifier is orcl; DGMGRL add database orcldg as connect identifier is orcldg; DGMGRL enable configuration; DGMGRL show configuration;show configuration输出里两个数据库的状态都应该是Success备库的Intended State为STANDBY。到这里主库、ASM、DG 三层都通了整套环境就算落地。5. Dataguard 搭建的边界与参数陷阱主备同步中的 4 个常见翻车现场5.1 现象RMAN duplicate 后备库一直处于 mount日志不应用后面具体写一发完整的 DG 验证章节。为了避免结构重复我把以下内容并入到第 5 章作为避坑与常见问题章节其下包含 5 个具体翻车现场。6. 避坑与常见问题RHEL 7.6 19C ASM Dataguard 的 5 个翻车现场6.1 现象crsctl start crs 起不来CRS-4639 报错现象执行crsctl start crs后CRS 进程反复拉起又失败crsctl stat res -t里ora.cssd永远是 OFFLINE。原因RHEL 7.6 的 udev 规则没生效/dev/sdb1属主仍是root:diskASM 实例无权访问 OCR 磁盘。另一个高频原因是/dev/sdb1这种分区设备没有在/etc/udev/rules.d里配置规则写的是/dev/sdb整盘设备但实际分区名是/dev/sdb1匹配不上。解决检查ls -l /dev/sd*确认设备属主不匹配就重新执行udevadm control --reload-rules udevadm trigger。规则里统一按分区名写别写整盘同时确认 grid 用户对设备有 0660 权限。若权限正确仍起不来看/u01/app/grid/diag/asm/asm/ASM1/trace/alert_asm1.log里面会明确写ORA-15032或权限拒绝的详细行。6.2 现象DBCA 建库报 ORA-00845内存初始化失败现象dbca执行到 60% 左右报ORA-00845: MEMORY_TARGET not supported on this system数据库创建失败。原因19C 启动时尝试把 SGA 映射到/dev/shm而 RHEL 7.6 默认/dev/shm只有物理内存的一半甚至某些云镜像只有 64M。memory_target超过/dev/shm大小Oracle 直接拒绝启动。解决把/dev/shm重新挂载大一些比如 16Gmount -o remount,size16G /dev/shm同时写入/etc/fstab让重启后依然生效。如果不想依赖/dev/shm可以在 pfile 里把memory_target设小或者改用sga_target加pga_aggregate_target的经典分配方案。6.3 现象RMAN duplicate 时报 ORA-17503数据文件创建失败现象duplicate target database for standby from active database执行到一半报ORA-17503: ksfdopn:2 Failed to open file DATA/ORCL/datafile/...RMAN 进程中断。原因几乎都是备库 ASM 磁盘组名不对或主备磁盘组路径不一致。比如主库数据存在DATA_MAIN备库 ASM 只建了DATARMAN 拿到主库的路径后在备库解析不了。解决主备库磁盘组名保持一致这是最省心的方案。如果确实做不到在 duplicate 命令里带db_file_name_convert和log_file_name_convert把主库路径映射到备库路径。DG 场景下强烈不建议两边磁盘组名不一致日常维护和切换时路径映射会让你头大。6.4 现象备库 mounted 但 apply lag 一直增长v$dataguard_status 报错现象show configuration显示备库状态Success但select name,value,unit from v$dataguard_stats where name like %lag%;里apply lag持续增大备库一直没有应用日志。原因备库没建 standby redo log主库传过来的日志只能写到FRA的 arc 目录无法循环应用到备库数据文件。另一常见原因是log_archive_dest_2配置了SYNC但备库已经落后太多网络传输恢复后需要手工追赶。解决在备库上为每个线程增加一组 standby redo log数量要比主库的 online redo group 多 1 组大小和主库 online redo 保持一致SQL alter database add standby logfile group 4 size 512M; SQL alter database add standby logfile group 5 size 512M; SQL alter database add standby logfile group 6 size 512M;加上 standby redo 后再手工启动日志应用SQL alter database recover managed standby database using current logfile disconnect from session;随后观察apply lag在几分钟内回落。备库没有 standby redo 时DG 链路能通但永远追不上这是最隐蔽的配置缺口。6.5 现象备库日志传输显示ORA-12514无法连接到备库服务现象主库v$archive_dest_status里dest_id2的status不是VALID错误信息是ORA-12514: TNS:listener does not currently know of service requested in connect descriptor。原因备库 listener 没有静态注册动态注册因为备库没完全启动而没成功。DG 场景下 RMAN duplicate 和主库传输都要求备库有静态监听。解决在备库listener.ora中填写SID_LIST里面GLOBAL_DBNAME写数据库唯一名orcldgORACLE_HOME写备库的$ORACLE_HOMESID_NAME写ORCLDG。重载监听后先tnsping orcldg通再回主库执行alter system switch logfile;触发一次日志传输看v$archive_dest_status是否变VALID。7. 验证与切换测试把 DG 当生产用之前要做完的动作整套环境装完别急着收工。DG 的意义在切换切换之前至少跑一遍验证和一次演练。验证命令主要看三处数据保护状态、日志传输状态、日志应用状态。dgmgrl sys/oracleorcl DGMGRL show configuration verbose DGMGRL validate database orcldgvalidate database会做一次完整的健康检查包括网络连通、归档传输、备库可恢复性。输出里出现SUCCESS字样的项才合格。show configuration的Protection Mode一栏如果是MaxPerformance说明log_archive_dest_2实际跑的是 ASYNC代码里写的是SYNC的话这里应该是MaxAvailability。不一致就去查备库的 pfile 是不是被 duplicate 过程覆盖了。切换演练是 DG 里最值得做的一次操作。在 DGMGRL 里执行DGMGRL switchover to orcldg;执行后等Switchover succeeded再查show configuration此时ORCLDG应该是PRIMARYORCL变成STANDBY。别急着切回去让备库转主库后跑几分钟每周的巡检 SQL比如查v$log、v$datafile状态。select name,open_mode,database_role from v$database; select group#,status,type from v$log order by 1; select status,count(*) from v$datafile group by status;open_mode为READ WRITE、database_role为PRIMARY日志组状态都落在CURRENT或ACTIVE上才算正常。确认无误后再switchover to orcl切回来。整个切换过程主库不需要停机连接会瞬断一下这就是 DG 的核心价值。我自己的习惯是每次装完这套环境都会把主备两台的v$dataguard_stats查一次留个基线截图。后续巡检时 lag 值哪天突然从个位数涨到几百秒不用翻日志就能第一时间发现。DG 这环境最大的坑永远是“以为配好了”而不是“没配好”。希望这套从系统准备到切换验证的流程能帮你省掉几个通宵。本文还有配套的精品资源点击获取