5,889
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
zhuxincheng 2006-10-15
- 打赏
- 举报
这种问题跟 循环或增量事务类型无关。
解决它有两种可行方法：
一、扩大LOGBUFF的大小，WINDOWS中默认是1000（pages）*4K大小，可以适当改大。
二、在事务执行中控制，可以设置每满1000笔记录自动COMMIT一次。
解决它有两种可行方法：
一、扩大LOGBUFF的大小，WINDOWS中默认是1000（pages）*4K大小，可以适当改大。
二、在事务执行中控制，可以设置每满1000笔记录自动COMMIT一次。
zhuxincheng 2006-10-15
- 打赏
- 举报
这种问题跟 循环或增量事务类型无关。
解决它有两种可行方法：
一、扩大LOGBUFF的大小，WINDOWS中默认是1000（pages）*4K大小，可以适当改大。
二、在事务执行中控制，可以设置每满1000笔记录自动COMMIT一次。
解决它有两种可行方法：
一、扩大LOGBUFF的大小，WINDOWS中默认是1000（pages）*4K大小，可以适当改大。
二、在事务执行中控制，可以设置每满1000笔记录自动COMMIT一次。
lingyunfeipu 2006-10-11
- 打赏
- 举报
[标题]解决 DB2 日志满问题的一种方法
环境:
产品：DB2 UDB
平台：跨平台
版本：8
问题描述:
DB2 使用的活动日志的最大空间是由下面公式：
(logprimary + logsecond) * logfilsiz * 4096
计算出的大小来决定的（logprimary，logsecond，logfilsiz是数据库配置参数）。若该空
间已全部被分配，而应用仍试图请求更多活动日志空间时，就会发生日志满的情况，此时，
用户的更新、删除或插入操作都会使 DB2DIAG.LOG 中写入以下信息：
SQL0964C 数据库的事务日志已满。
DB2 活动日志满通常是由于存在大量未提交事务的数据，使得活动日志的空间不能及时释放
，使新的事务无法申请到可用日志空间，而最终报出 SQL0964C 的错误所致。为使应用程序
成功运行，而不是被回滚，通常会考虑根据情况选择增大以上公式中的某些数据库参数，以
增大活动日志空间来解决这一问题。
但还有另外一种原因，即在日志空间并未用尽的情况下，当某个占有最旧活动日志的应用长
时间未作提交操作，阻止了日志的 LSN 的分配，造成日志空间无法使用，同样会引发这一日
志满的报错。对于这种情况，可以提交该交易或利用 FORCE 命令来终止此应用程序，以便释
放它所占用的日志空间，使 LSN 可以继续分配，空闲的日志空间可用。这里就提供了由这一
原因导致日志满问题的解决方法。
解答:
首先检查 DB2 诊断日志文件 db2diag.log，在其中查找类似如下信息：
2003-01-16-02.53.54.935308 Instance:db2inst1 Node:016
PID:144252(db2agntp (SAMPLE) 16) Appid:*.*
data_protection sqlpgrsp Probe:50 Database:SAMPLE
Log Full -- active log held by appl. handle 787273
End this application by COMMIT, ROLLBACK or FORCE APPLICATION.
:
:
由此，可以找到最早持有日志空间的应用程序，其句柄为 787273。如果使用 DB2 的快照工
具，通过从快照的输出中查找类似以下信息：
Appl id holding the oldest transaction = 787273
同样可以找到这个应用程序的句柄。这时使用以下命令可以在无需断开数据库其它应用程序
的连接的情况下强行终止该应用程序：
db2 force application (787273)
DB20000I FORCE APPLICATION 命令成功完成。
DB21024I 该命令为异步的，可能不会立即生效。
根据提示，由于该命令是异步操作，可再次使用：
db2 list applications
验证应用是否已被真正停止，如果输出中已没有该应用，它所占有的日志空间会因应用程序
被回滚而立即释放，而 DB2 日志因此重新可用。
环境:
产品：DB2 UDB
平台：跨平台
版本：8
问题描述:
DB2 使用的活动日志的最大空间是由下面公式：
(logprimary + logsecond) * logfilsiz * 4096
计算出的大小来决定的（logprimary，logsecond，logfilsiz是数据库配置参数）。若该空
间已全部被分配，而应用仍试图请求更多活动日志空间时，就会发生日志满的情况，此时，
用户的更新、删除或插入操作都会使 DB2DIAG.LOG 中写入以下信息：
SQL0964C 数据库的事务日志已满。
DB2 活动日志满通常是由于存在大量未提交事务的数据，使得活动日志的空间不能及时释放
，使新的事务无法申请到可用日志空间，而最终报出 SQL0964C 的错误所致。为使应用程序
成功运行，而不是被回滚，通常会考虑根据情况选择增大以上公式中的某些数据库参数，以
增大活动日志空间来解决这一问题。
但还有另外一种原因，即在日志空间并未用尽的情况下，当某个占有最旧活动日志的应用长
时间未作提交操作，阻止了日志的 LSN 的分配，造成日志空间无法使用，同样会引发这一日
志满的报错。对于这种情况，可以提交该交易或利用 FORCE 命令来终止此应用程序，以便释
放它所占用的日志空间，使 LSN 可以继续分配，空闲的日志空间可用。这里就提供了由这一
原因导致日志满问题的解决方法。
解答:
首先检查 DB2 诊断日志文件 db2diag.log，在其中查找类似如下信息：
2003-01-16-02.53.54.935308 Instance:db2inst1 Node:016
PID:144252(db2agntp (SAMPLE) 16) Appid:*.*
data_protection sqlpgrsp Probe:50 Database:SAMPLE
Log Full -- active log held by appl. handle 787273
End this application by COMMIT, ROLLBACK or FORCE APPLICATION.
:
:
由此，可以找到最早持有日志空间的应用程序，其句柄为 787273。如果使用 DB2 的快照工
具，通过从快照的输出中查找类似以下信息：
Appl id holding the oldest transaction = 787273
同样可以找到这个应用程序的句柄。这时使用以下命令可以在无需断开数据库其它应用程序
的连接的情况下强行终止该应用程序：
db2 force application (787273)
DB20000I FORCE APPLICATION 命令成功完成。
DB21024I 该命令为异步的，可能不会立即生效。
根据提示，由于该命令是异步操作，可再次使用：
db2 list applications
验证应用是否已被真正停止，如果输出中已没有该应用，它所占有的日志空间会因应用程序
被回滚而立即释放，而 DB2 日志因此重新可用。
sntang_2008 2006-09-30
- 打赏
- 举报
方法:
1.扩充日志文件大小或个数
2.先停一下数据库,备份日志到其他设备,再删除日志.
1.扩充日志文件大小或个数
2.先停一下数据库,备份日志到其他设备,再删除日志.
wuya8115 2006-09-28
- 打赏
- 举报
清空日志才是唯一的方法，要是只是改日志大小，那要是数据太多，日志太大，那不是还要另外买硬盘了？？？？？？？？？？？？？
亮剑_ 2006-09-25
- 打赏
- 举报
把事务日志改大一些就可以了，相关的有三个参数
LOGFILSIZ
LOGPRIMARY
LOGSECOND
一般改前两个就行了，具体可参见DW文章：
http://www-128.ibm.com/developerworks/cn/db2/library/techarticles/0301kline/0301kline.html
LOGFILSIZ
LOGPRIMARY
LOGSECOND
一般改前两个就行了，具体可参见DW文章：
http://www-128.ibm.com/developerworks/cn/db2/library/techarticles/0301kline/0301kline.html
whoami1618 2006-09-07
- 打赏
- 举报
to jkfree(乌鸦大间谍)
语言描述有歧义，领会精神就行。
语言描述有歧义，领会精神就行。
MasterJ 2006-09-02
- 打赏
- 举报
上面的老兄这样应该是关闭用户出口和日值出口参数吧，不是启用吧！！！
whoami1618 2006-08-31
- 打赏
- 举报
启用的恢复的日志保留 (LOGRETAIN) = OFF
启用的记录的用户出口 (USEREXIT) = OFF
修改LOGRETAIN和USEREXIT会影响到数据库的在线备份和恢复。
启用的记录的用户出口 (USEREXIT) = OFF
修改LOGRETAIN和USEREXIT会影响到数据库的在线备份和恢复。
qiukiller1981 2006-08-29
- 打赏
- 举报
应该是在做大事务处理吧，比如大数据量的DELETE或UPDATE，要是这种情况，建议你最好改变策略，比如，把大数据量的UPDATE改变成“1。把不需要update的记录insert进临时表，2。把要update的记录APPEND到新表里，3。把原表drop掉。4。把临时表RENAME一下。”这样应该可以缓解事务日志的压力
songfrh 2006-08-29
- 打赏
- 举报
写错了
db2 update db cfg using logretain no
db2 update db cfg using logretain no
songfrh 2006-08-29
- 打赏
- 举报
db2 update db cfg using logretain on
conanfans 2006-08-01
- 打赏
- 举报
这种情况通常都 是SQL有错,形成了迪卡尔积
xja 2006-07-31
- 打赏
- 举报
扩充日志文件大小或个数
亮剑_ 2006-07-30
- 打赏
- 举报
是不是在执行大事务或import大量数据时出现提示的，增大数据库堆试一下（dbheap）
mcfiwxl 2006-07-27
- 打赏
- 举报
建议扩大日志大小和个数, 同时需要检查应用中有没有特别大的事务. 如果单个事务产生的日志超过了总的日志大小,会造成该事务无法提交.
Mr_Bean 2006-07-25
- 打赏
- 举报
稍微调整下数据库堆大小看看
你这个应该是循环日至
你这个应该是循环日至
partnersoft 2006-07-25
- 打赏
- 举报
建议最好logsecond上得日志不要用上，不然会影响性能
Ryan76 2006-07-24
- 打赏
- 举报
增大如下的参数：
日志文件大小（4KB） (LOGFILSIZ) = 10000
主日志文件的数目 (LOGPRIMARY) = 12
辅助日志文件的数目 (LOGSECOND) = 20
日志文件大小（4KB） (LOGFILSIZ) = 10000
主日志文件的数目 (LOGPRIMARY) = 12
辅助日志文件的数目 (LOGSECOND) = 20
xiaozhanger 2006-07-24
- 打赏
- 举报
db2的日志记录有两种方式，一个是递增的，我认为一般的应用没有必要用这种方式，
另一个是循环方式的，
另一个是循环方式的，
加载更多回复（3）
