Oracle集群中OLR與套接字文件分析

這篇文章主要介紹“Oracle集群中OLR與套接字文件分析”，在日常操作中，相信很多人在Oracle集群中OLR與套接字文件分析問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Oracle集群中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。

| 轉儲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與套接字文件分析”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！