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之路
墨天輪：http://www.sunline.cc/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
——————————————————————————