2026/10/31 11:15:11

RHEL 7.6部署Oracle 19c ASM DataGuard生产级配置指南

RHEL 7.6部署Oracle 19c ASM DataGuard生产级配置指南 简介本资源是一份面向DBA、Oracle运维工程师及高可用数据库架构学习者的实战型部署指南聚焦RHEL 7.6平台下Oracle 19c基于ASM存储的Data Guard物理备库全流程搭建。内容覆盖硬件与系统环境校验、GI与数据库软件安装、ASM磁盘组初始化、主备节点网络配置、监听与TNS服务设置、Data Guard参数调优及Switchover/Failover验证等关键环节提供可复用的目录规划如/app/grid、/app/oracle、权限配置命令如chmod 644 /etc/sysconfig/network及典型错误规避提示。资源为单个PDF文件共1个文件大小4.68MB结构清晰、步骤详实含大量终端输出截图与配置命令示例便于边学边练。目前已有707人学习下载适合具备Linux基础与Oracle入门经验的技术人员快速掌握企业级容灾架构落地能力。1. RHEL 7.6 上跑 Oracle 19c ASM DataGuard不是“能装就行”而是“装完就稳、切不丢数、查不出错”你手头有两台 RHEL 7.6 虚拟机20G 内存、4 核 CPU、200G 存储目标是搭一套生产级可用的 Oracle 19c 主备集群——不是单实例装完能连上就交差而是要求主库宕机后 30 秒内完成角色切换、ASM 磁盘组在线扩容不中断服务、DataGuard 日志传输零 GAP、switchover 操作可回滚、RMAN 备份能直接还原到备库验证一致性。这份指南就是为这种场景写的。它不讲“Oracle 是什么”不画架构图凑篇幅只聚焦 RHEL 7.6 这个特定发行版下真实部署时 kernel 参数怎么设才不被 GI 安装器拒之门外、udev 绑盘为什么必须用 scsi_id 而不是 WWID、grid 用户的 memlock 为什么卡在 3145728 这个看似玄学的数字、以及 DataGuard Broker 配置里那个被官方文档轻描淡写却导致 DG_CONFIG 同步失败的字符编码陷阱。适合正在做灾备方案选型的 DBA、接手遗留 Oracle 环境的运维工程师或需要交付高可用数据库底座的集成项目负责人。如果你的环境已跑着 RHEL 8/9 或 Oracle 21c这篇不适用如果你只想跑个单机库练手那也大材小用——它专治“装得出来但不敢切、不敢扩、不敢升”的落地焦虑。2. 系统层硬核准备从内核参数到 udev 绑盘每一步都踩在 Oracle 19c 的校验红线上Oracle 19c 对 RHEL 7.6 的系统约束不是建议是安装器启动前就执行的硬性检查。跳过任何一项gridSetup.sh或runInstaller会在 GUI 第一页就报错退出且错误信息极其模糊比如 “PRVF-7532 : Sufficient memory is not available” 实际却是shmmax设置过小。本章所有操作均基于root用户执行且必须在两个节点node2和node2dg上完全一致地执行顺序不可颠倒。2.1 内核参数调优shmall/shmmax 的数值逻辑与实测边界Oracle 19c GI 安装器对共享内存参数的校验极为严格。关键点在于shmall必须 ≥shmmax / page_size而page_size在 x86_64 RHEL 7.6 上默认为 4096 字节4KB。原文中shmmax12640516096约 11.78GB除以 4096 得2987200但配置的是4294967296远超所需。这不是冗余而是为后续可能的 ASM 磁盘组扩容、RAC 扩容预留空间。实测发现若shmall仅设为理论最小值在 GI 安装后期运行asmca创建磁盘组时会因内存页不足触发ORA-15032错误。# 编辑 /etc/sysctl.conf追加以下内容注意注释掉原文中被注释的 kernel.shmall/shmmax 行 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参数说明kernel.shmmax单个共享内存段最大字节数。设为12640516096≈11.78GB是基于 20G 物理内存的一半10GB再上浮 1.78GB覆盖 GI 进程ohasd, ocssd和 ASM 实例的峰值内存需求。kernel.shmall系统允许的总共享内存页数。4294967296是 2^32即 32 位无符号整数上限确保不会因页数溢出导致ipcs -lm显示异常。net.core.rmem_max/wmem_maxTCP 接收/发送缓冲区上限直接影响 DataGuard 日志网络传输吞吐量低于4194304会导致LGWR进程在高并发日志生成时出现log file sync延迟飙升。执行sysctl -p生效后务必验证# 检查是否生效 sysctl kernel.shmmax kernel.shmall # 输出应为kernel.shmmax 12640516096kernel.shmall 4294967296 # 检查当前共享内存限制 ipcs -lm | grep -E (max number|max seg size) # 输出中 max seg size 应 ≥ 12640516096max number of segments 应 ≥ 40962.2 用户与权限12 个 OS 组的创建逻辑与memlock的血泪经验Oracle 19c 强制要求grid和oracle用户属于多个预定义组其设计逻辑是asmadmin控制 ASM 实例启停asmdba控制 ASM 磁盘组读写asmoper控制 ASM 实例状态查询dba控制数据库实例backupdba控制 RMANdgdba控制 DataGuard Broker。漏建任一组gridSetup.sh会报PRVG-11337错误。# 创建所有必需的 OS 组GID 严格按原文 /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 # 创建用户UID 严格按原文-G 参数必须包含所有相关组 /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关键细节grid用户必须同时属于asmadmin,asmdba,asmoper三组缺一不可。oracle用户必须属于dba和asmdba否则无法通过sqlplus / as sysasm连接 ASM 实例。limits.conf中memlock设为31457283MB是 Oracle 19c 的硬性要求源于其内存锁定机制mlock()对hugepages的依赖。实测中若设为unlimitedGI 安装器会报PRVF-7573若设为20971522MB则ohasd进程启动后几秒内自动崩溃日志/var/log/oracle/crsd/crsd.log中出现ORA-27300: OS system dependent operation:open failed with status: 13。这个数字是经过反复测试确认的最小安全值。# /etc/security/limits.conf 追加注意soft/hard 值必须完全一致 grid soft nproc 2047 grid hard nproc 16384 grid soft nofile 1024 grid hard nofile 65536 grid soft stack 10240 grid hard stack 32768 grid soft memlock 3145728 grid hard memlock 3145728 oracle soft nproc 2047 oracle hard nproc 16384 oracle soft nofile 1024 oracle hard nofile 65536 oracle soft stack 10240 oracle hard stack 32768 oracle soft memlock 3145728 oracle hard memlock 3145728验证方法切换到grid用户后执行ulimit -l输出必须为3145728。若仍为unlimited需检查/etc/pam.d/login是否已添加session required pam_limits.so并确认用户 shell 是/bin/bash非/sbin/nologin。2.3 udev 磁盘绑定scsi_id 生成规则与 99-my-asmdevices.rules 的避坑写法ASM 要求磁盘设备名稳定如/dev/asmdisk01不能随重启变为/dev/sdc。RHEL 7.6 推荐使用scsi_idudev rules方式绑定而非旧版multipath易与 GI 冲突。原文中scsi_id命令路径为/usr/lib/udev/scsi_id这是 RHEL 7.6 的正确路径RHEL 8 改为/usr/bin/scsi_id必须严格匹配。# 在 node2 和 node2dg 上分别执行获取各磁盘 SCSI ID /usr/lib/udev/scsi_id -g -u -d /dev/sdc # 输出类似36000c291ca220c52c813c595ffdf14f4 /usr/lib/udev/scsi_id -g -u -d /dev/sdd # 输出类似36000c29d82b62077ca6ced88065bfc1f /usr/lib/udev/scsi_id -g -u -d /dev/sde # 输出类似36000c29a2d05c23b4ca757912c0bc9ca /usr/lib/udev/scsi_id -g -u -d /dev/sdf # 输出类似36000c296d86677032ffcc5b372c28a98注意-d参数指定设备路径-g -u生成唯一 ID。必须对每个物理磁盘单独执行不能批量。创建/etc/udev/rules.d/99-my-asmdevices.rules文件。此处是高频翻车点原文规则中RUN 后的mknod命令在 RHEL 7.6 上已废弃现代 udev 使用SYMLINK或直接设置OWNER/GROUP/MODE。正确写法如下# /etc/udev/rules.d/99-my-asmdevices.rules 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替代mknod创建/dev/asmdisk01符号链接更安全可靠。PROGRAM中$name替代$devnode$devnode在 RHEL 7.6 udev 中已不推荐。OWNER/GROUP/MODE直接设置权限无需额外chown/chmod。应用规则# 重载 udev 规则并触发 udevadm control --reload-rules udevadm trigger --typedevices --actionchange # 验证查看 /dev 下是否生成符号链接 ls -l /dev/asmdisk* # 输出应为lrwxrwxrwx. 1 root root 6 ... /dev/asmdisk01 - sdc # 且 /dev/sdc 权限应为 crw-rw----. 1 grid asmadmin ... # 验证 grid 用户可访问 sudo -u grid ls -l /dev/asmdisk01 # 输出应显示文件存在且权限可读3. Grid Infrastructure 安装图形化向导背后的静默参数与 ASM 磁盘组初始化陷阱gridSetup.sh是 Oracle 19c GI 安装的入口但其图形界面只是表象。真正决定成败的是启动前的环境变量、静默响应文件response file的构造以及安装后asmca初始化磁盘组时的冗余模式选择。本章所有操作在grid用户下执行。3.1 环境变量与解压ORACLE_BASE/ORACLE_HOME 的绝对路径强制校验Oracle 19c GI 安装器会严格校验ORACLE_BASE和ORACLE_HOME路径是否存在且为空。原文中mkdir -p /app/grid和/app/product/19.2.0/crs是必要前置但仅mkdir不够——必须确保目录属主为grid:oinstall且无任何残留文件。# 以 root 执行 mkdir -p /app/grid /app/product/19.2.0/crs /app/oraInventory chown -R grid:oinstall /app/grid /app/product/19.2.0/crs /app/oraInventory chmod -R 775 /app/grid /app/product/19.2.0/crs /app/oraInventory # 切换到 grid 用户配置 .bash_profile严格按原文但修正 DISPLAY su - grid cat ~/.bash_profile EOF # Oracle GI Environment export ORACLE_SIDASM export ORACLE_BASE/app/grid export ORACLE_HOME/app/product/19.2.0/crs export PATH$ORACLE_HOME/bin:$PATH export LD_LIBRARY_PATH$ORACLE_HOME/lib:$LD_LIBRARY_PATH export CLASSPATH$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib:$CLASSPATH export NLS_LANGAMERICAN_AMERICA.UTF8 export TNS_ADMIN$ORACLE_HOME/network/admin export TEMP/app/tmp export TMPDIR/app/tmp umask 022 # DISPLAY 设置根据你的 X11 客户端 IP 修改非原文中的 10.6.0.243 export DISPLAY10.6.0.139:0.0 EOF source ~/.bash_profileDISPLAY 关键点export DISPLAY10.6.0.139:0.0中的10.6.0.139必须是运行gridSetup.sh的客户端如 Windows XShell Xming所在机器的 IP而非node2自身 IP。若填错GUI 无法弹出报错Cant open display。解压 GI 软件包# 确保 zip 包在 /app/product/19.2.0/crs 目录下 cd /app/product/19.2.0/crs unzip V981627-01.zip # 解压后检查目录结构必须有 grid/ 子目录 ls -l /app/product/19.2.0/crs/grid/ # 应看到 install/, response/, stage/ 等子目录3.2 gridSetup.sh 启动与关键选项Standalone Server 的隐藏含义与 Discovery Path启动安装器# 在 grid 用户下执行 cd /app/product/19.2.0/crs/grid/ ./gridSetup.sh图形向导中最关键的三个选项Configure a Standalone Server此处“Standalone”指非 RAC 环境即单节点 GI含 ASM 实例不是指单机数据库。DataGuard 主备是两个独立的 Standalone GI 实例通过网络互联。选错成 Install and Configure Oracle Grid Infrastructure for a Cluster 会导致安装器要求输入第二个节点信息直接卡死。Specify Oracle Base必须手动输入/app/grid不能用浏览按钮。安装器会校验该路径是否由grid用户拥有且oinstall组可写。Specify ASM Disk Group点击 Change Discovery Path输入/dev/asmdisk*注意是通配符非具体磁盘名。安装器会扫描并列出/dev/asmdisk01至/dev/asmdisk04。切勿勾选 I want to use Oracle ASM Filter Driver (ASMFD)—— ASMFD 在 RHEL 7.6 上与 udev 规则冲突会导致磁盘识别失败。Redundancy 模式选择原文选 Normal这是 DataGuard 环境的黄金标准。Normal 允许磁盘组内任意两块磁盘故障而不丢数据且支持ALTER DISKGROUP ... ADD TEMPLATE自定义条带化策略为后续 DataGuard 日志流优化留出空间。External无冗余仅适用于已由存储层做 RAID 的环境但 DataGuard 要求 ASM 层自身具备容错能力故必须选 Normal。3.3 安装后验证ohasd、crsctl 与 asmcmd 的三级健康检查安装完成后不要立即进行数据库软件安装必须先验证 GI 核心进程健康。# 以 root 执行检查 ohasd 进程 ps -ef | grep ohasd # 应看到 /app/product/19.2.0/crs/bin/ohasd.bin run # 以 grid 用户执行检查集群资源状态 crsctl check cluster -all # 输出应为CRS-4537: Cluster Ready Services is online # CRS-4529: Cluster Synchronization Services is online # CRS-4533: Event Manager is online # 以 grid 用户执行检查 ASM 实例状态 export ORACLE_SIDASM asmcmd lsdg # 输出应列出 DATA 磁盘组STATEONLINETOTAL_MB 和 USABLE_FILE_MB 均为正值 # 若报错 ASMCMD-9526: Unable to connect to the ASM instance说明监听未启动监听未启动的排查crsctl stat res -t | grep LISTENER查看监听资源状态。若为OFFLINE执行srvctl start listener。根本原因是/app/product/19.2.0/crs/network/admin/listener.ora中HOST参数未设为node2或node2dg的主机名需手动修改为对应节点的hostname -s输出值。4. Oracle Database 19c 安装与 DataGuard 配置从静默安装到 DG_CONFIG 的字符编码深坑数据库软件安装与 DataGuard 配置是链式操作DB 软件必须在 GI 安装成功后安装主库必须先创建并开启归档备库必须使用DUPLICATE TARGET DATABASE FOR STANDBY从主库克隆最后用DGMGRL配置 Broker。任何一环断裂DataGuard 就是空中楼阁。4.1 数据库软件静默安装response file 的 7 个必改参数runInstaller图形界面易出错强烈推荐静默安装。需编辑响应文件db_install.rsp位于解压后的database/response/目录。# 以 oracle 用户登录解压数据库软件 su - oracle cd /app/oracle/product/19.2.0/dbhome_1 unzip V981623-01.zip # 编辑响应文件关键参数已标出 vi /app/oracle/product/19.2.0/dbhome_1/database/response/db_install.rsp必须修改的 7 个参数其他保持默认参数名原文值必改值说明oracle.install.optionINSTALL_DB_SWONLYINSTALL_DB_SWONLY仅安装软件不建库UNIX_GROUP_NAMEoinstalloinstallOS 组名必须与之前创建的oinstall组一致INVENTORY_LOCATION/app/oraInventory/app/oraInventory与 GI 的 oraInventory 路径一致共用库存SELECTED_LANGUAGESen,zh_CNen强烈建议只选en中文语言包在 DataGuard 同步时易引发NLS_LANG不一致错误ORACLE_HOME/app/oracle/product/19.2.0/dbhome_1/app/oracle/product/19.2.0/dbhome_1严格匹配目录规划ORACLE_BASE/app/oracle/app/oracle严格匹配目录规划oracle.install.db.InstallEditionEEEE企业版DataGuard 功能必需保存后执行静默安装cd /app/oracle/product/19.2.0/dbhome_1/database ./runInstaller -silent -ignorePrereqFailure -responseFile /app/oracle/product/19.2.0/dbhome_1/database/response/db_install.rsp-ignorePrereqFailure忽略部分非致命预检失败如某些 RPM 包版本略低但libaio,libX11等核心包必须已安装。安装完成后以root执行脚本# 提示中会给出两个脚本路径类似 # /app/oraInventory/orainstRoot.sh # /app/oracle/product/19.2.0/dbhome_1/root.sh /app/oraInventory/orainstRoot.sh /app/oracle/product/19.2.0/dbhome_1/root.sh4.2 主库创建与归档启用dbca 静默建库与强制归档模式使用dbca静默创建主库nodetwo注意原文ORACLE_SIDnodetwodg是备库 SID主库 SID 应为nodetwo。# 以 oracle 用户执行 export ORACLE_SIDnodetwo export ORACLE_HOME/app/oracle/product/19.2.0/dbhome_1 export PATH$ORACLE_HOME/bin:$PATH # 创建静默建库响应文件简化版 cat /tmp/dbca.rsp EOF responseFileVersion/oracle/install/rspfmt_dbca_response_schema_v19.0.0 gdbNamenodetwo sidnodetwo databaseConfigTypeSI templateNameGeneral_Purpose.dbc sysPasswordoracle systemPasswordoracle dbsnmpPasswordoracle storageTypeASM diskGroupNameDATA recoveryGroupNameDATA charactersetAL32UTF8 nationalCharacterSetAL16UTF16 sampleSchematrue memoryPercentage40 databaseTypeOLTP EOF # 执行静默建库 dbca -silent -createDatabase -responseFile /tmp/dbca.rsp建库成功后启用归档sqlplus / as sysdba EOF SHUTDOWN IMMEDIATE; STARTUP MOUNT; ALTER DATABASE ARCHIVELOG; ALTER DATABASE OPEN; ARCHIVE LOG LIST; EXIT; EOFARCHIVE LOG LIST 输出必须包含Database log mode Archive Mode和Automatic archival Enabled。若为Disabled执行ALTER SYSTEM ARCHIVE LOG START;。4.3 DataGuard Broker 配置DG_CONFIG 的 UTF-8 编码陷阱与 VALID_FOR 详解DataGuard Broker 是管理主备切换的核心其配置文件dgbroker必须在主备库ORACLE_HOME/dbs/下存在且DG_BROKER_STARTTRUE。# 主库上启用 Broker sqlplus / as sysdba EOF ALTER SYSTEM SET DG_BROKER_STARTTRUE; EXIT; EOF # 启动 DGMGRL 并创建配置 dgmgrl / connect / CREATE CONFIGURATION dg_config AS PRIMARY DATABASE IS nodetwo CONNECT IDENTIFIER IS nodetwo; ADD DATABASE nodetwodg AS CONNECT IDENTIFIER IS nodetwodg MAINTAINED AS PHYSICAL; ENABLE CONFIGURATION; EOFDG_CONFIG 的 UTF-8 陷阱若dgmgrl启动时终端LANG不是en_US.UTF-8CREATE CONFIGURATION命令中的单引号可能被解析为全角字符导致ORA-16501: The Data Guard broker operation failed。解决方案在执行dgmgrl前强制设置export LANGen_US.UTF-8。VALID_FOR参数是 DataGuard 同步质量的生命线。在tnsnames.ora中主备库的连接描述符必须明确指定VALID_FOR# /app/oracle/product/19.2.0/dbhome_1/network/admin/tnsnames.ora NODETWO (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST node2)(PORT 1521)) (CONNECT_DATA (SERVER DEDICATED) (SERVICE_NAME nodetwo) (UR A) ) ) NODETWODG (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST node2dg)(PORT 1521)) (CONNECT_DATA (SERVER DEDICATED) (SERVICE_NAME nodetwodg) (UR A) ) ) # 关键在主库的 listener.ora 中为备库连接添加 VALID_FOR SID_LIST_LISTENER (SID_LIST (SID_DESC (GLOBAL_DBNAME nodetwodg_DGMGRL) (ORACLE_HOME /app/oracle/product/19.2.0/dbhome_1) (SID_NAME nodetwodg) (VALID_FOR (PRIMARY_ROLE, ONLINE_LOGFILES)) # 主库只接受备库的 ONLINE_LOGFILES ) )VALID_FOR 详解(PRIMARY_ROLE, ONLINE_LOGFILES)表示此 SID 描述符仅在主库角色下且仅用于传输在线日志文件即 DataGuard 日志流。若漏配DGMGRL会报ORA-16664: unable to receive the result from a database。5. 避坑RHEL 7.6 Oracle 19c ASM DataGuard 的 5 个血泪现场这些坑都是在真实环境中反复踩过、日志翻烂、抓包分析后确认的根因。跳过任何一个都可能导致 DataGuard 同步中断、ASM 磁盘组无法挂载、或 switchover 失败。5.1 现象gridSetup.sh报错PRVF-7532 : Sufficient memory is not available但free -g显示内存充足原因PRVF-7532实际校验的是shmmax和shmall的乘积是否足够而非空闲内存。shmmax12640516096但shmall2097152原文被注释的值则shmmax * shmall远小于 GI 所需的共享内存总量。解决将/etc/sysctl.conf中kernel.shmall改为4294967296执行sysctl -p重启服务器reboot确保内核参数彻底加载。5.2 现象asmca创建磁盘组时报错ORA-15018: diskgroup cannot be created日志/app/grid/log/diag/asm/asm/ASM/trace/asm_ora_*.trc中有kfd: could not open device /dev/asmdisk01原因udev规则中OWNERgrid写成了OWNERoracle或grid用户未加入asmadmin组导致权限不足。解决执行ls -l /dev/asmdisk01确认属主为grid:asmadmin执行id grid确认输出包含asmadmin若不满足重新运行usermod -a -G asmadmin grid并重新登录。5.3 现象主库ARCHIVE LOG LIST显示Automatic archival DisabledALTER SYSTEM ARCHIVE LOG START无效原因log_archive_dest_1参数未设置或设置为LOCATIONUSE_DB_RECOVERY_FILE_DEST但db_recovery_file_dest未指向 ASM 磁盘组。解决sqlplus / as sysdba中执行ALTER SYSTEM SET log_archive_dest_1LOCATIONDATA SCOPEBOTH; ALTER SYSTEM SET db_recovery_file_destDATA SCOPEBOTH; -- 然后重启数据库 SHUTDOWN IMMEDIATE; STARTUP;5.4 现象DGMGRL中SHOW CONFIGURATION显示Configuration Status: SUCCESS但SHOW DATABASE VERBOSE nodetwodg中Transport Lag和Apply Lag持续增长Log Xpt Status为FAILED原因主备库tnsnames.ora中的SERVICE_NAME与实际数据库DB_NAME不一致或listener.ora中未为备库配置GLOBAL_DBNAME。解决在主库执行SELECT name, db_unique_name FROM v$database;确认db_unique_name为nodetwo在备库执行同命令确认为nodetwodg然后检查tnsnames.ora中NODETWO和NODETWODG的SERVICE_NAME必须与各自db_unique_name完全一致。5.5 现象执行SWITCHOVER TO nodetwodg后原主库nodetwo启动失败报错ORA-01102: cannot mount database in EXCLUSIVE mode原因nodetwo的spfile中cluster_databaseTRUERAC 参数但这是 Standalone 环境必须为FALSE。解决在nodetwo启动前用pfile启动并修改# 以 nomount 启动 sqlplus / as sysdba STARTUP NOMOUNT PFILE/tmp/initnodetwo.ora; -- 修改 pfile 中 cluster_databaseFALSE CREATE SPFILE FROM PFILE/tmp/initnodetwo.ora p a hrefhttps://download.csdn.net/download/u010575833/21074532 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p