1、DB2數(shù)據(jù)庫的日志原理
事務(wù)日志記錄數(shù)據(jù)庫中所有對象和數(shù)據(jù)的改變，在早前版本中最大可達256G，其大小為( logprimary + logsecond ) * logfilsiz，其中l(wèi)ogprimary + logsecond的值小于或等于256，logfilsiz的最大為262144，在9.5版本中，日志最大已經(jīng)可以達到512G，其中l(wèi)ogfilsz的大小更改為524286。
DB2數(shù)據(jù)庫的日志分為主日志和輔助日志，其中主日志在第一個連接到達數(shù)據(jù)庫或者數(shù)據(jù)庫被激活后立即分配，而輔助日志在主日志大小不夠的時候動態(tài)分配。所以需要注意一點，日志所在的文件系統(tǒng)的大小必須大于主日志文件與輔助日志文件的大小之和。
DB2數(shù)據(jù)庫有2種日志配置方式，循環(huán)日志與歸檔日志。
循環(huán)日志：這是數(shù)據(jù)庫默認的日志使用方式，主日志用來記錄所有的更改，當事務(wù)提交后，日志文件會被重用。當主日志文件達到限制時，輔助日志文件將被使用。這種日志方式可以進行崩潰恢復(fù)和版本恢復(fù)，不能進行前滾恢復(fù)，不支持在線備份。
當活動事務(wù)的使用空間超過主日志和輔助日志的限制或者日志空間超過磁盤可使用空間，將會得到日志滿的錯誤。
歸檔日志：啟用logarchmetd1、logarchmetd2或打開logretain參數(shù)，注意，在9.5版本中，不推薦使用logretain參數(shù)，其所有的設(shè)置值將被忽略。在數(shù)據(jù)庫歸檔日志規(guī)劃時，建議不再使用logretain的方法。日志文件將不會被刪除-保持在線或者離線狀態(tài)。支持前滾恢復(fù)和在線備份。
疑問：歸檔日志下，日志一直保留，持續(xù)生成新日志，為什么還會出現(xiàn)日志滿的錯誤?
歸檔日志下，其可用的活動日志大小依然受到主日志與輔助日志大小之和的限制，所以，即使在歸檔日志下，日志滿的場景與活動日志下是完全一樣的。
2、日志使用中的問題與解決方法
在日常使用中，我們遇到最多的問題就是日志滿，現(xiàn)在用幾個實際的例子來看如何分析和解決日志滿的問題，一般的，日志滿可以分以下幾個場景：
A、 環(huán)境準備，并介紹數(shù)據(jù)庫日志使用大小評估方法：
數(shù)據(jù)庫參數(shù)設(shè)置如下：
日志文件大小(4KB) (LOGFILSIZ) = 10000
主日志文件的數(shù)目 (LOGPRIMARY) = 3
輔助日志文件的數(shù)目 (LOGSECOND) = 2
日志總大小為200M.
創(chuàng)建測試用表：
|
1 2 3 |
C:Documents and Settingsadministrator>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ù)的存儲過程：
|
雙擊代碼全選 |
|
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
C:Documents and Settingsadministrator>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命令成功完成。
我們來評估下插入使用日志的情況，以便構(gòu)造日志滿的場景，使用db2pd來查看事務(wù)日志的使用。
分別打開2個db2cmd會話窗口，在窗口1中我們執(zhí)行：
C:Documents and Settingsadministrator>db2 +c call proc_testlog(1)
返回狀態(tài) = 0
會話2中執(zhí)行:
|
雙擊代碼全選 |
|
|
1 2 3 4 5 6 7 8 9 |
C:Documents and Settingsadministrator>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 |
可以看到這個寫操作占用的日志大約為700個字節(jié)，在回話1中再重復(fù)執(zhí)行上面的命令，會話2中在看db2pd的輸出：
|
雙擊代碼全選 |
|
|
1 2 3 4 5 6 7 8 9 |
C:Documents and Settingsadministrator>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，我們可以這樣評估，單個事務(wù)每執(zhí)行一次表插入，插入一行占用的日志約為700字節(jié)，在一個事務(wù)中，插入多條記錄，插入一行記錄占用的日志約為634字節(jié)，當然，實際上當插入多行時，日志的大小會比計算值略大。
使用這個方法可以根據(jù)業(yè)務(wù)運行情況來評估需要數(shù)據(jù)庫應(yīng)該配置的日志大小，也可以評估單個大事務(wù)需要的日志空間。
根據(jù)估算，200M總?cè)罩敬笮。?00*1024*1024/635=330781。因此可以一次插入大約33W記錄來構(gòu)造日志滿的場景。
B、 事務(wù)日志滿場景一：當前未提交的事務(wù)太大，超過日志的限制。
在會話1中執(zhí)行：
C:Documents and Settingsadministrator>db2 commit
DB20000I SQL命令成功完成。
提交前面未提交的事務(wù)。
C:Documents and Settingsadministrator>db2 +c call proc_testlog(330000)
SQL0964C 數(shù)據(jù)庫的事務(wù)日志已滿。 SQLSTATE=57011
這時候我打開另外一個session，執(zhí)行一個不相關(guān)的插入操作。
C:Documents and Settingsadministrator>db2 "insert into test values(1112,1,’sdfsdfsdfsdf’,’sdfsdfsdfsdfsdf’,’sdfsdfsdffsdfsd’)
DB21034E 該命令被當作 SQL 語句來處理，因為它是無效的“命令行處理器”命令。在
SQL 處理期間，它返回：SQL0964C 數(shù)據(jù)庫的事務(wù)日志已滿。 SQLSTATE=57011
可以看到，當日志滿的時候其他的任何記日志的操作都將不能進行，所以整個系統(tǒng)基本處于不可用的狀態(tài)，除非等事務(wù)回滾結(jié)束。
OK，事務(wù)日志滿的情況出現(xiàn)，現(xiàn)在我們就根據(jù)日志滿的日志，來逆向分析是哪個操作導(dǎo)致的該問題，分析步驟如下：
首先，確定哪個應(yīng)用的事務(wù)占用了大量的日志空間：
在回話2中執(zhí)行：
|
雙擊代碼全選 |
|
|
1 2 3 4 5 6 7 8 9 10 11 |
C:Documents and Settingsadministrator>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)用的一個事務(wù)占用了大量的日志。如果有多個應(yīng)用占用了大量的日志，我們可以按照下面的方法逐個分析，看每個應(yīng)用是執(zhí)行了什么sql導(dǎo)致的占用如此大的日志。
然后使用db2pd確定這個日志執(zhí)行了什么語句導(dǎo)致占用了大量的日志：
|
雙擊代碼全選 |
|
|
1 2 3 4 5 6 7 8 9 10 11 |
C:Documents and Settingsadministrator>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)用，對應(yīng)的L-AnchID為185，L-StmtUID為1。在回話2中繼續(xù)使用db2pd找到對應(yīng)的sql語句：
|
雙擊代碼全選 |
|
|
1 2 3 4 5 6 |
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(?) … |
對應(yīng)AnchID為185, StmtUID為1的語句，是CALL proc_testlog(?)，通過上面的分析，我們可以找到，是調(diào)用存儲過程proc_testlog導(dǎo)致占用了大量的日志，從而找出導(dǎo)致日志滿的罪魁禍首。
解決方案：
首先，盡量規(guī)避超大事務(wù)的操作，對于必須執(zhí)行的這種大操作，可以考慮是否可以分解成幾個事務(wù)進行，如果可以，盡量分解為小事務(wù)的方式進行;如果業(yè)務(wù)上不可以分解，是否可以考慮采用不記日志的方式?比如，load代替insert?表針對這個操作，暫時改為不記日志的方式等等。
注意：當進行不記日志的操作時，必須非常清楚這樣的操作的影響，比如，歸檔日志下數(shù)據(jù)庫前滾的影響，hadr與復(fù)制的數(shù)據(jù)同步影響，操作失敗結(jié)果如何等等。
其次，總有些我們無法預(yù)料的操作發(fā)生，可能某個維護人員某天發(fā)出一個不適當?shù)拿睿瑒h除了大量的數(shù)據(jù)，導(dǎo)致日志滿，整個系統(tǒng)無法運行，如何規(guī)避這樣的操作帶來的系統(tǒng)運行影響呢?可以設(shè)置參數(shù)：max_log和DB2_FORCE_APP_ON_MAX_LOG注冊變量。
max_log此參數(shù)指示一個事務(wù)可以消耗的主日志空間的百分比。該值是為 logprimary 配置參數(shù)指定的值的百分比。如果該值設(shè)置為 0，那么對一個事務(wù)可以消耗的總的主日志空間的百分比沒有限制。我們可以配合設(shè)置DB2_FORCE_APP_ON_MAX_LOG注冊變量來規(guī)定如果應(yīng)用程序違反了 max_log 配置，我們對該應(yīng)用如何處理，DB2_FORCE_APP_ON_MAX_LOG設(shè)置為true，則超過max_log的應(yīng)用回被強制與數(shù)據(jù)庫斷開連接，事務(wù)將被回滾，并且將返回錯誤 SQL1224N。如果 DB2_FORCE_APP_ON_MAX_LOG 注冊表變量設(shè)置為 FALSE，則違反了max_log設(shè)置的的事務(wù)將失敗，并返回錯誤 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)機)、RESTORE DATABASE 和 ROLLFORWARD DATABASE。
C、 事務(wù)日志滿場景二：某個事務(wù)一直未提交，占用的日志不能被重用，導(dǎo)致日志滿
現(xiàn)在看另外一個場景，我在一個會話中執(zhí)行了如下命令：
C:Documents and Settingsadministrator>db2 +c call proc_testlog(3)
SQL0964C 數(shù)據(jù)庫的事務(wù)日志已滿。 SQLSTATE=57011
顯然，數(shù)據(jù)庫日志已滿，于是，根據(jù)上面的方法，我找是哪個事務(wù)占用了日志。
|
雙擊代碼全選 |
|
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
C:Documents and Settingsadministrator>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)任何一個占用大量日志的應(yīng)用程序，日志的使用顯然都非常的小，那為什么日志還會滿呢?我們再注意下占用日志的應(yīng)用，查看下各自使用的日志文件。
|
雙擊代碼全選 |
|
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
C:Documents and Settingsadministrator>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)，這個占用日志的應(yīng)用的日志開始lsn為0x0000538A93B7，結(jié)束lsn為0x0000538A9455，正好落在第一日志文件中，因為這個事務(wù)一直沒有被提交，所以S0000000.LOG一直不能被重用，這樣業(yè)務(wù)在將主日志和輔助日志用完后，無法重新開始使用日志文件，導(dǎo)致出現(xiàn)日志滿的錯誤。同樣，使用上面的方法，我們可以查找出這個Applications handle為7的一直沒有提交的小事務(wù)執(zhí)行的是什么操作。
上面的情況模擬方法：
在一個回話中執(zhí)行一個小事物，比如
C:\Documents and Settings\administrator>db2 +c "insert into test values ( 1112,1, ’sdfsdfsdfsdf’ , ’sdfsdfsdfsdfsdf’ , ’sdfsdfsdffsdfsd’ )
在另外一個回話中執(zhí)行占用事務(wù)比較大的操作，比如：db2 call proc_testlog(300000)，在這個回話中的操作都及時提交，直到配置的日志文件被使用完，再執(zhí)行小操作db2 call proc_testlog(3)，就可以出現(xiàn)上面的日志滿的情況。
解決方案：
可以看出，不是日志滿的問題一定是由于應(yīng)用占用大量的日志導(dǎo)致的，一個被忽略的未提交的操作也可能導(dǎo)致系統(tǒng)的日志無法被重用而導(dǎo)致日志滿，在應(yīng)用中，這是我們應(yīng)該盡量避免的。但是總是如果無法保證所有的操作都及時的提交，我們可以設(shè)置num_log_span參數(shù)來規(guī)避這個問題，參數(shù)指定是否對一個事務(wù)可以跨越多少個日志文件具有限制以及該限制是多少，當設(shè)置這個參數(shù)后，未提交的事務(wù)所在的日志與當前日志跨越的個數(shù)超過這個值，將被中斷，從而避免事務(wù)長時間存在導(dǎo)致系統(tǒng)日志滿。另外大事務(wù)可以跨越的日志也不能超過這個限制，所以當設(shè)置max_log和num_log_span后，一個事務(wù)所可以使用的事務(wù)日志將取2者中比較小的值。
當啟用了無限活動日志空間時，max_log和 num_log_span 配置參數(shù)非常有用。如果打開了無限記錄(即，logsecondary 為 -1)，那么事務(wù)數(shù)不受日志文件數(shù)的上限(logprimary + logsecond)限制。當?shù)竭_ logprimary 的值時，DB2 將開始歸檔活動日志，而不是使事務(wù)失敗。這樣可能會導(dǎo)致問題，例如，有一個長期運行的事務(wù)，但一直未落實它(可能是由于應(yīng)用程序不正確導(dǎo)致的)。如果出現(xiàn)這種情況，那么活動日志空間會不斷增長，從而可能使得崩潰恢復(fù)性能很差。為了防止這樣，可以為 max_log 和/或 num_log_span 配置參數(shù)指定值。
注意：系統(tǒng)臨時表的使用，系統(tǒng)臨時表的數(shù)據(jù)操作是不記日志的，但是表的定義是有少量日志記錄的，所以，臨時表定義了一直沒操作，不提交也可能會引起部分小日志的一直被占用。
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯(lián)系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
