简介：面向数据库运维工程师与DBA的实战型安装文档，聚焦在RHEL 7.6环境下搭建Oracle 19C高可用架构这一典型难题，覆盖从系统准备到主备同步的完整链路，适合具备一定Linux与Oracle基础、需要落地ASM存储与DataGuard容灾的中高级读者参考。资源包为单一PDF文件，约4.68MB，内容按硬件信息、软件版本、部署规划、安装前准备、Oracle 19C安装、ASM配置与DataGuard配置等模块依次展开，并给出node2主库与node2dg物理备库的目录规划、IP地址分配及磁盘空间实测数据，便于对照自身环境调整。文档还列出内核参数、SWAP建议、依赖包检查命令等细节，可帮助读者减少安装过程中的路径检测与依赖缺失问题。目前已有707人学习，适合作为一次性打通19C加ASM加DataGuard部署流程的操作蓝本。
1. 从两台机器到一套容灾：这份 RHEL 7.6 + Oracle 19C + ASM + DataGuard 指南到底能省你多少事
装一套带 DataGuard 的 Oracle 19C，最耗人的从来不是点“下一步”，而是前面那一堆没人愿意写进文档的脏活：内核参数算错一个shmmax，GI 装到一半报错；udev 规则里RESULT少抄一位，ASM 磁盘死活发现不了；两个节点ORACLE_SID配串了，DG 日志传过去直接拒收。这份指南的价值就在于，它把 RHEL 7.6 上从裸机到 primary + physical standby 跑通的全链路摊开了——硬件 4 核 20G 内存 200G 存储、GI 用 V981627-01.zip、DB 用 V981623-01.zip、ASM 走 udev 绑定、DG 做单实例主备。适合谁？手上有一对测试机、需要在一两天内把 19C DG 环境立起来做迁移验证或故障演练的 DBA，以及第一次完整走 ASM + DG 流程、不想在图形界面里反复翻车的人。下面按“环境怎么铺 → GI 和 ASM 怎么落 → DG 怎么接 → 坑在哪”的顺序拆。
2. 装 GI 之前把地基打平：内核参数、用户组与 udev 绑定
这一章是整份指南里最容易被跳过、也最容易在后期反噬的部分。很多人习惯先把 GI 介质解压、gridSetup.sh点起来，等报 precheck 失败再回头补，结果补完还得重跑一遍。我的建议是：所有系统层配置一次性做完、逐项验证，再碰安装程序。
2.1 内核参数与 Shell 限制：按 20G 内存反推数值
指南里给的是 20G 内存机器的配置，kernel.shmmax = 12640516096，这个数不是拍脑袋来的，它约等于物理内存的一半再留点余量（20G × 1024³ × 0.6 左右）。shmall则以页为单位，必须大于等于shmmax / 页大小，指南直接给了 4294967296，属于给足余量的写法。落到操作上：
# 追加内核参数，注意 shmmax 按实际物理内存的一半计算（单位字节） cat >> /etc/sysctl.conf <<'EOF' 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 EOF # 生效并抽查关键项 sysctl -p sysctl kernel.shmmax kernel.shmall kernel.sem逻辑说明：shmmax决定单个共享内存段的上限，SGA 超过它就会在启动实例时报ORA-27123；shmall是所有共享内存段的总页数上限，设小了同样起不来。kernel.sem四个值分别是SEMMSL SEMMNS SEMOPM SEMMNI，Oracle 对SEMMNI有最低要求，指南给的 128 是保守够用的值。改完必须sysctl -p，否则只写在文件里不生效——这是新手最常见的“我明明改了”的来源。
Shell 限制走/etc/security/limits.conf，grid 和 oracle 两个用户都要配，重点是memlock。指南给的是 3145728 KB（约 3G），这个值要能覆盖 GI 和实例锁定的内存量，配小了ulimit -l上不去，GI 启动会告警。配完还要确认 PAM 加载：
# 确认 PAM 会读取 limits.conf grep pam_limits.so /etc/pam.d/login # 没有则追加 echo "session required pam_limits.so" >> /etc/pam.d/login # 切到 grid 用户验证，注意要重新登录才生效 su - grid -c "ulimit -l; ulimit -n; ulimit -u"参数说明：nofile软限 1024、硬限 65536，nproc软限 2047、硬限 16384，这是 Oracle 官方推荐区间的常见取值。验证时一定要用su -重新登录，因为 limits 在会话建立时读取，当前 shell 里ulimit看到的还是旧值，很多人在这里误判成“没配成功”。
2.2 用户、组与目录：全路径必须先建出来
指南里组 ID 从 54321 的 asmadmin 一路排到 54330 的 racdba，oracle 用户 UID 54321、grid 用户 UID 54322。这套编号是 Oracle 生态里的惯例，照着敲就行，但要注意两个用户的附加组不能漏：oracle 要进dba,asmdba,backupdba,dgdba,kmdba,racdba,oper，grid 要进asmadmin,asmdba,asmoper,dba。漏了asmdba，后面 ASM 实例和数据库实例的权限就对不上。
# 建组（节选，完整按指南 54321~54330 顺序建） groupadd -g 54321 asmadmin groupadd -g 54322 asmdba groupadd -g 54323 asmoper groupadd -g 54324 dba groupadd -g 54326 oinstall # 建用户 useradd -u 54321 -g oinstall -G dba,asmdba,backupdba,dgdba,kmdba,racdba,oper oracle useradd -u 54322 -g oinstall -G asmadmin,asmdba,asmoper,dba grid # 目录必须提前建全，gridSetup 依赖这些路径存在 mkdir -p /app/grid /app/product/19.2.0/crs /app/oraInventory mkdir -p /app/oracle/product/19.2.0/dbhome_1 /app/tmp chown -R grid:oinstall /app/grid /app/product /app/oraInventory chown -R oracle:oinstall /app/oracle chmod -R 775 /app这里有个指南特意点出的细节：软件会安装在gridSetup所在路径，所以解压 GI 介质时目标目录必须就是ORACLE_HOME，不能先解压到/tmp再挪。目录没提前建好，安装程序检测不到路径，图形界面里那一步会直接灰掉。/app/tmp是给TEMP/TMPDIR用的，安装过程会往这里写临时文件，权限给足。
2.3 udev 绑定 ASM 磁盘：RESULT 必须逐位核对
ASM 要的是稳定、权限正确的块设备名，指南用 udev 规则把/dev/sdc~/dev/sdf绑成asmdisk01~asmdisk04。核心是先用scsi_id拿到每块盘唯一的 WWID，再写进规则文件做匹配。
# 逐块盘取 WWID，输出要原样抄进规则 /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/sdf # 规则文件示例（一块盘一条，RESULT 换成上一步实际输出） cat > /etc/udev/rules.d/99-my-asmdevices.rules <<'EOF' KERNEL=="sd*[!0-9]", ENV{DEVTYPE}=="disk", SUBSYSTEM=="block", \ PROGRAM=="/usr/lib/udev/scsi_id -g -u -d $devnode", \ RESULT=="36000c291ca220c52c813c595ffdf14f4", \ RUN+="/bin/sh -c 'mknod /dev/asmdisk01 b $major $minor; chown grid:asmadmin /dev/asmdisk01; chmod 0660 /dev/asmdisk01'" EOF # 重新触发并验证 /sbin/udevadm trigger --type=devices --action=change ls -l /dev/asmdisk*逻辑说明：KERNEL=="sd*[!0-9]"排除分区设备，只匹配整盘；PROGRAM调scsi_id取当前设备的 WWID，与RESULT比对，命中才执行RUN。mknod建块设备节点，chown grid:asmadmin和chmod 0660保证只有 grid 和 asmadmin 组能读写——ASM 实例以 grid 身份运行，权限不对会在asmcmd里看到磁盘但无法加入磁盘组。验证时ls -l要能看到属主是grid:asmadmin、权限brw-rw----，缺一不可。
提示：
RESULT里的 WWID 是 32 位十六进制串，抄错一位规则就不匹配，设备名不会出现。改完规则务必udevadm trigger再ls，别直接去gridSetup里点“change discovery path”碰运气。
3. GI 与 ASM 落地：从 gridSetup 到磁盘组 Normal 冗余
地基平了，这一章进入安装主体。指南走的是图形化gridSetup.sh，单实例场景选 “standalone server”，磁盘组命名DATA、冗余模式Normal。图形界面本身没什么可讲的，真正决定成败的是启动前的环境变量和安装过程中的几个选择。
3.1 环境变量：两个用户各一套，SID 不能串
指南给了 grid 和 oracle 两份.bash_profile，结构几乎一样，差异在ORACLE_SID、ORACLE_BASE、ORACLE_HOME。grid 侧ORACLE_SID=+ASM、ORACLE_BASE=/app/grid、ORACLE_HOME=/app/product/19.2.0/crs；oracle 侧ORACLE_SID是实例名（指南里出现过nodetwodg这类命名）、ORACLE_BASE=/app/oracle、ORACLE_HOME=/app/oracle/product/19.2.0/dbhome_1。
# grid 用户 ~/.bash_profile 关键行 export ORACLE_SID=+ASM export ORACLE_BASE=/app/grid export ORACLE_HOME=/app/product/19.2.0/crs export NLS_LANG=AMERICAN_AMERICA.UTF8 export TNS_ADMIN=$ORACLE_HOME/network/admin export TEMP=/app/tmp export TMPDIR=/app/tmp umask 022 alias sqlplus='rlwrap sqlplus' alias asmcmd='rlwrap asmcmd'参数说明：NLS_LANG指南把 GBK 那行注释掉、改用 UTF8，跨平台迁移时能少一堆乱码问题；TNS_ADMIN指向$ORACLE_HOME/network/admin，DG 的tnsnames.ora和listener.ora都放这里；umask 022保证安装生成的文件权限正常。rlwrap别名是提升交互体验的，没装rlwrap包的话别名会报错，但不影响安装，可以先注释掉。两个节点都要配，且 primary 和 standby 的ORACLE_SID必须区分开——这是 DG 能识别“我是谁”的基础。
3.2 启动 gridSetup 与磁盘组规划
环境变量source之后，以 grid 身份执行gridSetup.sh。指南明确解压目标就是ORACLE_HOME：
# 以 grid 身份操作 su - grid unzip V981627-01.zip -d /app/product/19.2.0/crs cd /app/product/19.2.0/crs ./gridSetup.sh图形界面里的关键选择：配置类型选 “Configure Oracle Grid Infrastructure for a Standalone Server”；磁盘组名DATA；冗余选Normal（至少两块盘做镜像）；发现路径点 “Change Discovery Path” 指向/dev/asmdisk*。Normal冗余意味着 4 块盘里可用容量约一半，这是拿空间换可靠性，测试环境做 DG 演练够用；如果盘少又想省空间，External也行，但就失去了 ASM 层面的镜像保护，得靠存储层兜底。
安装过程中会要求设 ASM 管理密码（指南统一用 oracle，仅限实验环境）、指定 OS 组角色（asmadmin/asmdba/asmoper对应到 grid 用户所在的组）。装完用asmcmd验证：
# 验证 ASM 实例与磁盘组状态 export ORACLE_SID=+ASM asmcmd lsdg srvctl status asmlsdg输出里STATE应为MOUNTED、TYPE为NORMAL，TOTAL_MB和FREE_MB能对上四块盘的容量。如果磁盘组没挂上，先查/dev/asmdisk*权限，再查asmadmin组归属，最后看alert日志里 ASM 实例的报错——顺序别乱，从外到内排。
3.3 数据库软件安装与建库前的确认
GI 装完，切到 oracle 用户解压 DB 介质V981623-01.zip到dbhome_1，跑runInstaller。这一步指南没有展开截图，但流程和 GI 类似：只装软件（software only），建库留到 DG 规划清楚之后再做，避免建了库又要改db_unique_name、开归档、配LOG_ARCHIVE_DEST。建库前确认三件事：ORACLE_HOME下bin/sqlplus可执行、/etc/oratab里没有残留旧条目、DATA磁盘组有足够空间放数据文件。这三项任何一项不对，后面 DG 配置都会以奇怪的方式失败。
4. DataGuard 主备打通：参数、密码文件与日志传输
到这一章，primary 上应该已经有一个正常运行的 19C 实例，ASM 存数据文件。DG 的目标是让 standby 通过 redo 传输保持同步。指南的节点规划是node2（primary，10.6.0.139）和node2dg（physical standby，10.6.0.137），单实例对单实例。
4.1 主库必改参数：归档、唯一名与日志传输目标
DG 的起点是主库开归档并声明自己的身份。db_unique_name在主备上必须不同，这是 DG 区分角色的核心标识；log_archive_config列出参与 DG 的所有唯一名；log_archive_dest_2指向备库的 TNS 别名。
-- primary 上执行 ALTER SYSTEM SET log_archive_config='DG_CONFIG=(node2,node2dg)' SCOPE=BOTH; ALTER SYSTEM SET log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=node2' SCOPE=BOTH; ALTER SYSTEM SET log_archive_dest_2='SERVICE=node2dg ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=node2dg' SCOPE=BOTH; ALTER SYSTEM SET log_archive_dest_state_2='ENABLE' SCOPE=BOTH; ALTER SYSTEM SET fal_server='node2dg' SCOPE=BOTH; ALTER SYSTEM SET fal_client='node2' SCOPE=BOTH; ALTER SYSTEM SET standby_file_management='AUTO' SCOPE=BOTH;参数说明：ASYNC表示异步传输，主库提交不等备库确认，性能影响小，测试环境首选；要更强保护可改SYNC，但网络抖动会直接拖慢主库提交。VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)限定这条目的地在主库角色下才生效，角色切换后备库不会往自己传。fal_server/fal_client是归档缺口自动补齐的通道，配反了缺口补不上。standby_file_management=AUTO让备库自动跟随主库的文件增删，不加这个，主库加个数据文件备库就报错。
改完shutdown immediate再startup mount，然后ALTER DATABASE ARCHIVELOG;再ALTER DATABASE OPEN;，确认ARCHIVE LOG LIST显示归档开启。
4.2 密码文件与 TNS：备库能连上才谈传输
redo 传输走的是 Oracle Net，备库要用和主库一致的sys密码做认证，所以密码文件必须从主库拷过去，且remote_login_passwordfile为EXCLUSIVE。
# primary 上确认密码文件位置 sqlplus -S / as sysdba <<'EOF' SELECT value FROM v$parameter WHERE name='remote_login_passwordfile'; EOF # 拷贝到 standby 对应目录（路径按实际 ORACLE_HOME 调整） scp $ORACLE_HOME/dbs/orapw$ORACLE_SID oracle@10.6.0.137:$ORACLE_HOME/dbs/TNS 部分，两个节点的tnsnames.ora都要有对方条目，listener.ora监听对应地址。指南网络规划里 primary 是 10.6.0.139、standby 是 10.6.0.137，tnsnames.ora里node2和node2dg两个别名分别指向这两个地址的 1521 端口。配完用tnsping node2dg从主库测、tnsping node2从备库测，双向通才算过。这一步不通，后面log_archive_dest_2会一直ERROR，v$archive_dest_status里能看到具体网络错误码。
4.3 备库搭建：RMAN 复制与 MRP 启动
备库的$ORACLE_HOME装好后，用主库的备份做 RMAN 复制。常见做法是主库RMAN里duplicate target database for standby from active database，走网络直接拉，不用先落备份集。执行前备库要起一个nomount状态的实例，参数文件里db_unique_name=node2dg、log_archive_dest_1指向本地归档路径、log_archive_dest_2指回主库。
# standby 上以 oracle 身份，实例 nomount 后执行 rman target sys/oracle@node2 auxiliary sys/oracle@node2dg <<'EOF' DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE SPFILE SET db_unique_name='node2dg' SET log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=node2dg' SET log_archive_dest_2='SERVICE=node2 ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=node2' SET fal_server='node2' SET fal_client='node2dg'; EOF逻辑说明：FROM ACTIVE DATABASE让 RMAN 直接从主库读数据文件传到备库，省去中间备份集；SPFILE SET在复制过程中直接改写备库参数，避免复制完再手工改一堆。复制完成后备库处于MOUNT状态，启动日志应用：
-- standby 上执行 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;USING CURRENT LOGFILE让 MRP 实时应用当前在线日志，而不是等归档，延迟更低。验证同步状态在主库查：
SELECT dest_id, status, error, gap_status FROM v$archive_dest_status WHERE dest_id=2; SELECT name, value, time_computed FROM v$dataguard_stats;status为VALID、gap_status为NO GAP才算通。v$dataguard_stats里transport lag和apply lag接近 0 说明实时同步正常。
5. 避坑与排查：五个让 DG 卡住的真实场景
这一章按“现象 → 原因 → 解决”写，都是这套环境里高频出现的。
现象一：gridSetup预检查报“未找到 ASM 磁盘”，但ls /dev/asmdisk*明明有。原因通常是 udev 规则里RESULT的 WWID 与实际不符，或者规则文件权限/命名不对导致 udev 没加载。解决：udevadm info --query=all --name=/dev/sdc核对 WWID，确认规则文件名以.rules结尾、放在/etc/udev/rules.d/，改完udevadm control --reload-rules && udevadm trigger，再ls -l看属主是否为grid:asmadmin。
现象二：实例启动报ORA-27123: unable to attach to shared memory segment。原因是kernel.shmmax小于 SGA 大小，或shmall不够。解决：按物理内存一半重算shmmax，shmall取shmmax/4096向上取整，sysctl -p后重启实例。别只改shmmax不改shmall，两个是一对。
现象三：主库v$archive_dest_status里 dest_2 一直ERROR，error列提示网络或认证失败。原因多为tnsnames.ora别名拼错、备库监听没起、或密码文件不一致。解决：主库tnsping node2dg先确认网络通，再sqlplus sys/密码@node2dg as sysdba确认认证通，不通就重拷密码文件并确认remote_login_passwordfile=EXCLUSIVE。
现象四：备库 MRP 启动后apply lag持续增大，v$managed_standby里 MRP0 状态WAIT_FOR_LOG。原因是主库归档没传到备库，常见于log_archive_dest_2的VALID_FOR写错角色，或standby_file_management没开导致文件创建失败。解决：查主库v$archive_dest_status的gap_status，有 gap 就靠fal_server补，同时确认standby_file_management=AUTO。
现象五：duplicate到一半报RMAN-05501或空间不足。原因是备库DATA磁盘组容量小于主库数据文件总量，或db_file_name_convert/log_file_name_convert没配导致路径映射失败。解决：备库磁盘组按主库数据量 1.2 倍规划，duplicate时显式带DB_FILE_NAME_CONVERT和LOG_FILE_NAME_CONVERT，路径两端都写全。
注意：实验环境里 ASM 密码、
sys密码统一用简单值是图省事，任何对外暴露的环境都必须换成强密码，并且tnsnames.ora、密码文件不要留在共享目录里。
6. 角色切换验证与一个我每次必做的检查习惯
环境搭完不等于 DG 可用，真正能证明它工作的是做一次 switchover。这一步指南没有展开，但它是验收 DG 的唯一硬标准。主库执行：
-- primary 上发起 switchover ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN; -- 原备库（现主库）上 ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN; ALTER DATABASE OPEN;切换后立刻验证三件事：新主库SELECT database_role FROM v$database;为PRIMARY；新备库v$managed_standby里 MRP0 重新起来；在新主库做一次小事务提交，到新备库查得到。三件都过，再切回来，确认双向可切。切换过程中最容易翻车的是监听没跟着角色走——local_listener和remote_listener没配好，切换后客户端连不上，所以切换前先把两个节点的local_listener指向各自地址。
我自己的习惯是：每次搭完 DG，不管多赶时间，都强制走一遍“切过去 → 写一条数据 → 查备库 → 切回来”的闭环，并且把v$dataguard_stats的 lag 值截图留档。因为 DG 的很多问题不是装的时候暴露，而是第一次真实切换才现形——参数看着都对，一切换就发现归档路径没权限、密码文件没同步。这套 RHEL 7.6 + 19C + ASM + DG 的流程，按上面四章的顺序铺下来，两天内跑通是现实的，前提是别跳步。希望帮到你。
本文还有配套的精品资源，点击获取
