RHEL 7.6 上 Oracle 19C + ASM + DataGuard 生产环境安装与容灾配置指南

简介本资源是一份面向数据库运维工程师与DBA的实战安装指南聚焦在RHEL 7.6环境下部署Oracle 19C并配合ASM存储与DataGuard容灾架构适合具备一定Linux与Oracle基础、需要搭建高可用数据库环境的技术人员参考。压缩包内仅含1个PDF文档大小约4.68MB内容以图文步骤形式呈现涵盖硬件与软件环境说明、主备节点规划、GI与ORACLE_HOME目录创建、网络配置、系统安装包检查等关键环节并逐步展开Oracle 19C软件安装、ASM磁盘组配置以及DataGuard主从复制与网络环境搭建的完整流程。文档中给出了节点node2与node2dg的具体部署参数、路径规划与命令示例便于读者对照自身环境快速落地。目前已有702人学习可作为搭建Oracle 19C ASM DataGuard架构时的操作参考与排错依据。1. RHEL 7.6 上 Oracle 19C ASM DataGuard一套能扛住生产环境的安装路线很多团队第一次在 RHEL 7.6 上装 Oracle 19C图省事直接用默认文件系统建库结果单机跑得好好的等到要上 DataGuard 做容灾时才发现主库用的是文件系统备库想改成 ASM两边存储结构对不上RMAN 恢复时各种报错最后只能推倒重来。这不是玄学是选型阶段就埋下的坑。这套方案要解决的核心问题就一个在 RHEL 7.6 上用 ASM 做共享存储把 Oracle 19C 主库和 DataGuard 备库一次性搭对让后续的 switchover、failover 有据可依。适合谁适合手里有物理机或虚拟机、需要做数据库高可用容灾、又不想在存储层反复返工的 DBA 和运维工程师。下面按「环境准备 → Grid 装 ASM → 装库 → 配 DataGuard → 排错」的顺序把每一步的命令、参数和判断依据讲清楚。2. 装之前先把地基打对RHEL 7.6 的系统参数与依赖2.1 内核参数和用户组别等安装器报错才回头改Oracle 19C 对 RHEL 7.6 的内核参数有硬性要求安装器检查不过会直接中断。我一般先把/etc/sysctl.conf一次性写全再sysctl -p生效避免装到一半回来补。# /etc/sysctl.conf 追加以下内容 fs.aio-max-nr 1048576 fs.file-max 6815744 kernel.shmall 2097152 kernel.shmmax 4398046511104 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 1048576kernel.shmmax设成物理内存的一半到 80% 之间我通常按内存的 70% 取整kernel.shmall是共享内存页数等于 shmmax 除以页大小4K 页就是除以 4096。fs.aio-max-nr不够会导致 ASM 异步 IO 报错这个值给到 1048576 基本够用。用户和组按标准建oinstall、dba、asmadmin、asmdba、asmoper。Grid 用户归asmadmin主组Oracle 用户归oinstall主组、dba和asmdba附加组。这一步错了后面asmca建磁盘组会提示权限不足。groupadd -g 54321 oinstall groupadd -g 54322 dba groupadd -g 54323 asmadmin groupadd -g 54324 asmdba groupadd -g 54325 asmoper useradd -u 54321 -g oinstall -G dba,asmdba,asmadmin,asmoper grid useradd -u 54322 -g oinstall -G dba,asmdba oracle2.2 依赖包和 limits两个最容易漏的点RHEL 7.6 的 ISO 里包不全oracle-database-preinstall-19c这个包能自动搞定大部分依赖但有些环境没配本地 yum 源就得手动装。核心依赖包括bc、binutils、compat-libcap1、compat-libstdc-33、gcc、glibc、libaio、libstdc、make、sysstat、unixODBC。少一个compat-libcap1Grid 安装到 40% 左右会静默失败日志里只写「缺少库」血泪经验。/etc/security/limits.conf里给 grid 和 oracle 都加上grid soft nofile 1024 grid hard nofile 65536 grid soft nproc 16384 grid hard nproc 16384 grid soft stack 10240 grid hard stack 32768 oracle soft nofile 1024 oracle hard nofile 65536 oracle soft nproc 16384 oracle hard nproc 16384 oracle soft stack 10240 oracle hard stack 32768提示改完 limits 一定要重新登录会话才生效ulimit -a确认 nofile 和 nproc 已经变过来否则安装器检查还是按旧值判断。2.3 共享磁盘和 ASM 设备准备ASM 要的是裸设备或未格式化的块设备。虚拟机环境下加三块盘一块给 OCR/Voting至少 3GB一块给 DATA 磁盘组一块给 FRA 快速恢复区。用lsblk确认设备名然后udev绑定权限别用chown硬改重启就丢。# /etc/udev/rules.d/99-oracle-asmdevices.rules KERNELsdb, SUBSYSTEMblock, ENV{DEVTYPE}disk, OWNERgrid, GROUPasmadmin, MODE0660 KERNELsdc, SUBSYSTEMblock, ENV{DEVTYPE}disk, OWNERgrid, GROUPasmadmin, MODE0660 KERNELsdd, SUBSYSTEMblock, ENV{DEVTYPE}disk, OWNERgrid, GROUPasmadmin, MODE0660执行udevadm control --reload-rules udevadm trigger再用ls -l /dev/sd*看属主是不是 grid:asmadmin。如果设备名会漂移改用/dev/disk/by-id/下的稳定路径这是生产环境的基本功。3. Grid Infrastructure 安装与 ASM 磁盘组创建3.1 静默安装 Grid响应文件怎么改图形界面在服务器上经常连不上静默安装更稳。先解压 LINUX.X64_193000_grid_home.zip 到 grid 用户家目录然后改gridsetup.rp。关键参数就几个ORACLE_BASE指向/u01/app/gridORACLE_HOME指向/u01/app/19.3.0/gridINVENTORY_LOCATION指向/u01/app/oraInventorycluster_type选STANDALONE单机 ASM 不需要 Clusterware 的完整集群但 Grid 基础服务要装。# 以 grid 用户执行 cd /u01/app/19.3.0/grid ./gridSetup.sh -silent -responseFile /home/grid/gridsetup.rp \ -waitForCompletion跑完后用gridSetup.sh -executeConfigTools执行 root 脚本或者手动按提示顺序跑orainstRoot.sh和root.sh。root.sh会启动ohasd这是 ASM 实例的守护进程跑完crsctl stat res -t应该能看到ora.asm是 ONLINE 状态。3.2 用 asmca 建磁盘组冗余级别怎么选ASM 实例起来后用asmca -silent建磁盘组。OCR/Voting 用 NORMAL 冗余至少两块盘DATA 和 FRA 看磁盘数量单块盘只能 EXTERNAL多块盘建议 NORMAL。# 建 OCR 磁盘组 asmca -silent -createDiskGroup \ -diskGroupName OCR \ -diskList /dev/sdb \ -redundancy NORMAL \ -au_size 4 # 建 DATA 磁盘组 asmca -silent -createDiskGroup \ -diskGroupName DATA \ -diskList /dev/sdc \ -redundancy EXTERNAL \ -au_size 4au_size是分配单元大小4MB 适合大多数 OLTP 场景如果要做大数据量顺序扫描可以调到 8MB 或 16MB但建完不能改得重建磁盘组。建完用asmcmd lsdg确认状态是 MOUNTEDasmcmd lsof看磁盘有没有 MISSING。3.3 验证 ASM 实例和磁盘组可用性装库之前必须确认 ASM 侧一切正常。切到 grid 用户export ORACLE_SIDASM然后sqlplus / as sysasm登录查v$asm_diskgroup和v$asm_disk。-- 确认磁盘组挂载状态和可用空间 SELECT name, state, type, total_mb, free_mb FROM v$asm_diskgroup; -- 确认每块盘都被 ASM 识别且没有坏盘 SELECT disk_number, name, path, state, mode_status FROM v$asm_disk ORDER BY disk_number;如果state是 DISMOUNTED先ALTER DISKGROUP DATA MOUNT;。如果盘状态是 MISSING检查 udev 权限和/dev下设备是否存在。这一步不确认后面 DBCA 建库会卡在「无法创建数据文件」上报错信息还不直接指向 ASM。4. Oracle 19C 数据库软件安装与 DBCA 建库4.1 静默安装数据库软件ORACLE_HOME 别和 Grid 混Oracle 软件装到/u01/app/oracle/product/19.3.0/dbhome_1和 Grid 的 home 完全分开。解压 LINUX.X64_193000_db_home.zip 到该目录改db_install.rsp关键项oracle.install.optionINSTALL_DB_SWONLYUNIX_GROUP_NAMEoinstallINVENTORY_LOCATION/u01/app/oraInventoryORACLE_HOME和ORACLE_BASE按实际路径填。# 以 oracle 用户执行 cd /u01/app/oracle/product/19.3.0/dbhome_1 ./runInstaller -silent -responseFile /home/oracle/db_install.rsp \ -ignorePrereqFailure -waitForCompletion-ignorePrereqFailure只在确认缺失项不影响运行时用比如某些包版本略低但功能正常。装完按提示用 root 跑root.sh然后dbca建库。4.2 DBCA 建库时怎么把数据文件落到 ASMDBCA 静默建库用dbca.rsp核心是datafileDestination指向DATArecoveryAreaDestination指向FRA。字符集按业务选一般AL32UTF8。totalMemory给物理内存的 60% 左右别把系统内存吃光。dbca -silent -createDatabase \ -templateName General_Purpose.dbc \ -gdbName orcl \ -sid orcl \ -responseFile NO_VALUE \ -characterSet AL32UTF8 \ -sysPassword Oracle_123 \ -systemPassword Oracle_123 \ -datafileDestination DATA \ -recoveryAreaDestination FRA \ -storageType ASM \ -asmSysPassword Oracle_123 \ -totalMemory 4096 \ -sampleSchema false建库过程中如果报ORA-15041: diskgroup space exhausted说明 DATA 磁盘组空间不够先asmcmd lsdg看 free_mb不够就加盘或调小db_block_size和totalMemory。建完用srvctl status database -d orcl确认实例状态再用sqlplus / as sysdba查v$datafile确认文件路径都是DATA开头。4.3 建库后必做的几项检查建完库别急着配 DataGuard先把归档模式和强制日志打开这是 DataGuard 的前置条件。-- 开启归档和强制日志 SHUTDOWN IMMEDIATE; STARTUP MOUNT; ALTER DATABASE ARCHIVELOG; ALTER DATABASE FORCE LOGGING; ALTER DATABASE OPEN; -- 确认归档路径和状态 ARCHIVE LOG LIST; SELECT log_mode, force_logging FROM v$database;force_logging必须为 YES否则备库可能因为 nologging 操作导致数据不一致。归档路径设到FRA用ALTER SYSTEM SET log_archive_dest_1LOCATIONFRA SCOPEBOTH SID*;。这些做完主库才算具备做 DataGuard 的资格。5. DataGuard 配置从主库准备到备库同步5.1 主库参数和密码文件DataGuard 要求主备库的db_unique_name不同db_name相同。主库设db_unique_nameorcl_pri备库设orcl_std。主库上开log_archive_config、log_archive_dest_2指向备库log_archive_dest_state_2ENABLE。ALTER SYSTEM SET log_archive_configDG_CONFIG(orcl_pri,orcl_std) SCOPEBOTH; ALTER SYSTEM SET log_archive_dest_1LOCATIONFRA VALID_FOR(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAMEorcl_pri SCOPEBOTH; ALTER SYSTEM SET log_archive_dest_2SERVICEorcl_std ASYNC VALID_FOR(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAMEorcl_std SCOPEBOTH; ALTER SYSTEM SET log_archive_dest_state_2ENABLE SCOPEBOTH; ALTER SYSTEM SET remote_login_passwordfileEXCLUSIVE SCOPESPFILE;密码文件必须重建因为要同步到备库。orapwd file$ORACLE_HOME/dbs/orapworcl passwordOracle_123 entries10 forcey。备库的密码文件直接拷过去或者用同样的命令重建保证 SYS 密码一致。5.2 备库用 RMAN 做 duplicateASM 环境下的注意点备库先装好 Oracle 软件建好 ASM 实例和磁盘组DATA、FRA但不建库。然后用 RMAN 的duplicate target database for standby from active database从主库直接拉。# 备库上执行连接主库和备库 rman target sys/Oracle_123orcl_pri auxiliary sys/Oracle_123orcl_std RMAN duplicate target database for standby from active database spfile parameter_value_convert orcl_pri,orcl_std set db_unique_nameorcl_std set control_filesDATA set datafile_name_convertDATA,DATA set log_archive_dest_1LOCATIONFRA VALID_FOR(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAMEorcl_std set log_archive_dest_2SERVICEorcl_pri ASYNC VALID_FOR(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAMEorcl_pri nocopy dorecover;nocopy在 ASM 环境下很关键它让 RMAN 直接在 ASM 磁盘组里创建数据文件而不是先拷到文件系统再转。datafile_name_convert如果主备都用DATA写成DATA,DATA即可RMAN 会自动用备库的db_unique_name做目录区分。跑完dorecover后备库执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;启动 MRP 进程。5.3 验证同步状态和切换测试主库切几个归档备库查v$archived_log和v$dataguard_status确认日志被应用。SELECT sequence#, applied FROM v$archived_log ORDER BY sequence#;看到appliedYES才算同步正常。-- 主库查传输状态 SELECT dest_id, status, error FROM v$archive_dest_status WHERE dest_id2; -- 备库查应用状态 SELECT process, status, sequence# FROM v$managed_standby;v$managed_standby里 MRP0 的 status 应该是WAIT_FOR_LOG或APPLYING_LOG。如果v$archive_dest_status的 status 是 ERROR看 error 字段常见的是 TNS 连不通或密码文件不一致。切换测试用ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY;在主库执行然后备库ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;确认两边角色互换后业务能连上再切回来。这个测试不做真出事时不敢切。6. 避坑与排查这套组合最容易翻车的五个地方6.1 坑一ASM 磁盘权限重启后丢失现象重启服务器后asmcmd lsdg显示磁盘组 DISMOUNTEDv$asm_disk里盘状态 MISSING。原因udev 规则没生效或设备名变了/dev/sdb重启后变成了/dev/sdc。解决改用/dev/disk/by-id/下的 WWID 路径写 udev 规则或者用multipath绑定。改完udevadm trigger再ALTER DISKGROUP DATA MOUNT;。6.2 坑二DBCA 建库卡在 45% 不动现象DBCA 进度条到 45% 左右长时间无响应日志里反复出现ORA-15041或ORA-15040。原因DATA 磁盘组空间不足或者au_size和db_block_size不匹配。解决asmcmd lsdg看 free_mb不够就加盘au_size至少是db_block_size的 4 倍4K 块配 4M AU 没问题如果块是 8K 就调到 8M AU。6.3 坑三DataGuard 备库 MRP 进程起不来现象备库v$managed_standby里没有 MRP0 进程或者状态是ERROR。原因standby_file_management没设成 AUTO或者log_archive_dest_1的DB_UNIQUE_NAME写错。解决ALTER SYSTEM SET standby_file_managementAUTO;检查log_archive_dest_1里的DB_UNIQUE_NAME和实际db_unique_name一致然后重启 MRPALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;再重新启动。6.4 坑四主备库密码文件不一致导致 TNS 连不上现象主库v$archive_dest_status里 dest_2 的 status 是 ERRORerror 写ORA-01031: insufficient privileges。原因备库的密码文件是从旧库拷的或者remote_login_passwordfile不是 EXCLUSIVE。解决主库orapwd重建密码文件scp 到备库$ORACLE_HOME/dbs/下两边remote_login_passwordfileEXCLUSIVE重启监听和实例。6.5 坑五switchover 后备库数据文件路径不对现象switchover 后备库变主库业务连上后报ORA-01157: cannot identify/lock data file。原因备库的db_file_name_convert和log_file_name_convert没配或者配了但路径映射不对。解决在备库的 spfile 里设db_file_name_convertDATA,DATA和log_file_name_convertFRA,FRA如果主备磁盘组名不同按实际映射写。改完重启备库再重新同步。7. 进阶技巧用 DataGuard Broker 简化切换和快速验证手动敲 switchover 命令容易漏步骤DataGuard Broker 能把切换、故障转移、状态监控统一管起来。配置不复杂但有几个参数必须提前设对。先在主备库都设dg_broker_starttrue然后dgmgrl里创建配置。# 主库上执行 dgmgrl sys/Oracle_123orcl_pri DGMGRL CREATE CONFIGURATION dg_config AS PRIMARY DATABASE IS orcl_pri CONNECT IDENTIFIER IS orcl_pri; DGMGRL ADD DATABASE orcl_std AS CONNECT IDENTIFIER IS orcl_std MAINTAINED AS PHYSICAL; DGMGRL ENABLE CONFIGURATION; DGMGRL SHOW CONFIGURATION;SHOW CONFIGURATION输出里Protection Mode默认是 MaxPerformance如果业务能接受一点延迟这个模式性能最好要零数据丢失就切 MaxAvailability 或 MaxProtection但网络抖动时主库可能挂起生产环境慎用。验证同步延迟用DGMGRL SHOW DATABASE orcl_std;看Apply Lag和Transport Lag。如果 lag 持续增大先查网络带宽再看备库 MRP 进程是不是卡在某个归档上。我一般会写个定时脚本每 5 分钟采一次 lag 值超过阈值就告警别等业务反馈查询变慢才发现。切换测试用DGMGRL SWITCHOVER TO orcl_std;Broker 会自动做前置检查比手动命令稳。切完SHOW CONFIGURATION确认角色互换业务连接串用 TNS 的ADDRESS_LIST配主备两个地址配合FAILOVERON客户端能自动重连。这套配完日常巡检就盯三个值Apply Lag、Transport Lag、v$dataguard_status里的 error 计数。我自己踩过最深的坑是第一次做 switchover 没测 TNS 重连切完业务连不上手动改连接串花了二十分钟。从那以后任何 DataGuard 环境上线前我一定在测试库把 switchover 和 failover 各跑一遍确认应用侧无感才算完。希望帮到你。本文还有配套的精品资源点击获取