Oracle故障排查思路
Oracle故障排查思路
摘要： 一、引言 在我們日常運維項目中，資料庫的運維都位於核心的位置，原因有兩個，一是資料庫的運維涉及的範圍非常廣泛，資料庫的種類比較多，二是資料庫的安全性非常重要，所有涉及到資料庫的操作，都需要非常謹慎。 資料庫的問題，大致可分為兩大類，一是資料庫系統穩定問題，一是資料庫系統性能問題。
一、引言
在我們日常運維項目中，資料庫的運維都位於核心的位置，原因有兩個，一是資料庫的運維涉及的範圍非常廣泛，資料庫的種類比較多，二是資料庫的安全性非常重要，所有涉及到資料庫的操作，都需要非常謹慎。
資料庫的問題，大致可分為兩大類，一是資料庫系統穩定問題，一是資料庫系統性能問題。系統穩定類的問題偏向管理，系統性能類的問題偏向優化。在實際分析與處理這兩類問題時，需要採用不同的思路。
本文就Oracle資料庫系統的故障排查思路做下分析，以期解決大家在Oracle資料庫運維中遇到的問題，尋求一個基本的解決思路。
二、資料庫系統穩定性問題排查思路
1、查看資料庫報警日誌
當資料庫遇到錯誤或故障時，首先需要查看的是發生錯誤或者故障時的錯誤代碼以及資料庫的警報日誌。經驗分析，資料庫絕大部分的故障都能從故障號或者警報日誌中清晰定位到。
根據不同的資料庫版本，資料庫報警日誌的位置有所不同：
Oracle 10g及之前版本報警日誌位置：
報警日誌位置：ORACLEBASE/ADMIN/SID/BDUMP下alertSID.logOracle11g報警日誌位置： ORACLE_BASE/diag/rdbms/SID/SID/trace/alert_SID.log
2、資料庫錯誤故障號
Oracle資料庫本身提供一套完善的錯誤代碼說明體系，詳細定義了各類錯誤說明以及給出相應的修正建議。
通常，Oracle將錯誤主要分為幾大類：
資料庫軟體及資料庫本身相關（ORA-），如：ORA-12514
資料庫導入導出工具相關（EXP-/IMP-），如：EXP-00008
資料庫監聽程序、網路服務相關（TNS-），如：TNS-12560
資料庫rman備份恢復相關（RMAN-），如：RMAN-06564
Oracle針對各類錯誤號，提供了一個名為「oerr」的工具用於查閱引起相應錯誤號的原因以及針對該錯誤的一些執行建議。
oerr工具的用法： oerr ERROR TYPE
其中： [ERROR TYPE]表示的是錯誤號的類型，資料庫及產品相關的錯誤類型為「ORA」；資料庫導入導出工具相關的錯誤類型為「EXP」或「IMP」；監聽程序或網路服務相關的錯誤類型為「TNS」；RMAN相關的錯誤類型為「RMAN」。如：
oerr ORA 2396
02396, 00000, "exceeded maximum idle time, please connect again"
// *Cause: as stated
// *Action:
幾個典型案例：
A、歸檔日誌滿造成sqlplus無法登錄
在alert_SID.log中，發現以下報錯：
ORA-16014: log 1 sequence# 61 not archived, no available destinations
ORA-00312: online log 1 thread 1: /alidata/app/oracle/oradata/orcl/redolog/redo01.log
ARCH: Connecting to console port...
處理方法：
df -h檢測文件系統
刪除日期靠前的歸檔日誌
處理完畢後，撰寫歸檔自動刪除腳本，防止類似問題再次發生。
B、初始化參數中SGA設置過大，資料庫無法啟動
設置資料庫的SGA過大，重啟資料庫的時候，資料庫無法啟動。
處理方法：
create pfile from spfile，通過spfile生成pfile
修改pfile文件，把SGA設置在一個合理的範圍，然後啟動資料庫。
C、用戶密碼過期問題
在客戶端，用戶連接時，報錯：
ERROR: ORA-28002: the password will expire within 5 days
說明用戶密碼即將過期，默認創建的用戶策略，密碼需要90天修改一次。
處理方法：
更改用戶密碼，或者設置策略，密碼永不過期：
alter user smsc identified by <新密碼>
ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED。
3、操作系統日誌
有些時候，資料庫、集羣出故障了，或許在資料庫的警報日誌、集羣的各類日誌中無法直接定位到問題的原因。這時，操作系統日誌可能能提供一些關於系統、及主機硬體相關的日誌記錄協助診斷。 不同的操作系統平臺，操作系統日誌存放路徑有所不一致。
Linux:/var/log/messages、messages.N(N為1-4)；
Solaris:/var/adm/messages、messages.N(N為0-3)；
AIX：errpt |more查看；
HP-UX：/var/adm/syslog/syslog.log；
從操作系統的日誌中，可以獲取跟系統運行有關的相關日誌記錄。譬如，網卡、光纖卡出現異常中斷；磁碟空間滿等等。這對診斷資料庫、集羣故障提供了很大幫助。 詳細的系統日誌提示意義，可參閱各平臺系統管理手冊。
三、資料庫性能問題排查思路
如果遇到資料庫性能方面的問題，建議採用Oracle提供的幾個內置工具（awr、addm、ash）與系統提供的工具（top、vmstat、iostat）相結合。通過這些工具生成的報告，進一步分析出問題的根源，解決問題。下面就幾個工具的使用，結合我們之前的案例做描述。
1、AWR報告
AWR報告是Oracle提供的一種性能收集和分析工具，它能提供一個時間段內整個系統資源使用情況的報告，通過這個報告，我們就可以瞭解一個系統的整個運行情況，這就像一個人全面的體檢報告。
如何分析AWR報告：
在看awr報告的時候，我們並不需要知道所有性能指標的含義，就可以判斷出問題的所在，這些性能指標其實代表了oracle內部實現，對oracle理解的越深，在看awr報告的時候，對資料庫性能的判斷也會越準確。資料庫出現性能問題，一般都在三個地方，io，內存，cpu，這三個又是息息相關的，當io負載增大時，肯定需要更多的內存來存放，同時也需要cpu花費更多的時間來過濾這些數據，相反，cpu時間花費多的話，有可能是解析sql語句，也可能是過濾太多的數據，倒不一定是和io或內存有關係了；
當我們把一條sql送到資料庫去執行的時候，我們要知道，什麼時候用到cpu，什麼時候用到內存，什麼時候用到io：
A、cpu：解析sql語句，嘗試多個執行計劃，最後生成一個資料庫認為是比較好的執行計劃，不一定是最優的，因為關聯表太多的時候，資料庫並不會窮舉所有的執行計劃，這會消耗太多的時間，oracle怎麼就知道這條數據時你要，另一個就不是你要的呢，這是需要cpu來過濾的；
B、內存：sql語句和執行計劃都需要在內存保留一段時間，還有取到的數據，根據lru演算法也會盡量在內存中保留，在執行sql語句過程中，各種表之間的連接，排序等操作也要佔用內存；
C、io：如果需要的數據在內存中沒有，則需要到磁碟中去取，就會用到物理io了，還有表之間的連接數據太多，以及排序等操作內存放不下的時候，也需要用到臨時表空間，也就用到物理io了。
這裡有一點說明的是，雖然oracle佔用了8G的內存，但pga一般只佔8G的20%，對於專用伺服器模式，每次執行sql語句，表數據的運算等操作，都在pga中進行的，也就是說只能用1.6G左右的內存，如果多個用戶都執行 多表關聯，而且表數據又多，再加上關聯不當的話，內存就成為瓶頸了，所有優化sql很重要的一點就是，減少邏輯讀和物理讀。
AWR報告生成方法：
cd $ORACLE_HOME/rdbms/admin
@awrrpt.sql;
html 保存格式，有text和html兩種選擇
選擇保留天數；
輸入起始ID
輸入結束ID
輸入報告保留路徑及名字
2、top、vmstat、iostat等工具使用
top、vmstat、iostat等工具均是操作系統層面的工具，可以很方便的觀測到目前CPU、內存、IO等使用情況，具體使用不再贅述。
四、小結
以上我們簡述了當資料庫遇到各類問題時，該如何利用各類日誌、工具做循序漸進的診斷分析。作為資料庫管理員，務必將上述各類日誌功能及相關位置記牢。做到在遇到問題時，能沉著應對，冷靜處理。 在實際的日常運維中，資料庫問題涉及到多個方面，需要結合具體的問題進行具體的分析和處理。
推薦閱讀：
