rac環(huán)境中數據文件權限不對導致的ORA－６００和

一　故障描述

1  2014-6-16 10:45查詢(xún)數據庫集群資源狀態(tài)，正常。

2  2014-6-16 10:47查詢(xún)陜西電力數據中心節點(diǎn)1的實(shí)例狀態(tài)，select instance_name,status from v$instance； 等待2分鐘沒(méi)有結果，故判斷實(shí)例1已經(jīng)hang機。

3 2014-6-16 10:50查詢(xún)陜西電力數據中心節點(diǎn)2的實(shí)例狀態(tài)，select instance_name,status from v$instance； 立即出現結果，故認為此時(shí)實(shí)例2還是正常的。

4 2014-6-16 10:51 查詢(xún)數據庫后臺日志，發(fā)現節點(diǎn)1后臺日志報如下錯誤：

節點(diǎn) 2 后臺日志報錯信息如下：

5 對數據庫做hang分析，通過(guò)hang分析，將引起數據庫鎖的會(huì )話(huà)和操作系統進(jìn)程找出來(lái)，然后KILL掉，解決數據庫hang問(wèn)題。

     將 hang分析文件中對應的進(jìn)程KILL掉，然后再次查詢(xún)實(shí)例狀態(tài)，select instance_name,status from v$instance; 發(fā)現還是不能查詢(xún)，此操作進(jìn)行了3次，還是不能查詢(xún)實(shí)例的狀態(tài)。

6 針對此種情況，故認為問(wèn)題比較嚴重，準備關(guān)閉RAC中節點(diǎn)1實(shí)例，以釋放資源和鎖。使用shutdown immediate 關(guān)閉節點(diǎn)1的實(shí)例，在關(guān)閉中，數據庫無(wú)任何報錯，但就是無(wú)法關(guān)閉。等待25分鐘左右，使用shutdown abort命令關(guān)閉數據庫。

啟動(dòng)數據庫，由于使用 shutdown abort關(guān)閉數據庫，數據庫在啟動(dòng)時(shí)需要數據恢復，而且數據庫啟動(dòng)時(shí)未報任何錯誤，故等待數據庫啟動(dòng)：

等待 45分鐘后，發(fā)現數據庫實(shí)例1還是沒(méi)啟動(dòng)起來(lái)，故判定數據庫啟動(dòng)應該是有問(wèn)題的，查看數據庫啟動(dòng)時(shí)執行什么操作：

查看 DFS鎖的類(lèi)型，發(fā)現此鎖為CI（ 'Cross-instance function invocation instance lock', ）鎖， P2=70（ clear pin instance flag ）。由于此鎖為實(shí)例鎖，必須要將 RAC中所有節點(diǎn)的實(shí)例關(guān)閉后，才可以將此鎖解除。

關(guān)閉數據庫實(shí)例 1、2，并重新啟動(dòng)，數據庫恢復正常。

二　原因分析

1  由于在2014年6月5日添加數據文件時(shí)，未對主機節點(diǎn)２上的LV更改權限，引起節點(diǎn)2上的實(shí)例無(wú)法訪(fǎng)問(wèn) /dev/rlvdcdat30G_7 3裸設備，導致節點(diǎn)2上的實(shí)例運行在不健康的狀態(tài)。

   在節點(diǎn) 1上添加的數據文件:

   節點(diǎn) 2 上的報錯信息：

   導致節點(diǎn) 2上的實(shí)例不健康運行：

     查詢(xún)官網(wǎng)，說(shuō) ORA-600是BUG，但我不這么認為，為什么在6月10前就沒(méi)報這個(gè)錯誤，在重啟后才出現。

     后來(lái)將 LV權限更改后，重啟節點(diǎn)2實(shí)例，ORA-600報錯消失。

  發(fā)現從 6月10日起，每天數據庫實(shí)例2都重啟一次。

查詢(xún)數據文件及對應的 LV，發(fā)現LV權限有問(wèn)題。

其中 SV鎖為DFS lock handle 中的 Sequence number value

CI 鎖為 Cross-instance function invocation instance

LB鎖為 數據行頭的LB （ Lock Byte鎖標識位） 鎖標識位

LV鎖為 Library cache invalidation instance

The DFS lock Handle為
The session waits for the lock handle of a global lock request. The lock handle identifies a global lock. With this lock handle, other operations can be performed on this global lock (to identify the global lock in future operations such as conversions or release). The global lock is maintained by the DLM.

原因總結：

此系統由于LV裸設備權限問(wèn)題導致節點(diǎn)2上數據庫實(shí)例運行在不正常的狀態(tài)，導致ORA-600及MMON（   Memory Monitor   ）進(jìn)程每隔 10分鐘左右死掉重啟，并導致實(shí)例2每天宕機一次；而MMON進(jìn)程是oracle數據庫的后臺進(jìn)程，主要的作用之一就是內存管理。應用系統在使用的過(guò)程中肯定會(huì )申請全局資源，如SV、LV、CI等，當節點(diǎn)1請求節點(diǎn)2上實(shí)例鎖或SV資源時(shí)，由于節點(diǎn)2數據庫實(shí)例運行在不正常的狀態(tài)及MMON經(jīng)常死掉，導致數據庫無(wú)法及時(shí)得到相應的資源及鎖信息，隨著(zhù)時(shí)間的累計，導致整個(gè)RAC環(huán)境所有的數據庫實(shí)例全部變?yōu)镠ANG機狀態(tài)。