您所在的位置： &
DB2事务日志使用详解(1)
DB2事务日志使用详解(1)
我们经常接到客户的电话说数据库日志满了，需要快速清除。对于一些初入门的DB2使用者去维护一个大数据量的系统，这几乎是他们必然会碰到的一个问题。碰到这样的问题，我们可以不厌其烦的一遍遍向客户解释这个问题的原因，也可以给出非常明确的解决方案，但是对于很多客户看来，这似乎是一个比较无奈的解决方案，他们只能承担着这种操作带来的系统中断。因此，对于数据库的设计人员，开发人员和维护人员来讲，非常清楚的了解数据库的日志原理与合理的规划一些操作以避免发生这样的情况是非常重要的！下面，我们就对数据库的日志原理和使用..
我们经常接到客户的电话，我的数据库日志满了，有没有什么好办法快速清除?尤其对于一些初入门的DB2使用者去维护一个大数据量的系统，这几乎是他们必然会碰到的一个问题。
我们也经常接到客户更紧急的电话，我的数据库不能使用了，因为日志占用太多空间，文件系统满了，就把日志删除了，现在数据库无法使用，这个是生产系统，需要尽快恢复，有什么办法可以让数据库立刻使用?
碰到这样的问题，我们可以不厌其烦的一遍遍向客户解释这个问题的原因，也可以给出非常明确的解决方案，但是对于很多客户看来，这似乎是一个比较无奈的解决方案，他们只能承担着这种操作带来的系统中断。
因此，对于数据库的设计人员，开发人员和维护人员来讲，非常清楚的了解数据库的日志原理与合理的规划一些操作以避免发生这样的情况是非常重要的！下面，我们就对数据库的日志原理和使用中经常遇到的问题以及其解决方法跟大家分享下。
1、DB2数据库的日志原理
事务日志记录数据库中所有对象和数据的改变，在早前版本中最大可达256G，其大小为( logprimary + logsecond ) * logfilsiz，其中logprimary + logsecond的值小于或等于256，logfilsiz的最大为262144，在9.5版本中，日志最大已经可以达到512G，其中logfilsz的大小更改为524286。
DB2数据库的日志分为主日志和辅助日志，其中主日志在第一个连接到达数据库或者数据库被激活后立即分配，而辅助日志在主日志大小不够的时候动态分配。所以需要注意一点，日志所在的文件系统的大小必须大于主日志文件与辅助日志文件的大小之和。
DB2数据库有2种日志配置方式，循环日志与归档日志。
循环日志：这是数据库默认的日志使用方式，主日志用来记录所有的更改，当事务提交后，日志文件会被重用。当主日志文件达到限制时，辅助日志文件将被使用。这种日志方式可以进行崩溃恢复和版本恢复，不能进行前滚恢复，不支持在线备份。
当活动事务的使用空间超过主日志和辅助日志的限制或者日志空间超过磁盘可使用空间，将会得到日志满的错误。
归档日志：启用logarchmetd1、logarchmetd2或打开logretain参数，注意，在9.5版本中，不推荐使用logretain参数，其所有的设置值将被忽略。在数据库归档日志规划时，建议不再使用logretain的方法。日志文件将不会被删除-保持在线或者离线状态。支持前滚恢复和在线备份。
疑问：归档日志下，日志一直保留，持续生成新日志，为什么还会出现日志满的错误？
归档日志下，其可用的活动日志大小依然受到主日志与辅助日志大小之和的限制，所以，即使在归档日志下，日志满的场景与活动日志下是完全一样的。
2、日志使用中的问题与解决方法
在日常使用中，我们遇到最多的问题就是日志满，现在用几个实际的例子来看如何分析和解决日志满的问题，一般的，日志满可以分以下几个场景：
A、环境准备，并介绍数据库日志使用大小评估方法：
数据库参数设置如下：
日志文件大小(4KB) (LOGFILSIZ) = 10000
主日志文件的数目 (LOGPRIMARY) = 3
辅助日志文件的数目 (LOGSECOND) = 2
日志总大小为200M.
创建测试用表：
C:\Documents and Settings\administrator>db2 "create table test_log(col int, col2 char(10)
,col3 timestamp,col4 varchar(100),col5 varchar(100),col6 varchar(100),col7 varch
ar(100),col8 varchar(100))"
DB20000I SQL命令成功完成。
创建插入数据的存储过程：
C:\Documents and Settings\administrator>db2 -td@ -vf proc_testlog.sql
create procedure proc_testlog(v1 int)
declare time int default 0;
while (time < v1)
insert into test_log values(1,'testlog',current timestamp,'testlogtestlogte……');
set time = time + 1;
DB20000I SQL命令成功完成。
我们来评估下插入使用日志的情况，以便构造日志满的场景，使用db2pd来查看事务日志的使用。
分别打开2个db2cmd会话窗口，在窗口1中我们执行：
C:\Documents and Settings\administrator>db2 +c call proc_testlog(1)
返回状态 = 0
会话2中执行:
C:\Documents and Settings\administrator>db2pd -db sample -transactions
Database Partition 0 -- Database SAMPLE -- Active -- Up 0 days 00:29:20
Transactions:
Address AppHandl [nod-index] TranHdl Locks State Tflag Tflag2
Firstlsn Lastlsn LogSpace SpaceReserved TID
AxRegCnt GXID
0x7FC21A80 7 [000-0 WRITE 0xx00000
000 0x 0x 110 700 0x
可以看到这个写操作占用的日志大约为700个字节，在回话1中再重复执行上面的命令，会话2中在看db2pd的输出：
C:\Documents and Settings\administrator>db2pd -db sample -transactions
Database Partition 0 -- Database SAMPLE -- Active -- Up 0 days 00:45:55
Transactions:
Address AppHandl [nod-index] TranHdl Locks State Tflag Tflag2
Firstlsn Lastlsn LogSpace SpaceReserved TID
AxRegCnt GXID
0x7FC21A80 7 [000-0 WRITE 0xx00000
000 0xB8 0x06 154
，我们可以这样评估，单个事务每执行一次表插入，插入一行占用的日志约为700字节，在一个事务中，插入多条记录，插入一行记录占用的日志约为634字节，当然，实际上当插入多行时，日志的大小会比计算值略大。
使用这个方法可以根据业务运行情况来评估需要数据库应该配置的日志大小，也可以评估单个大事务需要的日志空间。
根据估算，200M总日志大小，200*5=330781。因此可以一次插入大约33W记录来构造日志满的场景。
内容导航&第 1 页： &第 2 页：
关于&&&&&&的更多文章
本书由麦思博（北京）软件技术有限公司主编，由著名Oracle专家和
数据库产品
数据库综合
数据库新闻
维基百科将切换到另外一款开源数据库MariaDB
讲师： 7人学习过讲师： 31人学习过讲师： 19人学习过
机器学习(Machine Learning, ML)是一门多领域交叉学科
数据可视化是数据分析师进行决策支持的重要手段。在大
Apache Spark是立足于内存计算的一种快速数据分析方案
本书针对初级网管朋友所需掌握的网络组建和网络管理技能，以示例方式编写而成，其主要特点就是实用性和可操作性非常强。
51CTO旗下网站xjsunjie 的BLOG
用户名：xjsunjie
文章数：1008
评论数：2179
访问量：2535160
注册日期：
阅读量：5863
阅读量：12276
阅读量：378575
阅读量：1071200
51CTO推荐博文
某日下午，开发报告说在执行DML操作时，数据库报事务日志已满的错误。db2diag.log数据库日志中的报错信息：-16.43.30. EC502 & &LEVEL: ErrorPID & & : 126660 & & & & & & & TID &: 1 & & & & & PROC : db2agent (SSO) 0INSTANCE: db2inst1 & & & & & & NODE : 000 & & & & DB & : SSOAPPHDL &: 0-1103 & & & & & & & APPID: GA7.FUNCTION: DB2 UDB, data protection, sqlpgResSpace, probe:2860MESSAGE : ADM1823E &The active log is full and is held by application handle
& & & & &"1103". &Terminate this application by COMMIT, ROLLBACK or FORCE
& & & & &APPLICATION.客户端具体信息如下：$db2 delete from tzsdb01DB21034E &该命令被当作 SQL 语句来处理，因为它不是有效的“命令行处理器”命令。在 SQL 处理期间，它返回：SQL0964C &数据库的事务日志已满。 &SQLSTATE=57011这个问题的原因是：表中数据量过大，delete 时，会写入日志，但日志容量过小。解决方法： &增大日志容量、数据量 或 减少一次的删除数据量，分多次删除。生产环境为避免白天停库，提示开发分多次删除，这样就不出错了。但是要彻底解决这个问题，还需申请停库修改数据库参数。我们先看一下，数据库的关于日志的配置参数$ db2 get db cfg for tzsdb01 & & & Database Configuration for Database zssqdb01 Database configuration release level & & & & & & & & & &= 0x0d00 Database release level & & & & & & & & & & & & & & & & &= 0x0d00 Database territory & & & & & & & & & & & & & & & & & & &= cn Database code page & & & & & & & & & & & & & & & & & & &= 1208 Database code set & & & & & & & & & & & & & & & & & & & = UTF-8 Database country/region code & & & & & & & & & & & & & &= 86 Database collating sequence & & & & & & & & & & & & & & = IDENTITY
Multi-page file allocation enabled & & & & & & & & & & &= YES Log retain for recovery status & & & & & & & & & & & & &= RECOVERY User exit for logging status & & & & & & & & & & & & & &= YES Self tuning memory & & & & & & & & & &(SELF_TUNING_MEM) = ON Size of database shared memory (4KB) &(DATABASE_MEMORY) = AUTOMATIC(1662183) Database memory threshold & & & & & & & (DB_MEM_THRESH) = 10 Max storage for lock list (4KB) & & & & & & &(LOCKLIST) = AUTOMATIC(130720) Percent. of lock lists per application & & & (MAXLOCKS) = AUTOMATIC(97) Package cache size (4KB) & & & & & & & & & (PCKCACHESZ) = AUTOMATIC(421273) Sort heap thres for shared sorts (4KB) (SHEAPTHRES_SHR) = AUTOMATIC(46809) Sort list heap (4KB) & & & & & & & & & & & & (SORTHEAP) = AUTOMATIC(9361) Database heap (4KB) & & & & & & & & & & & & & &(DBHEAP) = AUTOMATIC(2626) Catalog cache size (4KB) & & & & & & &(CATALOGCACHE_SZ) = 300 Log buffer size (4KB) & & & & & & & & & & & &(LOGBUFSZ) = 4096Log file size (4KB) & & & & & & & & & & & & (LOGFILSIZ) = 1024 Number of primary log files & & & & & & & &(LOGPRIMARY) = 10 Number of secondary log files & & & & & & & (LOGSECOND) = 4 Changed path to log files & & & & & & & & &(NEWLOGPATH) =
Path to log files & & & & & & & & & & & & & & & & & & & = /home/db2inst1/db2inst1/NODE0000/SQL00001/SQLOGDIR/先看增大日志的容量,注意红色的值为1024$db2 update db cfg for zssqdb01 using logfilsiz 8192 & & & & & 将其增大到8192然后停止应用，停库再启库就生效了$db2 force applications all$db2stop$db2start如果需要增大日志的数据量则需要进行计算和这样设置，这时日志容量已变为8192Log file size (4KB) & & & & & & & & & & & & (LOGFILSIZ) = 8192 Number of primary log files & & & & & & & &(LOGPRIMARY) = 10 Number of secondary log files & & & & & & & (LOGSECOND) = 4现在的日志数据量为计算公式如下：数据库事务日志的数据量大小 = （ LOGPRIMARY + LOGSECOND ）* LOGFILSIZ * 4KB 即：（ 10 + 4）* 8192 * 4KB = 458752 K = 458 M &（大约数）下面断开此数据库的所有连接修改主日志文件个数： & &db2 update db cfg for &dbname& using LOGPRIMARY 15修改辅助日志文件个数：db2 update db cfg for &dbname& using LOGSECOND 10这时的大小=（15+10）*8192*4KB=9M (大约数）然后停库再启库，问题得到解决。注：LOGPRIMARY+LOGSECOND不能超过255，日志空间大小不能超过256G。对于LOGPRIMARY和LOGFILSIZ参数的修改需要断开连接，重连数据库才能生效。LOGSECOND参数的修改则立即生效，对于生产系统比较快的应急解决办法，可以直接先修改此参数。补充知识：1，主日志文件的数目 LOGPRIMARY此数据库配置参数用来指定要预分配的主日志文件个数。主日志文件建立分配给恢复日志文件的固定存储器数量。在循环日志管理模式下，数据库事务将按顺序重复使用主日志，也就是当一个主日志已满时，顺序使用下一个主日志，如果主日志已满，则按需一次分配一个辅助日志，辅助日志在使用完后，将被释放。如果你发现数据库会经常分配辅助日志文件，则可能需要通过增大日志文件大小或增大主日志文件的数目来提高系统性能。 2，辅助日志文件的数目 LOGSECOND此数据库配置参数用来指定按需分配的辅助日志文件个数。尽量不要把此参数的值设置成“ -1 ” ，“ -1 ”代表你在请求一个无限的活动日志空间，数据库也不会报数据库事务日志已满错误，如果空间不足则会报日志磁盘已满错误。 3，日志文件大小 LOGFILSIZ此数据库配置参数用来指定日志文件的大小。 4，数据库事务日志已满错误数据库事务日志已满错误是指当前事务无法写入到活动日志中（此时主日志文件和辅助日志文件已经全部用完或者没有足够当前事务写入的空间），需要注意的是，这个错误和日志磁盘空间已满是两个概念。数据库事务日志已满不是由于磁盘空间满引起的，而是由于没有落实的事务总体过大，超过了数据库事务日志所能容纳的最大大小所造成的。 当出现这样的错误时，不要尝试使用 DB2STOP FORCE 命令来强制停掉数据库，建议大家使用 FORCE APPLICATION 命令停掉引起这个错误的应用程序或者停掉所有的应用程序。也不建议大家使用 KILL 命令来杀掉任何 DB2 相关的进程。如果 使用DB2STOP FORCE命令hang住了，最后再尝试杀掉进程，重新DB2START或重启服务器。本文出自 “” 博客，请务必保留此出处
了这篇文章
类别：┆阅读(0)┆评论(0)DB2数据库事务日志已满问题解决方案
　　本系列文章主要介绍数据库管理员（DBA）在日常维护中遇上一些比较紧急的情况如何处理，本篇主要介绍DB2交易日志存储空间满问题如何处理。
　　1、数据库事务日志的最大大小
　　数据库事务日志的最大大小由数据库的三个配置参数决定，分别是&主日志文件的数目&（LOGPRIMARY）、&辅助日志文件的数目&（LOGSECOND）和&日志文件大小（4KB）&（LOGFILSIZ）。数据库事务日志的最大大小的计算公式如清单 01-32 所示：
　　清单 1. 数据库事务日志的最大大小的计算公式
　　数据库事务日志的最大大小 = （ LOGPRIMARY + LOGSECOND ）* LOGFILSIZ * 4KB
　　LOGSECOND 在这个公式中不能设为 & -1 & ，& -1 &代表你在请求一个无限的活动日志空间，数据库也不会报数据库事务日志已满错误，如果空间不足则会报日志磁盘已满错误，具体如本章第五节所述。下面我们具体看一下这三个参数：
　　1.主日志文件的数目 LOGPRIMARY
　　此数据库配置参数用来指定要预分配的主日志文件个数。主日志文件建立分配给恢复日志文件的固定存储器数量。在循环日志管理模式下，数据库事务将按顺序重复使用主日志，也就是当一个主日志已满时，顺序使用下一个主日志，如果主日志已满，则按需一次分配一个辅助日志，辅助日志在使用完后，将被释放。如果你发现数据库会经常分配辅助日志文件，则可能需要通过增大日志文件大小或增大主日志文件的数目来提高系统性能。
　　2.辅助日志文件的数目 LOGSECOND
　　此数据库配置参数用来指定按需分配的辅助日志文件个数。尽量不要把此参数的值设置成& -1 & ，& -1 &代表你在请求一个无限的活动日志空间，数据库也不会报数据库事务日志已满错误，如果空间不足则会报日志磁盘已满错误。
　　3.日志文件大小 LOGFILSIZ
　　此数据库配置参数用来指定日志文件的大小。
　　2、数据库事务日志已满错误
　　数据库事务日志已满错误是指当前事务无法写入到活动日志中（此时主日志文件和辅助日志文件已经全部用完或者没有足够当前事务写入的空间），需要注意的是，这个错误和日志磁盘空间已满是两个概念，如果想查看日志磁盘已满错误，请参照本章第五节。数据库事务日志已满不是由于磁盘空间满引起的，而是由于没有落实的事务总体过大，超过了数据库事务日志所能容纳的最大大小所造成的。
　　一般系统上线之初（如果是分阶段上线，则是每次上线之初），由于经常要导大量的数据，容易出现这个问题，当出现这个问题时，直接的办法是找到引起这个错误的当前事务，终止掉这个事务即可，后续在操作时找到当前执行的事务中比较大的事务，尽量落实或回滚该事务。
　　一般情况下，建议大家在系统上线之初进行导数时，尽量使用 LOAD 实用程序（如果是归档日志模式，建议使用带 NONRECOVERABLE 选项的 LOAD 实用程序，否则装入完成后数据库或装入的表所在的表空间会被置于备份暂挂状态，需要做一次全备才能解除备份暂挂状态），LOAD 实用程序在装入数据时不记日志。
　　如果使用 IMPORT 实用程序，建议使用 COMMITCOUNT 选项。无论是循环日志模式还是归档日志模式，使用 IMPORT 实用程序导入大量数据时，都有可能报数据库事务日志已满（也就是当前导入操作产生的事务过大，使得当前活动日志满了，包括所有的主日志和辅助日志都用完了），所以为了避免数据库日志已满错误，提高并发性，可以使用 COMMITCOUNT 选项，对要导入的数据分阶段提交。比如可以将 COMMITCOUNT 参数设置为&自动&，指示 import 实用程序 内部决定何时进行落实。此外，也可以将 COMMITCOUNT 选项设置为特定数字，指示 import 实用程序 在导入指定记录数后即进行落实。
　　尽量避免在上线之初直接使用& INSERT INTO & SEL...
分享这篇日志的人也喜欢
热门日志推荐
人人最热标签
分享这篇日志的人常去
北京千橡网景科技发展有限公司：
文网文[号··京公网安备号·甲测资字
文化部监督电子邮箱：wlwh@··
文明办网文明上网举报电话： 举报邮箱：&&&&&&&&&&&&
请输入手机号，完成注册
请输入验证码
密码必须由6-20个字符组成
下载人人客户端
品评校花校草，体验校园广场今天看啥 热点：
本文章来给大家总结一下关于SQL Server 2008 收缩清空大日志文件方，有需要了解SQL中清空大日志文件的同学可进入参考参考。由于SQL2008对文件和日志管理进行了优化，所以在SQL中可以运行的如下命令，但在SQL2008中不支持no_log清空日志。
1.清空日志
DUMP TRANSACTION 库名 WITH NO_LOG
2.截断事务日志：
BACKUP LOG 库名 WITH NO_LOG
SQL 2008收缩清空日志方法：
1.在SQL2008中清除日志就必须在简单模式下进行，等清除动作完毕再调回到完整模式，一定必务要再改回完整模式，不然数据库就不支持时间点备份了。
1).选择数据库&属性&选项&恢复模式&选择简单。
2).收缩数据库后，再调回完整。
2.可以用命令直接操作
-- set the database SIMPLE model.
ALTER DATABASE 数据库库名称 SET RECOVERY SIMPLE; GO
--Shrink the truncated log file to 2M
DBCC SHRINKFILE (日志名称, 2); GO -- Reset the database recovery model. ALTER DATABASE 库名称 SET RECOVERY FULL; GO
在当前数据库下:
select fileid,groupid,name from sysfiles where groupid=0
得到以下结果:
fileid&&&& groupid name
2&&&&&&&&& 0&&&&&&&&&&&&&&& test123_log
其中fileid为日志文件ID，name为日记名称test123_log
在SQL2008中清除日志就必须在简单模式下进行，等清除动作完毕再调回到完全模式。
方案一：完全命令模式
USE[master]
&&& ALTERDATABASE DNName SET RECOVERY SIMPLE WITH NO_WAIT
&&& ALTERDATABASE DNName SET RECOVERY SIMPLE&& --简单模式
&&& USE DNName
&&& DBCC SHRINKFILE (N'DNName_Log' , 11, TRUNCATEONLY)
&&& USE[master]
&&& ALTERDATABASE DNName SET RECOVERY FULLWITH NO_WAIT
&&& ALTERDATABASE DNName SET RECOVERY FULL& --还原为完全模式
方案二：部分命令模式 + 任务-收缩-文件（单个数据库）
ALTERDATABASE DNName SET RECOVERY SIMPLE&& --简单模式
右键-任务-收缩-文件-确定 下来数据库的日志只保留了1M
ALTERDATABASE DNName SET RECOVERY FULL& --还原为完全模式
优点：此清除日志所运行消耗的时间短，90GB的日志在分钟左右即可清除完毕，做完之后做个完全备份在分钟内
即可完成。
相关搜索：
相关阅读：
相关频道：
&&&&&&&&&&&&&&&&&&&&&&&&&&&&
Sql Server最近更新2010年2月 PowerBuilder大版内专家分月排行榜第二2010年1月 PowerBuilder大版内专家分月排行榜第二2010年1月 硬件使用大版内专家分月排行榜第二2009年9月 PowerBuilder大版内专家分月排行榜第二2009年8月 PowerBuilder大版内专家分月排行榜第二2009年2月 PowerBuilder大版内专家分月排行榜第二2009年1月 PowerBuilder大版内专家分月排行榜第二2008年12月 PowerBuilder大版内专家分月排行榜第二2008年11月 PowerBuilder大版内专家分月排行榜第二2008年10月 PowerBuilder大版内专家分月排行榜第二2008年9月 PowerBuilder大版内专家分月排行榜第二2008年8月 PowerBuilder大版内专家分月排行榜第二2008年7月 PowerBuilder大版内专家分月排行榜第二2008年3月 PowerBuilder大版内专家分月排行榜第二2007年12月 PowerBuilder大版内专家分月排行榜第二
2010年3月 PowerBuilder大版内专家分月排行榜第三2009年10月 PowerBuilder大版内专家分月排行榜第三2008年5月 PowerBuilder大版内专家分月排行榜第三2008年2月 PowerBuilder大版内专家分月排行榜第三
本帖子已过去太久远了，不再提供回复功能。