DB2活动日志满的原因、分析、处理与规避
日志使用
下图显示了并发事务条件下,日志使用的示意
有3个并发的程序Process 1、Process 2、Process 3。每一个程序都有两个事务。蓝块代表SQL语句,红块代表commit操作,绿块代表rollback操作。每一个向下的箭头都代表日志缓冲区的数据被刷新到日志磁盘上(默认是每一次提交操作都会导致日志缓冲被刷新到磁盘上)。
在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.
$ 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错误:
$ 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中会有以下报错
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,看一下这个应用的状态:
$ 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
<<--一个事务中可能有多条SQL,这个只表示当前正在执行或者最后执行过的SQL,并不能表示就是这条SQL导致了日志满,这里抓取到的是一条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.)根据抓取到的应用的snapshot,找应用开发人员查看为何不肯提交,这才是避免问题再次出现的根本办法。
2.)从DB2管理层面,可以设置数据库配置参数max_log和num_log_span
3.)可以写脚本,以固定的间隔抓取database snapshot中的Appl id holding the oldest transaction, 如果长时间不发生变化(比如2天),就Force掉。
补充说明:
查看数据库整体日志的作用率:
https://www.ibm.com/support/knowledgecenter/en/SSEPGG_11.1.0/com.ibm.db2.luw.sql.rtn.doc/doc/r0060791.html
查看每个应用使用的日志大小:
$ 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"
DB2活动日志满的原因、分析、处理与规避相关推荐
- db2关闭下一句sql的日志_分析DB2活动日志满的原因及解决DB2日志满方法与避免方案...
日志使用 下图显示了并发事务条件下,日志使用的示意 有3个并发的程序Process 1.Process 2.Process 3.每一个程序都有两个事务.蓝块代表SQL语句,红块代表commit操作,绿 ...
- DB2活动日志满的原因及解决与避免方案
下图显示了并发事务条件下,日志使用的示意 有3个并发的程序Process 1.Process 2.Process 3.每一个程序都有两个事务.蓝块代表SQL语句,红块代表commit操作,绿块代表ro ...
- DB2中常见sqlCode原因分析
DB2中常见sqlCode原因分析 000 | 00000 | SQL语句成功完成 01xxx | SQL语句成功完成,但是有警告 +012 | 01545 | 未限定的列名被解释为一个有相互关系的引 ...
- db2 删除索引_[收录量]史上最全的百度索引量下降原因分析及解
索引是流量的基础,每次索引数据的变化都在移动站长的敏感神经,"如何在索引量下降后开始分析"一直是大家讨论的热点话题.这一次小星SEO拔出一把小刀来帮忙,看看历史上最完整的百度指数下 ...
- 【linux】ARM开发板上设置RTC时间,断电重启后,设置失效的原因分析
问题描述 linux中使用date设置时间后用hwclock -w同步到RTC,断电重启后,有时会失效 原因分析 保存时间戳 1.使用命令关机(halt)会调用rc0.d中的脚本: 2.使用命令重启( ...
- Lua(Codea) 中 table.insert 越界错误原因分析
2019独角兽企业重金招聘Python工程师标准>>> Lua(Codea) 中 table.insert(touches, touch.id, touch) 越界错误原因分析 背景 ...
- SAP MM ME21N 创建PO时报错 - Net price in CNY becomes too large – 之原因分析
SAP MM ME21N 创建PO时报错 - Net price in CNY becomes too large – 之原因分析 昨天笔者在微信公众号里发布了一篇文章<SAP MM ME21N ...
- DB time抖动的原因分析
9月22日,"DBA+社群"开讲啦!由搜狐畅游高级DBA杨建荣在"DBA+北京群"进行了一次关于DB time抖动的原因分析的线上主题分享.小编特别整理出其中精 ...
- TypeError: 'module' object is not callable 原因分析
程序代码 class Person: #constructor def __init__(self,name,sex): self.Name = name ...
最新文章
- PyTorch Cookbook(常用代码段集锦)
- mysql-5.7.21-winx64_MySql-5.7.17 -winx64的安装配置
- 关于利用python进行验证码识别的一些想法
- 基于Shodan Python库的批量攻击实践 撒旦网
- 功夫熊孟军贤:如何拿到10万种子用户,创业的经验分享
- -Block和JSON
- [bzoj 3594] [Scoi2014]方伯伯的玉米田
- 人力资源管理系统、OA、行政管理系统、考勤管理、资产管理、车辆管理、绩效管理、员工管理、招聘、入职、离职、转正、加班、调休、企业OA系统、axure原型、rp源文件、web端后台管理原型、高保真原型
- HTML 内容不能被选择,不能被复制
- 如何找到解决问题的方法?
- 第2章 数据库系统体系结构
- 树的非递归(前序,中序,后序)
- spring security 参考 和 例子
- 号码卡JAVA算法---猜车牌号
- Makefile入门(超详细一文读懂)
- 51单片机点亮数码管,单片机学习的好的办法,单片机例子大全,单片机教程
- Tarjan算法附图详解(SCC)
- Cesium资料大集合
- Lab3-实现计划项app辅助类实现
- 教你如何编写游戏外挂