對系統故障處理的思考

    年初去某公司面試時，對方的項目經理問若是數據庫如今很慢，你該怎麼辦，我問慢的現象是什麼，數據庫是被調用的不會莫名其妙就慢了，對方說什麼都沒有，就是慢了，你該怎麼辦？我說既然是這樣，那就按老辦法處理了：
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性能的一些可能點，隨着系統運行的時間加長，還會有其它的問題出現，還會挖掘更多的隱患，只有那樣才能觸進系統更加健康良好的運行。