广州凡科互联网科技有限公司

营业时间
MON-SAT 9:00-18:00

全国服务热线
18720358503

公司门店地址
广州市海珠区工业大道北67号凤凰创意园

剖析DB2主题活动系统日志满的缘故及处理DB2系统

日期:2021-02-19 浏览:
剖析DB2主题活动系统日志满的缘故及处理DB2系统日志满方式与防止计划方案,db2系统日志
关注度1 评价 81  网民共享于:  :55 访问数33680次

下面的图显示信息了高并发事务管理标准下,系统日志应用的提示

有3个高并发的程序Process 1、Process 2、Process 3。每个程序都是有2个事务管理。mit实际操作,绿块意味着rollback实际操作。每个往下的箭头符号都意味着系统日志缓存区的数据信息被更新到系统日志硬盘上(默认设置是每一次递交实际操作都是造成系统日志缓存被更新到硬盘上)。

mit,系统日志缓存区被更新到硬盘上。
mit,系统日志缓存区被更新到硬盘上,这时系统日志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 * 4k高清B

系统日志满的缘故只不过二种:

1.) 一个琐事务hold住了首例主题活动系统日志,一直沒有递交,造成首例主题活动系统日志一直是主题活动情况,不被释放出来。这一跟拥堵相近,一一辆车因启动机常见故障(事务管理沒有递交)塞住街口(占有首例主题活动系统日志),即便后边的车也没有难题(事后事务管理一切正常递交),也没法根据街口,且会越积越大,最后造成全部路都堵满车(系统日志满)。

2.) 有一个事务管理十分大,快速耗尽了全部的系统日志。

系统日志满的主要表现:

最先运用会给出SQL0964C不正确:

$ db2 "insert into test select * from test"
mand was processed as an SQL statement because it was not a
valid Command mand. 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.1
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 = :15.068895
Application code page = 1386
Application country/region code = 86
DUOW correlation token = *LOCAL.DB2INST1.4
Application name = db2bp.exe
Application ID = *LOCAL.DB2INST1.4
Connection request start timestamp = :44.963163 --运用连库時间
pletion timestamp = :45.961157
Application idle time = 4 minutes 7 seconds
UOW log space used (Bytes) = 664
pletion timestamp = :45.961157
Elapsed time pleted uow (sec.ms)= 0.000000
UOW start timestamp = :02.770477 --当今事务管理刚开始時间
UOW stop timestamp = --mit
pletion 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 = :15.067789
Statement stop timestamp = :15.068893 
Elapsed time pleted 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 essfully.
mand 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掉。

填补表明:

查询每一个运用应用的系统日志尺寸:

$ 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 查询每一个已经应用的系统日志的状况

关键关心的主要参数有:

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 pensation log records.

根据对DB2主题活动系统日志满缘故的剖析大家便可以寻找处理此难题的方式同时防止此难题的再度出現

dengb.TechArticle剖析DB2主题活动系统日志满的缘故及处理DB2系统日志满方式与防止计划方案,db2系统日志 系统日志应用 下面的图显示信息了高并发事务管理标准下,系统日志应用的提示 有3个高并发的程序...



网站知识

联系方式丨CONTACT

  • 全国热线:18720358503
  • 传真热线:18720358503
  • Q Q咨询:2639601583
  • 企业邮箱:2639601583@qq.com

首页
电话
短信
联系