★ FEATURED ARTICLE 简介本资源是一份面向DBA、系统运维工程师及Oracle高可用架构学习者的实战部署指南聚焦RHEL 7.6环境下Oracle 19c单实例ASMData Guard物理备库的端到端搭建。内容覆盖硬件与系统预检4核/20G内存/200G存储、GI与数据库软件版本匹配V981627-01/V981623-01、双节点网络规划10.6.0.139/137、ASM磁盘组配置、主备库参数调优、监听与tnsnames定制、以及Data Guard同步验证等关键环节附详细目录结构、路径创建规范与权限设置要点如chmod 644 /etc/sysconfig/network。资源为1个PDF文件大小4.68MB内容排版清晰、命令可复制、截图与配置片段丰富便于按步骤实操与故障回溯。目前已有703人学习下载适合中高级Oracle技术人员快速构建高可用数据库环境并掌握企业级容灾部署核心技能。1. RHEL 7.6 上跑 Oracle 19c ASM Data Guard不是“能装就行”而是“装完就稳、切不丢数、查不出错”你手头有一套 RHEL 7.6 的两节点虚拟机4核20G内存200G存储目标是搭一套生产级可用的 Oracle 19c 高可用环境——不是单实例凑合用而是主库node2物理备库node2dg双活可切换底层用 ASM 管理磁盘故障时秒级拉起、RPO≈0、RTO2分钟。但现实很骨感Oracle 官方文档写得像天书OUI 图形界面卡在“Discovering disks”不动asmcmd lsdg返回空dgmgrl连不上 standby甚至sqlplus / as sysdba报 ORA-01034。这不是配置漏了是 RHEL 7.6 和 Oracle 19c 在内核参数、udev 绑定、用户权限、时间同步这四个层面存在隐性冲突点——它们不报错但会让 ASM 启不来、DG 同步断、监听连不上。本指南不讲“点击下一步”只拆解真实部署中必须手动干预的 7 个关键断点从/etc/sysctl.conf里shmall和shmmax的字节/页换算陷阱到scsi_id输出带空格导致 udev 规则失效的玄学问题从grid用户memlock限制被 SELinux 悄悄覆盖的血泪经验到DG_BROKER_STARTTRUE却始终不生效的隐藏依赖。适合已部署过单实例 Oracle、但首次接触 ASMDG 的 DBA 或系统工程师——你不需要懂 CRS 内部原理但必须知道哪一行命令改错一个参数就会让整个 Data Guard 变成黑匣子。2. ASM 磁盘准备与 udev 绑定为什么scsi_id输出带空格/dev/asmdisk01就永远不出现ASM 不是直接读/dev/sdc它依赖稳定、一致、权限正确的块设备路径。RHEL 7.6 默认的/dev/sdX命名会因启动顺序、HBA 重置而漂移必须用 udev 绑定为/dev/asmdisk01这类固定名。但实操中80% 的 ASM 启动失败源于scsi_id输出格式和 udev 规则不匹配——这不是配置错误是 Red Hat 对 SCSI 设备标识的实现细节。2.1 获取真实、无空格的 disk ID绕过scsi_id -g -u的坑/usr/lib/udev/scsi_id -g -u /dev/sdc在 RHEL 7.6 上常返回带前导空格或换行符的字符串如 36000c291ca220c52c813c595ffdf14f4而 udev 规则中的RESULT是严格字符串匹配空格不等价于无空格。直接复制粘贴会导致规则永不触发。正确做法是强制清洗输出# 清洗并验证每个磁盘的真实 ID无空格、无换行 for dev in sdc sdd sde sdf; do echo -n /dev/$dev: /usr/lib/udev/scsi_id -g -u -d /dev/$dev | tr -d [:space:] done逻辑说明tr -d [:space:]删除所有空白字符空格、制表符、换行确保输出为纯十六进制字符串。-d参数指定删除模式[:space:]是 POSIX 字符类比sed s/ //g更可靠能处理不可见控制符。预期输出每行末尾无空格/dev/sdc: 36000c291ca220c52c813c595ffdf14f4 /dev/sdd: 36000c29d82b62077ca6ced88065bfc1f /dev/sde: 36000c29a2d05c23b4ca757912c0bc9ca /dev/sdf: 36000c296d86677032ffcc5b372c28a982.2 编写防错 udev 规则用SYMLINK替代mknod规避设备节点权限丢失原始指南用mknod /dev/asmdisk01 b $major $minor手动创建设备节点但 RHEL 7.6 的 systemd-udevd 服务在重启后可能不重载该节点且chown grid:asmadmin权限易被后续 udev 事件覆盖。更健壮的做法是使用SYMLINK创建符号链接并通过OWNER/GROUP/MODE直接设置权限# 编辑 /etc/udev/rules.d/99-oracle-asm.rules注意文件名以 99- 开头确保优先级最高 KERNELsd*[!0-9], ENV{DEVTYPE}disk, SUBSYSTEMblock, \ PROGRAM/usr/lib/udev/scsi_id -g -u -d /dev/$name, \ RESULT36000c291ca220c52c813c595ffdf14f4, \ SYMLINKasmdisk01, OWNERgrid, GROUPasmadmin, MODE0660 KERNELsd*[!0-9], ENV{DEVTYPE}disk, SUBSYSTEMblock, \ PROGRAM/usr/lib/udev/scsi_id -g -u -d /dev/$name, \ RESULT36000c29d82b62077ca6ced88065bfc1f, \ SYMLINKasmdisk02, OWNERgrid, GROUPasmadmin, MODE0660 KERNELsd*[!0-9], ENV{DEVTYPE}disk, SUBSYSTEMblock, \ PROGRAM/usr/lib/udev/scsi_id -g -u -d /dev/$name, \ RESULT36000c29a2d05c23b4ca757912c0bc9ca, \ SYMLINKasmdisk03, OWNERgrid, GROUPasmadmin, MODE0660 KERNELsd*[!0-9], ENV{DEVTYPE}disk, SUBSYSTEMblock, \ PROGRAM/usr/lib/udev/scsi_id -g -u -d /dev/$name, \ RESULT36000c296d86677032ffcc5b372c28a98, \ SYMLINKasmdisk04, OWNERgrid, GROUPasmadmin, MODE0660参数说明SYMLINKasmdisk01创建/dev/asmdisk01符号链接指向实际设备如/dev/sdc比mknod更轻量、更持久。OWNERgrid GROUPasmadmin直接赋予grid用户和asmadmin组所有权避免chown命令被覆盖。MODE0660设置权限为rw-rw----确保只有grid和asmadmin可读写。反斜杠\续行符使长规则可读udev 会自动拼接。2.3 触发并验证 udev 规则udevadm trigger不等于“立刻生效”执行udevadm trigger --typedevices --actionchange后必须重启 udev 服务并验证设备节点否则ls -l /dev/asmdisk*可能仍为空# 1. 重载规则并重启 udev sudo udevadm control --reload-rules sudo systemctl restart systemd-udevd # 2. 手动触发针对已存在的磁盘 sudo udevadm trigger --subsystem-matchblock --actionchange # 3. 强制重新评估所有块设备关键 sudo udevadm settle --timeout10 # 4. 验证结果 ls -l /dev/asmdisk* # 正确输出应类似 # lrwxrwxrwx. 1 root root 3 Jun 10 14:22 /dev/asmdisk01 - sdc # lrwxrwxrwx. 1 root root 3 Jun 10 14:22 /dev/asmdisk02 - sdd # ...逻辑说明udevadm settle等待所有 udev 事件完成超时 10 秒防止挂起--subsystem-matchblock精准匹配块设备避免干扰其他子系统。ls -l显示符号链接目标确认是否指向正确的sdX。2.4 ASM 磁盘权限检查grid用户能否真正访问即使/dev/asmdisk01存在grid用户也可能因 SELinux 或 umask 被拒# 切换到 grid 用户测试读取权限 sudo -u grid bash -c dd if/dev/asmdisk01 of/dev/null bs512 count1 2/dev/null echo OK || echo FAIL: Permission denied若返回FAIL: Permission denied检查 SELinux 状态# 查看 SELinux 是否启用及当前模式 sestatus # 若为 enforcing临时设为 permissive仅测试 sudo setenforce 0 # 再次测试 dd 命令 # 若成功则需添加 SELinux 策略生产环境必须 sudo ausearch -m avc -ts recent | audit2why sudo ausearch -m avc -ts recent | audit2allow -M oracleasm sudo semodule -i oracleasm.pp提示RHEL 7.6 默认启用 SELinux/dev/asmdisk*的默认上下文是device_t而 ASM 要求oracleasm_device_t。audit2allow自动生成策略比手动semanage fcontext更可靠。3. Grid Infrastructure 安装跳过图形界面用响应文件静默安装 CRS 并规避 OUI 卡死gridSetup.sh图形界面在 RHEL 7.6 上极易卡在“Discovering disks”或“Validating user”阶段尤其当 X11 转发不稳定或DISPLAY设置错误时。生产环境必须用响应文件response file静默安装它能跳过所有交互、记录完整日志、且可版本化管理。但官方响应文件模板gridsetup.rsp有 3 处硬编码陷阱必须修改。3.1 准备静默安装响应文件修正INVENTORY_LOCATION和oracle.install.asm.OSDBA组名下载 GI 包V981627-01.zip后解压并定位模板unzip V981627-01.zip -d /app/product/19.2.0/crs cd /app/product/19.2.0/crs # 复制模板注意不是 grid/response/gridsetup.rsp而是根目录下的 rsp cp grid/response/gridsetup.rsp ./grid_rhel76.rsp编辑grid_rhel76.rsp修正以下关键参数原模板值多为占位符直接使用必失败# 必须修改项 oracle.install.responseFileVersion/oracle/install/rspfmt_crsinstall_response_schema_v19.0.0 ORACLE_HOSTNAMEnode2 INVENTORY_LOCATION/app/oraInventory # 原模板为 /u01/app/oraInventory必须与规划一致 SELECTED_LANGUAGESen,en_GB oracle.install.optionCRS_CONFIG ORACLE_BASE/app/grid ORACLE_HOME/app/product/19.2.0/crs oracle.install.asm.OSDBAasmdba # 原模板为 asmadmin但安装脚本实际校验的是 asmdba 组 oracle.install.asm.OSOPERasmoper oracle.install.asm.OSASMasmadmin oracle.install.crs.config.gpnp.scanNamescan-node2 oracle.install.crs.config.gpnp.scanPort1521 oracle.install.crs.config.gpnp.configureGNSfalse oracle.install.crs.config.autoConfigureClusterNodetrue oracle.install.crs.config.clusterNamerac-cluster oracle.install.crs.config.gpnp.configureGNSfalse oracle.install.crs.config.useIPMIfalse oracle.install.asm.SYSASMPasswordoracle # 与指南一致但建议生产环境用强密码 oracle.install.asm.diskGroup.nameDATA oracle.install.asm.diskGroup.redundancynormal oracle.install.asm.diskGroup.AUSize4 # AU Size 单位为 MB4MB 是 RHEL 7.6 19c 最佳实践 oracle.install.asm.diskGroup.discoveryString/dev/asmdisk* oracle.install.asm.monitorPasswordoracle oracle.install.crs.upgrade.clusterNodes oracle.install.asm.configureGIMRfalse oracle.install.crs.config.skipClusterChecktrue # 关键跳过集群检查因是单实例 ASM参数说明INVENTORY_LOCATION必须与4.4节创建的/app/oraInventory完全一致否则安装程序找不到 inventory。oracle.install.asm.OSDBAasmdba这是最大坑点。官方文档说用asmadmin但 19.2.0 的runInstaller实际代码校验asmdba组是否存在若填asmadmin安装会静默失败并退出。oracle.install.crs.config.skipClusterChecktrue明确告知安装程序这是 standalone server跳过冗余的集群验证如 OCR 磁盘检查避免卡在 “Checking for CRS configuration”。3.2 执行静默安装并实时监控日志-ignorePrereq不是万能钥匙# 以 root 执行响应文件需 root 权限 sudo -E /app/product/19.2.0/crs/gridSetup.sh \ -silent \ -responseFile /app/product/19.2.0/crs/grid_rhel76.rsp \ -ignorePrereqFailure \ -waitforcompletion \ -debug \ -logLevel 1 # 实时查看安装日志关键 tail -f /app/oraInventory/logs/installActions*.log逻辑说明-ignorePrereqFailure忽略预检失败如chronyd未停但不能忽略prereq错误如libaio缺失那些必须提前解决。-waitforcompletion阻塞等待安装完成避免脚本提前退出。-debug -logLevel 1开启调试日志installActions.log中会记录每一步执行命令、返回码、错误堆栈。sudo -E保留当前环境变量如DISPLAY,PATH避免gridSetup.sh找不到java。3.3 安装后 root.sh 执行/app/product/19.2.0/crs/root.sh的 3 个隐藏依赖gridSetup.sh成功后必须以 root 执行root.sh但它依赖三个未明说的条件# 1. 确保 /app/product/19.2.0/crs 有执行权限解压后可能为 644 sudo chmod -R 755 /app/product/19.2.0/crs # 2. 确保 /app/grid 有写权限ORACLE_BASE sudo chown -R root:oinstall /app/grid sudo chmod -R 775 /app/grid # 3. 执行 root.sh在 node2 上 sudo /app/product/19.2.0/crs/root.sh # 4. 验证 CRS 进程非 ps aux | grep crs而是用 crsctl sudo /app/product/19.2.0/crs/bin/crsctl check crs # 正确输出 # CRS-4638: Oracle High Availability Services is online # CRS-4537: Cluster Ready Services is online # CRS-4529: Cluster Synchronization Services is online # CRS-4533: Event Manager is online提示crsctl check crs是唯一可信验证方式。ps aux | grep ora_可能显示进程但 CRS 未真正在线。3.4 ASM 实例启动验证asmcmd不是万能sqlplus / as sysasm才是真相asmcmd lsdg返回空不代表 ASM 没起来——它可能只是没创建磁盘组。必须用 SQL*Plus 连接 ASM 实例# 切换到 grid 用户 sudo -u grid bash -c export ORACLE_SIDASM export ORACLE_HOME/app/product/19.2.0/crs $ORACLE_HOME/bin/sqlplus / as sysasm EOF set pagesize 100 col name for a20 col state for a10 select name, state, type, total_mb, free_mb from v\$asm_diskgroup; exit; EOF 逻辑说明v$asm_diskgroup是 ASM 元数据视图total_mb和free_mb非空才表示磁盘组已挂载。若返回no rows selected说明CREATE DISKGROUP未执行需手动创建见第 4 章。4. Oracle Database 19c 安装与 ASM 数据库创建dbca静默建库的 4 个致命参数安装 Oracle 软件包V981623-01.zip后不能直接dbca图形建库——ASM 磁盘组未创建、监听未配置、密码文件未生成都会导致建库失败。必须分三步先静默安装软件再用sqlplus手动创建 ASM 磁盘组最后用dbca静默建库。4.1 Oracle 软件静默安装复用 GI 的响应文件结构解压V981623-01.zip复制并修改响应文件unzip V981623-01.zip -d /app/oracle/product/19.2.0/dbhome_1 cd /app/oracle/product/19.2.0/dbhome_1 cp database/response/db_install.rsp ./db_install_rhel76.rsp编辑db_install_rhel76.rsp关键修改oracle.install.responseFileVersion/oracle/install/rspfmt_dbinstall_response_schema_v19.0.0 oracle.install.optionINSTALL_DB_SWONLY ORACLE_HOSTNAMEnode2 UNIX_GROUP_NAMEoinstall INVENTORY_LOCATION/app/oraInventory SELECTED_LANGUAGESen,en_GB ORACLE_HOME/app/oracle/product/19.2.0/dbhome_1 ORACLE_BASE/app/oracle oracle.install.db.InstallEditionEE oracle.install.db.OSDBA_GROUPdba oracle.install.db.OSOPER_GROUPoper oracle.install.db.OSBACKUPDBA_GROUPbackupdba oracle.install.db.OSDGDBA_GROUPdgdba oracle.install.db.OSKMDBA_GROUPkmdba oracle.install.db.OSRACDBA_GROUPracdba oracle.install.db.rootconfig.executeRootScripttrue oracle.install.db.rootconfig.configMethodROOT oracle.install.db.rootconfig.sudoLocation/usr/bin/sudo oracle.install.db.rootconfig.sudoPassword参数说明oracle.install.optionINSTALL_DB_SWONLY只安装软件不建库建库留到dbca。oracle.install.db.OSDGDBA_GROUPdgdba显式指定 DG 管理组确保DG_BROKER_START可用。oracle.install.db.rootconfig.executeRootScripttrue安装后自动执行root.sh避免遗漏。执行安装sudo -E /app/oracle/product/19.2.0/dbhome_1/runInstaller \ -silent \ -responseFile /app/oracle/product/19.2.0/dbhome_1/db_install_rhel76.rsp \ -ignorePrereqFailure \ -waitforcompletion \ -logLevel 14.2 手动创建 ASM 磁盘组CREATE DISKGROUP的COMPATIBLE.ASM必须匹配 19cdbca无法自动创建 ASM 磁盘组必须先用sqlplus连接 ASM 实例执行 DDLsudo -u grid bash -c export ORACLE_SIDASM export ORACLE_HOME/app/product/19.2.0/crs $ORACLE_HOME/bin/sqlplus / as sysasm EOF CREATE DISKGROUP DATA NORMAL REDUNDANCY FAILGROUP FG1 DISK /dev/asmdisk01 NAME ASMDISK01, /dev/asmdisk02 NAME ASMDISK02 FAILGROUP FG2 DISK /dev/asmdisk03 NAME ASMDISK03, /dev/asmdisk04 NAME ASMDISK04 ATTRIBUTE au_size4M, compatible.asm19.0.0, compatible.rdbms19.0.0, compatible.advm19.0.0; exit; EOF 参数说明NORMAL REDUNDANCY两路镜像满足 RHEL 7.6 单节点 ASM 的高可用要求。FAILGROUP将磁盘分为两个故障组FG1/FG2避免单点故障。compatible.asm19.0.0最关键参数。若设为12.1.0后续dbca创建数据库时会报ORA-15018: diskgroup cannot be created因为 19c 要求 ASM 兼容版本 ≥ 19.0.0。4.3dbca静默建库-createDatabase的 4 个不可省略参数dbca响应文件必须包含 ASM 相关路径和密码# 生成模板 /app/oracle/product/19.2.0/dbhome_1/bin/dbca -generateResponseTemplate -responseFile /tmp/dbca_template.rsp # 编辑 /tmp/dbca_template.rsp关键参数 responseFileVersion/oracle/install/rspfmt_dbca_response_schema_v19.0.0 gdbNamenodetwo sidnodetwo databaseConfigTypeSI templateNameGeneral_Purpose.dbc sysPasswordoracle systemPasswordoracle dbsnmpPasswordoracle storageTypeASM diskGroupNameDATA recoveryGroupNameFRA # 必须提前创建 FRA 磁盘组或设为 DATA characterSetAL32UTF8 nationalCharacterSetAL16UTF16 listenersLISTENER variablesFile variablesoracle.assistants.dbca.typeSI执行建库sudo -u oracle bash -c export ORACLE_HOME/app/oracle/product/19.2.0/dbhome_1 $ORACLE_HOME/bin/dbca \ -silent \ -createDatabase \ -responseFile /tmp/dbca_template.rsp \ -ignorePreReqs \ -debug \ -logLevel 1 提示-ignorePreReqs仅忽略非致命预检如内存不足警告-debug日志会记录dbca调用的每一个 SQL 和 shell 命令是排错核心依据。5. Data Guard 配置与避坑dgmgrl连不上、switchover失败的 5 个真实原因Data Guard 不是配完tnsnames.ora就能自动同步。dgmgrl连不上 standby、switchover卡在Waiting for the primary database to switch over、archive log list显示ARCHIVED LOG DESTINATION为DISABLED这些现象背后是 5 个必须手动验证的断点。5.1 主备库网络与监听配置tnsnames.ora的URA和SERVERDEDICATED缺一不可主库tnsnames.ora$ORACLE_HOME/network/admin/tnsnames.ora必须包含 standby 的连接描述符且必须启用URAConnect-time failover和SERVERDEDICATED# 主库 tnsnames.ora 中添加 NODE2DG (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST node2dg)(PORT 1521)) (CONNECT_DATA (SERVER DEDICATED) (SERVICE_NAME nodetwodg) (UR A) # 关键允许 dgmgrl 连接时自动重试 ) ) # 备库 tnsnames.ora 中添加反向 NODE2 (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST node2)(PORT 1521)) (CONNECT_DATA (SERVER DEDICATED) (SERVICE_NAME nodetwo) (UR A) ) )逻辑说明URA让dgmgrl在连接失败时自动尝试备用地址SERVERDEDICATED确保使用专用服务器进程避免共享服务器SHARED导致 DG Broker 通信异常。5.2 Data Guard Broker 配置DG_BROKER_STARTTRUE的 3 个前置条件ALTER SYSTEM SET DG_BROKER_STARTTRUE SCOPEBOTH;不会立即生效它依赖密码文件必须存在且同步# 主库生成密码文件 orapwd file$ORACLE_HOME/dbs/orapwnodetwo passwordoracle entries10 # 复制到备库保持文件名一致 scp $ORACLE_HOME/dbs/orapwnodetwo oraclenode2dg:$ORACLE_HOME/dbs/orapwnodetwodglog_archive_config必须双向配置-- 主库执行 ALTER SYSTEM SET log_archive_configDG_CONFIG(nodetwo,nodetwodg) SCOPEBOTH; -- 备库执行 ALTER SYSTEM SET log_archive_configDG_CONFIG(nodetwo,nodetwodg) SCOPEBOTH;fal_server和fal_client必须指向对方 TNS 别名-- 主库 ALTER SYSTEM SET fal_serverNODE2DG SCOPEBOTH; ALTER SYSTEM SET fal_clientNODE2 SCOPEBOTH; -- 备库 ALTER SYSTEM SET fal_serverNODE2 SCOPEBOTH; ALTER SYSTEM SET fal_clientNODE2DG SCOPEBOTH;5.3 使用dgmgrl创建配置CREATE CONFIGURATION的AS CONNECT IDENTIFIER必须是 TNS 别名# 主库上执行 dgmgrl / DGMGRL CREATE CONFIGURATION my_dg_config AS PRIMARY DATABASE IS nodetwo CONNECT IDENTIFIER IS NODE2; DGMGRL ADD DATABASE nodetwodg AS CONNECT IDENTIFIER IS NODE2DG MAINTAINED AS PHYSICAL; DGMGRL ENABLE CONFIGURATION;注意CONNECT IDENTIFIER IS NODE2中的NODE2是tnsnames.ora中定义的别名不是主机名或 SID。若填node2主机名dgmgrl会报ORA-12154: TNS:could not resolve the connect identifier specified。5.4 避坑Data Guard 常见问题排查现象 → 原因 → 解决现象 1dgmgrl连接 standby 时报ORA-12514: TNS:listener does not currently know of service requested原因备库监听器未注册nodetwodg服务或local_listener参数未设置。解决在备库执行ALTER SYSTEM SET local_listener(ADDRESS(PROTOCOLTCP)(HOSTnode2dg)(PORT1521)) SCOPEBOTH; ALTER SYSTEM REGISTER; -- 强制向监听器注册现象 2SHOW DATABASE VERBOSE nodetwodg显示Transport Lag为UNKNOWNApply Lag为0 seconds原因备库未启用managed recovery或log_archive_dest_2未启用。解决在备库执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; ALTER SYSTEM SET log_archive_dest_state_2ENABLE SCOPEBOTH;现象 3switchover时卡在Waiting for the primary database to switch over原因主库log_archive_dest_2的SYNC属性未启用或网络延迟过高。解决在主库执行ALTER SYSTEM SET log_archive_dest_2SERVICENODE2DG SYNC VALID_FOR(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAMEnodetwodg SCOPEBOTH;现象 4SELECT * FROM v$archive_gap;返回空但SELECT MAX(sequence#) FROM v$archived_log主备不一致原因归档日志未传输到备库或备库standby_file_management为MANUAL。解决在备库执行ALTER SYSTEM SET standby_file_managementAUTO SCOPEBOTH; -- 手动注册缺失日志 ALTER DATABASE REGISTER LOGFILE /path/to/archivelog_123.arc;现象 5dgmgrl执行SHOW CONFIGURATION报ORA-16664: unable to receive the result from a database原因DG_BROKER_CONFIG_FILE1和DG_BROKER_CONFIG_FILE2指向的 broker 配置文件损坏或权限不对。解决在主备库分别执行SHOW PARAMETER dg_broker_config_file; -- 确认文件存在且 grid/oracle 用户有读写权限 ls -l $ORACLE_HOME/dbs/dr1nodetwo.dat $ORACLE_HOME/dbs/dr2nodetwo.dat sudo chown oracle:oinstall $ORACLE_HOME/dbs/dr1nodetwo.dat $ORACLE_HOME/dbs/dr2nodetwo.dat6. 验证 Data Guard 切换与性能用switchover测试 RTO并监控 ASM I/O 延迟部署完成不等于可用。必须实测switchover的 RTO恢复时间目标和archive log list的归档延迟否则上线即翻车。我一般会强制走一遍switchover并记录从命令发出到备库OPEN的精确时间同时用iostat监控 ASM 磁盘的await平均等待毫秒因为 RHEL 7.6 的xfs文件系统在高并发下await 20ms就意味着 I/O 瓶颈。6.1 执行switchover并测量 RTOtime命令 dgmgrl脚本# 编写 switchover 脚本 /tmp/switchover.sh cat /tmp/switchover.sh EOF #!/bin/bash echo Starting switchover at $(date) dgmgrl / EOF2 SWITCHOVER TO nodetwodg; EXIT; EOF2 echo Switchover command sent at $(date) # 等待备库启动 while true; do sleep 5 STATUS$(sudo -u oracle sqlplus -s / as sysdba SQL SET PAGESIZE 0 FEEDBACK OFF VERIFY OFF HEADING OFF ECHO OFF SELECT status FROM v$instance; SQL ) if [[ $STATUS OPEN ]]; then echo Standby opened at $(date) break fi done EOF chmod x /tmp/switchover.sh # 执行并计时 time sudo -u oracle /tmp/switchover.sh逻辑说明time命令输出真实耗时realv$instance.status为OPEN表示数据库已可接受连接。RHEL 7.6 ASM 19c 的典型 RTO 应 ≤ 90 秒若 120 秒需检查 log_archive_dest本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
