简介本资源是一份面向数据库运维工程师与DBA的实战安装指南聚焦在RHEL 7.6环境下部署Oracle 19C并配合ASM存储与DataGuard容灾架构适合具备一定Linux与Oracle基础、希望搭建高可用数据库环境的中高级技术人员参考。压缩包内仅含1个PDF文档整体约4.68MB内容以图文步骤形式呈现便于按章节对照操作。文档围绕硬件与软件环境要求、主备节点部署规划、GI与ORACLE_HOME目录结构、网络环境配置、安装前系统检查等模块展开并详细记录了Oracle 19C软件安装、ASM磁盘组配置以及DataGuard主从复制与网络配置的完整流程同时给出节点空间分配、内核参数与依赖包检查等关键细节。目前已有702人学习适合需要快速搭建Oracle 19C ASM DataGuard实验或生产环境、并希望减少踩坑的读者参考。1. RHEL 7.6 上 Oracle 19C ASM DataGuard这套组合拳到底值不值得打RHEL 7.6 安装 Oracle 19C 并挂 ASM 存储、再搭 DataGuard 容灾这套组合在传统行业核心库场景里依然常见。原因不复杂19C 是长期支持版本ASM 把裸设备和文件系统管理统一收口DataGuard 提供物理级 standby 保护。三者叠在一起等于把“单机高可用 存储抽象 异地容灾”一次性铺齐。但这条链路对系统参数、内核模块、用户组权限、磁盘绑定顺序极其敏感任何一个环节对不上轻则 dbca 建库卡死重则实例起不来、DG 同步断档。这篇笔记按真实落地顺序拆先讲清为什么这么选再给可复现的配置和命令最后把踩过的坑摊开。适合有 Linux 基础、准备在 RHEL 7.6 上从零搭一套 19C ASM DataGuard 的 DBA 或运维。2. 环境准备RHEL 7.6 的底子怎么打才不返工2.1 系统版本与依赖包为什么必须锁死RHEL 7.6 对应内核 3.10.0-957Oracle 19C 官方认证矩阵里这个组合是明确支持的。很多人图省事用 RHEL 7.9 或 CentOS 7 直接上结果遇到 glibc 版本差异导致 runInstaller 静默退出。我一般会先确认三件事cat /etc/redhat-release输出是否为 7.6uname -r内核是否在 957 系列yum repolist是否指向本地 ISO 源而非公网源。依赖包用一条命令批量装别一个个补# 挂载本地 ISO 作为 yum 源避免公网波动 mount -o loop /opt/rhel-server-7.6-x86_64-dvd.iso /mnt cat /etc/yum.repos.d/local.repo EOF [local] namelocal baseurlfile:///mnt enabled1 gpgcheck0 EOF # Oracle 19C 在 RHEL 7.6 上的必需依赖 yum install -y binutils compat-libcap1 compat-libstdc-33 \ gcc gcc-c glibc glibc-devel ksh libaio libaio-devel \ libgcc libstdc libstdc-devel libXi libXtst make \ net-tools nfs-utils smartmontools sysstat unzip逻辑说明compat-libstdc-33 和 libaio-devel 是最容易漏的两个前者缺失会导致 netca 图形界面起不来后者缺失会让 ASM 磁盘组创建时报 ORA-15018。参数说明baseurl 指向本地挂载点生产环境如果走内网 yum 源把 baseurl 换成内网地址即可gpgcheck 按安全要求决定是否开启。2.2 内核参数与用户组别等 dbca 报错才回头改内核参数和资源限制必须在创建 oracle 用户之前落盘否则后续用ulimit -a验证时会出现“改了但没生效”的玄学。我习惯把参数写进/etc/sysctl.d/99-oracle.conf而不是直接改/etc/sysctl.conf方便回滚cat /etc/sysctl.d/99-oracle.conf EOF 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 1048576 EOF sysctl -p /etc/sysctl.d/99-oracle.conf参数说明kernel.shmmax 设为物理内存的一半到 80% 之间上面这个值对应约 4TB 内存上限小内存机器按实际调小。kernel.sem 四个值分别是 SEMMSL、SEMMNS、SEMOPM、SEMMNI19C 对 SEMMNI 要求不低于 128这里给 128 是底线。用户组按标准建 oinstall、dba、oper、asmadmin、asmdba、asmoper 六个组oracle 用户主组 oinstall附属组把其余五个全带上。grid 用户主组 oinstall附属组 asmadmin、asmdba、asmoper。这一步错了后面 ASM 实例和数据库实例互相认不到对方。2.3 磁盘绑定与 ASM 设备命名udev 规则是后悔药ASM 要求磁盘设备名稳定重启后不能漂移。常见做法是用 udev 规则绑定而不是靠 /dev/sdX 碰运气。先确认磁盘 WWID# 查看每块盘的 WWID用于 udev 规则匹配 /usr/lib/udev/scsi_id -g -u -d /dev/sdb /usr/lib/udev/scsi_id -g -u -d /dev/sdc拿到 WWID 后写规则文件/etc/udev/rules.d/99-asm.rules把 OCR 盘和 DATA 盘分别绑定成 asm-ocr、asm-data。规则里用RESULTWWID匹配SYMLINKasm-ocr指定别名同时设置OWNERgrid、GROUPasmadmin、MODE0660。执行udevadm control --reload-rules udevadm trigger后用ls -l /dev/asm-*验证属主和权限。这一步没做重启后 ASM 找不到磁盘组实例直接 mount 失败。3. Grid 与 Oracle 软件安装ASM 实例先跑起来3.1 Grid Infrastructure 安装前必须确认的三件事Grid 安装是整条链路里最容易翻车的一环。安装前我会反复确认第一/etc/hosts里 SCAN IP、VIP、公网 IP、私网 IP 全部解析正确且公网和私网在不同网段第二ping -c 3能通所有节点单机也要配 SCAN第三ASM 磁盘权限是 grid:asmadmin 且模式 0660。确认完再解压 grid 安装包运行./gridSetup.sh。图形界面里选“Configure Oracle Grid Infrastructure for a Standalone Server”磁盘组选 External 冗余单机场景把 asm-ocr 和 asm-data 两块盘分别指定用途。安装过程中 root 脚本要按提示在两个终端分别执行别图快跳步。3.2 ASM 磁盘组创建与 oracle 进入 asm 命令Grid 装完后用 grid 用户执行asmcmd进入 ASM 命令行这是后续所有磁盘操作的基础。常用命令我列几个高频的# 以 grid 用户进入 asmcmd su - grid asmcmd # 查看磁盘组状态 lsdg # 查看磁盘组里的磁盘 lsdsk --discovery # 查看 ASM 实例状态 lsct如果要在数据库实例里查 ASM 信息用sqlplus / as sysasm登录 ASM 实例执行select name, state, total_mb, free_mb from v$asm_diskgroup;。注意sqlplus / as sysasm和sqlplus / as sysdba是两个不同实例别混。ASM 磁盘组创建时AU 大小默认 1M如果数据仓库场景可以设 4M但 OLTP 保持 1M 即可。创建命令create diskgroup DATA external redundancy disk /dev/asm-data;OCR 盘同理。3.3 Oracle 19C 数据库软件安装与 dbca 建库Oracle 软件安装用 oracle 用户运行./runInstaller安装类型选“Set Up Software Only”因为库要用 dbca 单独建。安装路径建议/u01/app/oracle/product/19.0.0/dbhome_1Inventory 目录/u01/app/oraInventory。安装完执行 root 脚本后用 dbca 建库# 以 oracle 用户运行 dbca静默模式建库 dbca -silent -createDatabase \ -templateName General_Purpose.dbc \ -gdbName orcl \ -sid orcl \ -responseFile NO_VALUE \ -characterSet AL32UTF8 \ -sysPassword Oracle_123 \ -systemPassword Oracle_123 \ -createAsContainerDatabase true \ -numberOfPDBs 1 \ -pdbName pdb1 \ -storageType ASM \ -diskGroupName DATA \ -recoveryGroupName FRA \ -datafileDestination DATA \ -redoLogFileSize 200 \ -emConfiguration NONE参数说明storageType 必须写 ASMdiskGroupName 对应前面创建的 DATA 组recoveryGroupName 是 FRA 快速恢复区没有单独盘可以复用 DATA。redoLogFileSize 单位 MBOLTP 场景 200 起步。建库完成后用srvctl status database -d orcl确认实例状态再用sqlplus / as sysdba执行select name, open_mode from v$database;验证。4. DataGuard 搭建从主库到备库的完整链路4.1 主库参数配置与归档开启DataGuard 的前提是主库开归档且强制日志。先确认archive log list输出为 Archive Mode如果不是用shutdown immediate到 mount 状态执行alter database archivelog; alter database open;。然后设置 DG 相关参数-- 主库参数force_logging 必须开 alter database force logging; alter system set log_archive_dest_1locationUSE_DB_RECOVERY_FILE_DEST valid_for(all_logfiles,all_roles) scopeboth; alter system set log_archive_dest_2serviceorcl_st valid_for(online_logfiles,primary_role) db_unique_nameorcl_st scopeboth; alter system set log_archive_configdg_config(orcl,orcl_st) scopeboth; alter system set fal_serverorcl_st scopeboth; alter system set fal_clientorcl scopeboth; alter system set standby_file_managementAUTO scopeboth;参数说明log_archive_dest_2 里的 service 名要和 tnsnames.ora 里配的备库连接串一致db_unique_name 主备必须不同。fal_server 和 fal_client 是归档缺口自动补齐的关键不配的话备库追日志会断。改完参数后alter system switch logfile;触发一次归档确认归档路径有文件生成。4.2 备库创建RMAN duplicate 的两种方式备库搭建常用 RMAN duplicate分 active 和 backup-based 两种。active duplicate 直接从主库拉数据文件适合网络好的场景backup-based 需要先把备份传到备库。我一般用 active# 备库上执行先启动到 nomount rman target sys/Oracle_123orcl auxiliary sys/Oracle_123orcl_st # 在 RMAN 里执行 duplicate duplicate target database for standby from active database spfile parameter_value_convert orcl,orcl_st set db_unique_nameorcl_st set control_filesDATA/ORCL_ST/CONTROLFILE/current.ctl set db_file_name_convertDATA/ORCL,DATA/ORCL_ST set log_file_name_convertDATA/ORCL,DATA/ORCL_ST set fal_serverorcl set fal_clientorcl_st set standby_file_managementAUTO set log_archive_dest_1locationUSE_DB_RECOVERY_FILE_DEST valid_for(all_logfiles,all_roles) set log_archive_dest_2serviceorcl valid_for(online_logfiles,primary_role) db_unique_nameorcl set log_archive_configdg_config(orcl,orcl_st);逻辑说明parameter_value_convert 把主库参数里的 orcl 替换成 orcl_st避免备库参数冲突。db_file_name_convert 和 log_file_name_convert 处理路径转换如果主备路径完全一致可以省略。duplicate 完成后备库自动到 mount 状态执行alter database recover managed standby database using current logfile disconnect;开启实时应用。4.3 DG 同步状态验证与切换测试搭完不验证等于没搭。主库执行select database_role, protection_mode, open_mode from v$database;确认是 PRIMARY 和 MAXIMUM PERFORMANCE。备库执行同样语句确认是 PHYSICAL STANDBY 和 MOUNTED。然后主库切几次日志备库查select sequence#, applied from v$archived_log order by sequence# desc fetch first 5 rows only;看 applied 是否为 YES。切换测试用alter database switchover to orcl_st;切完主备角色互换再切回来。这一步不做真出事时不敢切。5. 避坑与排查这套组合最容易翻车的五个点5.1 现象dbca 建库到 45% 卡死日志无报错原因ASM 磁盘组 AU 大小和 redo 日志块大小不匹配或者 udev 权限在 dbca 运行中被重置。解决先查asmcmd lsdg确认磁盘组 mount 状态再查/dev/asm-*权限是否还是 grid:asmadmin。如果是权限问题重新执行 udevadm trigger 并重启 ASM 实例。AU 大小建组后不能改只能删组重建。5.2 现象备库 MRP 进程起不来alert 日志报 ORA-01111原因standby_file_management 没设 AUTO或者 db_file_name_convert 路径写错导致备库找不到数据文件。解决备库执行show parameter standby_file_management确认是 AUTO检查v$datafile里路径是否指向备库实际路径。如果是路径错用alter database rename file 旧路径 to 新路径;修正后重启 MRP。5.3 现象主库归档日志堆积备库追不上原因log_archive_dest_2 的 service 名解析失败或者网络带宽不够。解决主库tnsping orcl_st确认连通性查v$archive_dest_status里 dest_2 的 error 字段。如果是网络问题调大 SDU 或压缩归档传输。fal_server 配了但没生效检查 tnsnames.ora 里 fal 相关条目。5.4 现象ASM 实例重启后磁盘组 mount 失败原因udev 规则没持久化或者磁盘顺序变了导致 WWID 匹配不上。解决ls -l /dev/asm-*看设备是否存在不存在就重新执行udevadm trigger。如果 WWID 变了换盘或扩容更新 99-asm.rules 里的 RESULT 值。生产环境建议用 multipath 绑定后再做 udev。5.5 现象switchover 后备库起不来报 ORA-16016原因备库还有未应用的归档日志或者主库切换时还有活动事务。解决switchover 前确认备库v$archived_log里 applied 全 YES主库v$transaction无长事务。如果已经报错备库执行recover managed standby database cancel;再recover database until cancel;手动应用完剩余日志然后重新开 MRP。6. 进阶技巧把 DataGuard 的验证做成日常习惯搭完 DG 只是开始真正省心的是把验证做成脚本。我习惯在主库放一个定时任务每天凌晨切一次日志并检查备库应用延迟#!/bin/bash # dg_check.sh主库执行输出备库延迟秒数 sqlplus -s / as sysdba EOF set pages 0 feedback off alter system switch logfile; select name, value from v$dataguard_stats where nameapply lag; EOF逻辑说明apply lag 是备库应用延迟正常应在秒级。如果超过 300 秒脚本触发告警。参数说明v$dataguard_stats 里还有 transport lag两个都看。这个脚本配合监控平台比事后翻 alert 日志快得多。另一个技巧是备库只读测试。备库在 mount 状态不能查数据但可以临时alter database open read only;验证数据一致性查完再alter database recover managed standby database using current logfile disconnect;回到应用状态。注意open read only 期间 MRP 会停查完必须手动恢复别查完就忘了。最后说个血泪经验DG 的 tnsnames.ora 里主备连接串的 SID 和 SERVICE_NAME 别写混。我见过有人把 service 写成 SIDtnsping 能通但 DG 同步就是断查了两天才发现是连接串格式问题。主库用 SERVICE_NAME备库也用 SERVICE_NAME保持一致。这套组合拳打下来最深的体会是参数可以查文档但顺序和权限只能靠一遍遍试。希望帮到你。本文还有配套的精品资源点击获取