简介RHEL 7.6环境下搭建Oracle 19C数据库高可用架构的完整实操指南面向系统运维与数据库管理员重点解决ASM存储管理与Data Guard主从复制的部署难点。资源为PDF格式单文件压缩包仅4.68MB内容按实际部署流程组织从硬件需求、软件版本V981623-01.zip与V981627-01.zip、节点规划、目录设计到网络配置均有明确说明。指南详细演示了Oracle 19C数据库软件安装、ASM磁盘组配置、Data Guard主备库搭建与网络环境设置并针对安装路径预创建、权限调整、软件包检查等易错环节给出注意事项。文中基于node2主库与node2dg备库的真实操作记录提供清晰的命令示例、验证步骤及常见问题应对思路可帮助读者避开部署中的关键坑点快速构建稳定可用的高可用数据库环境。现有703人学习适合需要独立完成RHEL 7.6Oracle 19CASMData Guard部署的运维与DBA人员参考。1. RHEL 7.6 装 Oracle 19C ASM DataGuard一次双节点实战复盘Oracle 19C 是我装过的最容易在环境预检阶段卡住的版本尤其在 RHEL 7.6 上叠加 ASM 和 DataGuard 时一次部署要串联系统预配置、共享盘绑定、GI 安装、DG 搭建四条链路任何一环没对齐后面全被拖垮。这份资源是一套完整的双节点实验记录主库节点 node2、物理备库节点 node2dg4 块共享盘走 udev 绑定进 ASMGI 用 standalone server 模式搭建单实例 ASM再靠 DataGuard 日志传输把备库拉起。适合已经装过单机版、想在测试机复刻一套 19C ASM DG 高可用拓扑的 DBA 或准 DBA 照着做一遍。2. 安装前的系统预配置目录、用户组、内核参数与两个易错点19C 的安装前准备比 11g 敏感得多OUI 在预检阶段严格核对路径、内核参数、依赖包和用户组。我见过不少机器卡在 precheck 的 compat-libstdc 缺失也见过 root.sh 因为 NOZEROCONF 没配而反复起不来 OHASD这些都是环境阶段埋的雷。2.1 目录规划为什么必须先建全路径文档里的路径规划分成 GI 和 ORACLE 两套# GI 路径 export ORACLE_BASE/app/grid export ORACLE_HOME/app/product/19.2.0/crs mkdir -p /app/grid mkdir -p /app/product/19.2.0/crs mkdir -p /app/oraInventory # ORACLE 路径 export ORACLE_BASE/app/oracle export ORACLE_HOME/app/oracle/product/19.2.0/dbhome_1 mkdir -p /app/oracle/product/19.2.0/dbhome_1注需提前创建好全路径否则安装软件时检测不到路径。软件会安装在 gridSetup 所在路径。这里的关键不是 mkdir 本身而是 19C 的 OUI 不会帮你补建 ORACLE_HOME。11g 时代路径不存在时安装界面还能容忍18c/19c 的预检会直接报路径无法创建导致装配无法继续。mkdir -p 会连中间目录一并生成所以你只需要保证 /app 有足够空间以及全程用统一的分区规划。解压前先确认 /app 分区至少剩余 15G。GI 安装会写入 oraInventory、日志和 root.sh 产生的集群配置空间不足时 gridSetup.sh 跑到一半报磁盘空间不足非常麻烦。文档里主库 /app 是 45G、备库 40G从这个容量看是给 GI 软件、数据库软件和后续数据库文件都留了余量的。我一般还会额外创建 /app/tmp 并 export TEMP/app/tmp让 OUI 与各种脚本把临时文件写到独立目录避免默认 /tmp 空间或 inode 被吃满。数据库安装过程中的临时日志、OUI 备份文件都不小这条在文档里也有体现。2.2 用户与组划分grid/oracle 的附属组怎么给19C 的 ASM 与数据库分离力度比 11g 大。grid 用户负责 GI 和 ASMoracle 用户负责数据库软件。组划分如果给错了后面运行 root.sh 或者 asmca 会持续报权限错。/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 /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参数说明-g 指定主组-G 指定附属组。oracle 的主组是 oinstall附属组里必须有 dba 和 asmdba否则数据库软件连接 ASM 会因 OS 权限不足而失败grid 主组同样是 oinstall附属组必须有 asmadmin、asmdbaasmadmin 是管理 ASM 磁盘组的必需组成员dba 组是为了让 grid 也能以 SYSDBA 身份连 ASM。这一步容易抄错的是把 oracle 加进 asmadmin。生产上不建议给 oracle 分配 asmadmin避免一个账号里同时握有数据库和磁盘组的双重管理权日常变更容易误伤。两个节点都要建相同的用户和组UID/GID 保持一致跨节点做 rman duplicate 或 DG 文件访问时才不会出现属主不匹配。2.3 内核参数和 limits.confshmall 与 shmmax 怎么配19C 的预检查项包括 aio-max-nr、shmmax、sem、本地端口范围等。文档给的 /etc/sysctl.conf 是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参数含义上shmmax 决定单个共享内存段上限20G 物理内存的机器按一半取 12640516096约 11.7G是合理做法shmall 以页为单位配置 4294967296 页意味着约 16T 的共享内存总量保证 SGA 足够大时不会因共享内存总量不足而分配失败。注释里的 shmall2097152、shmmax4294967295 是旧版本模板在 19C 上按文档覆盖即可。改完运行 sysctl -p 生效。这里有个环境叠加要注意如果机器上预装过数据库或 Keepalived重新加载内核参数前先确认没有进程使用旧的共享内存配置否则 sysctl -p 会提示无法设置需要等共享内存段释放后再执行。内核参数之后是用户资源限制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 3145728memlock 单位是 KB3145728 KB 即 3GB 锁定内存SGA 会尝试把内存页锁住避免被换出。19C 预检对 memlock 有硬校验设小了直接报错。nofile 在生产上建议直接给 65536而不是文档最低线 1024否则连接数上来以后很容易碰到文件描述符瓶颈。对应还需要确认 /etc/pam.d/login 里包含 session required pam_limits.so缺了这行 limits.conf 不会真正生效。很多环境漏这一步导致 precheck 显示 ORA-12162 或权限相关的怪异报错。2.4 时间同步与依赖包chrony 关掉、compat-libstdc 手动装19C 的 ASM 实例内部依赖 Cluster Time Synchronization ServiceCTSS来保证节点时间一致。如果系统里开着 chrony 或 ntpdCTSS 会自动进入观察模式反而可能不主动校正时间。实验环境里文档的做法是直接关闭 chrony把时间同步交给 Oracle 自己的 ctssd 管理systemctl disable chronyd systemctl stop chronyd mv /etc/chrony.conf /etc/chrony.conf_bak注意这一步只适合测试或双节点实验环境生产环境请保留 NTP 或 chrony 作为外部时间源两套方案二选一不能同时开。依赖包检查用 rpm -q 批量核对rpm -q --qf %{NAME}-%{VERSION}-%{RELEASE} (%{ARCH})\n bc \ binutils compat-libcap1 compat-libstdc-33 glibc glibc-devel \ ksh libaio libaio-devel libX11 libXau libXi libXtst \ libXrender-devel libXrender libgcc libstdc libstdc-devel \ libxcb make nfs-utils net-tools python smartmontools sysstat targetcliRHEL 7.6 的镜像里没有 compat-libstdc-33需要单独下载 compat-libstdc-33-3.2.3-72.el7.i686.rpm 和 x86_64 两个包手动安装。这个包大多是给旧版本客户端的 glibc 依赖用的19C 预检会检查它缺了直接导致 precheck 失败。yum 安装时用 yum install 装主包集合即可文档里安装命令写的是 python-configshell8如果仓库里没有这个包名就装 python-configshell关键是让 resolver 把 rtslib 和 six 依赖拉全。另外一个容易忽略的是 /etc/sysconfig/network。文档里对这个文件做了 chmod 644 并追加 NOZEROCONFyes原因是 RHEL 7 上如果没有明确声明 NOZEROCONF网络服务可能对主机的默认路由做多余处理干扰 GI 的网络接口判断。我习惯在装 GI 之前就把这个文件固定好避免 root.sh 阶段还回头改网络配置。3. ASM 磁盘绑定udev 规则里 RESULT 与 mknod 的踩坑点ASM 磁盘绑定是 19C 安装里最容易被玄学问题困扰的一步。GI 安装界面启动后如果发现候选磁盘数为 090% 都是 udev 规则没生效或者 RESULT 匹配不精确。3.1 获取磁盘 SCSI ID先把 4 块共享盘的 SCSI 标识取出来/usr/lib/udev/scsi_id -g -u /dev/sdc /usr/lib/udev/scsi_id -g -u /dev/sdd /usr/lib/udev/scsi_id -g -u /dev/sde /usr/lib/udev/scsi_id -g -u /dev/sdfscsi_id 输出的是磁盘的 WWID 一类唯一标识。在 VMware 或 KVM 虚拟机里SCSI 直通盘的 ID 是类似 36000c29... 的长串物理机多路径环境下建议对多路径设备跑同一命令拿 WWID而不是对 sd 设备做绑定因为 sd 设备名重启后可能漂移WWID 稳定。参数说明-g 表示使用 udev 兼容格式输出-u 表示输出未转义的 UID-d 指定设备节点。生产上我一般先跑一个 for 循环把候选盘全打印出来确认哪几个是同组共享盘、哪个是本地盘别把系统盘绑进 ASM。for disk in sdc sdd sde sdf; do echo -n $disk: /usr/lib/udev/scsi_id -g -u -d /dev/$disk done如果是在虚拟化平台做这套记得把共享盘设为独立持久化模式别让快照把它们卷进去。否则 ASM 在节点状态变化时可能出现 IO 冲突到时候查起来非常绕。3.2 编写 udev 规则RESULT 必须与 scsi_id 输出完全一致文档给的规则文件是 /etc/udev/rules.d/99-my-asmdevices.rules每条规则针对一块盘KERNELsd*[!0-9], ENV{DEVTYPE}disk, SUBSYSTEMblock, \ PROGRAM/usr/lib/udev/scsi_id -g -u -d $devnode, \ RESULT36000c291ca220c52c813c595ffdf14f4, \ RUN/bin/sh -c mknod /dev/asmdisk01 b $major $minor; chown grid:asmadmin /dev/asmdisk01; chmod 0660 /dev/asmdisk01规则逻辑拆开看KERNEL 匹配 sd 开头的块设备且不带数字分区PROGRAM 在设备事件发生时调用 scsi_id 读取标识RESULT 与 PROGRAM 输出做精确比较匹配成功则执行 RUN 里的命令。RUN 里用 $major、$minor 动态取得设备号mknod 生成固定设备节点再把属主改成 grid:asmadmin、权限设为 0660。这里最容易踩的坑有三个。第一RESULT 里的 WWID 手抄错一位或者从网页复制规则时引号被转成中文引号规则直接失效第二KERNELsd*[!0-9] 只匹配 sd 设备如果是 vd 或 mpath 开头规则不生效需要把匹配规则改成对应前缀第三mknod 前没有删除旧节点或者 /dev/asmdisk01 已存在导致节点生成失败这种通常伴随报错要先把旧的 /dev/asmdisk* 清干净再触发。3.3 触发加载与权限验证规则写完后执行触发/sbin/udevadm trigger --typedevices --actionchange ls -l /dev/asmdisk01 /dev/asmdisk02 /dev/asmdisk03 /dev/asmdisk04正常输出应该四块盘全部存在属主都是 grid:asmadmin权限 0660。如果少了某一块先检查 dmesg 里 udev 事件是否报错再核对 RESULT 与 scsi_id 输出是否完全一致。方便起见可以写一条独立校验直接执行规则里的 PROGRAM 命令看输出再和规则里的 RESULT 逐字符比对。两台节点都要做同样的绑定且设备的 WWID 必须一一对应。我曾经遇到主节点绑了 01-04备节点只绑了两块结果 GI 配置完成后 ASM 同步复制数据的磁盘组在备库侧连 mount 都做不到。配 ASM 磁盘前两个节点各自 ls /dev/asmdisk* 并核对数量是很便宜的一道防线。4. 安装 Grid Infrastructurestandalone server 与磁盘组的三个选择GI 软件全称是 Grid Infrastructure。在 19C 单实例 ASM 场景里GI 只提供 ASM 实例和集群件服务不跑 RAC。安装方式上用图形化的 gridSetup.sh比静默模式直观得多。4.1 GI 解压与安装入口文档里 GI 的解压和安装是同一个目录export ORACLE_BASE/app/grid export ORACLE_HOME/app/product/19.2.0/crs unzip V981627-01.zip -d /app/product/19.2.0/crs /app/product/19.2.0/crs/gridSetup.sh注意这里 ORACLE_HOME 就是 /app/product/19.2.0/crsGI 软件解压后 gridSetup.sh 位于该目录下运行时 OUI 会自动识别 ORACLE_HOME 而无需重复填写。如果 ORACLE_HOME 环境变量和解压目录不一致OUI 会提示 home 目录不匹配甚至要求重新解压。解压前先确认 /app 分区剩余空间。GI 安装会写入 oraInventory、日志和 root.sh 临时产生的集群配置空间不足时 gridSetup.sh 跑到一半报错非常麻烦。文档里管理密码配置为 oracle19C 对 GI 密码策略允许在安装界面自定义但建议口令至少 8 位且含大小写字母和数字纯小写 oracle 只是实验环境的偷懒做法生产环境别这么干。V981627-01.zip 是对应 19.3 版本的 GI 安装包数据库软件包是 V981623-01.zip。两个 zip 解压后目录不要混放一份 ORACLE_HOME 就装一套 GI另外一套 ORACLE_HOME 留给数据库软件。4.2 standalone server 选项单实例 ASM 的起点gridSetup.sh 启动后在配置类型界面选择 standalone server这是单实例 ASM 的入口。选 RAC 或 RAC One 会进入集群配置流程要求配置两个节点的心跳网络与私网和当前目标不符。选 standalone server 后OUI 会自动启用本地 ASM 实例并只创建可选的 ASM 磁盘组所需的资源。文档中明确本次是单实例数据库配置点选 standalone server所以后续只出现一个节点的环境检查和 root.sh 执行不会要求配私网网卡。安装过程中 OUI 会检查网络接口如果机器上有多个网卡它可能提示选择公网网卡这里保持默认就行跟 RAC 的公共网络和 ASM 监听配置不同。root.sh 执行时会把 OHASD 注册为系统服务并把集群件启动到 ONLINE。RHEL 7 用的是 systemdroot.sh 会生成一个 ohasd.service 的 unit 文件。这一步失败通常和网络配置有关也就是前面提的 NOZEROCONF 和 avahi-daemonsystemctl stop avahi-daemon systemctl disable avahi-daemonavahi-daemon 会抢占链路本地地址并干扰 GI 对网络接口的判断不关掉它 root.sh 大概率会出现 CRS-5011 或者 ohasd 起不来的现象。root.sh 执行成功后用 crsctl 确认集群件状态crsctl check has crsctl stat res -t正常输出里 ohasd 和 cssd 都应是 ONLINE。这一步做完ASM 实例会被自动拉起可以用前端页面继续后续配置。4.3 磁盘组与密码策略Normal Redundancy 的选择逻辑进入 ASM 磁盘组配置界面后磁盘组名称文档给的是 DATA发现路径点 change discovery path 去扫描 /dev/asmdisk* 那组设备。如果扫描结果为空回到第 3 章检查 udev 规则别急着重跑安装。Redundancy 模式选 Normal意味着每个 extent 在两块磁盘上各有一份镜像允许任意一块盘 fail 而不丢数据External 模式则完全依赖存储自身冗余。两块盘以上才建议 Normal文档环境里有 4 块盘选 Normal 是合理的既保证可靠性也为后续加盘留了余量。如果生产环境只有一块可用盘就退回到 External否则 ASM 会强制要求故障组。密码设置上ASMSNMP 和 SYSASM 的密码在安装界面里统一设置。给 ASM 实例设置完密码后安装脚本会把密码记录到 GI 的 wallet 里后续 asmca、asmcmd 或 OEM 监控都要用到。我一般会在一张本地笔记里记录 SYSASM 密码和磁盘组名称的对应关系防止半年后自己忘了 ASMSNMP 口令导致监控全部失灵。5. DataGuard 搭建与常见问题排查五个高频拦路点文档里 DataGuard 部分相对简单主备库节点分别为 node2 和 node2dg。这里基于 19C 数据库软件安装完成、两个实例已经用 dbca 建库或克隆出来的前提展开 DG 的最小配置链路。5.1 主库与备库的基础参数设置先在主库上开 force logging并指定 DG 配置名与传输目标ALTER DATABASE FORCE LOGGING; ALTER SYSTEM SET LOG_ARCHIVE_CONFIGDG_CONFIG(node2,node2dg); ALTER SYSTEM SET LOG_ARCHIVE_DEST_2SERVICEnode2dg LGWR ASYNC VALID_FOR(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAMEnode2dg; ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2ENABLE; ALTER SYSTEM SET FAL_SERVERnode2dg; ALTER SYSTEM SET STANDBY_FILE_MANAGEMENTAUTO; ALTER SYSTEM SET DB_UNIQUE_NAMEnode2 SCOPESPFILE;参数说明SERVICE 后面跟的是 tnsnames.ora 里定义到备库的别名不是主机名LGWR ASYNC 表示日志写入进程异步传输对主库性能影响小但容灾 RPO 会比 SYNC 略高。VALID_FOR 两个括号里的值限定该归档路径的生效范围第一个括号表示适用于在线日志文件第二个括号表示只在主库角色下生效这个组合能让主备切换后自动禁用此路径避免备库继续往主库方向传日志。FAL_SERVER 是备库请求缺失归档时向主库要日志的服务器主备两侧要互相指向对方。DB_UNIQUE_NAME 是 DG 组内唯一标识主备库各自的 db_unique_name 不能相同后续 dgmgrl 和 v$dataguard_stats 都依赖它。备库上对应的配置方向反过来ALTER SYSTEM SET DB_UNIQUE_NAMEnode2dg SCOPESPFILE; ALTER SYSTEM SET LOG_ARCHIVE_CONFIGDG_CONFIG(node2,node2dg); ALTER SYSTEM SET LOG_ARCHIVE_DEST_2SERVICEnode2 LGWR ASYNC VALID_FOR(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAMEnode2; ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2ENABLE; ALTER SYSTEM SET FAL_SERVERnode2;两份配置里主备库的 db_unique_name 必须和初始化参数、tnsnames 别名全部对齐。如果主库 LOG_ARCHIVE_DEST_2 的 DB_UNIQUE_NAME 写成 node2 而不是 node2dg备库会拒绝接收alert 日志里反复出现 ORA-16607。配完参数后主备库分别启用 DG brokerALTER SYSTEM SET DG_BROKER_STARTTRUE;备库是否由 broker 管理不影响日志传输本身但启用后才能在 dgmgrl 里做 switchover 和 failover 管理。5.2 备库搭建RMAN duplicate 与备库日志应用备库的物理文件用 rman duplicate 从主库拉一份。先保证备库实例处于 NOMOUNT再执行rman target sys/oraclenode2 auxiliary sys/oraclenode2dg RMAN DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE DBSID node2dg SPFILE SET DB_UNIQUE_NAMEnode2dg SET LOG_ARCHIVE_DEST_2SERVICEnode2 LGWR ASYNC VALID_FOR(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAMEnode2 SET FAL_SERVERnode2 NOFILENAMECHECK;FROM ACTIVE DATABASE 直接从主库在线拷贝数据文件不走备份集能省很多时间。SPFILE 子句让 duplicate 同时生成备库的 spfile。NOFILENAMECHECK 是当主备库文件路径不一致时避免做文件名匹配的开关但如果两边 ASM 磁盘组路径本来就一致去掉也无妨。备库创建完成后先为主库补一组 standby redo log。19C 的推荐做法是给每个线程配置 (在线日志组数1) 组 standby log大小与在线日志相同ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 SIZE 200M; ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 SIZE 200M; ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 SIZE 200M; ALTER DATABASE ADD STANDBY LOGFILE GROUP 7 SIZE 200M;没有 standby redo log 时备库也可以应用日志但会对归档文件做额外读取切换时也可能因为最后一段在线日志没被归档而产生差异。加上 standby redo log 后主库在线日志切换的写入路径会更平滑。然后启动 MRP 进程应用日志ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;USING CURRENT LOGFILE 表示既应用归档日志也直接应用在线日志这一项决定了备库能否在无归档中断的情况下持续同步。执行后查询 v$managed_standby 应有 MRP0 进程处于 APPLYING_LOG 状态。在 19C 里备库这套用 dbca 初始化成独立实例再 rman duplicate 是常见做法也可以用 dbca 的 createDuplicateDatabase 向导但命令行方式更好排查也方便在脚本里复现。5.3 常见问题排查现象、原因、解决第一坑备库 alert 日志反复刷 ORA-12514MRP 卡在 WAIT_FOR_LOG。原因是 LOG_ARCHIVE_DEST_2 中 SERVICE 指向的 tnsnames 别名里 SERVICE_NAME 填了 ORACLE_SID而不是备库实际监听的服务名。解决方法是把 tnsnames.ora 中 node2dg 条目的 SERVICE_NAME 配成备库的 service_name并用 tnsping 确认能通。第二坑root.sh 执行后 ohasd 起不来CRS-5011 报资源无法启动。原因通常是 avahi-daemon 未禁用或者 /etc/sysconfig/network 里没有 NOZEROCONFyes。解决先停止并禁用 avahi-daemon再追加 NOZEROCONFyes 到 network 文件最后重新执行 root.sh。第三坑19C 预检报 compat-libstdc-33 not found。原因RHEL 7.6 ISO 与在线 yum 源里确实没有这个包。解决手动下载 compat-libstdc-33-3.2.3-72.el7.i686.rpm 和 x86_64 两个 RPM 用 rpm -ivh 安装然后重新跑预检。第四坑备库 MRP 进程启动时报 ORA-16191 或 ORA-16607。原因主备库 SYS 密码不一致或者 log_archive_config 的 DG_CONFIG 与实际 db_unique_name 没对齐。解决主备库分别把 SYS 密码改成同一个重建密码文件再检查 DG_CONFIG 配置。第五坑switchover 后新主库无法继续传输日志。原因手工切换时 tnsnames 别名指向旧主库或 FAL_SERVER 方向未更新。解决用 dgmgrl 做 switchover 而不是手工切换broker 会自动反转日志传输方向手工切换路径下必须手动更新两边的 LOG_ARCHIVE_DEST_n。6. 验证 DataGuard 是否真正生效切换演练与日常检查习惯DG 搭建完不等于可以用真正有意义的是验证。我每次部署完都会做一轮状态查询、日志应用确认和一次完整的 switchover 演练。状态查询是第一步SELECT DATABASE_ROLE, DB_UNIQUE_NAME, OPEN_MODE, PROTECTION_MODE FROM V$DATABASE; SELECT PROCESS, STATUS, CLIENT_PROCESS FROM V$MANAGED_STANDBY WHERE PROCESS LIKE MRP%;主库应显示 PRIMARY_ROLE备库显示 PHYSICAL STANDBY 且 OPEN_MODE 为 READ ONLY WITH APPLY。MRP0 处于 APPLYING_LOG 说明日志持续应用。再查 redo 传输延迟SELECT NAME, VALUE, UNIT, TIME_COMPUTED FROM V$DATAGUARD_STATS;关注 APPLY_LAG 和 TRANSPORT_LAG正常应在几秒内。如果 LAG 持续增长看主库的归档进程是否被阻塞备库磁盘是否有压力。switchover 演练是唯一能证明 DG 真实可切换的动作。在 dgmgrl 里执行dgmgrl sys/oraclenode2 DGMGRL SHOW CONFIGURATION DGMGRL SWITCHOVER TO node2dgbroker 会先检查两边状态再自动完成日志传输反转、角色切换与启动。演练完后再用相同命令切回主库确认两个节点回到原角色。从那以后我每次建完 DG 都强制自己跑一轮上述流程哪怕只花了十分钟。dgmgrl 的 show configuration 和 v$dataguard_stats 这两条命令基本写进了日常巡检清单希望帮到你。本文还有配套的精品资源点击获取
简介RHEL 7.6环境下搭建Oracle 19C数据库高可用架构的完整实操指南面向系统运维与数据库管理员重点解决ASM存储管理与Data Guard主从复制的部署难点。资源为PDF格式单文件压缩包仅4.68MB内容按实际部署流程组织从硬件需求、软件版本V981623-01.zip与V981627-01.zip、节点规划、目录设计到网络配置均有明确说明。指南详细演示了Oracle 19C数据库软件安装、ASM磁盘组配置、Data Guard主备库搭建与网络环境设置并针对安装路径预创建、权限调整、软件包检查等易错环节给出注意事项。文中基于node2主库与node2dg备库的真实操作记录提供清晰的命令示例、验证步骤及常见问题应对思路可帮助读者避开部署中的关键坑点快速构建稳定可用的高可用数据库环境。现有703人学习适合需要独立完成RHEL 7.6Oracle 19CASMData Guard部署的运维与DBA人员参考。1. RHEL 7.6 装 Oracle 19C ASM DataGuard一次双节点实战复盘Oracle 19C 是我装过的最容易在环境预检阶段卡住的版本尤其在 RHEL 7.6 上叠加 ASM 和 DataGuard 时一次部署要串联系统预配置、共享盘绑定、GI 安装、DG 搭建四条链路任何一环没对齐后面全被拖垮。这份资源是一套完整的双节点实验记录主库节点 node2、物理备库节点 node2dg4 块共享盘走 udev 绑定进 ASMGI 用 standalone server 模式搭建单实例 ASM再靠 DataGuard 日志传输把备库拉起。适合已经装过单机版、想在测试机复刻一套 19C ASM DG 高可用拓扑的 DBA 或准 DBA 照着做一遍。2. 安装前的系统预配置目录、用户组、内核参数与两个易错点19C 的安装前准备比 11g 敏感得多OUI 在预检阶段严格核对路径、内核参数、依赖包和用户组。我见过不少机器卡在 precheck 的 compat-libstdc 缺失也见过 root.sh 因为 NOZEROCONF 没配而反复起不来 OHASD这些都是环境阶段埋的雷。2.1 目录规划为什么必须先建全路径文档里的路径规划分成 GI 和 ORACLE 两套# GI 路径 export ORACLE_BASE/app/grid export ORACLE_HOME/app/product/19.2.0/crs mkdir -p /app/grid mkdir -p /app/product/19.2.0/crs mkdir -p /app/oraInventory # ORACLE 路径 export ORACLE_BASE/app/oracle export ORACLE_HOME/app/oracle/product/19.2.0/dbhome_1 mkdir -p /app/oracle/product/19.2.0/dbhome_1注需提前创建好全路径否则安装软件时检测不到路径。软件会安装在 gridSetup 所在路径。这里的关键不是 mkdir 本身而是 19C 的 OUI 不会帮你补建 ORACLE_HOME。11g 时代路径不存在时安装界面还能容忍18c/19c 的预检会直接报路径无法创建导致装配无法继续。mkdir -p 会连中间目录一并生成所以你只需要保证 /app 有足够空间以及全程用统一的分区规划。解压前先确认 /app 分区至少剩余 15G。GI 安装会写入 oraInventory、日志和 root.sh 产生的集群配置空间不足时 gridSetup.sh 跑到一半报磁盘空间不足非常麻烦。文档里主库 /app 是 45G、备库 40G从这个容量看是给 GI 软件、数据库软件和后续数据库文件都留了余量的。我一般还会额外创建 /app/tmp 并 export TEMP/app/tmp让 OUI 与各种脚本把临时文件写到独立目录避免默认 /tmp 空间或 inode 被吃满。数据库安装过程中的临时日志、OUI 备份文件都不小这条在文档里也有体现。2.2 用户与组划分grid/oracle 的附属组怎么给19C 的 ASM 与数据库分离力度比 11g 大。grid 用户负责 GI 和 ASMoracle 用户负责数据库软件。组划分如果给错了后面运行 root.sh 或者 asmca 会持续报权限错。/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 /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参数说明-g 指定主组-G 指定附属组。oracle 的主组是 oinstall附属组里必须有 dba 和 asmdba否则数据库软件连接 ASM 会因 OS 权限不足而失败grid 主组同样是 oinstall附属组必须有 asmadmin、asmdbaasmadmin 是管理 ASM 磁盘组的必需组成员dba 组是为了让 grid 也能以 SYSDBA 身份连 ASM。这一步容易抄错的是把 oracle 加进 asmadmin。生产上不建议给 oracle 分配 asmadmin避免一个账号里同时握有数据库和磁盘组的双重管理权日常变更容易误伤。两个节点都要建相同的用户和组UID/GID 保持一致跨节点做 rman duplicate 或 DG 文件访问时才不会出现属主不匹配。2.3 内核参数和 limits.confshmall 与 shmmax 怎么配19C 的预检查项包括 aio-max-nr、shmmax、sem、本地端口范围等。文档给的 /etc/sysctl.conf 是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参数含义上shmmax 决定单个共享内存段上限20G 物理内存的机器按一半取 12640516096约 11.7G是合理做法shmall 以页为单位配置 4294967296 页意味着约 16T 的共享内存总量保证 SGA 足够大时不会因共享内存总量不足而分配失败。注释里的 shmall2097152、shmmax4294967295 是旧版本模板在 19C 上按文档覆盖即可。改完运行 sysctl -p 生效。这里有个环境叠加要注意如果机器上预装过数据库或 Keepalived重新加载内核参数前先确认没有进程使用旧的共享内存配置否则 sysctl -p 会提示无法设置需要等共享内存段释放后再执行。内核参数之后是用户资源限制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 3145728memlock 单位是 KB3145728 KB 即 3GB 锁定内存SGA 会尝试把内存页锁住避免被换出。19C 预检对 memlock 有硬校验设小了直接报错。nofile 在生产上建议直接给 65536而不是文档最低线 1024否则连接数上来以后很容易碰到文件描述符瓶颈。对应还需要确认 /etc/pam.d/login 里包含 session required pam_limits.so缺了这行 limits.conf 不会真正生效。很多环境漏这一步导致 precheck 显示 ORA-12162 或权限相关的怪异报错。2.4 时间同步与依赖包chrony 关掉、compat-libstdc 手动装19C 的 ASM 实例内部依赖 Cluster Time Synchronization ServiceCTSS来保证节点时间一致。如果系统里开着 chrony 或 ntpdCTSS 会自动进入观察模式反而可能不主动校正时间。实验环境里文档的做法是直接关闭 chrony把时间同步交给 Oracle 自己的 ctssd 管理systemctl disable chronyd systemctl stop chronyd mv /etc/chrony.conf /etc/chrony.conf_bak注意这一步只适合测试或双节点实验环境生产环境请保留 NTP 或 chrony 作为外部时间源两套方案二选一不能同时开。依赖包检查用 rpm -q 批量核对rpm -q --qf %{NAME}-%{VERSION}-%{RELEASE} (%{ARCH})\n bc \ binutils compat-libcap1 compat-libstdc-33 glibc glibc-devel \ ksh libaio libaio-devel libX11 libXau libXi libXtst \ libXrender-devel libXrender libgcc libstdc libstdc-devel \ libxcb make nfs-utils net-tools python smartmontools sysstat targetcliRHEL 7.6 的镜像里没有 compat-libstdc-33需要单独下载 compat-libstdc-33-3.2.3-72.el7.i686.rpm 和 x86_64 两个包手动安装。这个包大多是给旧版本客户端的 glibc 依赖用的19C 预检会检查它缺了直接导致 precheck 失败。yum 安装时用 yum install 装主包集合即可文档里安装命令写的是 python-configshell8如果仓库里没有这个包名就装 python-configshell关键是让 resolver 把 rtslib 和 six 依赖拉全。另外一个容易忽略的是 /etc/sysconfig/network。文档里对这个文件做了 chmod 644 并追加 NOZEROCONFyes原因是 RHEL 7 上如果没有明确声明 NOZEROCONF网络服务可能对主机的默认路由做多余处理干扰 GI 的网络接口判断。我习惯在装 GI 之前就把这个文件固定好避免 root.sh 阶段还回头改网络配置。3. ASM 磁盘绑定udev 规则里 RESULT 与 mknod 的踩坑点ASM 磁盘绑定是 19C 安装里最容易被玄学问题困扰的一步。GI 安装界面启动后如果发现候选磁盘数为 090% 都是 udev 规则没生效或者 RESULT 匹配不精确。3.1 获取磁盘 SCSI ID先把 4 块共享盘的 SCSI 标识取出来/usr/lib/udev/scsi_id -g -u /dev/sdc /usr/lib/udev/scsi_id -g -u /dev/sdd /usr/lib/udev/scsi_id -g -u /dev/sde /usr/lib/udev/scsi_id -g -u /dev/sdfscsi_id 输出的是磁盘的 WWID 一类唯一标识。在 VMware 或 KVM 虚拟机里SCSI 直通盘的 ID 是类似 36000c29... 的长串物理机多路径环境下建议对多路径设备跑同一命令拿 WWID而不是对 sd 设备做绑定因为 sd 设备名重启后可能漂移WWID 稳定。参数说明-g 表示使用 udev 兼容格式输出-u 表示输出未转义的 UID-d 指定设备节点。生产上我一般先跑一个 for 循环把候选盘全打印出来确认哪几个是同组共享盘、哪个是本地盘别把系统盘绑进 ASM。for disk in sdc sdd sde sdf; do echo -n $disk: /usr/lib/udev/scsi_id -g -u -d /dev/$disk done如果是在虚拟化平台做这套记得把共享盘设为独立持久化模式别让快照把它们卷进去。否则 ASM 在节点状态变化时可能出现 IO 冲突到时候查起来非常绕。3.2 编写 udev 规则RESULT 必须与 scsi_id 输出完全一致文档给的规则文件是 /etc/udev/rules.d/99-my-asmdevices.rules每条规则针对一块盘KERNELsd*[!0-9], ENV{DEVTYPE}disk, SUBSYSTEMblock, \ PROGRAM/usr/lib/udev/scsi_id -g -u -d $devnode, \ RESULT36000c291ca220c52c813c595ffdf14f4, \ RUN/bin/sh -c mknod /dev/asmdisk01 b $major $minor; chown grid:asmadmin /dev/asmdisk01; chmod 0660 /dev/asmdisk01规则逻辑拆开看KERNEL 匹配 sd 开头的块设备且不带数字分区PROGRAM 在设备事件发生时调用 scsi_id 读取标识RESULT 与 PROGRAM 输出做精确比较匹配成功则执行 RUN 里的命令。RUN 里用 $major、$minor 动态取得设备号mknod 生成固定设备节点再把属主改成 grid:asmadmin、权限设为 0660。这里最容易踩的坑有三个。第一RESULT 里的 WWID 手抄错一位或者从网页复制规则时引号被转成中文引号规则直接失效第二KERNELsd*[!0-9] 只匹配 sd 设备如果是 vd 或 mpath 开头规则不生效需要把匹配规则改成对应前缀第三mknod 前没有删除旧节点或者 /dev/asmdisk01 已存在导致节点生成失败这种通常伴随报错要先把旧的 /dev/asmdisk* 清干净再触发。3.3 触发加载与权限验证规则写完后执行触发/sbin/udevadm trigger --typedevices --actionchange ls -l /dev/asmdisk01 /dev/asmdisk02 /dev/asmdisk03 /dev/asmdisk04正常输出应该四块盘全部存在属主都是 grid:asmadmin权限 0660。如果少了某一块先检查 dmesg 里 udev 事件是否报错再核对 RESULT 与 scsi_id 输出是否完全一致。方便起见可以写一条独立校验直接执行规则里的 PROGRAM 命令看输出再和规则里的 RESULT 逐字符比对。两台节点都要做同样的绑定且设备的 WWID 必须一一对应。我曾经遇到主节点绑了 01-04备节点只绑了两块结果 GI 配置完成后 ASM 同步复制数据的磁盘组在备库侧连 mount 都做不到。配 ASM 磁盘前两个节点各自 ls /dev/asmdisk* 并核对数量是很便宜的一道防线。4. 安装 Grid Infrastructurestandalone server 与磁盘组的三个选择GI 软件全称是 Grid Infrastructure。在 19C 单实例 ASM 场景里GI 只提供 ASM 实例和集群件服务不跑 RAC。安装方式上用图形化的 gridSetup.sh比静默模式直观得多。4.1 GI 解压与安装入口文档里 GI 的解压和安装是同一个目录export ORACLE_BASE/app/grid export ORACLE_HOME/app/product/19.2.0/crs unzip V981627-01.zip -d /app/product/19.2.0/crs /app/product/19.2.0/crs/gridSetup.sh注意这里 ORACLE_HOME 就是 /app/product/19.2.0/crsGI 软件解压后 gridSetup.sh 位于该目录下运行时 OUI 会自动识别 ORACLE_HOME 而无需重复填写。如果 ORACLE_HOME 环境变量和解压目录不一致OUI 会提示 home 目录不匹配甚至要求重新解压。解压前先确认 /app 分区剩余空间。GI 安装会写入 oraInventory、日志和 root.sh 临时产生的集群配置空间不足时 gridSetup.sh 跑到一半报错非常麻烦。文档里管理密码配置为 oracle19C 对 GI 密码策略允许在安装界面自定义但建议口令至少 8 位且含大小写字母和数字纯小写 oracle 只是实验环境的偷懒做法生产环境别这么干。V981627-01.zip 是对应 19.3 版本的 GI 安装包数据库软件包是 V981623-01.zip。两个 zip 解压后目录不要混放一份 ORACLE_HOME 就装一套 GI另外一套 ORACLE_HOME 留给数据库软件。4.2 standalone server 选项单实例 ASM 的起点gridSetup.sh 启动后在配置类型界面选择 standalone server这是单实例 ASM 的入口。选 RAC 或 RAC One 会进入集群配置流程要求配置两个节点的心跳网络与私网和当前目标不符。选 standalone server 后OUI 会自动启用本地 ASM 实例并只创建可选的 ASM 磁盘组所需的资源。文档中明确本次是单实例数据库配置点选 standalone server所以后续只出现一个节点的环境检查和 root.sh 执行不会要求配私网网卡。安装过程中 OUI 会检查网络接口如果机器上有多个网卡它可能提示选择公网网卡这里保持默认就行跟 RAC 的公共网络和 ASM 监听配置不同。root.sh 执行时会把 OHASD 注册为系统服务并把集群件启动到 ONLINE。RHEL 7 用的是 systemdroot.sh 会生成一个 ohasd.service 的 unit 文件。这一步失败通常和网络配置有关也就是前面提的 NOZEROCONF 和 avahi-daemonsystemctl stop avahi-daemon systemctl disable avahi-daemonavahi-daemon 会抢占链路本地地址并干扰 GI 对网络接口的判断不关掉它 root.sh 大概率会出现 CRS-5011 或者 ohasd 起不来的现象。root.sh 执行成功后用 crsctl 确认集群件状态crsctl check has crsctl stat res -t正常输出里 ohasd 和 cssd 都应是 ONLINE。这一步做完ASM 实例会被自动拉起可以用前端页面继续后续配置。4.3 磁盘组与密码策略Normal Redundancy 的选择逻辑进入 ASM 磁盘组配置界面后磁盘组名称文档给的是 DATA发现路径点 change discovery path 去扫描 /dev/asmdisk* 那组设备。如果扫描结果为空回到第 3 章检查 udev 规则别急着重跑安装。Redundancy 模式选 Normal意味着每个 extent 在两块磁盘上各有一份镜像允许任意一块盘 fail 而不丢数据External 模式则完全依赖存储自身冗余。两块盘以上才建议 Normal文档环境里有 4 块盘选 Normal 是合理的既保证可靠性也为后续加盘留了余量。如果生产环境只有一块可用盘就退回到 External否则 ASM 会强制要求故障组。密码设置上ASMSNMP 和 SYSASM 的密码在安装界面里统一设置。给 ASM 实例设置完密码后安装脚本会把密码记录到 GI 的 wallet 里后续 asmca、asmcmd 或 OEM 监控都要用到。我一般会在一张本地笔记里记录 SYSASM 密码和磁盘组名称的对应关系防止半年后自己忘了 ASMSNMP 口令导致监控全部失灵。5. DataGuard 搭建与常见问题排查五个高频拦路点文档里 DataGuard 部分相对简单主备库节点分别为 node2 和 node2dg。这里基于 19C 数据库软件安装完成、两个实例已经用 dbca 建库或克隆出来的前提展开 DG 的最小配置链路。5.1 主库与备库的基础参数设置先在主库上开 force logging并指定 DG 配置名与传输目标ALTER DATABASE FORCE LOGGING; ALTER SYSTEM SET LOG_ARCHIVE_CONFIGDG_CONFIG(node2,node2dg); ALTER SYSTEM SET LOG_ARCHIVE_DEST_2SERVICEnode2dg LGWR ASYNC VALID_FOR(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAMEnode2dg; ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2ENABLE; ALTER SYSTEM SET FAL_SERVERnode2dg; ALTER SYSTEM SET STANDBY_FILE_MANAGEMENTAUTO; ALTER SYSTEM SET DB_UNIQUE_NAMEnode2 SCOPESPFILE;参数说明SERVICE 后面跟的是 tnsnames.ora 里定义到备库的别名不是主机名LGWR ASYNC 表示日志写入进程异步传输对主库性能影响小但容灾 RPO 会比 SYNC 略高。VALID_FOR 两个括号里的值限定该归档路径的生效范围第一个括号表示适用于在线日志文件第二个括号表示只在主库角色下生效这个组合能让主备切换后自动禁用此路径避免备库继续往主库方向传日志。FAL_SERVER 是备库请求缺失归档时向主库要日志的服务器主备两侧要互相指向对方。DB_UNIQUE_NAME 是 DG 组内唯一标识主备库各自的 db_unique_name 不能相同后续 dgmgrl 和 v$dataguard_stats 都依赖它。备库上对应的配置方向反过来ALTER SYSTEM SET DB_UNIQUE_NAMEnode2dg SCOPESPFILE; ALTER SYSTEM SET LOG_ARCHIVE_CONFIGDG_CONFIG(node2,node2dg); ALTER SYSTEM SET LOG_ARCHIVE_DEST_2SERVICEnode2 LGWR ASYNC VALID_FOR(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAMEnode2; ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2ENABLE; ALTER SYSTEM SET FAL_SERVERnode2;两份配置里主备库的 db_unique_name 必须和初始化参数、tnsnames 别名全部对齐。如果主库 LOG_ARCHIVE_DEST_2 的 DB_UNIQUE_NAME 写成 node2 而不是 node2dg备库会拒绝接收alert 日志里反复出现 ORA-16607。配完参数后主备库分别启用 DG brokerALTER SYSTEM SET DG_BROKER_STARTTRUE;备库是否由 broker 管理不影响日志传输本身但启用后才能在 dgmgrl 里做 switchover 和 failover 管理。5.2 备库搭建RMAN duplicate 与备库日志应用备库的物理文件用 rman duplicate 从主库拉一份。先保证备库实例处于 NOMOUNT再执行rman target sys/oraclenode2 auxiliary sys/oraclenode2dg RMAN DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE DBSID node2dg SPFILE SET DB_UNIQUE_NAMEnode2dg SET LOG_ARCHIVE_DEST_2SERVICEnode2 LGWR ASYNC VALID_FOR(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAMEnode2 SET FAL_SERVERnode2 NOFILENAMECHECK;FROM ACTIVE DATABASE 直接从主库在线拷贝数据文件不走备份集能省很多时间。SPFILE 子句让 duplicate 同时生成备库的 spfile。NOFILENAMECHECK 是当主备库文件路径不一致时避免做文件名匹配的开关但如果两边 ASM 磁盘组路径本来就一致去掉也无妨。备库创建完成后先为主库补一组 standby redo log。19C 的推荐做法是给每个线程配置 (在线日志组数1) 组 standby log大小与在线日志相同ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 SIZE 200M; ALTER DATABASE ADD STANDBY LOGFILE GROUP 5 SIZE 200M; ALTER DATABASE ADD STANDBY LOGFILE GROUP 6 SIZE 200M; ALTER DATABASE ADD STANDBY LOGFILE GROUP 7 SIZE 200M;没有 standby redo log 时备库也可以应用日志但会对归档文件做额外读取切换时也可能因为最后一段在线日志没被归档而产生差异。加上 standby redo log 后主库在线日志切换的写入路径会更平滑。然后启动 MRP 进程应用日志ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;USING CURRENT LOGFILE 表示既应用归档日志也直接应用在线日志这一项决定了备库能否在无归档中断的情况下持续同步。执行后查询 v$managed_standby 应有 MRP0 进程处于 APPLYING_LOG 状态。在 19C 里备库这套用 dbca 初始化成独立实例再 rman duplicate 是常见做法也可以用 dbca 的 createDuplicateDatabase 向导但命令行方式更好排查也方便在脚本里复现。5.3 常见问题排查现象、原因、解决第一坑备库 alert 日志反复刷 ORA-12514MRP 卡在 WAIT_FOR_LOG。原因是 LOG_ARCHIVE_DEST_2 中 SERVICE 指向的 tnsnames 别名里 SERVICE_NAME 填了 ORACLE_SID而不是备库实际监听的服务名。解决方法是把 tnsnames.ora 中 node2dg 条目的 SERVICE_NAME 配成备库的 service_name并用 tnsping 确认能通。第二坑root.sh 执行后 ohasd 起不来CRS-5011 报资源无法启动。原因通常是 avahi-daemon 未禁用或者 /etc/sysconfig/network 里没有 NOZEROCONFyes。解决先停止并禁用 avahi-daemon再追加 NOZEROCONFyes 到 network 文件最后重新执行 root.sh。第三坑19C 预检报 compat-libstdc-33 not found。原因RHEL 7.6 ISO 与在线 yum 源里确实没有这个包。解决手动下载 compat-libstdc-33-3.2.3-72.el7.i686.rpm 和 x86_64 两个 RPM 用 rpm -ivh 安装然后重新跑预检。第四坑备库 MRP 进程启动时报 ORA-16191 或 ORA-16607。原因主备库 SYS 密码不一致或者 log_archive_config 的 DG_CONFIG 与实际 db_unique_name 没对齐。解决主备库分别把 SYS 密码改成同一个重建密码文件再检查 DG_CONFIG 配置。第五坑switchover 后新主库无法继续传输日志。原因手工切换时 tnsnames 别名指向旧主库或 FAL_SERVER 方向未更新。解决用 dgmgrl 做 switchover 而不是手工切换broker 会自动反转日志传输方向手工切换路径下必须手动更新两边的 LOG_ARCHIVE_DEST_n。6. 验证 DataGuard 是否真正生效切换演练与日常检查习惯DG 搭建完不等于可以用真正有意义的是验证。我每次部署完都会做一轮状态查询、日志应用确认和一次完整的 switchover 演练。状态查询是第一步SELECT DATABASE_ROLE, DB_UNIQUE_NAME, OPEN_MODE, PROTECTION_MODE FROM V$DATABASE; SELECT PROCESS, STATUS, CLIENT_PROCESS FROM V$MANAGED_STANDBY WHERE PROCESS LIKE MRP%;主库应显示 PRIMARY_ROLE备库显示 PHYSICAL STANDBY 且 OPEN_MODE 为 READ ONLY WITH APPLY。MRP0 处于 APPLYING_LOG 说明日志持续应用。再查 redo 传输延迟SELECT NAME, VALUE, UNIT, TIME_COMPUTED FROM V$DATAGUARD_STATS;关注 APPLY_LAG 和 TRANSPORT_LAG正常应在几秒内。如果 LAG 持续增长看主库的归档进程是否被阻塞备库磁盘是否有压力。switchover 演练是唯一能证明 DG 真实可切换的动作。在 dgmgrl 里执行dgmgrl sys/oraclenode2 DGMGRL SHOW CONFIGURATION DGMGRL SWITCHOVER TO node2dgbroker 会先检查两边状态再自动完成日志传输反转、角色切换与启动。演练完后再用相同命令切回主库确认两个节点回到原角色。从那以后我每次建完 DG 都强制自己跑一轮上述流程哪怕只花了十分钟。dgmgrl 的 show configuration 和 v$dataguard_stats 这两条命令基本写进了日常巡检清单希望帮到你。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
