it運(yùn)維: 分析DB2活動(dòng)日志滿的原因及解決DB2日志滿方法與避免方案

2020-03-29 16:39 作者：admin 瀏覽量：

 
3月17日我們分享了一篇文章,”無企業(yè),不上云”,被各大平臺(tái)轉(zhuǎn)載分享,這讓我們看到了互聯(lián)網(wǎng)的熱情,也看到了企業(yè)對(duì)上云的渴望,艾銻無限作為阿里云的戰(zhàn)略合作伙伴,我們更樂意幫助企業(yè)上云,讓更多的企業(yè)邁向數(shù)字化時(shí)代.
 
我們相信每一家企業(yè)都是IT企業(yè),每一家企業(yè)都是互聯(lián)網(wǎng)企業(yè),每一家企業(yè)都是數(shù)字化企業(yè),這一切的基礎(chǔ)都是基于云,云將會(huì)成為企業(yè)最重要的基礎(chǔ)設(shè)施,就像水、媒、電一樣的重要. 那為什么云對(duì)于企業(yè)來說如此重要呢,主要有以下五個(gè)方面:

1、應(yīng)變力
云端快速部署、自由擴(kuò)展的優(yōu)勢，使網(wǎng)站、APP等應(yīng)用上線、迭代更加靈活，提高了信息系統(tǒng)的運(yùn)營效率。云以突出的應(yīng)變能力，適應(yīng)多變的企業(yè)信息化進(jìn)程，降低試錯(cuò)成本，加快研發(fā)進(jìn)度，增強(qiáng)企業(yè)創(chuàng)新的信心。

2、穩(wěn)定性
云環(huán)境為企業(yè)業(yè)務(wù)創(chuàng)造了一個(gè)穩(wěn)定、可靠的空間，使用戶體驗(yàn)更好，客戶滿意度顯著提升。互聯(lián)網(wǎng)產(chǎn)品獲得流量和用戶粘性的核心是用戶體驗(yàn)，在線用戶流暢訪問，便捷操作，才會(huì)有較高的市場占有率。

3、性價(jià)比
云計(jì)算優(yōu)異的性價(jià)比，為企業(yè)信息化大幅降低了成本。使企業(yè)可以把更多的資金，投入到業(yè)務(wù)創(chuàng)新中。傳統(tǒng)企業(yè)轉(zhuǎn)型升級(jí)存在著大量的不確定性，低成本的云計(jì)算幫助企業(yè)消除了資金上的顧慮。

4、安全性

轉(zhuǎn)型中的傳統(tǒng)企業(yè)，因?qū)W(wǎng)絡(luò)環(huán)境不熟悉，擔(dān)心網(wǎng)絡(luò)攻擊、數(shù)據(jù)泄露等安全問題。云計(jì)算服務(wù)商有專業(yè)的技術(shù)和高效的服務(wù)體系，幫助企業(yè)保護(hù)數(shù)據(jù)安全、規(guī)避安全風(fēng)險(xiǎn)和提供海量數(shù)據(jù)查詢，企業(yè)可以專注于網(wǎng)站和應(yīng)用程序，而不是基礎(chǔ)設(shè)施。
 
5、擴(kuò)展性
 
在企業(yè)信息化的成本結(jié)構(gòu)中，購買硬件軟件成本占比很高，而實(shí)際用于開發(fā)的支出就相應(yīng)很低，并且耗費(fèi)時(shí)間較長。如果完全基于云開架設(shè)IT系統(tǒng)，幾個(gè)小時(shí)就可完成基本框架。如果業(yè)務(wù)增加，就是直接購買服務(wù)器，邊際效益很低，采用云后，由于云計(jì)算的高擴(kuò)展性，通過邊際效益可實(shí)現(xiàn)成本下降。 綜上所述,未來云就像我們用的水、電、媒一樣成為企業(yè)的必須品,也會(huì)是最重要的基礎(chǔ)設(shè)施一個(gè)部分,所以數(shù)字化轉(zhuǎn)型的企業(yè),首先要上云,再考慮如何整合和重構(gòu)企業(yè)內(nèi)部的數(shù)據(jù),從而讓計(jì)算起到主導(dǎo)作用,最終實(shí)現(xiàn)企業(yè)數(shù)字化轉(zhuǎn)型終極目標(biāo).
 
 

分析DB2活動(dòng)日志滿的原因及解決DB2日志滿方法與避免方案

日志使用
下圖顯示了并發(fā)事務(wù)條件下，日志使用的示意 有3個(gè)并發(fā)的程序Process 1、Process 2、Process 3。每一個(gè)程序都有兩個(gè)事務(wù)。藍(lán)塊代表SQL語句，紅塊代表commit操作，綠塊代表rollback操作。每一個(gè)向下的箭頭都代表日志緩沖區(qū)的數(shù)據(jù)被刷新到日志磁盤上（默認(rèn)是每一次提交操作都會(huì)導(dǎo)致日志緩沖被刷新到磁盤上）。
在T1時(shí)刻，事務(wù)A commit，日志緩沖區(qū)被刷新到磁盤上。
在T2時(shí)刻，事務(wù)B commit，日志緩沖區(qū)被刷新到磁盤上，此時(shí)日志X使用完，但由于X中的事務(wù)C還沒有提交，所以X此時(shí)還是活動(dòng)日志。
在上圖中，如果事務(wù)C一直沒有提交操作，那么日志X將永遠(yuǎn)是首個(gè)活動(dòng)日志(oldest transaction log)，后續(xù)的日志也是活動(dòng)日志，其他應(yīng)用最終會(huì)導(dǎo)致日志滿。
活動(dòng)日志
如果一個(gè)日志中包含有未提交的事務(wù)，那么這個(gè)日志就是活動(dòng)日志(也有其他情況，比如雖然所有事務(wù)已經(jīng)提交，但對(duì)應(yīng)的更改還沒有持久化到磁盤上)。
首個(gè)活動(dòng)日志(First Active Log)
第一個(gè)活動(dòng)日志，首個(gè)活動(dòng)日志之后的日志（也就是編號(hào)比首個(gè)活動(dòng)日志大的日志）都是活動(dòng)日志，可以通過數(shù)據(jù)庫的snapshot查看first active log, current active log, 以及 last active log.

1 2 3 4 5

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

日志滿原因
DB2總的可用活動(dòng)日志的最大空間是有限制的，當(dāng)達(dá)到限制之后，就會(huì)發(fā)生日志滿的問題，限制為(LOGPRIMARY + LOGSECOND) * LOGFILSIZ * 4KB
日志滿的原因無非兩種:
1.) 一個(gè)小事務(wù)hold住了首個(gè)活動(dòng)日志，一直沒有提交，導(dǎo)致首個(gè)活動(dòng)日志一直是活動(dòng)狀態(tài)，不被釋放。這個(gè)跟堵車類似，一輛車因發(fā)動(dòng)機(jī)故障（事務(wù)沒有提交）堵住路口（占用首個(gè)活動(dòng)日志），即使后面的車都沒有問題（后續(xù)事務(wù)正常提交），也無法通過路口，且會(huì)越積越多，最終導(dǎo)致整個(gè)路都堵滿車（日志滿）。
2.) 有個(gè)事務(wù)非常大，迅速用盡了所有的日志。
日志滿的表現(xiàn):
首先應(yīng)用會(huì)報(bào)出SQL0964C錯(cuò)誤：

1 2 3 4

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

其次，db2diag.log中會(huì)有以下報(bào)錯(cuò)

1 2 3 4 5 6 7 8 9 10

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

日志滿的臨時(shí)處理：
1. 可以通過增加LOGSECOND來臨時(shí)增加可用的日志大小（修改時(shí)需要加上immediate選項(xiàng)使之立即生效）；增加LOGPRIMARY并沒有用，因?yàn)樾枰貑?shù)據(jù)庫才能生效。
2. force掉hold住首個(gè)活動(dòng)日志的的應(yīng)用，在force之前，可以抓取snapshot，看一下這個(gè)應(yīng)用的狀態(tài)：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50

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

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

1 2 3

$ 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, 如果長時(shí)間不發(fā)生變化（比如2天），就Force掉。
補(bǔ)充說明：
查看每個(gè)應(yīng)用使用的日志大小：

1	$ 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 查看每個(gè)正在使用的日志的情況
重點(diǎn)關(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.
通過對(duì)DB2活動(dòng)日志滿原因的分析我們就可以找到解決此問題的方法同時(shí)避免此問題的再次出現(xiàn)