歸檔日志增長(zhǎng)過(guò)快處理解決

1、處理歸檔日志增加過(guò)快一例(2010-08-25 20:03:47) 轉(zhuǎn)載標(biāo)簽： oracle歸檔日志增加過(guò)快分類： 原創(chuàng)文章 處理歸檔日志增加過(guò)快一例摘要       本文介紹了不久前作者是如何徹底解決一家醫(yī)院數(shù)據(jù)庫(kù)由于歸檔日志增長(zhǎng)過(guò)快,導(dǎo)致磁盤剩余空間占滿，引起宕機(jī)全過(guò)程。通過(guò)本案例的描述,我們可以了解到當(dāng)遇到數(shù)據(jù)庫(kù)宕機(jī)問(wèn)題時(shí)，應(yīng)該如何分析現(xiàn)象、找到問(wèn)題關(guān)鍵、最終徹底解決該問(wèn)題的一個(gè)總體思路，最后還應(yīng)該深入思考該問(wèn)題產(chǎn)生的原因，總結(jié)出避免以后再出現(xiàn)該問(wèn)題的建議。關(guān)鍵字: ORACLE、歸檔日志、宕機(jī)、DML語(yǔ)句初步了解 &

2、#160;     早上一來(lái)到公司，XZH就告訴我接到CQ公司的有一個(gè)技術(shù)申請(qǐng)，大致情況為一家三甲醫(yī)院，采用Rac+Linux環(huán)境，啟用了歸檔模式，但是由于日志增長(zhǎng)過(guò)快，我們的技術(shù)人員設(shè)雖然置自動(dòng)刪除歸檔的任務(wù)，但是還是沒有避免磁盤空間被占滿，已經(jīng)引起醫(yī)院2次全院無(wú)法使用，雖然CQ公司也安排多名技術(shù)人員去現(xiàn)場(chǎng)處理，但是醫(yī)院認(rèn)為一直沒有解決徹底，因此信息主管對(duì)此意見較大，希望公司安排技術(shù)支持部現(xiàn)場(chǎng)徹底解決該問(wèn)題。       通過(guò)申請(qǐng)描述，我大致了解到以下幾個(gè)關(guān)鍵點(diǎn)：  

3、60;    1.醫(yī)院?jiǎn)⒂昧藲w檔，也做了定期自動(dòng)刪除歸檔日志的任務(wù)。       2.由于歸檔日志增加過(guò)快，已經(jīng)導(dǎo)致醫(yī)院2號(hào)節(jié)點(diǎn)宕機(jī)。       3.我們的技術(shù)人員去了幾次，都未徹底解決，用戶已經(jīng)意見很大了。       這只是個(gè)初步情況，往往只能了解問(wèn)題的大概，具體的問(wèn)題產(chǎn)生的原因還是得到用戶那里去才能真正了解，于是立即出發(fā)，前往用戶處處理問(wèn)題?，F(xiàn)場(chǎng)分析問(wèn)題  &

4、#160;    到達(dá)醫(yī)院，同系統(tǒng)管理員互相寒暄了幾句，了解大體情況是醫(yī)院昨天凌晨部分科室反映不能登錄導(dǎo)航臺(tái)，于是系統(tǒng)管理員深夜被叫到醫(yī)院，查看服務(wù)器發(fā)現(xiàn)數(shù)據(jù)庫(kù)已經(jīng)宕機(jī)，檢查磁盤空間，發(fā)現(xiàn)其中一個(gè)節(jié)點(diǎn)的剩余空間為0，于是立即刪除部分過(guò)去的歸檔日志，重新啟動(dòng)服務(wù)器，下面科室才能夠正常登錄，談話間不斷聽見系統(tǒng)管理員抱怨深夜到醫(yī)院是如何如何不情愿，看來(lái)意見是比較大。而且同樣的問(wèn)題不久前才出現(xiàn)過(guò)一次，當(dāng)時(shí)是中午，詢問(wèn)同去的同事，了解到確實(shí)不久前也出現(xiàn)過(guò)一次同樣的情況，當(dāng)時(shí)認(rèn)為是歸檔日志的定期刪除保留的日志時(shí)間太長(zhǎng)，當(dāng)時(shí)保留的是30天的日志，后來(lái)改為保留5天的日志，心想不會(huì)

5、再出現(xiàn)該問(wèn)題，沒想到還是無(wú)法避免。       接下來(lái)，該我們自己著手分析問(wèn)題了，因?yàn)楫吘褂脩裘枋龅闹皇撬闹饔^判斷，而且真正要想了解到時(shí)發(fā)生的真實(shí)情況，看是應(yīng)該看下Oracle的日志才能確認(rèn)，這也是我們處理問(wèn)題必須遵守的原則，首先看下該節(jié)點(diǎn)的alter.ora在出現(xiàn)問(wèn)題時(shí)的錯(cuò)誤記錄，部分記錄情況如下：Fri Jul 18 22:10:18 2010Errors in file /u01/app/oracle/admin/orcl/bdump/orcl2_arc1_13762.trc:ORA-19502: Message 19502

6、not found; No message file for product=RDBMS, facility=ORA; arguments: /u01/app/oracle/archive/2_24046_698868487.dbf 22529 512ORA-27072: Message 27072 not found; No message file for product=RDBMS, facility=ORALinux-x86_64 Error: 9: Bad file descriptorAdditional information: 4Additional information:

7、22529Additional information: 507392ORA-19502: Message 19502 not found; No message file for product=RDBMS, facility=ORA; arguments: /u01/app/oracle/archive/2_24046_698868487.dbf 22529 512Fri Jul 18 22:10:18 2010ARCH: Archival stopped, error occurred. Will continue retryingFri Jul 18 22:10:18 2010ORAC

8、LE Instance orcl2 - Archival Error       從日志記錄的時(shí)間可以看出，真正出問(wèn)題應(yīng)該是在22點(diǎn)多鐘，只是系統(tǒng)管理員凌晨才得到問(wèn)題反饋，可以看出自己查看日志是多么的重要，不過(guò)從來(lái)錯(cuò)誤的記錄看，確實(shí)是由于無(wú)法歸檔，導(dǎo)致該節(jié)點(diǎn)出現(xiàn)問(wèn)題，這個(gè)判斷到是準(zhǔn)確的。首先檢查了下日志的增長(zhǎng)速度，發(fā)現(xiàn)每個(gè)節(jié)點(diǎn)平均每13分鐘就產(chǎn)生一個(gè)50M的歸檔日志，一天的歸檔日志就接近30G，而醫(yī)院的日志放在本地磁盤，磁盤剩余空間也就100多G，按照這種日志的增長(zhǎng)速度，空間被日志撐爆也就理所當(dāng)然了。但是以該院的規(guī)模和業(yè)務(wù)量來(lái)看，產(chǎn)生

9、這么多的日志肯定是不正常的，所以找到日志增長(zhǎng)過(guò)快的原因，是解決問(wèn)題的根本。       首先觀察下歸檔日志產(chǎn)生的頻率，我們?nèi)‘?dāng)天24小時(shí)產(chǎn)生日志的頻率數(shù)，如下圖：               發(fā)現(xiàn)除了在上午業(yè)務(wù)高峰期（89點(diǎn)），其他時(shí)間段沒有明顯的曲線變化，而且凌晨時(shí)分（07點(diǎn)）的日志也切換頻繁，這就肯定有問(wèn)題，于是我生成今天2點(diǎn)3點(diǎn)的AWR報(bào)告進(jìn)行分析，分析情況如下：  &#

10、160;     首先看該時(shí)間段的會(huì)話不多，只有60多個(gè)會(huì)話，除去系統(tǒng)自帶的幾個(gè)會(huì)話，真正應(yīng)用ZLHIS的會(huì)話肯定不多，證明當(dāng)時(shí)醫(yī)院的業(yè)務(wù)肯定不繁忙。        但是每秒鐘的處理事務(wù)卻有23.82,比很多三甲醫(yī)院業(yè)務(wù)高峰期的事務(wù)都要大，肯定有問(wèn)題，進(jìn)一步分析執(zhí)行sql：        發(fā)現(xiàn)即使在凌晨時(shí)分，居然也會(huì)如此頻繁的執(zhí)行大量的sql語(yǔ)句，其中涉及到update等DML語(yǔ)句，勢(shì)必會(huì)產(chǎn)生大量歸檔日志，從表名看，

11、應(yīng)該是與體檢系統(tǒng)有直接關(guān)系，通過(guò)分析，發(fā)現(xiàn)是zl_體檢任務(wù)結(jié)果_Transation過(guò)程中的語(yǔ)句。該過(guò)程是實(shí)現(xiàn)把體檢病人的檢驗(yàn)結(jié)果更新到體檢系統(tǒng)里面，我們程序有2種方式進(jìn)行更新：       1.后臺(tái)每天晚上定時(shí)對(duì)全院未完成體檢的病人集中更新一次，通過(guò)調(diào)用zl_體檢任務(wù)結(jié)果_TransationAll實(shí)現(xiàn)，其中zl_體檢任務(wù)結(jié)果_TransationAll過(guò)程里面，又循環(huán)調(diào)用了zl_體檢任務(wù)結(jié)果_Transation過(guò)程。       2.是由操作人員在程序上操作，單獨(dú)更新某

12、一指定病人，只調(diào)用zl_體檢任務(wù)結(jié)果_Transation過(guò)程。       后一種情況肯定不會(huì)頻繁執(zhí)行該過(guò)程，目標(biāo)鎖定在第一種，后臺(tái)作業(yè)方式，于是查看系統(tǒng)后臺(tái)作業(yè)，發(fā)現(xiàn)問(wèn)題作業(yè)，如下：        該后臺(tái)作業(yè)中該過(guò)程的執(zhí)行頻率被調(diào)整3分鐘，通過(guò)對(duì)zl_體檢任務(wù)結(jié)果_TransationAll過(guò)程分析我們知道，只要體檢病人沒有完成體檢，都會(huì)對(duì)其檢驗(yàn)結(jié)果進(jìn)行更新，而該醫(yī)院當(dāng)時(shí)正好進(jìn)行大量體檢，有上千病人沒有完成體檢，每次執(zhí)行該過(guò)程，都會(huì)對(duì)這些病人進(jìn)行更新，可想而知肯

13、定會(huì)產(chǎn)生大量日志，所以如此頻繁的執(zhí)行該過(guò)程，肯定是不現(xiàn)實(shí)的，定位了問(wèn)題，接下來(lái)就該處理該問(wèn)題?，F(xiàn)場(chǎng)處理問(wèn)題       詢問(wèn)相關(guān)人員，了解到由于該院體檢科想實(shí)時(shí)得到體檢病人的檢驗(yàn)結(jié)果，所以我們的同事按醫(yī)院的要求對(duì)作業(yè)執(zhí)行頻率進(jìn)行了調(diào)整所致，說(shuō)明了問(wèn)題的嚴(yán)重性，經(jīng)過(guò)和醫(yī)院協(xié)商，闡述利弊，得到醫(yī)院的同意，按醫(yī)院要求最后把該后臺(tái)作業(yè)修改為每天執(zhí)行2次，中午一次，晚上一次。處理方法如下：1. 1.        刪除原來(lái)的job由于知道job號(hào)為107，所以調(diào)用dbms_j

14、ob包刪除              exec dbms_job.remove(107);2. 2.        創(chuàng)建2個(gè)的job,一個(gè)是中午13點(diǎn)執(zhí)行，一個(gè)晚上執(zhí)行1點(diǎn)-1點(diǎn)的jobvariable job number;begin  sys.dbms_job.submit(job => :job,      

15、;                what => 'zl_體檢任務(wù)結(jié)果_TransationAll;',                      next_date => to_date('20-07-

16、2010 01:00:00', 'dd-mm-yyyy hh24:mi:ss'),                      interval => 'trunc(Sysdate)+1+01/24+00/(24*60)+00/(24*60*60)');  commit;end;/-13點(diǎn)的jobvariable job&#

17、160;number;begin  sys.dbms_job.submit(job => :job,                      what => 'zl_體檢任務(wù)結(jié)果_TransationAll;',           

18、60;          next_date => to_date('20-07-2010 13:00:00', 'dd-mm-yyyy hh24:mi:ss'),                      interval => 'trunc(S

19、ysdate)+1+13/24+00/(24*60)+00/(24*60*60)');  commit;end;/3. 3.        后續(xù)處理       通過(guò)上面的修改，馬上可以觀察到2個(gè)節(jié)點(diǎn)的日志產(chǎn)生速度明顯下降了，觀察了1個(gè)小時(shí)，才產(chǎn)生了1個(gè)歸檔日志，由于是在下午時(shí)分，本身醫(yī)院業(yè)務(wù)不是太忙，這種歸檔日志的產(chǎn)生速度應(yīng)該是正常的。       然后，再對(duì)每個(gè)節(jié)點(diǎn)的備份和歸檔日志的刪除策略進(jìn)行下檢查，1，2號(hào)機(jī)都改為每天晚上12點(diǎn)定時(shí)刪除30天前的歸檔日志，standby的機(jī)器由于空間比較大，調(diào)整為每天12點(diǎn)定時(shí)刪除60天前的歸檔日志，最后要求醫(yī)院近期觀察下日志的生成速度，經(jīng)過(guò)醫(yī)院的確認(rèn)，得到醫(yī)院的認(rèn)可。（另：第二天，要求醫(yī)院提供日志切換的次數(shù)統(tǒng)計(jì)，如下圖，可以看到確實(shí)歸檔日志切換已經(jīng)恢復(fù)正常，看到問(wèn)題得到解決，醫(yī)院的管理員也相當(dāng)高興。） 后續(xù)總結(jié)