更換硬碟後，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...
從雲伺服器硬碟更換認識備份 快照 映象
前段時間因為伺服器硬碟用盡，急需更換硬碟，為了防止意外發生，必須要將伺服器快照下來，製作成映象模板，然後在新硬碟上使用映象。快照，正如字面上的意思，就是在某個時間點對系統的一次轉殖。如果你對乙個硬碟做快照了，就相當於將將這塊硬碟轉殖了乙份，好吧，你說複製也行。在運維領域，映象還有另一層意思，通俗易懂...