在開始向大家分享之前，先說說 Oracle 的錯誤的標示體系，大家都知道在 Oracle 數據庫中有大量的錯誤，比如以 ora-開頭、tns-開頭、crs-開頭，當然還有其他工具類的錯誤開頭比如 exp 和 imp 等。
當然都是大家熟悉的錯誤開頭，其中 ora-類錯誤大家接觸的最多，這是和 Oracle 數據庫相關的錯誤類別，今天就和大家分享的是 ora-00481錯誤。
我們先來看看 ora-00481 的含義及可能的原因。
Ora-00481 錯誤意思是 lmon 進程 abort。
Ora-00481 錯誤的可能原因有以下幾種：
1. 由 DRM 引起，當 DRM 開始後但是並未完成所致。
2. ASM 或者 database 啓動失敗造成 RAC 重構時報 ora-00481錯誤
3. Lmon 與 OCSSD 通信失敗出現 ora-00481 錯誤
4. 實例被驅逐時伴隨 ora-00481 錯誤。
以上4條引起481錯誤的原因。
下面就這幾個可能原因簡單在日誌中反饋的結果做下分析：
1. 由 DRM 引起的481錯誤。
由 DRM 引起的 ora-00481錯誤，是由於 DRM 開始但是並未完成導致，在 lmon 的 trace 文件中會顯示 DRM 並未完成的提示：
在上述 trace 中，沒有 End DRM(107) 的信息。意思就是 DRM 期間，LMON 進程沒有工作導致 DRM 並沒有完成，以至於實例被驅逐。在這種情況下需要更多日誌信息來確定是由於 DRM 未完成導致的，我們可以按照下述的步驟進行一步步的確定：
A. LMSx trace 文件給出如下類似的信息:
上述顯示需要更多的 LOCK ELEMENTS (簡稱 LE) ， 但是沒有有效的。
LMS 進程在 DRM 重構的過程中由於 LE 短缺導致失速，然後導致 DRM 超時並造成實例的crash.
這種問題需要打補丁 bug:11875294,bug:12537479，根據補丁內容設置參數_gc_read_mostly_locking。
B. 還有一種情況如下；
在 lmon trace文件中體現如下：
LMON 進程等待 LMD 接收 ftdones。
進一步查看 LMD0 的 trace 文件，來確定爲什麼 LMD 不工作了，這個需要查看所有節點上的 LMD0 的 trace 文件。如下：
在 trace 文件中 “avl 0”意味着目前該節點可用的 ticket 數量爲0；所以 LMS 進程跑出了 flow control tickets 的範圍，在該種情況下，Oracle 推薦更新相應補丁來解決此類問題，比如：bug16819962.17452841,17801017,17847764,16088176；或者通過調整初始化參數_lm_tickets 來增加 tickets 的數量；根據我們的實際經驗，對於高併發系統來講，建議調整爲5000。
這裏很可能人可能並不理解什麼是 ticket，這裏我再爲大家簡單介紹一下 Oracle ticket 消息機制，這是 Oracle 爲了保證在實例之間傳輸的消息的平衡和對傳輸的消息的機率，控制彼此之間的合理流量而引入的一個消息機制，RAC 通過 ticket 對彼此之間傳輸的流量和機率進行控制。
一個節點發送一則消息隊列的同時會帶着一個 ticket 到對端，對端的 ticket 會增加。本地的 ticket 會減少，本地節點會根據可用的 buffer 和已經收到的信息以及發送的請求 ticket 的信息（null-req）計算本地可用的 tickets。當本地沒有 ticket 可用，本地的 LMS/LMD 就會進入消息等待隊列，並持續的檢查 ticket latch 裏的信息，判斷是否有可用的 ticket 的信息可用。直到對端發送回 message，並帶回可用的 tickets 後，本地才能再繼續發送消息到對端。上述的例子就是由於實例間 ticket 短缺，引發 LMS/LMD 之間消息傳輸超時出現的故障。
這個可以通過視圖 GV$GES_TRAFFIC_CONTROLLER 來獲取每個節點上的 avalible 的 ticket 的數量，或者可以通過隱含參數_lm_tickets 來進行控制，該參數默認值是1000，通過該參數可以避免上述出現的錯誤。
2. 在 alert 中發現如下信息：
並且這條信息是在實例被驅逐或者實例由於 ora-00481abort。
在這種情況下，有三種思路，如下；
① 心跳網絡連接問題，
② HAIP 的問題，在這種情況下，先需要確定 HAIP 是否可以正常使用。
③ 服務器負載壓力過大。可以通過 oswatcher 來收集系統資源使用情況。
3. 在 alert 中發現如下信息：
Ora-29701 錯誤，意思 lmon 與 OCSSD of CRS/GridInfrastructure. 丟失連接。
在這種情況有兩種思路：
① 確定是否有 job 或者用戶誤刪除了 /tmp/.oracle 和 /var/tmp/.oracle
② 更新補丁 bug 14096821.
Ora-00481 錯誤可能出現的原因以及日誌中的反饋我們已經大概瞭解了，下面我們就看看用戶 crm 庫的具體情況。
客戶這的 crm 數據庫在8月1日早上2節點突然業務連接中斷，查看2節點 alert 日誌發現日誌中報了 ora-00481 錯誤，並且後續導致2節點實例 abort，在2分鐘之內又重新啓動，恢復正常。
先介紹下客戶這邊的環境 HP-Unix + RAC, Oracle 版本10.2.0.4 使用的是裸設備。所以需要收集的日誌文件有，database alert 日誌，trace 文件（lmon, lmd, lms, diag, lmhb, dia0），按照順序先收集 database alert 日誌，如下：
上述信息中，只是表明了由於481錯誤終止了實例，所以需要更多的信息來確定問題來源。
在分析 LMON 的 trace 文件之前，簡單的描述下 LMON 進程，LMON 進程，主要是監控 RAC 的 GES 信息以及負責檢查集羣中各個節點的健康情況，當有節點出現故障時，負責進行 reconfig 以及 GRD (globalresource Directory)
的恢復等。
RAC 的腦裂機制，Lmon 進程檢查到實例級別出現腦裂時，會通知 clusterware 來進行腦裂操作，當等待超過一定時間，那麼 LMON 進程會自動觸發 IMR (instancemembership recovery)，這實際上也就是我們所說的 Instancemembership reconfig。
其次，lmon 進程主要通過2種心跳機制來檢查判斷集羣節點的健康狀態：
① 網絡心跳（主要是通過 ping 進行檢測）
② 控制文件磁盤心跳，其實就是每個節點的 ckpt 進程每3s更新一次 controlfile 的機制。
現在查看上述中給出的 lmon 的 trace 日誌文件：
我們可以看出在 LMON 進程的 trace 文件中最近的記錄爲4月24日，並沒有發現故障時間點8月1日的相關信息。由於是 Oracle LMON 檢測到異常後並終止了實例，那麼我們進一步分析 LMON 進程；
因此我們這裏進一步檢查確認是否有相關的有價值的線索。
通過 ls -rtl | greplmon 命令得到最近的 LMON 的 trace 日誌。
查看最近的 LMON 的 trace 日誌，ngcrm2_lmon_11361.trc
結合 alert 和 LMON trace 查看，時間點順序是這樣的：
時間 1 08:29:43，實例終止，
時間 2 08:30:11.107 在 LMON trace 中 reconfigure 開始，
在結合 alert 日誌中
時間 1 08:30:00 實例進程啓動
時間 2 08:30:06，實例啓動完成，啓動後臺進程包括 LMON 進程，
時間 3 08:30:18 進程 CRS 重構，
時間 4 08:30:35 database open。
也就是說上述的 LMON 進程的 trace 文件是在實例恢復後的 trace 文件，在之前的就沒有，而且在實例恢復後的 LMONtrace 文件中看到 DRM Reconfiguration 都是正常的。所以在這沒辦法判定是否是由於 DRM 造成的481錯誤。
需要進一步來查看 lmd 日誌和 diag 日誌，以及 lms 日誌：
Lms 日誌（more ngcrm2_lms0_11365.trc）
LMD 日誌（ngcrm2_lmd0_11363.trc）
Diag 日誌信息（ngcrm2_diag_11357.trc）
在這三個日誌中由於設置了 dump_file_size 的大小爲 5M，之前的日誌都沒法查看。
但是在 alert 日誌中和 LMON 日誌，LMD 日誌中多次出現與 DRM 相關的內容，而且在 LMD 日誌中，出現的如下兩條內容：
以及 LMON 日誌中的：
等信息，在結合我們之前分析的 ora-00481 錯誤出現的幾個因素，是由於 DRM 開始後未完成，在實例啓動起來後，重新進行未完成的 reconfiguer. 並且在之後的 LMON trace 文件中，還可以看到一些 DRM 開始以及結束的信息，且非常頻繁。
總結：基於我們對 Oracle lmon 等進程的原理以及結合前面的種種日誌分析，我們認爲此次故障跟 Oracle DRM 有極大關係（實際上我們在其他客戶案例中遇到了很多類似情況，尤其是 Oracle 10g rac 環境中，DRM 穩定性較差）。
DRM（Dynamic Resourcemanagement）動態資源管理。真正實現是在10.1.0.2之後的版本之後，10g 之前也有。
該特性的設計初衷是爲了通過更改所訪問資源的 master node 降低跨節點頻繁訪問需求，通過更改 master node 的節點屬性，讓訪問資源的頻繁的節點成爲 master node ，把節點之間的塊交換放在節點本地以降低節點之間訪問塊的低價。在 10gR2 之後，file affinity 演化爲細粒度更高的 object affinity，並且同時引入了 undoaffinity，只要是滿足隱含參數要求，DRM 就會被啓用，可以通過 LMON 和 lms 的 trace 文件就可以發現有很多的 remastering. 在11g之後 Oracle 引入了兩個重要的指標。Read-mostly locking 以及 reader bypass.。read-mostly locking: 簡單的說就是，對於某個對象，比如讀非常多，預先給它加一層共享訪問鎖，所有結點都持有，因而減少了共享鎖的申請操作。而當需要寫操作時，需申請排它鎖時，在每個結點上都申請一個”anti-lock”鎖，可以理解爲”反鎖”，然後再 cache fusion。
reader bypass：與 read-mostly locking 是互斥的，主要是爲讀少寫多的業務進行的優化。reader bypass 同樣引入了一種新的鎖模式 weakX lock（又稱 xw 鎖）。可以在S鎖沒有釋放以前，爲一個 block 加上一個xw鎖，對這個 block 進行修改，但是不允許立刻 commit，直到所有的的S鎖都關閉或者降級到N鎖，LMS 就會向 xw 鎖的持有者發送一條信息可以進行 commit.
該案例中，最終建議用戶關閉 DRM，關閉 DRM 可以設置如下兩個參數。
但是有一點，客戶的環境都是生產系統，而且在1號中午12點之前是出賬時間，不允許重啓數據庫，所以只能臨時的增大上述兩個參數的值，減少 DRM 被觸發的機率，變相的關閉 DRM。在屏蔽 DRM 後，目前數據庫至今允許穩定。
更改參數如下：
在11gR2 之後可以通過_lm_drm_disable 可以在線動態禁用 DRM，對於該參數的描述如下：
設置_lm_drm_disable 在不同的 level 有不同的含義。
Level4 disable read mostly
Level 5 disable DRM for all but undo
Level 7 disable DRM for all including undo.
一般情況下建議 level 設置爲5。命令如下：
Altersystem set “_lm_drm_disable”=5;
最後總結下，伴隨481錯誤的出現往往就是實例的重啓，而且我們也看到了，481錯誤出現的場景都是在 RAC 環境下，在 RAC 穩定的情況下，唯一考慮的也就是心跳問題和 DRM 問題，這兩個問題其實都還是跟各個節點的業務運行情況有關係，爲了降低心跳壓力和 DRM 重構，最好的手段還是對業務進行分離，如果不然，檢查各自的數據庫環境的參數，確保不會出現上述相關隱含參數未改的情況，在兩節點壓力過大的情況下會導致節點實例重啓。