DB2报“数据库日志已满”问题解决
解决DB2数据库“事务日志”已满问题
解决DB2数据库“事务⽇志”已满问题在使⽤DB2进⾏⼤量的update,insert,import的操作时候，事务⽇志可能会⽤光,即⽇志⽂件不够，还有⼀种情况是应⽤程序占⽤了很⼤的事务并且没有提交，造成后续应⽤不能重⽤⽇志，导致⽇志满。
针对上⾯两个问题，给出的解决⽅案如下:1.⽇志⽂件不够总共⽇志⼤⼩为：（ LOGPRIMARY + LOGSECOND ）* LOGFILSIZ * 4KB ，其中4KB为数据页，不同数据库设置的数据页可能不⼀样。
对⼀个表进⾏全表update时候，占⽤的最⼤事务空间约为表⼤⼩的2倍。
这主要是事务⽇志记录了两种⽅式，do和redo。
例如⼀张task表⼤⼩为160M，全表update时候所⽤到的最⼤⽇志空间约为320M。
如果觉得⽇志空间不够，可以⽤ db2 update db cfg for <dbname> using <p> <v>。
例如要更改主⽇志⼤⼩：db2 update db cfg for <dbname> using logprimary 30.2.应⽤程序占⽤很⼤事务⽇志并且没有提交，造成后续操作不能重⽤⽇志。
针对这样相似的问题，我们通常先找到应⽤程序的ID,然后将应⽤程序停掉。
2.1⽤快照⽅式获取应⽤程序使⽤⽇志情况。
例如：(1).打开监控开关:db2 update monitor switches using statement on uow on(2).获取数据库快照:db2 get snapshot for database on <dbname>。
找到快照中⽇志空间使⽤部分：Log space available to the database (Bytes)= 20394939Log space used by the database (Bytes) = 5061Maximum secondary log space used (Bytes) = 0Maximum total log space used (Bytes) = 12255Secondary logs allocated currently = 0Log pages read = 0Log read time (sec.ns) = 0.000000004Log pages written = 6Log write time (sec.ns) = 0.000000004Number write log IOs = 6Number read log IOs = 0Number partial page log IOs = 5Number log buffer full = 0Log data found in buffer = 0Appl id holding the oldest transaction = 136Log to be redone for recovery (Bytes) = 4923Log accounted for by dirty pages (Bytes) = 4923File number of first active log = 0File number of last active log = 2File number of current active log = 0File number of log being archived = Not applicable从快照信息中我们可以看到最后使⽤⽇志的应⽤程序的ID，如上图红⾊部分所⽰，即最后的应⽤程序的ID为136.(3).获取应⽤程序的使⽤⽇志的详细信息。
ORA-00257归档日志写满的解决方法
ORA-00257归档⽇志写满的解决⽅法背景：在前⼀篇博客中我们提到了，在我成功设定数据库为归档模式以后，第⼆天再次尝试连接数据库，报错:ORA-00257。
在⽹上找到了⼀圈资料，有些是说归档⽇志写满，删除归档⽇志。
有些是说闪回⽇志写满，关闭闪回⽇志。
主要参考⽂献有以下：删除归档⽇志⽂件的⽅法：惜分飞⼤⼤的博客：关闭闪回⽇志：⾸先我认为是闪回⽇志写满，但是查了数据库以后发现我并没可有开启闪回⽇志，那么就是归档⽇志⽂件写满的缘故了。
使⽤以下⼏个命令可以看出当前归档⽇志⽂件的使⽤情况：select*from v$recovery_file_dest;select sum(percent_space_used)*3/100from v$flash_recovery_area_usage;select*from v$flash_recovery_area_usage;select*from v$version;归档⽇志⽂件⽬录、最⼤值（已经设定为20G）、当前使⽤值可以看到ARCHIVED LOG的使⽤率是3.84%，这是因为我已经删除掉归档⽇志⽂件了。
在没有删除归档⽇志之前是99.46这样打的数字，表明我们的归档⽇志已经使⽤了⼤部分的空间。
所以进⼊rman程序删除归档⽇志rman target sys/pass@prjdbcrosscheck archivelog all;delete archivelog until time 'sysdate'; --删除所有⽇志delete expired archivelog all;--删除过期⽇志深层分析后来我想这样⼿动删除也不是个办法总得让系统⾃动删除。
后来就做了数据库备份脚本。
执⾏的备份策略如下：1. 每周执⾏增量0的备份，顺便备份归档⽇志，并且删除过期归档⽇志2. 每天执⾏增量1的备份，顺被备份归档⽇志，并且删除过期归档⽇志。
因为我没有设定归档⽇志的有效期，所以⼀档完成增量备份，那么之前的所有归档⽇志都会被删除，相当于只保留⼀天的归档⽇志。
DB2表空间已满
解决方法但由于是双机，所以裸设备需要在hacmp中建，或者建了后两边同步一下，可以找富通和IBM解决。
DB2解决tablespace满的问题1. 连接到数据库，查看一下tablespace的使用情况db2 => list tablespaces show detailTablespaces for Current DatabaseTablespace ID = 0Name = SYSCATSPACEType = System managed spaceContents = Any dataState = 0x0000Detailed explanation:NormalTotal pages = 4814Useable pages = 4814Used pages = 4814Free pages = Not applicableHigh water mark (pages) = Not applicablePage size (bytes) = 4096Extent size (pages) = 32Prefetch size (pages) = 32Number of containers = 1Tablespace ID = 1Name = TEMPSPACE1Type = System managed spaceContents = System Temporary dataState = 0x0000Detailed explanation:NormalTotal pages = 227Useable pages = 227Used pages = 227Free pages = Not applicableHigh water mark (pages) = Not applicablePage size (bytes) = 4096Extent size (pages) = 32Prefetch size (pages) = 32Number of containers = 1Name = USERSPACE1Type = Database managed spaceContents = Any dataState = 0x0000Detailed explanation:NormalTotal pages = 131072Useable pages = 131056Used pages = 12080Free pages = 118976High water mark (pages) = 12432Page size (bytes) = 4096Extent size (pages) = 16Prefetch size (pages) = 16Number of containers = 1Minimum recovery time = 2006-09-25-07.22.30.000000Tablespace ID = 3Name = USERSPACE2Type = Database managed spaceContents = Any dataState = 0x0000Detailed explanation:NormalTotal pages = 65536Useable pages = 65520Used pages = 65520Free pages = 0High water mark (pages) = 65520Page size (bytes) = 16384Extent size (pages) = 16Prefetch size (pages) = 16Number of containers = 1Minimum recovery time = 2006-08-11-02.52.11.000000Tablespace ID = 4Name = TMPSPACE3Type = System managed spaceContents = System Temporary dataState = 0x0000Detailed explanation:NormalTotal pages = 199Used pages = 199Free pages = Not applicableHigh water mark (pages) = Not applicablePage size (bytes) = 16384Extent size (pages) = 32Prefetch size (pages) = 32Number of containers = 1Minimum recovery time = 2005-12-15-11.09.33.000000发现USERSPACE2 Free pages为0了2. 再看一下USERSPACE2使用的containerdb2 => list tablespace containers for 3 show detailTablespace Containers for Tablespace 3Container ID = 0Name = /dev/rdatacdblv2Type = DiskTotal pages = 65536Useable pages = 65520Accessible = Yes只有一个/dev/rdatacdblv23. 查看一下系统中相关的裸设备#>cd /dev#>ls -l *datacdb*brw-rw---- 1 db2admin db2grp1 10, 10 11月11 2004 datacdblv1 brw-rw---- 1 db2admin db2grp1 10, 12 4月05 2006 datacdblv2 crw-rw---- 1 db2admin db2grp1 10, 10 9月30 15时01 rdatacdblv1 crw-rw---- 1 db2admin db2grp1 10, 12 10月09 18时43 rdatacdblv24. 创建一个新的裸设备#>mklv -y'datacdblv3' -t'raw' db2vg 4rootvg是卷组的名称，可以用lsvg查，16是块的数量，要看OS的PPSIZE，相乘就是裸设备的大小5. 看一下新的的设备#>ls -l *datacdb*brw-rw---- 1 db2admin db2grp1 10, 10 11月11 2004 datacdblv1 brw-rw---- 1 db2admin db2grp1 10, 12 4月05 2006 datacdblv2 brw-rw---- 1 root system 10, 18 10月09 19时56 datacdblv3 crw-rw---- 1 db2admin db2grp1 10, 10 9月30 15时01 rdatacdblv1 crw-rw---- 1 db2admin db2grp1 10, 12 10月09 18时43 rdatacdblv2 crw-rw---- 1 root system 10, 18 10月09 19时56 rdatacdblv36. 修改属主#>chown db2admin:db2grp1 *datacdb*7. 再看一下属主是否已经改了#>ls -l *datacdb*brw-rw---- 1 db2admin db2grp1 10, 10 11月11 2004 datacdblv1 brw-rw---- 1 db2admin db2grp1 10, 12 4月05 2006 datacdblv2 brw-rw---- 1 db2admin db2grp1 10, 18 10月09 19时56 datacdblv3 crw-rw---- 1 db2admin db2grp1 10, 10 9月30 15时01 rdatacdblv1 crw-rw---- 1 db2admin db2grp1 10, 12 10月09 18时43 rdatacdblv2 crw-rw---- 1 db2admin db2grp1 10, 18 10月09 19时56 rdatacdblv38. 连接到数据库9. 为tablespace增加containerdb2 => alter tablespace USERSPACE2 add (device'/dev/rdatacdblv3' 32768)10. 最后确认一下是否增加成功了db2 => list tablespaces show detailTablespaces for Current DatabaseTablespace ID = 0Name = SYSCATSPACEType = System managed space Contents = Any dataState = 0x0000Detailed explanation:NormalTotal pages = 4814Useable pages = 4814Used pages = 4814Free pages = Not applicableHigh water mark (pages) = Not applicable Page size (bytes) = 4096Extent size (pages) = 32Prefetch size (pages) = 32Number of containers = 1Tablespace ID = 1Name = TEMPSPACE1Type = System managed space Contents = System Temporary data State = 0x0000Detailed explanation:NormalTotal pages = 227Useable pages = 227Used pages = 227Free pages = Not applicableHigh water mark (pages) = Not applicable Page size (bytes) = 4096Extent size (pages) = 32Prefetch size (pages) = 32Number of containers = 1Tablespace ID = 2Name = USERSPACE1Type = Database managed space Contents = Any dataState = 0x0000Detailed explanation:NormalTotal pages = 131072Useable pages = 131056Used pages = 12080Free pages = 118976High water mark (pages) = 12432Page size (bytes) = 4096Extent size (pages) = 16Prefetch size (pages) = 16Number of containers = 1Minimum recovery time = 2006-09-25-07.22.30.000000Tablespace ID = 3Name = USERSPACE2Type = Database managed spaceContents = Any dataState = 0x10000000Detailed explanation:DMS rebalancer is activeTotal pages = 98304Useable pages = 98272Used pages = 65520Free pages = 0High water mark (pages) = 65520Page size (bytes) = 16384Extent size (pages) = 16Prefetch size (pages) = 16Number of containers = 2Minimum recovery time = 2006-08-11-02.52.11.000000Tablespace ID = 4Name = TMPSPACE3Type = System managed spaceContents = System Temporary dataState = 0x0000Detailed explanation:NormalTotal pages = 199Useable pages = 199Used pages = 199Free pages = Not applicableHigh water mark (pages) = Not applicablePage size (bytes) = 16384Extent size (pages) = 32Prefetch size (pages) = 32Number of containers = 1。
归档日志满、硬盘满、表空间满的空间不够处理方法
归档日志满、硬盘满、表空间满的空间不够处理方法一、归档日志满，清理归档日志方法 (2)二、硬盘存储空间充足，但数据库表空间不足的扩容方法 (3)三、硬盘存储空间不足，对硬盘进行扩容或增加 (4)四、暂不能增加磁盘，但磁盘已满的处理方法 (6)一、归档日志满，清理归档日志方法archive log 日志已满ORA-00257: archiver error. Connect internal only, until freed 错误的处理方法1. 用sys用户登录sqlplus sys/pass@tt as sysdba2. 看看archiv log所在位置SQL> show parameter log_archive_dest;NAME TY PE VALUE------------------------------------ ----------- ------------------------------ log_archive_dest stringlog_archive_dest_1 stringlog_archive_dest_10 string3. 一般VALUE为空时，可以用archive log list;检查一下归档目录和log sequence SQL> archive log list;Database log mode Archive ModeAutomatic archival EnabledArchive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 360Next log sequence to archive 360Current log sequence 3624. 检查flash recovery area的使用情况,可以看见archivelog已经很大了，达到96.62 SQL> select * from V$FLASH_RECOVERY_AREA_USAGE;FILE_TYPE PERCENT_SPACE_USEDPERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES------------ ------------------ ------------------------- --------------- CONTROLFILE .13 0 1ONLINELOG 2.93 0 3ARCHIVELOG 96.62 0 1415. 计算flash recovery area已经占用的空间SQL> select sum(percent_space_used)*3/100 from v$flash_recovery_area_usage;SUM(PERCENT_SPACE_USED)*3/100-----------------------------2.99046. 找到recovery目录, show parameter recoverSQL> show parameter recover;NAME TYPE VALUE--------------------------- ----------- ------------------------------db_recovery_file_dest string /u01/app/oracle/flash_recovery_areadb_recovery_file_dest_size big integer 5Grecovery_parallelism integer 07 上述结果告诉我们，归档位置用的是默认值，放在flash_recovery_area下(db_recovery_file_dest目录=/u01/app/oracle/flash_recovery_area)[*************.0]#echo$ORACLE_BASE/u01/app/oracle [root@sha3 10.2.0]# cd $ORACLE_BASE/flash_recovery_area/tt/archivelog转移或清除对应的归档日志, 删除一些不用的日期目录的文件，注意保留最后几个文件（比如360以后的）8. 登陆rman准备删除归档日志，rman target sys/pass[root@sha3 oracle]# rman target sys/pass9. 检查一些无用的archivelogRMAN> crosscheck archivelog all;10. 删除过期的归档RMAN> delete expired archivelog all;删除7天前的归档：DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7';删除全部归档（noprompt不交互）：DELETE noprompt ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-0';删除从7天前到现在的全部日志：DELETE ARCHIVELOG FROM TIME 'SYSDATE-7';11. 再次查询，发现使用率正常，已经降到23.03SQL> select * from V$FLASH_RECOVERY_AREA7_USAGE;FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES 二、硬盘存储空间充足，但数据库表空间不足的扩容方法表空间使用情况查询：SELECT a.tablespace_name "表空间名",total/1024/1024/1024 || 'G' 表空间大小,free/1024/1024/1024 || 'G' 表空间剩余大小,(total - free)/1024/1024/1024 || 'G' 表空间使用大小,ROUND((total - free) / total, 4) * 100 "使用率 %"FROM (SELECT tablespace_name, SUM(bytes) freeFROM DBA_FREE_SPACEGROUP BY tablespace_name) a,(SELECT tablespace_name, SUM(bytes) totalFROM DBA_DATA_FILESGROUP BY tablespace_name) bWHERE a.tablespace_name = b.tablespace_name扩容语句，执行如下SQL：alter tablespace MSSCPMIS add datafile '/u02/app/oradata/orcl/msscpmis02.dbf' size 5720M alter tablespace MSSCPMIS add datafile '/u02/app/oradata/JSDBA/MSSCPMIS12.dbf' size 30720M alter tablespace MSSCPMIS add datafile '/u02/app/oradata/JSDBA/MSSCPMIS13.dbf' size 30720M alter tablespace MSSCPMIS add datafile '/u02/app/oradata/JSDBA/MSSCPMIS14.dbf' size 30720M alter tablespace MSSCPMIS add datafile '/u02/app/oradata/JSDBA/MSSCPMIS15.dbf' size 30720M 备注：也可以放在不同的硬盘上附录数据文件最大值上限跟数据块大小相关，数据块大小的默认值一般都是8KB。
关于DB2常见性能问题的解决参考
关于DB2常见性能问题的解决参考最近一个项目在做性能测试时，在并发达到一定数后，DB2数据库资源占用很大，必须对数据库和应用进行优化。
该项目要求性能指标（CPU<70%，内存占用<70%，IO<60），按照网友介绍的经验，分别针对CPU、内存、IO进行问题排查和分析。
现将过程总结如下：一、CPU分析通过资源监视器查看一个或多个CPU 的使用率，确定确实存在CPU使用率一直居高不下的情况。
1、首先排除掉存在死循环的情况。
（并发下来后，CPU使用率会降下来）。
2、DB2占用CPU的主要行为有：语句编译、大量排序、DB2实用工具运行。
3、先查看是否有大量的语句编译：通过DB2的表函数MON_GET_WORKLOAD，可以查看到：select varchar(workload_name,30) as workload_name,sum(total_cpu_time),sum(total_compile_proc_time),sum(act_rqsts_total),um(total_compilations),sum(total_act_time), sum(pkg_cache_inserts), sum(pkg_cache_lookups) from TABLE(MON_GET_WORKLOAD('',-2)) as T group by workload_name如果compile_proc_time 高于5-10% 的total_cpu_time，并且pkg_cache_inserts/pkg_cache_lookups 高于4-5%，则数据库在语句编译上花费了太多的时间。
必须调大语句集中器STMT_CONC的大小。
采用逐步调大的方式来跟踪效果。
4、查看是否存在大量的SORT首先通过db2的快照，看是否存在大量的sort溢出✓Sort overflows/Total sorts * 100% 表示排序溢出百分比，通常情况下，该值应该小于3。
DB2报“数据库日志已满”问题解决
DB2报“数据库日志已满”问题解决用控制中心直接改会比较容易一点，在数据库名称上点右键-->配置-->日志-->日志文件大小、主日志文件数、辅助日志文件数改大一点。
也可用命令行db2cmddb2 update db cfg for mymakro using LOGFILSIZ 512 --日志文件大小db2 update db cfg for mymakro using LOGPRIMARY 20 --主日志db2 update db cfg for mymakro using LOGSECOND5 10 --辅助日志要将与此数据库的所有连接断开后才会生效。
执行批处理时,DB2 报数据库的事务日志已满的错误,解决办法辅助日志文件的数目(LOGSECOND) = 25已更改的至日志文件的路径(NEWLOGPATH) =日志文件路径= D:\DB2\NODE0000\SQL00003\SQLOGDIR\溢出日志路径(OVERFLOWLOGPATH) =镜像日志路径(MIRRORLOGPATH) =首个活动日志文件= S0000005.LOG磁盘上已满的块日志(BLK_LOG_DSK_FUL) = NO事务使用的最大活动日志空间的百分比(MAX_LOG) = 01 个活动UOW 的活动日志文件的数目(NUM_LOG_SPAN) = 0组落实计数(MINCOMMIT) = 1软检查点前回收的日志文件的百分比(SOFTMAX) = 100启用的恢复的日志保留(LOGRETAIN) = RECOVERY启用的日志记录的用户出口(USEREXIT) = OFFHADR 数据库角色= STANDARDHADR 本地主机名(HADR_LOCAL_HOST) =HADR 本地服务名称(HADR_LOCAL_SVC) =HADR 远程主机名(HADR_REMOTE_HOST) =HADR 远程服务名称(HADR_REMOTE_SVC) =远程服务器的HADR 实例名(HADR_REMOTE_INST) =HADR 超时值(HADR_TIMEOUT) = 120HADR 日志写同步方式(HADR_SYNCMODE) = NEARSYNC第一个日志归档方法(LOGARCHMETH1) = LOGRETAIN logarchmeth1 的选项(LOGARCHOPT1) =第二个日志归档方法(LOGARCHMETH2) = OFFlogarchmeth2 的选项(LOGARCHOPT2) =故障转移日志归档路径(FAILARCHPATH) =错误时重试日志归档次数(NUMARCHRETRY) = 5日志归档重试延迟（秒）(ARCHRETRYDELAY) = 20供应商选项(VENDOROPT) =启用的自动重新启动(AUTORESTART) = ON索引重新创建时间和重做索引构建(INDEXREC) = SYSTEM (RESTART) 在索引构建期间记录页(LOGINDEXBUILD) = OFFloadrec 会话的缺省数目(DFT_LOADREC_SES) = 1要保留的数据库备份的数目(NUM_DB_BACKUPS) = 12恢复历史保留时间（天数）(REC_HIS_RETENTN) = 366TSM 管理类(TSM_MGMTCLASS) =TSM 节点名(TSM_NODENAME) =TSM 所有者(TSM_OWNER) =TSM 密码(TSM_PASSWORD) =自动维护(AUTO_MAINT) = OFF自动数据库备份(AUTO_DB_BACKUP) = OFF自动表维护(AUTO_TBL_MAINT) = OFF自动runstats (AUTO_RUNSTATS) = OFF自动统计信息概要分析(AUTO_STATS_PROF) = OFF自动概要文件更新(AUTO_PROF_UPD) = OFF自动重组(AUTO_REORG) = OFFdb2 => quitDB20000I QUIT 命令成功完成。
日志空间满（经典诠释）
日志空间满（经典诠释）转载自CUer的几个帖子！***********************************************有两种情况，可能出现这个问题。
一是应用系统给SQL Server发送了一个用户自定义事务，一直未提交，这个最早活跃事务阻碍系统截断日志。
二是客户端向SQL Server发送了一个修改数量大的事务，清日志时，该事务还正在执行之中，此事务所涉及的日志只能等到事务结束后，才能被截掉。
对于第一种情况，只要督促用户退出应用或者提交事务，系统管理员便可清掉日志。
因为给SQL Server发送Dump transaction with no-log或者with truncate-only，它截掉事务日志的非活跃部分。
所谓非活跃部分是指服务器检查点之间的所有已提交或回退的事务。
而从最早的未提交的事务到最近的日志记录之间的事务日志记录被称为活跃的。
从此可以看明，打开的事务能致使日志上涨，因为在最早活跃事务之后的日志不能被截除。
对于第二种情况，道理也同上。
只是在处理它时，需慎重从事。
如果这个大事务已运行较长时间，应尽量想法扩大数据库日志空间，保证该事务正常结束。
若该事务被强行回滚，SQL Server需要做大量的处理工作，往往是正向执行时间的几倍，系统恢复时间长，可能会影响正常使用的时间。
***********************************************如果出现提交了一个大的事务把整个日志库填满了，这时无论你怎么截断日志都是徒劳时，可以有三种办法解决：1.重启数据库（最笨的但最有效的），但肯定会有REDO和UNDO恢复时间长。
2.给数据库日志加空间，但必须有足够的空间。
3.找出执行大事物SESSION的ID，KILL它，但也会回滚，而且不定可以KILL得掉。
***********************************************对于第1个方法，可否直接修改sysdatabases里的status设为-32768,然后再进入数据库dump tran dbname with truncate_only,然后再重启把status设为0。
归档日志满处理过程
ASMCMD> cd archivelog
ASMCMD> ls
2011_10_05/
2011_10_06/
ASMCMD> cd 2011_10_05
ASMCMD> ls -lrt----该命令按时间升序显示文件
ASMCMD>rm filename --filename为要删除的文件名
SQL> alter system setdb_recovery_file_dest_size=4G;
系统已更改。
SQL> show parameter db_recovery_file_dest_size
NAMETYPEVALUE
------------------------------------ ----------- ------------------------------
当数据库运行在归档模式时，如果没有做好备份策略或归档文件和备份文件放到同一个逻辑区，则偶尔会遇到归档日志满导致系统挂起事故。在这样情况下，重启数据库不仅没有用而且将问题更复杂化（记得重启后在HA模式下的共享存储也不见了，进行了手工mount后进行手工删除部分归档日志）。
根据实际环境有不同处理方法，如下是比较通用的处理过程：
2、查看用于归档日志或备份的磁盘空间
在Linux或Unix下可以通过查看空间使用情况：$df -h
如果使用Oracle ASM存储技术，则通过如下命令查看：
$export ORACLE_SID=+ASM1
$asmcmd
ASMCMD> lsdg
3、删除归档日志物理文件，归档日志一般都是位于归档目录下
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
DB2报“数据库日志已满”问题解决
用控制中心直接改会比较容易一点，在数据库名称上点右键-->配置-->日志-->日志文件大小、主日志文件数、辅助日志文件数改大一点。
也可用命令行db2cmd
db2 update db cfg for mymakro using LOGFILSIZ 512 --日志文件大小
db2 update db cfg for mymakro using LOGPRIMARY 20 --主日志
db2 update db cfg for mymakro using LOGSECOND5 10 --辅助日志
要将与此数据库的所有连接断开后才会生效。
执行批处理时,DB2 报数据库的事务日志已满的错误,解决办法
辅助日志文件的数目(LOGSECOND) = 25
已更改的至日志文件的路径(NEWLOGPATH) =
日志文件路径= D:\DB2\NODE0000\SQL00
003\SQLOGDIR\
溢出日志路径(OVERFLOWLOGPATH) =
镜像日志路径(MIRRORLOGPATH) =
首个活动日志文件= S0000005.LOG
磁盘上已满的块日志(BLK_LOG_DSK_FUL) = NO
事务使用的最大活动日志空间的百分比(MAX_LOG) = 0
1 个活动UOW 的活动日志文件的数目(NUM_LOG_SPAN) = 0
组落实计数(MINCOMMIT) = 1
软检查点前回收的日志文件的百分比(SOFTMAX) = 100
启用的恢复的日志保留(LOGRETAIN) = RECOVERY
启用的日志记录的用户出口(USEREXIT) = OFF
HADR 数据库角色= STANDARD
HADR 本地主机名(HADR_LOCAL_HOST) =
HADR 本地服务名称(HADR_LOCAL_SVC) =
HADR 远程主机名(HADR_REMOTE_HOST) =
HADR 远程服务名称(HADR_REMOTE_SVC) =
远程服务器的HADR 实例名(HADR_REMOTE_INST) =
HADR 超时值(HADR_TIMEOUT) = 120
HADR 日志写同步方式(HADR_SYNCMODE) = NEARSYNC
第一个日志归档方法(LOGARCHMETH1) = LOGRETAIN logarchmeth1 的选项(LOGARCHOPT1) =
第二个日志归档方法(LOGARCHMETH2) = OFF
logarchmeth2 的选项(LOGARCHOPT2) =
故障转移日志归档路径(FAILARCHPATH) =
错误时重试日志归档次数(NUMARCHRETRY) = 5
日志归档重试延迟（秒）(ARCHRETRYDELAY) = 20
供应商选项(VENDOROPT) =
启用的自动重新启动(AUTORESTART) = ON
索引重新创建时间和重做索引构建(INDEXREC) = SYSTEM (RESTART) 在索引构建期间记录页(LOGINDEXBUILD) = OFF
loadrec 会话的缺省数目(DFT_LOADREC_SES) = 1
要保留的数据库备份的数目(NUM_DB_BACKUPS) = 12
恢复历史保留时间（天数）(REC_HIS_RETENTN) = 366
TSM 管理类(TSM_MGMTCLASS) =
TSM 节点名(TSM_NODENAME) =
TSM 所有者(TSM_OWNER) =
TSM 密码(TSM_PASSWORD) =
自动维护(AUTO_MAINT) = OFF
自动数据库备份(AUTO_DB_BACKUP) = OFF
自动表维护(AUTO_TBL_MAINT) = OFF
自动runstats (AUTO_RUNSTATS) = OFF
自动统计信息概要分析(AUTO_STATS_PROF) = OFF
自动概要文件更新(AUTO_PROF_UPD) = OFF
自动重组(AUTO_REORG) = OFF
db2 => quit
DB20000I QUIT 命令成功完成。
C:\>db2 connect to testdatabase
数据库连接信息
数据库服务器= DB2/NT 8.2.4
SQL 授权标识= ADMINIST...
本地数据库别名= TESTDATABASE
connect to testdatabase
数据库连接信息
数据库服务器= DB2/NT 8.2.4
SQL 授权标识= ADMINIST...
本地数据库别名= TESTDATABASE
update db cfg for testdatabase using logfilsiz 6000
DB20000I UPDATE DATABASE CONFIGURATION 命令成功完成。
SQL1363W 为立即修改而提交的一个或多个参数未动态更改。
对于这些配置参数，必须在所有应用程序都与此数据库断开连接之后，更改才会生效。
update db cfg for testdatabase using logprimary 4
DB20000I UPDATE DATABASE CONFIGURATION 命令成功完成。
SQL1363W 为立即修改而提交的一个或多个参数未动态更改。
对于这些配置参数，必须在所有应用程序都与此数据库断开连接之后，更改才会生效。
update db cfg for testdatabase using logsecond 25
DB20000I UPDATE DATABASE CONFIGURATION 命令成功完成。
C:\>db2 ? sql964 (根据错误码查看错误解释)
SQL0964C数据库的事务日志已满。
解释:
已使用事务日志中的所有空间。
若使用具有辅助日志文件的循环日志，则尝试分配和使用这些日志。
当文件
系统没有更多空间时，不能使用辅助日志。
若使用归档日志，则文件系统不提供空间来包含新日志文件。
不能处理该语句。
用户响应:
在接收到此消息(SQLCODE) 时，执行COMMIT 或
ROLLBACK，或重试该操作。
若并发应用程序正在更新数据库，则重试该操作。
当另一个应用程序完成事务时，可能释放日志空间。
发出更频繁的落实操作。
若事务还未落实，则当落实事务时，可能会释放日志空间。
设计应用程序时，应考虑何时落实已更新的事务，以防止日志已满的情况。
若发生死锁，则更频繁地检查它们。
这可以通过减小数据库配置参数DLCHKTIME 来实现。
这将检测到死锁，并且很快解决（通过ROLLBACK），这将释放日志空间。
若经常发生这种情况，则增大数据库配置参数以允许更大的日志文件。
更大的日志文件需要更多空间，但是减少了应用程序重试该操作的需要。
若正在安装样本数据库，则删除它并再次安装样本数据库。
sqlcode : -964。