上篇《Oracle叢集技術 | 叢集的自啟動系列（一）》中我們說到系統啟動後由init.ohasd和ohasd兩個指令碼相互配合共同來完成叢集的啟動，當init.ohash前期工作準備完成，ohasd啟動叢集時需要首先讀取olr檔案，根據olr檔案中記錄的資訊啟動叢集的初始化資源層，並在該過程中建立叢集啟動及執行時所需的套接字檔案。

| OLR

OLR檔案中記錄的資訊是ohasd守護程式啟動叢集初始化資源時所需要的資源定義資訊，當叢集啟動時ohasd會從/etc/oracle/olr.loc檔案中獲取olr檔案的位置。

[root@node1 ~]# ls -ltr /etc/oracle
total 2248
drwxr-xr-x. 3 root oinstall    4096 Nov 21 01:38 scls_scr
drwxrwxr-x. 5 root oinstall    4096 Nov 21 01:38 oprocd
-rws--x---. 1 root oinstall 2279833 Nov 21 01:38 setasmgid
-rw-r--r--. 1 root root           0 Nov 21 01:38 olr.loc.orig
-rw-r--r--. 1 root oinstall      81 Nov 21 01:38 olr.loc
-rw-r--r--. 1 root root           0 Nov 21 01:38 ocr.loc.orig
-rw-r--r--. 1 root oinstall      40 Nov 21 01:38 ocr.loc
drwxrwx---. 2 root oinstall    4096 Nov 21 01:44 lastgasp
[root@node1 ~]# cat /etc/oracle/olr.loc
olrconfig_loc=/u01/app/11.2.0/grid/cdata/node1.olr
crs_home=/u01/app/11.2.0/grid
[root@node1 ~]# ls -ltr /u01/app/11.2.0/grid/cdata/node1.olr
-rw-------. 1 root oinstall 272756736 Jan  8 21:40 /u01/app/11.2.0/grid/cdata/node1.olr
[root@node1 ~]#

對於olr檔案，每個節點都有自己的olr檔案，預設位置在$GRID_HOME/cdata/<hostname>.olr，上面我們也提到olr配置檔案的路徑記錄在/etc/oracle/olr.loc檔案中，獲取olr配置檔案的位置也可以使用ocrcheck命令，ocrcheck命令同時也會驗證ocr/olr的邏輯完整性:

[root@node1 ~]# ocrcheck -local
Status of Oracle Local Registry is as follows :
     Version                  :          3
     Total space (kbytes)     :     262120
     Used space (kbytes)      :       2676
     Available space (kbytes) :     259444
     ID                       :  810831447
     Device/File Name         : /u01/app/11.2.0/grid/cdata/node1.olr
                                Device/File integrity check succeeded
     Local registry integrity check succeeded
     Logical corruption check succeeded
[root@node1 ~]# ocrcheck -local -config
Oracle Local Registry configuration is :
     Device/File Name         : /u01/app/11.2.0/grid/cdata/node1.olr
[root@node1 ~]#

ocrcheck驗證完整性是根據安裝時生成libocr11.so,根據libocr11.so內容來檢查ocr/olr。

注:如果ocrcheck檢查完整性失敗可以參考文件(ID 1617639.1)。

| 轉儲OLR檔案

olr檔案為二進位制方式儲存，我們可以使用oracle提供的ocrdump工具對olr檔案進行轉儲，生成文字模式的檔案，方便我們瞭解olr檔案內容。

[root@node1 ~]# ocrdump -local
[root@node1 ~]# ls -ltr
total 284
drwxr-xr-x. 2 root   root       4096 Jan 10  2018 tmp
drwxr-xr-x. 2 root   root       4096 Jan 10  2018 scripts
...
-rw-r--r--. 1 root   root      10257 Nov 20 09:20 install.log.syslog
-rw-r--r--. 1 root   root      52196 Nov 20 09:23 install.log
-rw-------. 1 root   root       1717 Nov 20 09:23 anaconda-ks.cfg
-rw-------. 1 root   root     179399 Jan  8 22:05 OCRDUMPFILE
[root@node1 ~]#

[grid@rac1 tmp]$ cat OCRDUMPFILE 
05/31/2018 03:50:13
/u01/app/11.2.0/grid/bin/ocrdump.bin -local 
[SYSTEM]
UNDEF : 
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}
... 
[SYSTEM.ORA_CRS_HOME]
ORATEXT : /u01/app/11.2.0/grid
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}
##GI_HOME資訊
[SYSTEM.WALLET]
UNDEF : 
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_CREATE_SUB_KEY, OTHER_PERMISSION : PROCR_CREATE_SUB_KEY, USER_NAME : root, GROUP_NAME : root}
... 
[SYSTEM.version.activeversion]
ORATEXT : 11.2.0.4.0
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}
##叢集版本資訊
[SYSTEM.GPnP]
UNDEF : 
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_NONE, OTHER_PERMISSION : PROCR_NONE, USER_NAME : grid, GROUP_NAME : oinstall}
##叢集初始化資源GPnP定義資訊
[SYSTEM.GPnP.profiles]
BYTESTREAM (16) : 
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_NONE, OTHER_PERMISSION : PROCR_NONE, USER_NAME : grid, GROUP_NAME : oinstall}
[SYSTEM.GPnP.profiles.peer]
UNDEF : 
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_NONE, OTHER_PERMISSION : PROCR_NONE, USER_NAME : grid, GROUP_NAME : oinstall}
…
[SYSTEM.network]
UNDEF : 
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : grid, GROUP_NAME : oinstall}
[SYSTEM.network.haip]
UNDEF : 
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : grid, GROUP_NAME : oinstall}
[SYSTEM.network.haip.group]
UNDEF : 
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : grid, GROUP_NAME : oinstall}
[SYSTEM.network.haip.group.cluster_interconnect]
UNDEF : 
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : grid, GROUP_NAME : oinstall}
[SYSTEM.network.haip.group.cluster_interconnect.interface]
UNDEF : 
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : grid, GROUP_NAME : oinstall}
##叢集初始化資源HAIP資訊
[SYSTEM.OCR]
UNDEF : 
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}
##OCR資訊
[SYSTEM.OCR.BACKUP]
UNDEF : 
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}
...

OLR與OCR檔案的資料儲存都是採用樹形結構，詳細資訊檢視dump後的檔案即可，這裡不再解讀。

| OLR檔案丟失導致的初始化資源層無法啟動

olr檔案丟失後，叢集啟動時alert[hostname].log日誌中會有明顯olr檔案無法讀取的錯誤資訊，如下：

alertnode1.log:

2018-03-26 06:15:17.579: 
[ohasd(5219)]CRS-0704:Oracle High Availability Service aborted due to Oracle Local Registry error [PROCL-33: Oracle Local Registry is not configured Storage layer error [Error opening olr.loc file. No such file or directory] [2]]. Details at (:OHAS00106:) in /u01/app/11.2.0/grid/log/node1/ohasd/ohasd.log.
2018-03-26 06:15:17.733: 
[ohasd(5230)]CRS-0704:Oracle High Availability Service aborted due to Oracle Local Registry error [PROCL-33: Oracle Local Registry is not configured Storage layer error [Error opening olr.loc file. No such file or directory] [2]]. Details at (:OHAS00106:) in /u01/app/11.2.0/grid/log/node1/ohasd/ohasd.log.
2018-03-26 06:15:17.886: 
[ohasd(5241)]CRS-0704:Oracle High Availability Service aborted due to Oracle Local Registry error [PROCL-33: Oracle Local Registry is not configured Storage layer error [Error opening olr.loc file. No such file or directory] [2]]. Details at (:OHAS00106:) in /u01/app/11.2.0/grid/log/node1/ohasd/ohasd.log.
[client(5256)]CRS-10001:CRS-10132: No msg for has:crs-10132 [10][60]

日誌中直接報olr.loc檔案無法開啟。(opening olr.loc file. No such file or directory)

[root@node1 ~]# ps -ef | grep -E 'ohasd|agent|gpnp|gipc|mdns' | grep -v grep
root     1332    1  0 20:53 ?   00:00:00 /bin/sh /etc/init.d/init.ohasd run
[root@node1 ~]#

後臺程式中，只有init.ohasd指令碼執行在後臺，初始化資源層中所有資源均為啟動，對於olr檔案丟失，我只需要透過備份的olr檔案還原即可。

| OLR檔案的備份與恢復

OLR檔案會在GI軟體安裝之後，或者GI升級之後自動進行一次備份，OLR檔案並不會像OCR一樣自動進行備份，如果初始化資源層面的資源出現變動，建議手工備份OLR檔案。

1.手動備份OLR

ocrconfig -local -manualbackup

2.檢視OLR檔案的備份

ocrconfig -local -showbackup

3.恢復OLR檔案

ocrconfig -local -restore <olr備份>

恢復時確保ohasd.bin未啟動，如果ohasd.bin仍在執行，請使用crsctlstop crs停止GI。

恢復OLR過程中如果出現PROTL-16:Internal Error錯誤，導致恢復失敗，可能是由於olr.loc檔案丟失導致，因為olr檔案還原時會讀取olr.loc檔案，將olr檔案恢復到olr.loc指定的位置。

[root@rac1 oracle]# ocrconfig -local -restore /u01/app/11.2.0/grid/cdata/rac1/backup_20180221_045700.olr
PROTL-16: Internal Error
[root@rac1 oracle]#

如果仍然失敗，請嘗試建立虛擬OLR，設定正確的所有權和許可權，然後重試還原命令：

#cd <OLR location> 
#touch <hostname> .olr 
#chmod 600 <hostname> .olr 
#chown <grid>：<oinstall> <hostname> .olr

4.驗證OLR檔案的完整性

對於OLR檔案的完整性驗證，也可以使用Oracle提供的CVU進行驗證，但這裡的驗證並不檢查OLR檔案內容的邏輯完整性，如果需要同時驗證邏輯完整性還需使用ocrcheck -local進行驗證。

[grid@node1 ~]$ cluvfy comp olr
Verifying OLR integrity 
Checking OLR integrity...
Checking OLR config file...
OLR config file check successful
Checking OLR file attributes...
OLR file check successful
WARNING: 
This check does not verify the integrity of the OLR contents. Execute 'ocrcheck -local' as a privileged user to verify the contents of OLR.
OLR integrity check passed
Verification of OLR integrity was successful. 
[grid@node1 ~]$

5.OLR檔案的自動備份

在12.2.0.1以上版本中，Grid也開始支援OLR檔案的自動備份，自動備份功能作為BUG的一部分而進行提供，BUG 24799186(現由BUG 26493466取代)，但在18.1以及GI RU 12.2.0.1.180116中以包含OLR自動備份功能。

| 套接字檔案

套接字檔案是程式與程式之間雙向通訊的端點，是程式間通訊的一種約定，Oracle叢集在啟動時，首先讀取OLR檔案進行初始化資源層的啟動，並逐步實現叢集的啟動，在此過程中會在/var/tmp/.oracle目錄中建立相關叢集程式需要的套接字檔案。

套接字檔案是叢集執行過程中必不可少的檔案，在叢集執行過程中請不要刪除相關套接字檔案，如果套接字檔案丟失會導致一些不可預知的問題。

如下測試是在叢集執行過程，手工刪除/var/tmp/.oracle中的所有檔案後，透過crsctl檢查叢集狀態，輸出CRS-4535與CRS-4000以及CRS-4639，第一感覺是叢集未啟動，但實際情況是叢集與資料庫均執行正常。

[root@node1 ~]# crsctl stat res -t
CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4000: Command Status failed, or completed with errors.
[root@node1 ~]# crsctl check crs
CRS-4639: Could not contact Oracle High Availability Services
[root@node1 ~]# ps -ef | grep -E 'ohasd|agent|mdns|gpnp|gipc|pmon' | grep -v grep
root   1332 1  0 Jan20 ?  00:00:00 /bin/sh /etc/init.d/init.ohasd run
root   3829 1  0 Jan20 ?  00:01:19 /u01/app/11.2.0/grid/bin/ohasd.bin reboot
grid   3951 1  0 Jan20 ?  00:01:10 /u01/app/11.2.0/grid/bin/oraagent.bin
grid   3962 1  0 Jan20 ?  00:00:00 /u01/app/11.2.0/grid/bin/mdnsd.bin
grid   3973 1  0 Jan20 ?  00:00:11 /u01/app/11.2.0/grid/bin/gpnpd.bin
grid   3984 1  0 Jan20 ?  00:01:43 /u01/app/11.2.0/grid/bin/gipcd.bin
root   3986 1  0 Jan20 ?  00:02:18 /u01/app/11.2.0/grid/bin/orarootagent.bin
root   4030 1  0 Jan20 ?  00:00:16 /u01/app/11.2.0/grid/bin/cssdagent
grid   4390 1  0 Jan20 ?  00:00:05 asm_pmon_+ASM1
grid   4559 1  0 Jan20 ?  00:02:03 /u01/app/11.2.0/grid/bin/oraagent.bin
root   4567 1  0 Jan20 ?  00:02:17 /u01/app/11.2.0/grid/bin/orarootagent.bin
oracle 4769 1  0 Jan20 ?  00:01:44 /u01/app/11.2.0/grid/bin/oraagent.bin
oracle 4832 1  0 Jan20 ?  00:00:07 ora_pmon_oraapp1
[root@node1 ~]#

對於套接字檔案丟失導致叢集執行不正常以及其他問題，最簡單的辦法就是重新啟動叢集，叢集在啟動時會重新建立需要的套接字檔案。

| 作者簡介

Oracle叢集技術 | OLR與套接字檔案（二）

| 套接字檔案

楊禹航·沃趣科技高階資料庫技術專家

熟悉Oracle資料庫內部機制，豐富的資料庫及RAC叢集層故障診斷、效能調優、OWI、資料庫備份恢復及遷移經驗。

相關文章