常見問題及處理方案
CPU使用率高的問題
通過操作系統命令top topas glance等查看top進程號，確認是系統進程還是oracle應用進程，查詢當前top進程執行的操作和sql語句進行分析。

根據進程號獲取正在執行的sql

SELECT a.osuser, a.username,b.address,b.hash_value, b.sql_text from v$session a, v$sqltext b, v$process p
where p.spid = &spid
and p.addr = a.paddr
and a.STATUS = 'ACTIVE'
and a.sql_address =b.address
order by address, piece;



數據庫無法連接
數據庫無法連接，一般可能是如下原因造成：
（1）數據庫宕了
（2）監聽異常
（3）數據庫掛起
（4）歸檔目錄滿
（5）數據庫或應用主機的網卡出現問題不能正常工作
（6）應用主機到數據庫主機的網絡出現問題。
1、數據庫宕了
立即啟動數據庫。
Startup
2、監聽異常
此時一般體現為：
監聽進程占用CPU資源大；d
監聽日志異常。
此時，立即重啟監聽，監聽重啟一般能在1分鐘之內完成。
Lsnrctl restart
3、數據庫掛起
立即重啟數據庫。
Startup
4、歸檔目錄滿
（1）在沒有部署OGG數據同步的情況下，立即清理歸檔日志文件。
（2）如果部署了OGG數據同步，查看OGG正在讀取的歸檔日志文件，立即
清理OGG不再需要的日志文件。
5、數據庫或應用主機的網卡出現問題不能正常工作。
立即聯系主機工程師處理。
6、應用主機到數據庫主機的網絡出現問題。
立即聯系網絡維護人員查看。


CRS/GI無法啟動
對于10g及11gR1版本的CRS問題
1、進入/tmp目錄下，看是否產生了crsctl.xxxxx文件
如果有的話，看文件內容，一般會提示OCR無法訪問，或者心跳IP無法
正常綁定等信息。
2、如果/tmp目錄下沒有crsctl.xxxxx文件
此時查看ocssd.log文件，看是否能從中得到有價值的信息。
可能的問題：網絡心跳不通。
3、/tmp目錄無crsctl.xxxxx且日志中沒有報錯信息，只有停CRS時的日志信
息。
此時可能是RAC兩個節點對并發裸設備的訪問有問題，此時考慮：
（1）停掉兩個節點的CRS。
（2）兩個節點先同時去激活并發VG，然后再激活VG。
（3）重新啟動CRS。
對于11gR2的GI問題
分析$GRID_HOME/log/nodename目錄下的日志文件，看是否能從中找出無法啟動的原因。
常見問題：
1、心跳IP不同。
2、ASM實例無法啟動。

對CRS的故障診斷和分析,參加本文檔中RAC部分的MOS文檔.



數據庫響應慢

應急處理步驟：
（1）找到占用CPU資源大的sql或者模塊，然后停掉此應用模塊。
（2）如果屬于由于種種原因引起的數據庫hang住情況，立即重啟數據
庫，此時重啟需要約15分鐘時間。
重要說明：
如果重啟數據庫的話，會有如下負面影響：
（1）要kill掉所有連接到數據庫中的會話，所有會話都會回滾。
（2）立即重啟的話，不能獲取并保留分析數據庫掛起原因的信息，在后續分析問題時，沒有足夠信息用于分析問題產生的根本原因。
一般正常重啟的話，都需要手動獲取用于分析數據庫重啟原因的信息，以便編寫分析報告，但是在最長情況下，獲取日志信息可能就要40分鐘時間。此時一般做systemstate dump，且如果是rac情況的話，需要2個節點都做，且需要做2次或以上。
常規處理步驟，分如下幾種情況處理：
（1）所有業務模塊都慢。
（2）部分業務模塊慢。
（3）數據庫hang住。
所有業務模塊都慢
此時首先查看系統資源，看是否屬于CPU資源使用率100%的問題，如果是，參考本章“CPU使用率高的問題”解決辦法。如果系統資源正常，那很可能是數據庫hang住了，此時參考數據庫Hang部分。
部分業務模塊慢
分析運行慢的模塊的sql語句：
（1）看是否是新上的sql。
（2）看執行計劃是否高效。
（3）優化運行慢的模塊的sql語句。
數據庫hang住
應急處理方式：重啟數據庫。
常規處理方式：
（1）分析alert日志，看是否能從alert日志中，可以很快找到引起問題的原
因。

（2）做3級別的hanganalyze，先做一次，然后隔一分鐘以后再做一次。
并分析