日志使用

下圖顯示了并發(fā)事務(wù)條件下，日志使用的示意

有3個并發(fā)的程序Process 1、Process 2、Process 3。每一個程序都有兩個事務(wù)。藍塊代表SQL語句，紅塊代表commit操作，綠塊代表rollback操作。每一個向下的箭頭都代表日志緩沖區(qū)的數(shù)據(jù)被刷新到日志磁盤上（默認是每一次提交操作都會導(dǎo)致日志緩沖被刷新到磁盤上）。

在T1時刻，事務(wù)A commit，日志緩沖區(qū)被刷新到磁盤上。
在T2時刻，事務(wù)B commit，日志緩沖區(qū)被刷新到磁盤上，此時日志X使用完，但由于X中的事務(wù)C還沒有提交，所以X此時還是活動日志。

在上圖中，如果事務(wù)C一直沒有提交操作，那么日志X將永遠是首個活動日志(oldest transaction log)，后續(xù)的日志也是活動日志，其他應(yīng)用最終會導(dǎo)致日志滿。

活動日志

如果一個日志中包含有未提交的事務(wù)，那么這個日志就是活動日志(也有其他情況，比如雖然所有事務(wù)已經(jīng)提交，但對應(yīng)的更改還沒有持久化到磁盤上)。

首個活動日志(First Active Log)

第一個活動日志，首個活動日志之后的日志（也就是編號比首個活動日志大的日志）都是活動日志，可以通過數(shù)據(jù)庫的snapshot查看first active log, current active log, 以及 last active log.

$ db2 get snapshot for db on sample | grep -i "File number"File number of first active log      = 0File number of last active log       = 2File number of current active log     = 0File number of log being archived     = Not applicable

日志滿原因

DB2總的可用活動日志的最大空間是有限制的，當達到限制之后，就會發(fā)生日志滿的問題，限制為(LOGPRIMARY + LOGSECOND) * LOGFILSIZ * 4KB

日志滿的原因無非兩種:

1.) 一個小事務(wù)hold住了首個活動日志，一直沒有提交，導(dǎo)致首個活動日志一直是活動狀態(tài)，不被釋放。這個跟堵車類似，一輛車因發(fā)動機故障（事務(wù)沒有提交）堵住路口（占用首個活動日志），即使后面的車都沒有問題（后續(xù)事務(wù)正常提交），也無法通過路口，且會越積越多，最終導(dǎo)致整個路都堵滿車（日志滿）。

2.) 有個事務(wù)非常大，迅速用盡了所有的日志。

日志滿的表現(xiàn):

首先應(yīng)用會報出SQL0964C錯誤：

$ db2 "insert into test select * from test"DB21034E The command was processed as an SQL statement because it was not avalid Command Line Processor command. During SQL processing it returned:SQL0964C The transaction log for the database is full. SQLSTATE=57011

其次，db2diag.log中會有以下報錯

2017-03-09-17.24.50.315000+480 E3234873F644     LEVEL: ErrorPID   : 8532 TID : 13028     PROC : db2syscs.exeINSTANCE: DB2INST1       NODE : 000      DB  : SAMPLEAPPHDL : 0-453APPID: *LOCAL.DB2INST1.170309092321AUTHID : MIAOQINGSONG     HOSTNAME: ADMINIB-PR7US3IEDUID  : 13028EDUNAME: db2agent (SAMPLE)FUNCTION: DB2 UDB, data protection services, sqlpgResSpace, probe:2860MESSAGE : ADM1823E The active log is full and is held by application handle     "0-441". Terminate this application by COMMIT, ROLLBACK or FORCE     APPLICATION.

日志滿的臨時處理：

1. 可以通過增加LOGSECOND來臨時增加可用的日志大小（修改時需要加上immediate選項使之立即生效）；增加LOGPRIMARY并沒有用，因為需要重啟數(shù)據(jù)庫才能生效。

2. force掉hold住首個活動日志的的應(yīng)用，在force之前，可以抓取snapshot，看一下這個應(yīng)用的狀態(tài)：

$ db2 get snapshot for database on sample | grep -i oldestAppl id holding the oldest transaction   = 441$ db2 get snapshot for application agentid 441      Application SnapshotApplication handle     = 441Application status     = UOW Waiting <<--應(yīng)用狀態(tài)為UOW WaitingStatus change time     = 2017-03-09 17:23:15.068895Application code page   = 1386Application country/region code      = 86DUOW correlation token   = *LOCAL.DB2INST1.170309092244Application name      = db2bp.exeApplication ID       = *LOCAL.DB2INST1.170309092244..Connection request start timestamp     = 2017-03-09 17:22:44.963163 <<--應(yīng)用連庫時間Connect request completion timestamp    = 2017-03-09 17:22:45.961157Application idle time   = 4 minutes 7 seconds..UOW log space used (Bytes) = 664Previous UOW completion timestamp     = 2017-03-09 17:22:45.961157Elapsed time of last completed uow (sec.ms)= 0.000000UOW start timestamp    = 2017-03-09 17:23:02.770477 <<--當前事務(wù)開始時間UOW stop timestamp     =      <<--當前事務(wù)結(jié)束時間為空，說明還沒有commitUOW completion status   =..Statement type       = Dynamic SQL StatementStatement = CloseSection number       = 201Application creator    = NULLIDPackage name= SQLC2K26Consistency Token     =Package Version ID     =Cursor name= SQLCUR201Statement member number  = 0Statement start timestamp = 2017-03-09 17:23:15.067789Statement stop timestamp  = 2017-03-09 17:23:15.068893 Elapsed time of last completed stmt(sec.ms)= 0.000024Total Statement user CPU time       = 0.000000Total Statement system CPU time      = 0.000000..Dynamic SQL statement text:   select * from t1

<<--一個事務(wù)中可能有多條SQL，這個只表示當前正在執(zhí)行或者最后執(zhí)行過的SQL，并不能表示就是這條SQL導(dǎo)致了日志滿，這里抓取到的是一條SELECT語句，SELECT語句不占用日志。

$ db2 "force application (441)"DB20000I The FORCE APPLICATION command completed successfully.DB21024I This command is asynchronous and may not be effective immediately.

日志滿的避免：

1.）根據(jù)抓取到的應(yīng)用的snapshot，找應(yīng)用開發(fā)人員查看為何不肯提交，這才是避免問題再次出現(xiàn)的根本辦法。
2.）從DB2管理層面，可以設(shè)置數(shù)據(jù)庫配置參數(shù)max_log和num_log_span
3.）可以寫腳本，以固定的間隔抓取database snapshot中的Appl id holding the oldest transaction, 如果長時間不發(fā)生變化（比如2天），就Force掉。

補充說明：

查看每個應(yīng)用使用的日志大小：

$ db2 "select application_handle,UOW_LOG_SPACE_USED,UOW_START_TIME FROM TABLE(MON_GET_UNIT_OF_WORK(NULL,-1)) order by UOW_LOG_SPACE_USED" 

也可以通過db2pd -db <dbname> -transactions 查看每個正在使用的日志的情況

重點關(guān)注的參數(shù)有：

ApplHandl
The application handle of the transaction.
SpaceReserved
The amount of log space that is reserved for the transaction.
LogSpace
The total log space that is required for the transaction, including the used space and the reserved space for compensation log records.

通過對DB2活動日志滿原因的分析我們就可以找到解決此問題的方法同時避免此問題的再次出現(xiàn)