共計 9449 個字符，預計需要花費 24 分鐘才能閱讀完成。

這篇文章主要介紹“Oracle 集群中 OLR 與套接字文件分析”，在日常操作中，相信很多人在 Oracle 集群中 OLR 與套接字文件分析問題上存在疑惑，丸趣 TV 小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Oracle 集群中 OLR 與套接字文件分析”的疑惑有所幫助！接下來，請跟著丸趣 TV 小編一起來學習吧！

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