我們經(jīng)常接到客戶的電話，我的數(shù)據(jù)庫日志滿了，有沒有什么好辦法快速清除?尤其對(duì)于一些初入門的DB2使用者去維護(hù)一個(gè)大數(shù)據(jù)量的系統(tǒng)，這幾乎是他們必然會(huì)碰到的一個(gè)問題。
我們也經(jīng)常接到客戶更緊急的電話，我的數(shù)據(jù)庫不能使用了，因?yàn)槿罩菊加锰嗫臻g，文件系統(tǒng)滿了，就把日志刪除了，現(xiàn)在數(shù)據(jù)庫無法使用，這個(gè)是生產(chǎn)系統(tǒng)，需要盡快恢復(fù)，有什么辦法可以讓數(shù)據(jù)庫立刻使用?
碰到這樣的問題，我們可以不厭其煩的一遍遍向客戶解釋這個(gè)問題的原因，也可以給出非常明確的解決方案，但是對(duì)于很多客戶看來，這似乎是一個(gè)比較無奈的解決方案，他們只能承擔(dān)著這種操作帶來的系統(tǒng)中斷。
因此，對(duì)于數(shù)據(jù)庫的設(shè)計(jì)人員，開發(fā)人員和維護(hù)人員來講，非常清楚的了解數(shù)據(jù)庫的日志原理與合理的規(guī)劃一些操作以避免發(fā)生這樣的情況是非常重要的!下面，我們就對(duì)數(shù)據(jù)庫的日志原理和使用中經(jīng)常遇到的問題以及其解決方法跟大家分享下。
1、DB2數(shù)據(jù)庫的日志原理
事務(wù)日志記錄數(shù)據(jù)庫中所有對(duì)象和數(shù)據(jù)的改變，在早前版本中最大可達(dá)256G，其大小為( logprimary + logsecond ) * logfilsiz，其中l(wèi)ogprimary + logsecond的值小于或等于256，logfilsiz的最大為262144，在9.5版本中，日志最大已經(jīng)可以達(dá)到512G，其中l(wèi)ogfilsz的大小更改為524286。
DB2數(shù)據(jù)庫的日志分為主日志和輔助日志，其中主日志在第一個(gè)連接到達(dá)數(shù)據(jù)庫或者數(shù)據(jù)庫被激活后立即分配，而輔助日志在主日志大小不夠的時(shí)候動(dòng)態(tài)分配。所以需要注意一點(diǎn)，日志所在的文件系統(tǒng)的大小必須大于主日志文件與輔助日志文件的大小之和。
DB2數(shù)據(jù)庫有2種日志配置方式，循環(huán)日志與歸檔日志。
循環(huán)日志：這是數(shù)據(jù)庫默認(rèn)的日志使用方式，主日志用來記錄所有的更改，當(dāng)事務(wù)提交后，日志文件會(huì)被重用。當(dāng)主日志文件達(dá)到限制時(shí)，輔助日志文件將被使用。這種日志方式可以進(jìn)行崩潰恢復(fù)和版本恢復(fù)，不能進(jìn)行前滾恢復(fù)，不支持在線備份。
當(dāng)活動(dòng)事務(wù)的使用空間超過主日志和輔助日志的限制或者日志空間超過磁盤可使用空間，將會(huì)得到日志滿的錯(cuò)誤。
點(diǎn)擊查看大圖
歸檔日志：啟用logarchmetd1、logarchmetd2或打開logretain參數(shù)，注意，在9.5版本中，不推薦使用logretain參數(shù)，其所有的設(shè)置值將被忽略。在數(shù)據(jù)庫歸檔日志規(guī)劃時(shí)，建議不再使用logretain的方法。日志文件將不會(huì)被刪除-保持在線或者離線狀態(tài)。支持前滾恢復(fù)和在線備份。
點(diǎn)擊查看大圖
疑問：歸檔日志下，日志一直保留，持續(xù)生成新日志，為什么還會(huì)出現(xiàn)日志滿的錯(cuò)誤?
歸檔日志下，其可用的活動(dòng)日志大小依然受到主日志與輔助日志大小之和的限制，所以，即使在歸檔日志下，日志滿的場景與活動(dòng)日志下是完全一樣的。
[!--empirenews.page--]
2、日志使用中的問題與解決方法
在日常使用中，我們遇到最多的問題就是日志滿，現(xiàn)在用幾個(gè)實(shí)際的例子來看如何分析和解決日志滿的問題，一般的，日志滿可以分以下幾個(gè)場景：
A、 環(huán)境準(zhǔn)備，并介紹數(shù)據(jù)庫日志使用大小評(píng)估方法：
數(shù)據(jù)庫參數(shù)設(shè)置如下：
日志文件大小(4KB) (LOGFILSIZ) = 10000
主日志文件的數(shù)目 (LOGPRIMARY) = 3
輔助日志文件的數(shù)目 (LOGSECOND) = 2
日志總大小為200M.
創(chuàng)建測(cè)試用表：
Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/
-->C:/Documents and Settings/administrator>db2 "create table test_log(col int, col2 char(10)
,col3 timestamp,col4 varchar(100),col5 varchar(100),col6 varchar(100),col7 varch
ar(100),col8 varchar(100))"
DB20000I SQL命令成功完成。
創(chuàng)建插入數(shù)據(jù)的存儲(chǔ)過程：
Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/
-->C:/Documents and Settings/administrator>db2 -td@ -vf proc_testlog.sql
create procedure proc_testlog(v1 int)
begin
declare time int default 0;
while (time < v1)
do
insert into test_log values(1,'testlog',current timestamp,'testlogtestlogte
stlogtestlogtestlogtestlogtestlogtestlogtestlogtestlogtestlogtestlogtestlogtestl
og','testlogtestlogtestlogtestlogtestlogtestlogtestlogtestlogtestlogtestlogtestl
ogtestlogtestlogtestlog','testlogtestlogtestlogtestlogtestlogtestlogtestlogtestl
ogtestlogtestlogtestlogtestlogtestlogtestlog','testlogtestlogtestlogtestlogtestl
ogtestlogtestlogtestlogtestlogtestlogtestlogtestlogtestlogtestlog','testlogtestl
ogtestlogtestlogtestlogtestlogtestlogtestlogtestlogtestlogtestlogtestlogtestlogt
estlog');
set time = time + 1;
end while;
end
DB20000I SQL命令成功完成。
我們來評(píng)估下插入使用日志的情況，以便構(gòu)造日志滿的場景，使用db2pd來查看事務(wù)日志的使用。
分別打開2個(gè)db2cmd會(huì)話窗口，在窗口1中我們執(zhí)行：
C:/Documents and Settings/administrator>db2 +c call proc_testlog(1)
返回狀態(tài) = 0
會(huì)話2中執(zhí)行:
Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/
--> C:/Documents and Settings/administrator>db2pd -db sample -transactions
Database Partition 0 -- Database SAMPLE -- Active -- Up 0 days 00:29:20
Transactions:
Address AppHandl [nod-index] TranHdl Locks State Tflag Tflag2
Firstlsn Lastlsn LogSpace SpaceReserved TID
AxRegCnt GXID
0x7FC21A80 7 [000-00007] 2 7 WRITE 0x00000000 0x00000
000 0x000027718800 0x000027718800 110 700 0x000000004F13
1 0
可以看到這個(gè)寫操作占用的日志大約為700個(gè)字節(jié)，在回話1中再重復(fù)執(zhí)行上面的命令，會(huì)話2中在看db2pd的輸出：
Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/
-->C:/Documents and Settings/administrator>db2pd -db sample -transactions
Database Partition 0 -- Database SAMPLE -- Active -- Up 0 days 00:45:55
Transactions:
Address AppHandl [nod-index] TranHdl Locks State Tflag Tflag2
Firstlsn Lastlsn LogSpace SpaceReserved TID
AxRegCnt GXID
0x7FC21A80 7 [000-00007] 2 8 WRITE 0x00000000 0x00000
000 0x000028E385B8 0x000028E38806 154 1334 0x000000004F57
1 0
1334-700=634，我們可以這樣評(píng)估，單個(gè)事務(wù)每執(zhí)行一次表插入，插入一行占用的日志約為700字節(jié)，在一個(gè)事務(wù)中，插入多條記錄，插入一行記錄占用的日志約為634字節(jié)，當(dāng)然，實(shí)際上當(dāng)插入多行時(shí)，日志的大小會(huì)比計(jì)算值略大。
使用這個(gè)方法可以根據(jù)業(yè)務(wù)運(yùn)行情況來評(píng)估需要數(shù)據(jù)庫應(yīng)該配置的日志大小，也可以評(píng)估單個(gè)大事務(wù)需要的日志空間。
根據(jù)估算，200M總?cè)罩敬笮。?00*1024*1024/635=330781。因此可以一次插入大約33W記錄來構(gòu)造日志滿的場景。
[!--empirenews.page--]
B、 事務(wù)日志滿場景一：當(dāng)前未提交的事務(wù)太大，超過日志的限制。
在會(huì)話1中執(zhí)行：
C:/Documents and Settings/administrator>db2 commit
DB20000I SQL命令成功完成。
提交前面未提交的事務(wù)。
C:/Documents and Settings/administrator>db2 +c call proc_testlog(330000)
SQL0964C 數(shù)據(jù)庫的事務(wù)日志已滿。 SQLSTATE=57011
這時(shí)候我打開另外一個(gè)session，執(zhí)行一個(gè)不相關(guān)的插入操作。
C:/Documents and Settings/administrator>db2 "insert into test values(1112,1,’sdfsdfsdfsdf’,’sdfsdfsdfsdfsdf’,’sdfsdfsdffsdfsd’)
DB21034E 該命令被當(dāng)作 SQL 語句來處理，因?yàn)樗菬o效的“命令行處理器”命令。在
SQL 處理期間，它返回：
SQL0964C 數(shù)據(jù)庫的事務(wù)日志已滿。 SQLSTATE=57011
可以看到，當(dāng)日志滿的時(shí)候其他的任何記日志的操作都將不能進(jìn)行，所以整個(gè)系統(tǒng)基本處于不可用的狀態(tài)，除非等事務(wù)回滾結(jié)束。
OK，事務(wù)日志滿的情況出現(xiàn)，現(xiàn)在我們就根據(jù)日志滿的日志，來逆向分析是哪個(gè)操作導(dǎo)致的該問題，分析步驟如下：
首先，確定哪個(gè)應(yīng)用的事務(wù)占用了大量的日志空間：
在回話2中執(zhí)行：
Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/
-->C:/Documents and Settings/administrator>db2pd -db sample -transactions
Database Partition 0 -- Database SAMPLE -- Active -- Up 0 days 00:02:27
Transactions:
Address AppHandl [nod-index] TranHdl Locks State Tflag Tflag2
Firstlsn Lastlsn LogSpace SpaceReserved TID
AxRegCnt GXID
…..
0x7FC21A80 7 [000-00007] 2 10 WRITE 0x00000000 0x00000
000 0x00003D86000C 0x000048C4FCD0 14014572 201955470 0x000000004F91
1 0
…..
可以看到上面紅色部分， AppHandl為7的應(yīng)用的一個(gè)事務(wù)占用了大量的日志。如果有多個(gè)應(yīng)用占用了大量的日志，我們可以按照下面的方法逐個(gè)分析，看每個(gè)應(yīng)用是執(zhí)行了什么sql導(dǎo)致的占用如此大的日志。
然后使用db2pd確定這個(gè)日志執(zhí)行了什么語句導(dǎo)致占用了大量的日志：
Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/
-->C:/Documents and Settings/administrator>db2pd -db sample -applications
Database Partition 0 -- Database SAMPLE -- Active -- Up 0 days 00:02:36
Applications:
Address AppHandl [nod-index] NumAgents CoorEDUID Status C-
AnchID C-StmtUID L-AnchID L-StmtUID Appid
WorkloadID WorkloadOccID
…..
0x7AED8080 7 [000-00007] 1 1572 UOW-Waiting 0
0 185 1 *LOCAL.DB2.081111100729
1 1
…..
Application handle為7的應(yīng)用，對(duì)應(yīng)的L-AnchID為185，L-StmtUID為1。在回話2中繼續(xù)使用db2pd找到對(duì)應(yīng)的sql語句：
Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/
--> db2pd -db sample -dynamic
…..
Dynamic SQL Statements:
Address AnchID StmtUID NumEnv NumVar NumRef NumExe Text
0x7EA7D540 185 1 1 1 1 1 CALL proc_testlog(?)
…
對(duì)應(yīng)AnchID為185, StmtUID為1的語句，是CALL proc_testlog(?)，通過上面的分析，我們可以找到，是調(diào)用存儲(chǔ)過程proc_testlog導(dǎo)致占用了大量的日志，從而找出導(dǎo)致日志滿的罪魁禍?zhǔn)住?/p>
解決方案：
首先，盡量規(guī)避超大事務(wù)的操作，對(duì)于必須執(zhí)行的這種大操作，可以考慮是否可以分解成幾個(gè)事務(wù)進(jìn)行，如果可以，盡量分解為小事務(wù)的方式進(jìn)行;如果業(yè)務(wù)上不可以分解，是否可以考慮采用不記日志的方式?比如，load代替insert?表針對(duì)這個(gè)操作，暫時(shí)改為不記日志的方式等等。
注意：當(dāng)進(jìn)行不記日志的操作時(shí)，必須非常清楚這樣的操作的影響，比如，歸檔日志下數(shù)據(jù)庫前滾的影響，hadr與復(fù)制的數(shù)據(jù)同步影響，操作失敗結(jié)果如何等等。
其次，總有些我們無法預(yù)料的操作發(fā)生，可能某個(gè)維護(hù)人員某天發(fā)出一個(gè)不適當(dāng)?shù)拿睿瑒h除了大量的數(shù)據(jù)，導(dǎo)致日志滿，整個(gè)系統(tǒng)無法運(yùn)行，如何規(guī)避這樣的操作帶來的系統(tǒng)運(yùn)行影響呢?可以設(shè)置參數(shù)：max_log和DB2_FORCE_APP_ON_MAX_LOG注冊(cè)變量。
max_log此參數(shù)指示一個(gè)事務(wù)可以消耗的主日志空間的百分比。該值是為 logprimary 配置參數(shù)指定的值的百分比。如果該值設(shè)置為 0，那么對(duì)一個(gè)事務(wù)可以消耗的總的主日志空間的百分比沒有限制。我們可以配合設(shè)置DB2_FORCE_APP_ON_MAX_LOG注冊(cè)變量來規(guī)定如果應(yīng)用程序違反了 max_log 配置，我們對(duì)該應(yīng)用如何處理，DB2_FORCE_APP_ON_MAX_LOG設(shè)置為true，則超過max_log的應(yīng)用回被強(qiáng)制與數(shù)據(jù)庫斷開連接，事務(wù)將被回滾，并且將返回錯(cuò)誤 SQL1224N。如果 DB2_FORCE_APP_ON_MAX_LOG 注冊(cè)表變量設(shè)置為 FALSE，則違反了max_log設(shè)置的的事務(wù)將失敗，并返回錯(cuò)誤 SQL0964N。該應(yīng)用程序仍然可以提交在工作單元中由先前語句完成的工作，它也可以回滾已完成的工作以撤銷該工作單元。
通過次設(shè)置我們可以保證即使有大事務(wù)操作，總有(1-max_log/100)*log_primary+log_second的日志可以用來處理日常交易，從而避免系統(tǒng)中斷。
注意： 由 max_log 配置參數(shù)施加的限制不適用于下列 DB2 命令：ARCHIVE LOG、BACKUP DATABASE、LOAD、REORG TABLE(聯(lián)機(jī))、RESTORE DATABASE 和 ROLLFORWARD DATABASE。
[!--empirenews.page--]
C、 事務(wù)日志滿場景二：某個(gè)事務(wù)一直未提交，占用的日志不能被重用，導(dǎo)致日志滿
現(xiàn)在看另外一個(gè)場景，我在一個(gè)會(huì)話中執(zhí)行了如下命令：
C:/Documents and Settings/administrator>db2 +c call proc_testlog(3)
SQL0964C 數(shù)據(jù)庫的事務(wù)日志已滿。 SQLSTATE=57011
顯然，數(shù)據(jù)庫日志已滿，于是，根據(jù)上面的方法，我找是哪個(gè)事務(wù)占用了日志。
Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/
-->C:/Documents and Settings/administrator>db2pd -db sample -transactions
Database Partition 0 -- Database SAMPLE -- Active -- Up 0 days 00:10:12
Transactions:
Address AppHandl [nod-index] TranHdl Locks State Tflag Tflag2
Firstlsn Lastlsn LogSpace SpaceReserved TID
AxRegCnt GXID
0x7FC21A80 12 [000-00012] 2 7 READ 0x00000000 0x00000
000 0x000000000000 0x000000000000 0 0 0x0000000053A9
1 0
0x7FC22780 13 [000-00013] 3 0 READ 0x00000000 0x00000
000 0x000000000000 0x000000000000 0 0 0x00000000538F
1 0
0x7FC23480 14 [000-00014] 4 0 READ 0x00000000 0x00000
000 0x000000000000 0x000000000000 0 0 0x0000000053BE
1 0
0x7FC24180 15 [000-00015] 5 0 READ 0x00000000 0x00000
000 0x000000000000 0x000000000000 0 0 0x000000005391
1 0
0x7FC24E80 16 [000-00016] 6 0 READ 0x00000000 0x00000
000 0x000000000000 0x000000000000 0 0 0x000000005394
1 0
0x7FC25B80 17 [000-00017] 7 4 WRITE 0x00000000 0x00000
000 0x0000538A93B7 0x0000538A9455 184 408 0x00000000539A
很奇怪，從結(jié)果顯示，我沒有發(fā)現(xiàn)任何一個(gè)占用大量日志的應(yīng)用程序，日志的使用顯然都非常的小，那為什么日志還會(huì)滿呢?我們?cè)僮⒁庀抡加萌罩镜膽?yīng)用，查看下各自使用的日志文件。
Code highlighting produced by Actipro CodeHighlighter (freeware)
http://www.CodeHighlighter.com/
--> C:/Documents and Settings/administrator>db2pd -db sample -logs
Database Partition 0 -- Database SAMPLE -- Active -- Up 0 days 00:12:34
Logs:
Current Log Number 4
Pages Written 9498
Method 1 Archive Status n/a
Method 1 Next Log to Archive n/a
Method 1 First Failure n/a
Method 2 Archive Status n/a
Method 2 Next Log to Archive n/a
Method 2 First Failure n/a
Address StartLSN State Size Pages Filename
0x7FBECBD4 0x0000537F0000 0x00000000 10000 10000 S0000000.LOG
0x7FBECC74 0x000055F00000 0x00000000 10000 10000 S0000001.LOG
0x7FBECD14 0x000058610000 0x00000000 10000 10000 S0000002.LOG
0x7EABB2F4 0x00005AD20000 0x00000000 10000 10000 S0000003.LOG
0x7EABB394 0x00005D430000 0x00000000 10000 10000 S0000004.LOG
分析發(fā)現(xiàn)，這個(gè)占用日志的應(yīng)用的日志開始lsn為0x0000538A93B7，結(jié)束lsn為0x0000538A9455，正好落在第一日志文件中，因?yàn)檫@個(gè)事務(wù)一直沒有被提交，所以S0000000.LOG一直不能被重用，這樣業(yè)務(wù)在將主日志和輔助日志用完后，無法重新開始使用日志文件，導(dǎo)致出現(xiàn)日志滿的錯(cuò)誤。同樣，使用上面的方法，我們可以查找出這個(gè)Applications handle為7的一直沒有提交的小事務(wù)執(zhí)行的是什么操作。
上面的情況模擬方法：
在一個(gè)回話中執(zhí)行一個(gè)小事物，比如
C:/Documents and Settings/administrator>db2 +c "insert into test values ( 1112,1, ’sdfsdfsdfsdf’ , ’sdfsdfsdfsdfsdf’ , ’sdfsdfsdffsdfsd’ )
在另外一個(gè)回話中執(zhí)行占用事務(wù)比較大的操作，比如：db2 call proc_testlog(300000)，在這個(gè)回話中的操作都及時(shí)提交，直到配置的日志文件被使用完，再執(zhí)行小操作db2 call proc_testlog(3)，就可以出現(xiàn)上面的日志滿的情況。
解決方案：
可以看出，不是日志滿的問題一定是由于應(yīng)用占用大量的日志導(dǎo)致的，一個(gè)被忽略的未提交的操作也可能導(dǎo)致系統(tǒng)的日志無法被重用而導(dǎo)致日志滿，在應(yīng)用中，這是我們應(yīng)該盡量避免的。但是總是如果無法保證所有的操作都及時(shí)的提交，我們可以設(shè)置num_log_span參數(shù)來規(guī)避這個(gè)問題，參數(shù)指定是否對(duì)一個(gè)事務(wù)可以跨越多少個(gè)日志文件具有限制以及該限制是多少，當(dāng)設(shè)置這個(gè)參數(shù)后，未提交的事務(wù)所在的日志與當(dāng)前日志跨越的個(gè)數(shù)超過這個(gè)值，將被中斷，從而避免事務(wù)長時(shí)間存在導(dǎo)致系統(tǒng)日志滿。另外大事務(wù)可以跨越的日志也不能超過這個(gè)限制，所以當(dāng)設(shè)置max_log和num_log_span后，一個(gè)事務(wù)所可以使用的事務(wù)日志將取2者中比較小的值。
當(dāng)啟用了無限活動(dòng)日志空間時(shí)，max_log和 num_log_span 配置參數(shù)非常有用。如果打開了無限記錄(即，logsecondary 為 -1)，那么事務(wù)數(shù)不受日志文件數(shù)的上限(logprimary + logsecond)限制。當(dāng)?shù)竭_(dá) logprimary 的值時(shí)，DB2 將開始?xì)w檔活動(dòng)日志，而不是使事務(wù)失敗。這樣可能會(huì)導(dǎo)致問題，例如，有一個(gè)長期運(yùn)行的事務(wù)，但一直未落實(shí)它(可能是由于應(yīng)用程序不正確導(dǎo)致的)。如果出現(xiàn)這種情況，那么活動(dòng)日志空間會(huì)不斷增長，從而可能使得崩潰恢復(fù)性能很差。為了防止這樣，可以為 max_log 和/或 num_log_span 配置參數(shù)指定值。
注意：系統(tǒng)臨時(shí)表的使用，系統(tǒng)臨時(shí)表的數(shù)據(jù)操作是不記日志的，但是表的定義是有少量日志記錄的，所以，臨時(shí)表定義了一直沒操作，不提交也可能會(huì)引起部分小日志的一直被占用。
本文來自CSDN博客，轉(zhuǎn)載請(qǐng)標(biāo)明出處：http://blog.csdn.net/jeff2007/archive/2009/12/02/4922671.aspx