db2 活动日志激增的原因分析处理
本文简单地介绍了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 =
File number of last active log =
File number of current active log = 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=
其次,db2diag.log中会有以下报错
---17.24.50.315000+ E3234873F644 LEVEL: Error
PID : TID : PROC : db2syscs.exe
INSTANCE: DB2INST1 NODE : DB : SAMPLE
APPHDL : - APPID: *LOCAL.DB2INST1.
AUTHID : MIAOQINGSONG HOSTNAME: ADMINIB-PR7US3I
EDUID : EDUNAME: db2agent (SAMPLE)
FUNCTION: DB2 UDB, data protection services, sqlpgResSpace, probe:
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 = $ db2 get snapshot for application agentid Application Snapshot Application handle =
Application status = UOW Waiting <<--应用状态为UOW Waiting
Status change time = -- ::15.068895
Application code page =
Application country/region code =
DUOW correlation token = *LOCAL.DB2INST1.
Application name = db2bp.exe
Application ID = *LOCAL.DB2INST1. .. Connection request start timestamp = -- ::44.963163 <<--应用连库时间
Connect request completion timestamp = -- ::45.961157
Application idle time = minutes seconds UOW log space used (Bytes) =
Previous UOW completion timestamp = -- ::45.961157
Elapsed time of last completed uow (sec.ms)= 0.000000
UOW start timestamp = -- ::02.770477 <<--当前事务开始时间
UOW stop timestamp = <<--当前事务结束时间为空,说明还没有commit
UOW completion status = Statement type = Dynamic SQL Statement
Statement = Close
Section number =
Application creator = NULLID
Package name = SQLC2K26
Consistency Token =
Package Version ID =
Cursor name = SQLCUR201
Statement member number =
Statement start timestamp = -- ::15.067789
Statement stop timestamp = -- ::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掉。
补充案例1:
活动日志激增排查:
DB2总的可用活动日志的最大空间是有限制的,当达到限制之后,就会发生日志满的问题,限制为(LOGPRIMARY + LOGSECOND) * LOGFILSIZ * 4KB
日志满的原因无非两种:
1. 一个小事务hold住了首个活动日志,一直没有提交,导致首个活动日志一直是活动状态,不被释放。这个跟堵车类似,一辆车因发动机故障(事务没有提交)堵住路口(占用首个活动日志),即使后面的车都没有问题(后续事务正常提交),也无法通过路口,且会越积越多,最终导致整个路都堵满车(日志满)。
2. 有个事务非常大,迅速用尽了所有的日志。
日志满的临时处理:
. 可以通过增加LOGSECOND来临时增加可用的日志大小(修改时需要加上immediate选项使之立即生效);增加LOGPRIMARY并没有用,因为需要重启数据库才能生效。
. force掉hold住首个活动日志的的应用,在force之前,可以抓取snapshot,看一下这个应用的状态: db2 get snapshot for database on sample | grep -i oldest
首个活动日志(First Active Log)
第一个活动日志,首个活动日志之后的日志(也就是编号比首个活动日志大的日志)都是活动日志,可以通过数据库的snapshot查看first active log, current active log, 以及 last active log. db2 get snapshot for db on fxyjdb|grep -i "File number" 日志有无报错 db2diag -l "Error,Severe" -H 1d 查看事务占用日志情况
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 get snapshot for db on fxyjdb|grep -i oldest 查询 App Handle 49379 具体事务信息
db2 get snapshot for application agentid 49379 查看当前事务 db2top -db fxyjdb -h参数说明 输入参数a 写入App Handle 49379回车 取得相关信息包括sql语句 确认sql drop掉相关事务 db2 "force application(49379)" 再次查看事务占用日志情况 此外可以用db2pd -db dbname -logs检查
Appl id holding the oldest transaction = 49379
http://www-01.ibm.com/support/docview.wss?uid=swg21664899
The database snapshot will show the oldest transaction.
Collect following output,
db2 get snapshot for database on <db-name> And, look for following in the database snapshot output,
"Appl id holding the oldest transaction "
The application handle showing up against the above field have to be forced off to get the transaction log space back against that. db2 "force application (appl-handle)" If there are more than one application which might be causing the issue then the same step might have to be repeated multiple times forcing the current oldest transaction from that moment, until the log full situation is taken care. Following could be run during the time of the problem to get a full picture of all the transactions,
db2pd –db <db-name> -transactions There are some rare situations when the transaction log files might be held by indoubt transaction. Indoubt transaction can be caused by anything using two phase commit. The way to check indoubt transaction is to run, db2 list indoubt transactions with prompting and, then take necessary step to rollback or, forget the transaction. As a permanent solution, fix the queries which might not be committing frequently enough or, increase the total log space if it's not large enough by increasing any of LOGPRIMARY, LOGSECOND or, LOGFILSZ as necessary.
db2 活动日志激增的原因分析处理的更多相关文章
- SQLServer日志无法收缩原因分析及解决
SQL Server中的事务日志无疑是SQL Server中最重要的部分之一.因为SQL SERVER利用事务日志来确保持久性(Durability)和事务回滚(Rollback).从而还部分确保了事 ...
- SQLServer数据库中开启CDC导致“事务日志空间被占满,原因为REPLICATION”的原因分析和解决办法
本文出处:http://www.cnblogs.com/wy123/p/6646143.html SQLServer中开启CDC之后,在某些情况下会导致事务日志空间被占满的现象为:在执行增删改语句(产 ...
- DB2事务日志
1.DB2数据库的日志原理 事务日志记录数据库中所有对象和数据的改变,在早前版本中最大可达256G,其大小为( logprimary + logsecond ) * logfilsiz,其中logpr ...
- SQL查询速度慢的原因分析和解决方案
SQL查询速度慢的原因分析和解决方案 查询速度慢的原因很多,常见如下几种: 1.没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷) 2.I/O吞吐量小,形成了瓶颈效应. 3.没有创建 ...
- [terry笔记]ArchiveLog归档日志激增解决思路
归档日志激增的危害是巨大的,最严重的结果就是数据库无法正常工作,导致整个系统无法正常工作,其次就算数据库可以正常工作,但激增的归档会对磁盘产生大量消耗,导致性能下降. 归档日志激增一般是因 ...
- Linux ssh登陆慢的两种原因分析
Linux ssh登陆慢的两种原因分析 如果做运维就一定会遇到ssh登陆Linux服务器慢的问题,问题比较好解决,一般Google之后有很多文章都告诉你解决方法,但是很少有文章分析为什么会慢,这篇文章 ...
- SQL Server 磁盘请求超时的833错误原因分析以及解决
本文出处:http://www.cnblogs.com/wy123/p/6984885.html 最近遇到一个SQL Server服务器响应极度缓慢,并且出现客户端请求报错的情况,在数据库中的erro ...
- MySQL This function has none of DETERMINISTIC, NO SQL...错误1418 的原因分析及解决方法
MySQL开启bin-log后,调用存储过程或者函数以及触发器时,会出现错误号为1418的错误: ERROR 1418 (HY000): This function has none of DETER ...
- Caused by java.lang.IllegalStateException Not allowed to start service Intent { cmp=com.x.x.x/.x.x.xService }: app is in background uid UidRecord问题原因分析(二)
应用在适配Android 8.0以上系统时,会发现后台启动不了服务,会报出如下异常,并强退: Fatal Exception: java.lang.IllegalStateException Not ...
随机推荐
- MDX Cookbook 11 - 计算 Year Over Year 增长 (同比计算) ParallelPeriod
这一小节主要介绍如何在一个平行期间的度量值,当前值的对比对象是指当前值的上一年,上一个季度或者其它时间级别上与当前值同一时间点上的的那个对象.有一个非常常见的需求就是对比上一年同一个时间点的某个值来判 ...
- RPC框架-hessian学习
先说说hessian有什么优点和缺点 一.优点: 比 Java 原生的对象序列化/反序列化速度更快, 序列化出来以后的数据更小.序列化协议跟应用层协议无关, 可以将 Hessian 序列化以后的数据放 ...
- mysql乱码问题解决办法
最近开发一下小项目,遇到了最常见的乱码问题. 1.数据库使用utf-8 utf-8_generic_ci编码,使用csv上传并导入数据,插入数据的时候出现了问题,有很大部分数据没有被导入,所以使用m ...
- kubernetes中port、target port、node port的对比分析,以及kube-proxy代理
转:http://blog.csdn.net/xinghun_4/article/details/50492041 容器网络实例 服务中的3个端口设置 这几个port的概念很容易混淆,比如创建如下se ...
- MacOS安装react。问题 -- npm全局包的权限问题
网上的教程有好多,在这里不一一列举,我只介绍我今天安装成功的步骤 首先,在安装react之前要先配置好node 1.安装node 在这里下载node的安装包https://nodejs.org/en/ ...
- python中的ord函数
chr().unichr()和ord() chr()函数用一个范围在range(256)内的(就是0-255)整数作参数,返回一个对应的字符.unichr()跟它一样,只不过返回的是Unicode字符 ...
- WebMisSharp升级说明,最新版本1.6.0
尊敬的C3 AM.C3 FX.WebMisSharp用户您好: 非常感谢长期来您对WebMisSharp系列产品的支持,您的使用和反馈是我们进步的最大动力.在你们的帮助下我们又向前迈进了一步,我们功能 ...
- Spring MVC异常统一处理的三种方式
Spring 统一异常处理有 3 种方式,分别为: 使用 @ ExceptionHandler 注解 实现 HandlerExceptionResolver 接口 使用 @controlleradvi ...
- Fedora Server 21 安装 搜狗拼音输入法
最新文章:Virson’s Blog 借鉴文章:博客园-怒杀神殿 ChinaUnix-firo 百度贴吧-fedora吧 方法一:解压deb安装包方式安装: 如果本机已安装ibus,需要先卸载, ...
- Ubuntu 中的VI和vim
转载出处:http://blog.csdn.net/xiajun07061225/article/details/7039413 或功能键[Home]:移动到这一行的最前面字符处. $或功能键[End ...