對系統故障處理的思考

    年初去某公司面試時，對方的項目經理問如果數據庫現在很慢，你該怎麼辦，我問慢的現象是什麼，數據庫是被調用的不會莫名其妙就慢了，對方說什麼都沒有，就是慢了，你該怎麼辦？我說既然是這樣，那就按老辦法處理了：
1. 登陸機器用topas 、svmon -G、sar 1 100、ps aux 等，查看cpu、內存、交換區、磁盤的繁忙程度，看下是否有佔系統資源特別大的進程。
2. 查 v$session_event、v$session_wait 看是否有大量的 latch free、enqueue、 free buffer waits等等待事件，看下歸檔日誌的文件系統是否滿了。
3. 如有佔系統資源特別大的進程，通過v$process和v$session兩個視圖找到 Oracle進程的sid,serial#,把它用 Alter  system kill session ‘sid,serial#’;殺掉；如果是歸檔日誌滿了，就清理日誌。
4. 通過上面操作，表面現象基本會消除，下來再慢慢分析是什麼原因引起的慢，是應用服務引起的、還是業務邏輯引起的、還是sql的性能引起的，找不到本質它還會慢的。
    寫上面那段話，想要說明什麼目的呢？其實很簡單，就是想說明，任何故障都是有原因的，都是有表面現象的，說沒有任何現象那是扯蛋，而且這一類的信息系統也就那麼幾類故障，絕對不會發生像動車追尾的事故，所以在發生故障時，觀察現象是很重要的，對於一個有經驗的人來說，從現象上就能基本判定是哪裏的問題，
所以我們一定要提醒和引導報障人，報告故障時：
1. 要詳細的說出故障的現象，說不清時就截圖，圖片更加一目瞭然。
2. 故障的時間點，通過時間點可以找到相關日誌，還能瞭解到相關的人員在此時間做了什麼操作，必定能操作系統的也就那幾個人。
3. 故障的影響範圍，是幾個人用不了，還是很多人或者全用不了。如果影響了幾個人，那肯定不是服務的問題，就不用去查服務了，直接去檢查終端（有時也不能全憑經驗，也要謹慎點）；如果是影響範圍很大，那就直接查看監控服務（如F5，每臺服務的運行狀態一目瞭然）。
4. 通過上面的幾步已經基本確定故障了，下來儘快恢復系統正常運行，然後再慢慢分析故障原因。
5. 通過查找上面時間點的系統故障日誌，基本會看到相關的錯誤信息的，如調用了那個數據庫對象、返回了什麼oracle的錯誤、寫了什麼java異常信息；如果沒找到或者幾百M的日誌不好找，那隻能模擬測試看故障能否再重現，一般有詳細的操作步驟，故障大多能重現的。
6. 如果是Java 問題就去分析相關的jap、java文件、配置文件（或web服務的配置文件）等。
7. 如果日誌記錄了數據庫對象的信息，那更簡單，直接去test下相應的數據庫對象，不是邏輯問題就是sql性能問題。
8. 修改找到的問題，形成案例集，避免類似故障下次再次發生。
   上面提到的只是日常故障的基本處理思路，不說處理方法，很多時候思路比方法更加重要，好多時候不是我們不會處理，而是我們沒有處理的思路，不知道下一步該朝那走，這樣就麻煩了。
   根據多年系統的故障來看，60%都是人爲造成的，40%纔是系統自身產生的故障，在系統產生的故障中大部分都是業務邏輯、sql性能引起的，還有一小部分是網絡、硬件引起的。sql性能方面的主要有以下：
1. 沒有使用正確的索引，如語句中寫的是組合索引、函數索引，但表上沒有建立相應的索引，或着是沒把組合索引字段放在最前面。
2. 分區表沒建立本地索引，或者是建了本地索引但沒有用到分區字段。
3. 多表連接時基表沒有選好，或者是where條件沒有明確指定各表的連接條件，或者是過濾最大數據的條件沒有放在後面。
4. 使用了不必要的類型轉換，特別是字符型與數值型的比較，這點很容易疏忽。
5. 對列進行了不必要的操作，包括數據庫函數、計算表達式等。
   例：
   select * from record where  substrb(CardNo,1,4)='0757'  
   select * from record where  amount/30< 1000  
   select * from record where  to_char(begintime,'yyyymmdd')='20101201'
6. 使用了 in 、not in 、exists、 not exists 等，應使用外連接outer joins 。
7. 使用了不必要的索引，應該用 +0 或 || '' 使索引失效。
8. 使用了複雜的group by分組計算條件。
9. 大數據量時，增加查詢的範圍限制，避免全範圍的搜索。
10. 條件中用到or 、null、not null、<>、like 等操作符。
11. 中間表、臨時表數據不及時truncate，歷史表數據沒有及時清理，索引沒有定期重建等都會引起sql性能的低下。
    上面寫的只是日常故障的基本處理思路和影響sql性能的一些可能點，隨着系統運行的時間加長，還會有其它的問題出現，還會挖掘更多的隱患，只有那樣才能觸進系統更加健康良好的運行。