
简介面向数据库运维工程师与DBA的实战型安装文档聚焦在RHEL 7.6环境下搭建Oracle 19C单实例加ASM存储并配置DataGuard物理备库的完整流程适合已具备Linux基础、希望掌握企业级高可用架构部署的中高级读者。资源包内仅含1个PDF文件大小约4.68MB按硬件与软件环境、部署规划、安装目录规划、网络配置、安装前准备、Oracle 19C安装、ASM安装、DataGuard配置等章节组织给出节点node2与node2dg的磁盘划分、GI与ORACLE_HOME路径、IP地址及系统包检查命令等具体参数可对照逐步执行。已有707人学习下载可作为搭建主备容灾实验环境、梳理安装检查项与排错思路的参考手册。1. 双节点 RHEL 7.6 上把 Oracle 19C 装进 ASM 并挂上 DataGuard这份指南能省掉你三天试错手上只有两台 4 核 20G 的机器却要交付一套带物理备库的 Oracle 19C 环境最怕的不是装不上而是装到一半发现 ASM 磁盘权限不对、DataGuard 日志传不过去回头重来。这份安装指南就是围绕这个场景整理的RHEL 7.6 打底Grid Infrastructure 19C 管 ASM 存储主库 node2 与备库 node2dg 通过 DataGuard 做物理复制。它把硬件核对、系统参数、用户组、udev 绑盘、GI 图形化安装、建库到备库同步串成一条线适合需要在一两天内把测试或准生产库跑起来、又不想在环境准备上反复翻车的一线 DBA。下面按我实际复现的顺序拆参数和坑都落到具体命令上。2. 装 GI 之前先把系统底座压平内核参数、用户组与 udev 绑盘Oracle 19C 对操作系统的要求并不玄学真正让人翻车的是“装完 GI 才发现某个包没装、某个参数没生效”。这一章把安装前准备拆成可逐条执行的检查项顺序建议就是硬件与包 → 用户与组 → 内核与 shell 限制 → 时间服务 → 共享盘绑定。每一步都给出验证命令别急着往下走。2.1 硬件、软件包与目录规划先对齐指南给的基线是 4 核、20G 内存、200G 存储SWAP 按 20G 配/dev/shm约 10G。这个配置跑单实例加一个物理备库够用但如果后面要开 RMAN 全备到本地盘/app至少留 45G 以上备库侧同理。软件包检查用一条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 python-configshell python-rtslib python-six \ smartmontools sysstat targetcli这条命令只做查询输出里出现not installed的包再用yum install补。RHEL 7.6 镜像里没有compat-libstdc-33需要手动装 i686 和 x86_64 两个 rpm这是最常见的漏项。目录规划上GI 的ORACLE_BASE/app/grid、ORACLE_HOME/app/product/19.2.0/crs数据库侧ORACLE_BASE/app/oracle、ORACLE_HOME/app/oracle/product/19.2.0/dbhome_1。注意指南里那句提醒全路径必须提前mkdir -p建好否则 OUI 检测不到而且 GI 会装到gridSetup.sh所在路径路径错了后面改起来很麻烦。2.2 用户组、环境变量与内核参数一次配到位用户和组按官方推荐的 OSDBA 体系建grid 和 oracle 分属不同主组但都要进asmadmin、asmdba、dba这些组。建完用id grid、id oracle核对别只看命令有没有报错/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环境变量两个用户各写一份~/.bash_profilegrid 的ORACLE_SIDASMoracle 的ORACLE_SID按库名设主备库要区分开。NLS_LANG统一成AMERICAN_AMERICA.UTF8TEMP/TMPDIR指到/app/tmpumask 022。内核参数写/etc/sysctl.conf重点是kernel.shmmax取物理内存一半左右20G 机器给到 12640516096kernel.shmall按页算要不小于 shmmaxfs.aio-max-nr1048576、fs.file-max6815744。改完sysctl -p必须回读确认sysctl kernel.shmmax看实际值。shell 限制写/etc/security/limits.confgrid 和 oracle 都要有nproc、nofile、stack、memlock四组软硬限制并在/etc/pam.d/login加session required pam_limits.so否则 limits 不生效。2.3 时间服务与 avahi 处理别让 CTSS 背锅实验环境里指南选择关掉 chrony、不配 NTP让 Oracle 自己用 CTSS 同步两节点时间。做法是systemctl disable chronyd、systemctl stop chronyd再把/etc/chrony.conf备份移走。这个选择在纯实验环境可行但两节点时间基线要手动确认一致date对一遍。生产或准生产别这么干老老实实配外部时间源。另外avahi-daemon要停掉并禁用它和 19C 的 mDNS 解析容易打架表现为安装时节点名解析忽好忽坏。这两步做完基础环境就算压平了再往下走 GI 安装。3. 用 udev 把共享盘钉成 asmdiskGI 安装前最容易被忽略的一步ASM 能不能被 GI 发现取决于磁盘设备名是否稳定、权限是否对。直接拿/dev/sdc这种名字去建磁盘组重启后顺序一变就全乱。正确做法是用scsi_id取 WWID写 udev 规则绑定成固定名字并把属主设成grid:asmadmin、权限0660。这一章把绑盘和 GI 安装串起来讲。3.1 取 WWID 并写 99-my-asmdevices.rules先对每块候选盘取唯一标识/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把输出的 WWID 逐条填进/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/asmdisk01RESULT必须和scsi_id输出完全一致一个字符都不能差RUN里先mknod再改属主权限顺序不能反。四块盘对应asmdisk01到asmdisk04。写完执行/sbin/udevadm trigger --typedevices --actionchange然后ls -l /dev/asmdisk*确认属主是grid:asmadmin、权限brw-rw----。这一步没做对后面 GI 的磁盘发现界面就是空的或者发现了但建组时报权限错误。3.2 GI 安装standalone server 与 DATA 磁盘组解压 GI 包到ORACLE_HOME后执行gridSetup.sh图形界面里选 “standalone server”因为这是单实例加备库不是 RAC。磁盘组名DATA冗余模式选 Normal至少两块盘通过 “change discovery path” 指到/dev/asmdisk*让安装器发现盘。管理密码统一设角色组按前面建的组勾选。安装过程中如果卡在 “INS-” 类报错先回头看 udev 权限和/dev/shm大小这两个占多数。GI 装完用crsctl stat res -t看 ASM 实例状态asmcmd lsdg确认 DATA 组挂载正常再进数据库安装。4. 建库、配 DataGuard主备同步的配置顺序与验证点GI 和 ASM 就位后数据库安装本身反而顺。真正需要设计的是 DataGuard 的配置顺序主库先开归档、强制日志备库用 RMAN 复制再配日志传输和应用。顺序错了会出现备库追不上、日志缺口补不回来的情况。4.1 主库开归档与强制日志主库 node2 上先把归档打开并开启强制日志保证所有变更都进 redoSHUTDOWN IMMEDIATE; STARTUP MOUNT; ALTER DATABASE ARCHIVELOG; ALTER DATABASE FORCE LOGGING; ALTER DATABASE OPEN; ALTER SYSTEM SET LOG_ARCHIVE_DEST_1LOCATION/app/arch VALID_FOR(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAMEnode2 SCOPEBOTH;DB_UNIQUE_NAME主备必须不同这是 DataGuard 识别身份的关键。归档路径提前建好并给足空间/app/arch别和软件目录挤在一个小分区。开完用archive log list确认归档模式已生效v$database里FORCE_LOGGING为 YES。4.2 备库 RMAN 复制与日志应用备库 node2dg 上配好tnsnames和静态监听用 RMAN 从主库复制rman target sys/oraclenode2 auxiliary sys/oraclenode2dg RMAN duplicate target database for standby from active database spfile parameter_value_convert node2,node2dg set db_unique_namenode2dg set log_archive_dest_1LOCATION/app/arch VALID_FOR(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAMEnode2dg set log_archive_dest_2SERVICEnode2 LGWR ASYNC VALID_FOR(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAMEnode2 set fal_servernode2 set standby_file_managementAUTO nofilenamecheck;复制完成后备库处于 mount 状态执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;开启实时应用。验证点有三个主库v$archive_dest_status里 dest_2 状态为 VALID备库v$managed_standby有 MRP0 进程在跑主库切一次日志后备库v$archived_log能看到对应 sequence 且appliedYES。三个都过才算 DataGuard 真正通了。5. 避坑排查这套组合里最容易翻车的五处装这套环境报错信息往往指向表象根因在更前面。下面五条是我复现时实际遇到或高频出现的按“现象 → 原因 → 解决”记。现象GI 磁盘发现界面看不到任何盘。原因udev 规则里RESULT和scsi_id输出不一致或规则文件没触发。解决重新scsi_id取 WWID 逐字比对udevadm trigger后ls -l /dev/asmdisk*确认设备存在且属主grid:asmadmin。现象建库时 OUI 提示 ORACLE_HOME 路径无效。原因全路径没提前建或 GI 装到了gridSetup.sh所在目录。解决安装前mkdir -p建好/app/product/19.2.0/crs和/app/oracle/product/19.2.0/dbhome_1从正确目录执行安装脚本。现象备库 MRP0 进程起不来日志传不过去。原因主备DB_UNIQUE_NAME重复或log_archive_dest_2的 service 名解析不到。解决核对两边db_unique_name不同tnsping主备服务名静态监听里注册备库。现象安装中途报共享内存或信号量不足。原因kernel.shmmax/shmall没生效或 limits 没被 PAM 加载。解决sysctl -p后回读实际值确认/etc/pam.d/login有pam_limits.so重新登录使 limits 生效。现象两节点时间漂移导致 DataGuard 日志应用延迟。原因关掉 chrony 后没手动对齐时间基线。解决实验环境装前date对齐生产环境配外部时间源别依赖 CTSS 兜底。6. 验收与日常巡检用几条 SQL 确认这套环境真的能扛装完不等于交付完得有一套能重复跑的验收动作。我一般会在主库和备库各跑一遍下面这组查询把结果贴进交付记录-- 主库确认归档传输与备库状态 SELECT dest_id, status, error, destination FROM v$archive_dest_status WHERE dest_id IN (1,2); -- 备库确认应用进程与延迟 SELECT process, status, sequence# FROM v$managed_standby WHERE process LIKE MRP%; SELECT name, value, time_computed FROM v$dataguard_stats WHERE name IN (transport lag,apply lag);transport lag和apply lag接近 0 才算健康v$archive_dest_status里 dest_2 的error必须为空。再补一个切换演练主库ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;之前先确认备库能正常 apply切完用SELECT database_role FROM v$database;核对角色互换然后切回来。这个动作在测试环境走一遍比任何文档都让人安心。几个参数上的边界值得记LOG_ARCHIVE_DEST_2用LGWR ASYNC适合大多数场景同步模式SYNC会拖主库提交除非业务明确要求零丢失standby_file_managementAUTO必须开否则主库加数据文件备库不跟FAL_SERVER配好日志缺口时备库能自动去主库取。备库只读打开Active DataGuard需要额外授权测试环境用 mount 状态验证同步就够。血泪经验是这套环境里 80% 的“装不上”都发生在 GI 之前udev 权限、内核参数、包缺失三件事占大头。从那以后我每次动手前都强制走一遍rpm -q批量检查、sysctl回读、ls -l /dev/asmdisk*三连确认无误再碰gridSetup.sh。希望帮到你。本文还有配套的精品资源点击获取