Oracle 19c RAC ADG on RHEL9.6 遇到的几个坑
大家好，我是 JiekeXu,江湖人称“强哥”，青学会 MOP 技术社区主席，荣获 Oracle ACE Pro 称号，墨天轮 MVP，墨天轮年度“墨力之星”，拥有 Oracle OCP/OCM 认证,MySQL 5.7/8.0 OCP 认证以及 PCA、PCTA、OBCA、OGCA、KCA、KCP、KCM、KCSM 等众多国产数据库认证证书,欢迎关注我的微信公众号“JiekeXu DBA之路”，然后点击右上方三个点“设为星标”置顶，更多干货文章才能第一时间推送，谢谢！
前 言
近期接到一新活，领导让把一单机 ADG 替换成 RAC，并将业务从原主库切换到新搭建的 RAC 库，活是挺简单的，但有个小问题就是购买的硬件仅支持 RHEL 8.6 以上的系统，不支持 RHEL 7.9，所以决定使用 RHEL 9.6 安装 Oracle 19.23 RAC 来支持业务运行，本周在搭建测试环境时遇到了几个小坑，特此记录一下。
坑一 内存大页无法使用
配置好的内存大页无法使用，只要一启动数据库实例，主机立马 OOM 重启，重启之后因为 RAC 实例自动管理自启动，接着主机又重启，循环往复，临时解决办法只能先将内存大页参数注释掉排查问题。
# cat /etc/sysctl.conf | grep hugepages
#vm.nr_hugepages =13400
这个值是从原主库系统参数里拷贝过来的，主机内存大小也和原库一样，唯一的区别在于原库是 RHEL7.9，目标备库是 RHEL9.6，然后 memlock 设置为 44245094，这都没有问题。
# cat /etc/security/limits.d/oracle-database-preinstall-19c.conf | grep memlock
oracle hard memlock 44245094
oracle soft memlock 44245094
# free -h
total used free shared buff/cache available
Mem: 46Gi 39Gi 9.0Gi 2.9Gi 6.4Gi 7.5Gi
Swap: 19Gi 0B 19Gi
# cat /etc/sysctl.d/99-oracle-database-preinstall-19c-sysctl.conf | grep swap
vm.swappiness = 0
至于主机会重启应该是 swappiness 为零，用不到交换内存，SGA 直接使用内存又不够，进而直接启动实例后 OOM。那么接下来需要排查为何内存大页无法使用。首先想到的便是数据库参数 use_large_pages,查看参数值也是为 TRUE，memory_target值也为 0。
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.23.0.0.0
SQL> show parameter use_large_pages
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
use_large_pages string TRUE
SQL>
SQL> col name for a22
SQL> col value for a22
SQL> select name, value from v$parameter where name in ('memory_target','sga_target','sga_max_size');
NAME VALUE
---------------------- ----------------------
sga_max_size 22548578304
sga_target 22548578304
memory_target 0
查看 alert 日志发现也是没有使用大页，如果使用了大页会在内存中有显示，这里ALLOCATED_PAGES 已分配页面显示为 0 则未使用：
Supported system pagesize(s): 2025-08-08T16:31:08.418662+08:00 PAGESIZE AVAILABLE_PAGES EXPECTED_PAGES ALLOCATED_PAGES ERROR(s) 2025-08-08T16:31:08.418700+08:00 4K Configured 7 5505031 NONE 2025-08-08T16:31:08.418762+08:00 2048K 13400 10753 0 NONE 2025-08-08T16:31:08.418798+08:00
接下来查看操作系统日志，没有明显错误，但在日志中有 SHM_HUGETLB 关键字信息
# grep SHM_HUGETLB /var/log/messages
Aug 7 16:40:25 jiekerac1 kernel: hugetlbfs: oracle (184038): Using mlock ulimits for SHM_HUGETLB is obsolete
Aug 7 16:55:37 jiekerac1 kernel: hugetlbfs: oracle (17720): Using mlock ulimits for SHM_HUGETLB is obsolete
Aug 7 17:04:04 jiekerac1 kernel: hugetlbfs: oracle (16900): Using mlock ulimits for SHM_HUGETLB is obsolete
Aug 7 17:07:43 jiekerac1 kernel: hugetlbfs: oracle (8240): Using mlock ulimits for SHM_HUGETLB is obsolete
Aug 7 17:10:28 jiekerac1 kernel: hugetlbfs: oracle (7361): Using mlock ulimits for SHM_HUGETLB is obsolete
Aug 7 17:14:06 jiekerac1 kernel: hugetlbfs: oracle (9957): Using mlock ulimits for SHM_HUGETLB is obsolete
Aug 7 18:25:15 jiekerac1 kernel: hugetlbfs: oracle (50633): Using mlock ulimits for SHM_HUGETLB is obsolete
# 另一节点也是有此关键信息：
# grep SHM_HUGETLB /var/log/messages
Aug 8 16:28:15 jiekerac2 kernel: hugetlbfs: oracle (32209): Using mlock ulimits for SHM_HUGETLB is obsolete
Aug 8 16:31:08 jiekerac2 kernel: hugetlbfs: oracle (7956): Using mlock ulimits for SHM_HUGETLB is obsolete
Aug 8 16:33:31 jiekerac2 kernel: hugetlbfs: oracle (8256): Using mlock ulimits for SHM_HUGETLB is obsolete
问题原因
经过排查与网络搜索，最终确认是由于少配置了 hugetlb_shm_group 参数导致。
(vm.hugetlb_shm_group 参数设置为有权使用 HugePages 的操作系统组。默认情况下，此参数设置为 0，
从而允许所有组使用 HugePages，可以将此参数设置为 Oracle 数据库进程所属的操作系统组，如 oinstall)。
[root@jiekerac1 ~]# cat /proc/sys/vm/hugetlb_shm_group 0 [root@jiekerac1 ~]# cat /etc/group | grep install oinstall:x:1000:oracle,grid [root@jiekerac1 ~]# id oracle -g 1000 [root@jiekerac1 ~]# id grid -g 1000
解决办法
查看 Oracle 和 Grid 用户组 oinstall GID 为 1000，那么在 sysctl.conf 中增加 vm.hugetlb_shm_group=1000 ,然后重启系统，重启后发现内存大页已使用。
# echo 1000 > /proc/sys/vm/hugetlb_shm_groug
# sysctl -w vm.hugetlb_shm_group=1000
# cat /etc/sysctl.conf | grep huge
vm.nr_hugepages =13400
vm.hugetlb_shm_group=1000
# cat /proc/meminfo | grep Huge
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
FileHugePages: 0 kB
HugePages_Total: 13400
HugePages_Free: 13400
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
Hugetlb: 27443200 kB
# reboot
[root@jiekerac1 ~]# cat /proc/meminfo | grep Huge
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
FileHugePages: 0 kB
HugePages_Total: 13400
HugePages_Free: 2762
HugePages_Rsvd: 115
HugePages_Surp: 0
Hugepagesize: 2048 kB
Hugetlb: 27443200 kB
周末在网上也看到了一篇因为使用 systemctl 管理的 Oracle 单机也没法使用内存大页，这当然也是第一次遇见，也很少看到有人使用 systemctl 管理 Oracle。
坑二 预安装 preinstall 包带来的烦恼
通过安装官网提供的 dnf localinstall oracle-database-preinstall-19c-1.0-1.el9.x86_64.rpm -y,然后我们查看 var 目录下的安装日志 orakernel.log 得知，会先创建组 oinstall、dba、oper 和 backupdba、dgdba、kmdba、racdba 相关组(如果已存在则跳过创建)，接着创建 Oracle 用户，然后备份参数 sysctl.conf 并修改，且在 sysctl.d 目录下生成一个 99-oracle 开头的文件保存所有参数，接着修改参数 limits.d 目录下的 oracle 开头的文件，接着备份并修改 /etc/default/grub 内核参数文件，关闭透明大页，禁用 numa,在这期间也安装了一些 rpm 包，但没有日志打印出来。
cat /var/log/oracle-database-preinstall-19c/backup/Aug-06-2025-11-31-00/orakernel.log
Group oinstall - Already exists. Not creating again.
Group dba - Already exists. Not creating again.
Group oper - Already exists. Not creating again.
Adding group backupdba with gid 54324
Adding group dgdba with gid 54325
Adding group kmdba with gid 54326
Adding group racdba with gid 54330
User oracle - Already exists. Not creating or modifying.
User creation passed
Saving a copy of the initial sysctl.conf
Disabling Transparent Hugepages.
Refer Oracle Note:1557478.1
Disabling defrag.
Refer Oracle Note:1557478.1
Taking a backup of old config files under /var/log/oracle-database-preinstall-19c/backup/Aug-06-2025-11-31-00
cat /etc/sysctl.d/99-oracle-database-preinstall-19c-sysctl.conf
cat /etc/default/grub
cat /etc/security/limits.d/oracle-database-preinstall-19c.conf --仅有 Oracle 用户限制
# oracle-database-preinstall-19c setting for memlock hard limit is maximum of 128GB on x86_64 or 3GB on x86 OR 90 % of RAM
oracle hard memlock 134217728 ## 44245094
# oracle-database-preinstall-19c setting for memlock soft limit is maximum of 128GB on x86_64 or 3GB on x86 OR 90% of RAM
oracle soft memlock 134217728 ## 44245094
这些设置基本上都没有啥太大的问题，但 limits 限制仅有 Oracle 用户的设置，没有 Grid 用户，且 memlock 参数直接给我设置成了 128GB=134217728，我这里只是希望设置成 44245094 = 90% of RAM。另外对于官方要求的其他的 prm 包，也是少了几个没有安装。
rpm -q bc \ binutils \ compat-openssl11 \ elfutils-libelf \ fontconfig \ glibc \ glibc-devel \ ksh \ libaio \ libasan \ liblsan \ libX11 \ libXau \ libXi \ libXrender \ libXtst \ libxcrypt-compat \ libgcc \ libibverbs \ libnsl \ librdmacm \ libstdc++ \ libxcb \ libvirt-libs \ make \ policycoreutils \ policycoreutils-python-utils \ smartmontools \ sysstat | grep "not installed" package compat-openssl11 is not installed package libasan is not installed package liblsan is not installed package libvirt-libs is not installed 预定义安装包中少了上面四个包，还需要单独安装 dnf -y install compat-openssl11 libasan \ liblsan \ libvirt-libs
当然这都算是小问题了，不是什么大坑，安装的时候注意下就行。还有一点注意的就是 **Oracle 12c (12.2) 及更高版本在 Oracle Linux 和 Red Hat Enterprise Linux 上安装 Oracle 数据库或 Oracle GI 时，不再需要编译器包 gcc 和 gcc-c++。**如果有其他包 比如 rlwrap 包要编译安装，需单独安装 gcc-c++ 相关的包。
在 RHEL 9.6 中安装包有所区别，比 RHEL 7 增加了 libasan、liblsan、compat-openssl11 、libxcrypt-compat、libibverbs 、libnsl、librdmacm、libvirt-libs 八个包
--查看已安装的 prm 包是 32 位还是 64 位 rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE} (%{ARCH})\n" | grep glibc-devel
坑三 执行 runcluvfy 预安装检查卡住
如下在执行预安装检查时，敲命令半小时多了没有任何反应，也没有日志输出，没办法最后要放弃时，突然想到了之前看的文章。https://mp.weixin.qq.com/s/6MWe6twWZ7010YBjcx3nig 想到了执行安装前需要 * export CV_ASSUME_DISTID=RHEL8*
su - grid cd /u01/app/19.0.0/grid/ ./runcluvfy.sh stage -pre crsinst -n jiekerac1,jiekerac2 -fixup -verbose> /home/grid/checkGrid.log 2>&1
*CV_ASSUME_DISTID：此属性用于CVU无法检测或支持特定平台或发行版的情况。Oracle 不建议更改此属性，因为这可能导致 CVU 无法正常工作。* 没办法，设置完此参数后很快就检查通过了，虽只检查了节点1。
*注意：********由于19c(19.3)版本已发布一段时间，该版本不包含针对 OL/RHEL 9 的特定预先检查。安装程序将因以下错误而失败，因为不存在针对 OL/RHEL 9 的特定预先检查。*
[WARNING] [INS-08101] Unexpected error while executing the action at state:'*supportedOSCheck*' CAUSE: No additional information available. ACTION: Contact Oracle Support Services or refer to the software manual. SUMMARY: - java.lang.NullPointerException
*因此，需要引导安装程序将已安装的操作系统视为 OL 8，并执行相关检查。*
*因此，在启动安装程序之前，需要设置以下变量：*
$ export CV_ASSUME_DISTID=OL8 <<<<< If performing Installation on Oracle Linux 9
$ export CV_ASSUME_DISTID=RHEL8 <<<<< If performing Installation on RedHat Linux 9
坑四 ADG 搭建过程中遇到 ORA-00202 的错误
在 ADG 搭建过程中，我们需要使用 duplicate 将主库的数据同步到备库中，但是在同步的过程中遇到了 ORA-00245 的错误。这个错误也比较常见，之前应该也写过相同的案例，大概就是因为在备份的时候，快照控制文件备份需要备份到共享存储 ASM 里，如果在文件系统上，另外一个节点访问不到就会报target might not be on shared storage目标可能不在共享存储上，那么解决办法也就是将其放到 ASM 里就行。
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 08/07/2025 19:11:01
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
RMAN-03009: failure of backup command on c1 channel at 08/07/2025 19:11:01
ORA-00245: control file backup failed; in Oracle RAC, target might not be on shared storage
但是，为何会不在 ASM 里呢？原主库虽然是测试库，但也做过 Rman 备份，此值也是改过的，当时有点纳闷，后来这两天才想到原主库也是上个月刚通过搭建 ADG 的方式切换成主库的，duplicate 之后 Rman 参数会将 SNAPSHOT CONTROLFILE 默认放到节点一的 dbs 目录下，节点二没法访问就会报错。知道了问题，那就修改参数填坑吧。
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DATA'; new RMAN configuration parameters: CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DATA'; new RMAN configuration parameters are successfully stored
通过上面的参数设置后，继续运行 duplicate 但是又报了下面的错误，ORA-00202与ORA-17503 无法打开 ASM 文件，猛然间也很让人迷惑，明明已经改到 ASM 了呀，但仔细一看发现还是改错了，这里需要写具体的路径加文件名，不能直接写磁盘组名称。
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 08/07/2025 19:13:58
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
RMAN-03009: failure of backup command on c1 channel at 08/07/2025 19:13:58
ORA-00234: error in identifying or opening snapshot or copy control file
ORA-00202: control file: '+DATA'
ORA-17503: ksfdopn:2 Failed to open file +DATA
ORA-15045: ASM file name '+DATA' is not in reference form
**正确的参数设置办法，写清楚具体路径和文件名即可。**然后 duplicate 就可以正常执行了。
RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DATA/JIEKEXU/CONTROLFILE/snapcf_jiekexu.f';
old RMAN configuration parameters:
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DATA';
new RMAN configuration parameters:
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DATA/JIEKEXU/CONTROLFILE/snapcf_jiekexu.f';
new RMAN configuration parameters are successfully stored
RMAN> show all;
RMAN configuration parameters for database with db_unique_name JXRTUAT are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '+DATA';
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE RMAN OUTPUT TO KEEP FOR 7 DAYS; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO ALL STANDBY;
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DATA/JXRTUAT/CONTROLFILE/snapcf_jiekexu.f';
坑五 MOS 上发现的一个值得注意的问题 ORA-00354
REDO Block Header Corruption Seen On ASM Post OS Migration To RHEL 9.6 (Doc ID 3091260.1)
将数据库迁移至 RHEL 9.6 并将其更新至 19.27 版本遇到了 REDO Block Header ORA-00354: corrupt redo log block header .
uname -a 5.14.0-570.16.1.el9_6.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Apr 29 17:28:25 EDT 2025 x86_64 x86_64 x86_64 GNU/Linux --数据库 alert 日志如下 2025-05-22T16:16:04.287721-07:00 Closing local archive destination LOG_ARCHIVE_DEST_1 '+RECO/<<PRDDB>>/ARCHIVELOG/2025_05_22/thread_1_seq_2024.293.1201798165', error=354 (<<PRDDB>>) 2025-05-22T16:16:04.318064-07:00 Deleted Oracle managed file +RECO/<<PRDDB>>/ARCHIVELOG/2025_05_22/thread_1_seq_2001.809.1201798795 2025-05-22T16:16:04.324307-07:00 ARC0 (PID:17763): Abort creation of archive log '+RECO/<<PRDDB>>/ARCHIVELOG/2025_05_22/thread_1_seq_2024.293.1201798165', error:354 2025-05-22T16:16:04.341211-07:00 Errors in file /u01/app/oracle/diag/rdbms/<<PRDDB>>/<<PRDDB>>/trace/<<PRDDB>>_arc3_17773.trc: ORA-16038: log 3 sequence# 2001 cannot be archived ORA-00354: corrupt redo log block header <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ORA-00312: online log 3 thread 1: '+DATA/<<PRDDB>>/ONLINELOG/group_3.523.1201730473' ORA-00312: online log 3 thread 1: '+RECO/<<PRDDB>>/ONLINELOG/group_3.859.1201730473'
官方在审查了几个损坏的块转储后，发现重做块中的块信息不正确（可能是写入操作出现问题），导致数据损坏。此外，还发现了一个模式，即预期块数与实际块数之间存在8个块的差异。
Corrupt redo block 65539 detected: BAD BLOCK HEADER header size = 16, block size = 512 Flag: 0x1 Format: 0x22 Block: 0x0000fffb Seq: 0x0000020d Beg: 0x5c Cks:0x7fd4 Dump of memory from 0x00007F783590D600 to 0x00007F783590D800 7F783590D600 00002201 0000FFFB 0000020D 7FD4805C [."..........\...] ◀◀---- Found block 65531 while expected 65539 for sequence 525
可能的原因是：
Red Hat Enterprise Linux (RHEL) 9.6 在块层引入的更改似乎导致了与某些虚拟磁盘的丢弃操作相关的数据损坏问题，尤其是在与 Oracle 数据库工作负载配合使用时。这被怀疑是回归问题，Red Hat 已承认该问题。其支持和工程团队正在积极努力复现并解决该问题。
解决办法：
根据 RHEL 的说明，该问题可通过以下其中一种方式进行临时解决。
1）将 Oracle 数据库磁盘的 discard_max_bytes 设置为 0
例如，可以在运行时使用以下命令将 discard_max_bytes 更改为选定的磁盘，这将禁用指定设备上的丢弃操作。
for i in sdc sdd sde sdf; do echo 0 > /sys/block/$i/queue/discard_max_bytes; done
2）使用 RHEL 9.5 内核
该问题不会影响 RHEL 9.5.z 内核。使用 RHEL 9.5 内核重新启动系统可完全避免该问题。
3）作为临时解决方法，将 Oracle 重做日志移动到 XFS 文件系统，该文件系统似乎受此与丢弃相关的行为影响较小。
参考文章
Requirements for Installing Oracle Database/Client 19c (19.22 or higher) on OL9 or RHEL9 64-bit (x86-64) (Doc ID 2982833.1) REDO Block Header Corruption Seen On ASM Post OS Migration To RHEL 9.6 (Doc ID 3091260.1) 在 Unix AIX，HP-UX，Linux，Solaris 和 MS Windows 操作系统上安装和配置 Oracle 数据库（RDBMS）的要求的快速参考(12.1/12.2/18c/19c) (Doc ID 2226599.1) RMAN CONFIGURE SNAPSHOT CONTROLFILE to ASM fails ORA-00234 ORA-00202 ORA-17503 ORA-15045 (Doc ID 1564738.1) https://docs.oracle.com/en/database/oracle/oracle-database/19/cwlin/supported-red-hat-enterprise-linux-9-distributions-for-x86-64.html
全文完，希望可以帮到正在阅读的你，如果觉得有帮助，可以分享给你身边的朋友，同事，你关心谁就分享给谁，一起学习共同进步~~~
欢迎关注我的公众号【JiekeXu DBA之路】，一起学习新知识！
——————————————————————————
公众号：JiekeXu DBA之路
墨天轮：https://www.modb.pro/u/4347
CSDN ：https://blog.csdn.net/JiekeXu
ITPUB：https://blog.itpub.net/69968215
IFCLUB：https://ifclub.com.cn/user?type=1
腾讯云：https://cloud.tencent.com/developer/user/5645107
——————————————————————————
