更換硬碟後,oracle能正常啟動,但是listner不能啟動,因此應用程式和客戶端都不能連線資料庫了。經過一番查詢,問題跟蹤,終於解決。沒有重灌oracle,沒有重建listner配置。具體過程如下:
話說硬碟壞了一段時間了,因為不是業務伺服器,僅作開發測試用,所以一直沒有機會換硬碟,最近終於偷得半日閒,為伺服器更換了硬碟,重啟伺服器後,raid控制系統自動重新建立了raid。100g左右的資料,重建raid沒花太長時間。啟動系統後,可以遠端連線,各種web服務也正常。
但是,有乙個應用始終不能正常運作。調查下日誌,發現問題原因是資料庫始終不能正常連線上。
然後,檢視了下資料庫的狀態,原來資料庫雖然正常啟動了,但是listner卻沒有啟動起來。手工啟動,仍然失敗。考慮到沒有變更過資料庫的各種配置檔案,那麼問題似乎不應該是資料庫程式引起的。
既然,問題發生在啟動listner時,那麼最好是能查下listner的啟動日誌。
單看這個日誌,還是不好分析,網上查到可以啟動trace跟蹤,進行分析,於是在配置檔案
listener.ora中增加:
trace_level_listener=16
再次啟動listner,仍然失敗,但是檢視trc檔案有收穫:
trc檔案
...............
sntuscrt:illegal permission
sntuscrt: exit
snlsodx_lookup: entry
snlsodx_lookup: can't open shared object library
................
查查其他系統上,此時應該在/var/tmp/.oracle建立檔案。馬上考慮是不是許可權問題,結果
ls -l /var/tmp/.oracle 的結果是drwxrwxrwt,這樣貌似就沒有問題了吧。可是,listner仍然不能啟動。
此時,有些懷疑是不是其他配置檔案有問題了,結果重建了listener.ora,問題還是沒有解決。
再次回到檔案許可權的角度上,檢視了一下/var/tmp的上層目錄的許可權,終於找到問題了,
/var 的 ls -l 的結果是 drwxrwx---,怪不得報許可權不足呢,把它的許可權改回 drwxrwxr-x試試,
再次啟動listner,終於,久違的啟動成功日誌打出來了。
剛才不能正常運轉的應用也恢復正常了。
看來,更改系統硬體後,還真是不能掉以輕心啊。尤其是系統中的檔案許可權屬性,都要查一查哦。
參考:
伺服器掛載硬碟!
前言 linux伺服器要掛載硬碟的原因主要有以下幾點 1 linux伺服器在預設情況下,所有的東西都是裝在系統盤。系統盤的空間有限,如果站點和資料較多很容易把空間撐滿,導致環境和資料庫等等服務啟動不了。2 linux伺服器掛載磁碟可以避免因為系統損壞導致 資料丟失。3 linux伺服器掛載硬碟可以更...
hp伺服器 新增硬碟 HP伺服器增加硬碟實施方案
hp 伺服器增加硬碟實施方案 一 raid 配置 進機房操作 停止伺服器上的程序 用xsmgss 使用者登入,執行 停資料庫 oracle 使用者 home oracle sqlplus nolog sql conn as sysdba sql shutdown immediate sql exit...
從雲伺服器硬碟更換認識備份 快照 映象
前段時間因為伺服器硬碟用盡,急需更換硬碟,為了防止意外發生,必須要將伺服器快照下來,製作成映象模板,然後在新硬碟上使用映象。快照,正如字面上的意思,就是在某個時間點對系統的一次轉殖。如果你對乙個硬碟做快照了,就相當於將將這塊硬碟轉殖了乙份,好吧,你說複製也行。在運維領域,映象還有另一層意思,通俗易懂...