數(shù)據(jù)庫異常處理技術報告

1、數(shù)據(jù)庫異常處理技術報告文檔控制修改記錄日期作者版本修改記錄審閱姓名職位目錄背景概述1報告內(nèi)容2技術細節(jié)3數(shù)據(jù)庫CRASH3數(shù)據(jù)庫性能不理想導致業(yè)務停頓4數(shù)據(jù)庫掛起6關鍵業(yè)務由于持續(xù)錯誤無法完成工作7結論8附錄93 / 11文檔可自由編輯打印背景概述在日常數(shù)據(jù)庫維護過程中，經(jīng)常遇到數(shù)據(jù)庫CRASH，數(shù)據(jù)庫一些性能問題，數(shù)據(jù)庫HANG，某些關鍵業(yè)務無法正常完成。一般出現(xiàn)這些問題后，為了保障業(yè)務正常運行，經(jīng)常直接重新啟動數(shù)據(jù)庫。這樣無法保留當時的數(shù)據(jù)庫的一些狀態(tài)信息，在后期進行問題分析的時候有很大的難度。經(jīng)常是一個問題不了了之。報告內(nèi)容在該報告中，會針對數(shù)據(jù)庫的各種不同異常情況，在出現(xiàn)這種情況下，應

2、該做那些相關的信息收集。通過收集的信息判斷數(shù)據(jù)庫在不同異常情況下暴露的問題，提供相關的技術手段避免問題的再次發(fā)生。該報告分析數(shù)據(jù)庫在下列四種情況下發(fā)生異常時要做的分析操作：1. 數(shù)據(jù)庫CRASH2. 數(shù)據(jù)庫性能不理想導致業(yè)務停頓3. 數(shù)據(jù)庫掛起4. 關鍵業(yè)務由于持續(xù)錯誤無法完成工作技術細節(jié)數(shù)據(jù)庫CRASH當數(shù)據(jù)庫CRASH后，整個數(shù)據(jù)庫服務已經(jīng)完全停止。這個時候請查看數(shù)據(jù)庫警告日志，檢查是否有對應的TRACE文件生成。收集數(shù)據(jù)庫TRACE文件，RDA報告。如果客戶購買有ORACLE的標準服務，針對該問題創(chuàng)建一級TAR。具體處理流程如下數(shù)據(jù)庫CRASH啟動DB收集TRACE文件，RDA報告創(chuàng)建一

3、級TAR分析CRASH的具體原因，編寫報告現(xiàn)場分析不能啟動的原因，同時創(chuàng)建一級TAR正常啟動不能啟動數(shù)據(jù)庫CRASH相對來說是一個綜合問題，導致數(shù)據(jù)庫異常CRASH有很多鐘情況。一般如果由于是硬件原因?qū)е拢敲磾?shù)據(jù)庫很難在短時間內(nèi)啟動。那么要確認數(shù)據(jù)庫有沒有很完善的備份策略。如果是數(shù)據(jù)庫軟件配置問題，可以調(diào)整部分參數(shù)，在短時間內(nèi)將數(shù)據(jù)庫啟動。數(shù)據(jù)庫性能不理想導致業(yè)務停頓在某些特殊情況下，數(shù)據(jù)庫性能急劇下降，部分應用大量消耗系統(tǒng)資源。嚴重時導致整個系統(tǒng)運行緩慢。在這種情況下，對數(shù)據(jù)庫做相關的下列操作。1如果是CPU/Memory緊張，用glance/topas檢查top process 消耗時間

4、1分鐘如果alert_sid.log文件有出錯信息，找出問題關鍵的session id/ OS process id 消耗時間1分鐘如沒有OS/DB出錯信息，使用腳本檢查兩階段事務和lock handle事務。然后使用event 10046/10053采集sql plan 消耗時間5分鐘使用statspack來收集數(shù)據(jù)庫性能報告， 如果系統(tǒng)性能極低，。Snap間隔5分鐘。然后做hanganalyze dump,間隔90秒。消耗時間10分鐘2(3a)如果top process不是數(shù)據(jù)庫服務器進程，立即kill -9 ospid (如果是oracle應用進程則在執(zhí)行kill -9前先做收集proc

5、essstate dump信息)消耗時間2分鐘(3b)如session id沒有指向數(shù)據(jù)庫服務器進程，收集processstate dump信息然后立即用kill session命令關閉這個數(shù)據(jù)會話 消耗時間2分鐘(3c)刪除pending兩階段事務和lock handle事務。收集processstate dump信息然后用kill session命令關閉這個數(shù)據(jù)會話 消耗時間2分鐘3觀察業(yè)務情況，如沒有解決則重復step2,34如果問題長時間未能排除，建議重新啟動數(shù)據(jù)庫5收集trace文件6生成RDA報告和STATSPACK報告7使用OSW收集CPU/Memory信息，oracle ale

6、rt文件 2分鐘1. 收集事物狀態(tài)收集兩階段事務SELECT local_tran_id FROM dba_2pc_pending;Execute dbms_transaction.purge_lost_db_entry('<LOCAL_TRAN_ID>'); Commit;收集某個進程的信息10046主要是對應在數(shù)據(jù)庫使用基于規(guī)則模式下的統(tǒng)計信息，10053主要對應數(shù)據(jù)庫使用基于成本優(yōu)化模式下的統(tǒng)計信息。Event 10046:Sql> oradebug setospid pidSql> oradebug unlimitSql> oradebug

7、 event 10046 trace name context forever,level 12sql> oradebug event 10046 trace name context offEvent 10053:Sql> oradebug setospid pidSql> oradebug unlimitSql> oradebug event 10053 trace name context forever,level 12sql> oradebug event 10053 trace name context off2. 收集PROCESS DUMPSql&

8、gt; oradebug setospid ospidSql> oradebug unlimitSql> oradebug dump processstate 33. 收集RDA報告$./rda.sh -v4. 收集STATSPACK報告?/rdbms/admin/spreport數(shù)據(jù)庫掛起在日常工作中，可能由于多種原因?qū)е聰?shù)據(jù)庫掛起，整個系統(tǒng)無法進行工作。所有事務都處于等待狀態(tài)。在這種情況下，請按照下列步驟對數(shù)據(jù)庫進行信息收集。1) 做hanganalyze dumpSql> oradebug setmypid;Sql> oradebug unlimit;Sql>

9、; oradebug dump hanganalyze 3;Sql> !sleep 300Sql> oradebug dump hanganalyze 3;2) 做system dumpSql> oradebug setmypid;Sql> oradebug unlimit;Sql> oradebug dump systemstate 10Sql> !sleep 900Sql> oradebug dump systemstate 10Sql> !sleep 900 -每次中間停頓900秒Sql> oradebug dump systemstate 103) 重新啟動數(shù)據(jù)庫4) 收集trace文件和rda報告關鍵業(yè)務由于持續(xù)錯誤無法完成工作在日常工作中，某個關鍵業(yè)務無法正常運行，而且運行異常周期不定，建議使用下列方法診斷錯誤。1) 使用PROCESS DUMP獲得信息SQL> ORADEBUG SETOSPID pid （注1）SQL> ORADEBUG UNLIMITSQL> ORADEBUG DUMP PROCESSSTATE 102) 使用EVENT參數(shù)獲得信息如出錯代碼是ORA- 0xxxxx則在initsid.ora文件中加入Event = “ 0xxxx trace name c