利用ipcrm清除資料庫crash後沒有釋放的記憶體段

某測試庫，開發報告無法連線使用，登陸進該server，首先輸入ps –ef | grep ORACLE_SID發現該instance沒有啟動，

檢視alertlog，日誌顯示11月28號0:00db有過一次日誌切換，10分鐘後開始出現7445錯誤，過一會dbw0程式dead，然後PMON程式terminated，此時資料庫crash；

緊接著是啟動資料庫，版本為10.2.0.4，在open階段報告錯誤

ORA-00704: bootstrap process failure
ORA-39700: database must be opened with UPGRADE option

如此反覆了幾次資料庫始終沒有正常啟動

僅從以上錯誤很容易讓人聯想到是資料庫升級沒有成功，需要升級一下資料字典即可；但是alertlog並沒有資料庫曾經升級過的記錄，而且此套資料庫有好幾個公司維護，也很難求證此前資料庫有過什麼重大變更。

正在糾結於要不要根據提示升級資料字典時，一條重要線索出現，該資料庫原本是10.2.0.5的，自從crash後才有人試圖以10.2.0.4的版本將其啟動，怪不得會有上述錯誤。

重新設定LD_LIBRARY_PATH/ORACLE_HOME為10.2.0.5，以sysdba登陸，應該顯示connected to a idle instance才對，可此次只提示session connected；

輸入startup，報告ORA-03113: end-of-file on communication channel；

輸入shutdown immediate，報告ORA-01033: ORACLE initialization or shutdown in progress

再次執行ps –ef | grep ORACLE_SID，後臺程式並沒有啟動，執行ipcs –m | grep oracle返回10條記錄，而ps –ef | grep pmon | -V “grep”返回9條，原因終於找到了。

資料庫crash的時候，對應的共享記憶體段並沒有被OS及時釋放，才導致既無法啟動又無法關閉的怪現象。

解決辦法：ipcs –m | grep oracle找到對應的nattach為0的記錄，然後執行ipcrm –m id即可釋放對應的共享記憶體段；此時再次登陸，敲入startup即可正常啟動資料庫，版本10.2.0.5