it運維: 分析DB2活動日志滿的原因及解決DB2日志滿方法與避免方案
2020-03-29 16:39 作者：admin 瀏覽量：
企業上云為什么是數字化轉型升級的第一步
3月17日我們分享了一篇文章,”無企業,不上云”,被各大平臺轉載分享,這讓我們看到了互聯網的熱情,也看到了企業對上云的渴望,艾銻無限作為阿里云的戰略合作伙伴,我們更樂意幫助企業上云,讓更多的企業邁向數字化時代.
我們相信每一家企業都是IT企業,每一家企業都是互聯網企業,每一家企業都是數字化企業,這一切的基礎都是基于云,云將會成為企業最重要的基礎設施,就像水、媒、電一樣的重要.
1、應變力
云端快速部署、自由擴展的優勢，使網站、APP等應用上線、迭代更加靈活，提高了信息系統的運營效率。云以突出的應變能力，適應多變的企業信息化進程，降低試錯成本，加快研發進度，增強企業創新的信心。
2、穩定性
云環境為企業業務創造了一個穩定、可靠的空間，使用戶體驗更好，客戶滿意度顯著提升?；ヂ摼W產品獲得流量和用戶粘性的核心是用戶體驗，在線用戶流暢訪問，便捷操作，才會有較高的市場占有率。
3、性價比
云計算優異的性價比，為企業信息化大幅降低了成本。使企業可以把更多的資金，投入到業務創新中。傳統企業轉型升級存在著大量的不確定性，低成本的云計算幫助企業消除了資金上的顧慮。
4、安全性
轉型中的傳統企業，因對網絡環境不熟悉，擔心網絡攻擊、數據泄露等安全問題。云計算服務商有專業的技術和高效的服務體系，幫助企業保護數據安全、規避安全風險和提供海量數據查詢，企業可以專注于網站和應用程序，而不是基礎設施。
5、擴展性
在企業信息化的成本結構中，購買硬件軟件成本占比很高，而實際用于開發的支出就相應很低，并且耗費時間較長。如果完全基于云開架設IT系統，幾個小時就可完成基本框架。如果業務增加，就是直接購買服務器，邊際效益很低，采用云后，由于云計算的高擴展性，通過邊際效益可實現成本下降。
分析DB2活動日志滿的原因及解決DB2日志滿方法與避免方案
日志使用下圖顯示了并發事務條件下，日志使用的示意
在T1時刻，事務A commit，日志緩沖區被刷新到磁盤上。
在T2時刻，事務B commit，日志緩沖區被刷新到磁盤上，此時日志X使用完，但由于X中的事務C還沒有提交，所以X此時還是活動日志。
在上圖中，如果事務C一直沒有提交操作，那么日志X將永遠是首個活動日志(oldest transaction log)，后續的日志也是活動日志，其他應用最終會導致日志滿。
活動日志
如果一個日志中包含有未提交的事務，那么這個日志就是活動日志(也有其他情況，比如雖然所有事務已經提交，但對應的更改還沒有持久化到磁盤上)。
首個活動日志(First Active Log)
第一個活動日志，首個活動日志之后的日志（也就是編號比首個活動日志大的日志）都是活動日志，可以通過數據庫的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總的可用活動日志的最大空間是有限制的，當達到限制之后，就會發生日志滿的問題，限制為(LOGPRIMARY + LOGSECOND) * LOGFILSIZ * 4KB
日志滿的原因無非兩種:
1.) 一個小事務hold住了首個活動日志，一直沒有提交，導致首個活動日志一直是活動狀態，不被釋放。這個跟堵車類似，一輛車因發動機故障（事務沒有提交）堵住路口（占用首個活動日志），即使后面的車都沒有問題（后續事務正常提交），也無法通過路口，且會越積越多，最終導致整個路都堵滿車（日志滿）。
2.) 有個事務非常大，迅速用盡了所有的日志。
日志滿的表現:
首先應用會報出SQL0964C錯誤：
|
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 |
|
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. |
1. 可以通過增加LOGSECOND來臨時增加可用的日志大小（修改時需要加上immediate選項使之立即生效）；增加LOGPRIMARY并沒有用，因為需要重啟數據庫才能生效。
2. force掉hold住首個活動日志的的應用，在force之前，可以抓取snapshot，看一下這個應用的狀態：
|
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 <<--應用狀態為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 <<--應用連庫時間 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 <<--當前事務開始時間 UOW stop timestamp = <<--當前事務結束時間為空，說明還沒有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 |
|
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.）根據抓取到的應用的snapshot，找應用開發人員查看為何不肯提交，這才是避免問題再次出現的根本辦法。
2.）從DB2管理層面，可以設置數據庫配置參數max_log和num_log_span
3.）可以寫腳本，以固定的間隔抓取database snapshot中的Appl id holding the oldest transaction, 如果長時間不發生變化（比如2天），就Force掉。
補充說明：
查看每個應用使用的日志大?。?br />
| 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" |
重點關注的參數有：
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活動日志滿原因的分析我們就可以找到解決此問題的方法同時避免此問題的再次出現
相關文章
IT電腦維護外包
關閉