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、删除归档日志物理文件，归档日志一般都是位于归档目录下
DB2故障处理的思路及一般问题的解决办法
DB2故障处理的思路及一般问题的解决办法本文将介绍DB2故障处理的思路及一般问题的解决办法，包括有错误码的问题解决以及按照问题的范围和性质进行分类。
我认为解决问题的关键在于分清问题的种类，并清楚每种问题的解决办法。
另外很多的数据库的问题都是由于错误的操作，错误的配置引起的，所以本文在解释怎么样处理问题时也会给出一些好的建议，来避免产生问题。
本文重点介绍实用的方法。
对问题的分类有很多种方法，在本文中我我采用了两种分类方案。
第一种方案是是否有错误码。
即发生错误时是否同时返回了错误码，错误码既包括执行命令的返回码，也包扩应用程序的返回码。
有返回码的错误解决方案是，在db2 CLP中运行db2 ? SQLXXXX，然后根据对该问题的解释采取相应的解决方案。
对没有错误码的问题，如数据库hang，CPU使用率过高等问题，解决问题的经验将非常重要，在本文中会有详细的说明。
根据错误码解决问题举例（在下文中，再出现需要用这种方法解决问题时将不再重复）：如在连接数据库时发生错误错误码分为返回码（SQL0332N）和原因码（Reason Code "1"），针对不同的原因码有不同的解决方案运行db2 ? sql0332从输出种可以看到对于reason code 1的解释是所以可以通过设置代码页来解决这个问题就可以成功连接了。
第二种分类方案是按照问题的范围和性质进行分类。
分类如下：1．数据库实例问题2．数据库问题3．数据库性能问题4．应用开发与数据库有关的问题下面对每一类问题进行详细说明。
一、数据库实例的问题数据库实例问题可以分为两种情况1．实例无法启动，运行db2start后，直接返回错误码，如SQL1042C。
如果根据错误码信息无法解决，可以尝试如下方案：重新更新该实例，以root身份登录，Tip：常见的产生实例无法启动的原因数据库安装了新的补丁后没有运行db2iupdt数据库文件的权限被改成了777，数据库文件的权限是有要求的，所以不能将所有的文件都改成777的权限数据库实例文件被删除或损坏主机名与db2nodes.cfg里记录的不一致2．运行db2start时，hang在那里，既不报错，也无法启动实例这种情况一般是由于实例没有正常的停止造成的，一般运行下列命令可以解决：(将所有的与该实例有关的db2进程杀死kill -9 )然后重新启动实例。
Db2数据库归档日志很频繁
Db2数据库归档日志频繁解决方法问题现象:数据库dbbde执行命令：Db2 db2stop forceDb2 db2start运行一段时间后发现，归档日志目录中日志增长很快，日志个数很多，但是日志均未写满。
每个日志只有约3M.如图S0224497.LOG-S0*******.LOG查看实际配置Log file size (4KB) (LOGFILSIZ) = 10000Number of primary log files (LOGPRIMARY) = 10Number of secondary log files (LOGSECOND) = 20一个归档日志的大小为：4KB*10000=40M 由配置看归档日志大小正常，则可能是犹豫数据库提交事物过于频繁导致归档频率加快。
解决方法:db2 activate database dbbde归档日志恢复正常。
整理:由activate database命令初始化的数据库可以由deactivate database命令关闭,也可以通过stop database manager(或db2stop)命令关闭。
如果使用activate database命令初始化一个数据库,那么最后一个与数据库断开连接的应用就不会关闭数据库。
由于命令db2stop关闭了数据库实例，重新启动数据库没有进行激活操作activate会导致每一个连接断开后会提交事物并归档，导致了日志归档频率大的问题。
同时，如果在database没有激活之前,就在应用中使用connect to database_name或隐式连接，那么应用就必须要进行等待，直到数据库管理器启动了你要连接的数据库。
一般第一个应用会引发等待数据库管理器执行数据库启动的所有开销。
可以使用activate database database_name这样的命令启动特定的数据库。
这个命令就会免除第一个应用程序连接上来的时候等候数据库初始化所花费的时间。
各数据库空间满处理方法
DB2数据库：1、查看空间大小db2 list tablespaces show detail ，如下图；通过可用页数可以判断空间是否满2、查看数据库文件存放位置Db2 LIST TABLESPACE CONTAINERS FOR 表空间标识SHOW DETAIL 如下图：3、调整空间大小在现有数据文件扩容：alter tablespace datadbs extend(file'/home/db2inst1/db/r_dta_01' 1000M)增加新数据文件：alter tablespace datadbs add (file'/home/db2inst1/db/r_dta_02' 4096M)不指定单位（G,M,K）默认为页4、数据库的日志文件已满查看日志使用情况get db cfg for 数据库名修改日志文件大小：update db cfg for <dbname> using LOGFILSIZ 4096修改主日志文件个数：update db cfg for <dbname> using LOGPRIMARY20修改辅助日志文件个数：update db cfg for <dbname> using LOGSECOND 10将数据库设置为空间自增加ALTER TABLESPACE库名AUTORESIZE YES查看是否为自增加get snapshot for tablespaces onORACLE数据库:1、查看空间大小Select table_name, sum(bytes) ,file_name from dba_data_files group by tablespace_name,查看未用空间大小：select sum(bytes)/(1024*1024) as free_space,tablespace_name from dba_free_space group by tablespace_name;汇总:SELECT A.TABLESPACE_NAME,A.BYTES TOTAL,B.BYTES USED,C.BYTES FREE,(B.BYTES*100)/A.BYTES "% USED",(C.BYTES*100)/A.BYTES "% FREE" FROMSYS.SM$TS_A V AIL A,SYS.SM$TS_USED B,SYS.SM$TS_FREE C WHERE A.TABLESPACE_NAME=B.TABLESPACE_NAME ANDA.TABLESPACE_NAME=C.TABLESPACE_NAME;2、调整空间大小增加新数据文件并自增长：alter tablespace 库名add datafile '/home/oracle/data_02.dbf' size 200m autoextend on next 10m maxsize 500m/unlimeted;在现有数据文件扩容：alter database datafile '/opt/oracle/ora_tbs/xwj_datafile01.dbf ' resize 200m;日志已满的处理方法ORA-00257: archiver error. Connect internal only, until freed archive log1. 用sys用户登录sqlplus sys/oracle@ora10g as sysdba2. 看看archiv log所在位置SQL> show parameter log_archive_dest;NAME TYPE V ALUE------------------------------------ ----------- ------------------------------log_archive_dest stringlog_archive_dest_1 stringlog_archive_dest_10 string3. 一般V ALUE为空时，可以用archive log list;检查一下归档目录和log sequenceSQL> archive log list;Database log mode Archive ModeAutomatic archival EnabledArchive destination USE_DB_RECOVERY_FILE_DESTOldest online log sequence 360Next log sequence to archive 360Current log sequence 3624. 检查flash recovery area的使用情况,可以看见archivelog已经很大了，达到96.62SQL> select * from V$FLASH_RECOVERY_AREA_USAGE;FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES------------ ------------------ ------------------------- ---------------CONTROLFILE .13 0 1 ONLINELOG 2.93 0 3 ARCHIVELOG 96.62 0 141 BACKUPPIECE 0 0 0 IMAGECOPY0 0 0 FLASHBACKLOG 0 0 05. 计算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 V ALUE------------------------------------ ----------- ------------------------------db_recovery_file_dest string /u01/app/oracle/flas h_recovery_area db_recovery_file_dest_size big integer 5Grecovery_parallelism integer 07 上述结果告诉我们，归档位置用的是默认值，放在flash_recovery_area下(db_recovery_file_dest目录=/u01/app/oracle/flash_recovery_area)[root@sha3 10.2.0]# echo $ORACLE_BASE/u01/app/oracle[root@sha3 10.2.0]# cd $ORACLE_BASE/flash_recovery_area/ora10g/archivelog转移或清除对应的归档日志, 删除一些不用的日期目录的文件，注意保留最后几个文件（比如360以后的）---------------------------------------------------------------------------------------注意:在删除归档日志后，必须用RMAN维护控制文件，否则空间显示仍然不释放。
sql数据库日志已满的处理方式
DBCC SHRINKDATABASE收缩指定数据库中的数据文件大小。
语法DBCC SHRINKDATABASE（database_name ［, target_percent ][ ，｛NOTRUNCATE ｜TRUNCATEONLY ｝］)参数database_name是要收缩的数据库名称.数据库名称必须符合标识符的规则。
有关更多信息，请参见使用标识符。
target_percent是数据库收缩后的数据库文件中所要的剩余可用空间百分比.NOTRUNCATE导致在数据库文件中保留所释放的文件空间。
如果未指定，将所释放的文件空间释放给操作系统。
TRUNCATEONLY导致将数据文件中的任何未使用的空间释放给操作系统，并将文件收缩到上一次所分配的大小，从而减少文件大小,而不移动任何数据.不试图重新定位未分配页的行。
使用TRUNCATEONLY 时,忽略target_percentis。
注释Microsoft® SQL Server™可收缩:特定数据库的所有数据和日志文件。
执行DBCC SHRINKDATABASE。
一次一个特定数据库中的数据或日志文件.执行DBCC SHRINKFILE.DBCC SHRINKDATABASE 以每个文件为单位对数据文件进行收缩。
然而,DBCC SHRINKDATABASE 在对日志文件进行收缩时，看起来好像所有的日志文件都存在于一个连续的日志池中.假设名为mydb 的数据库有两个数据文件和两个日志文件。
这些数据文件和日志文件大小都为10 MB。
第一个数据文件包含6 MB 数据。
对于每个文件，SQL Server 计算目标大小，即要收缩文件到的大小.当用target_percent 指定DBCC SHRINKDATABASE 时，SQL Server 计算的目标大小是收缩后文件中的target_percent 可用空间大小.例如，如果指定按target_percent 为25 收缩mydb。
DB2事务日志使用详解
DB2事务日志使用详解摘要：我们经常接到客户的电话说数据库日志满了，需要快速清除。
对于一些初入门的DB2使用者去维护一个大数据量的系统，这几乎是他们必然会碰到的一个问题。
碰到这样的问题，我们可以不厌其烦的一遍遍向客户解释这个问题的原因，也可以给出非常明确的解决方案，但是对于很多客户看来，这似乎是一个比较无奈的解决方案，他们只能承担着这种操作带来的系统中断。
因此，对于数据库的设计人员，开发人员和维护人员来讲，非常清楚的了解数据库的日志原理与合理的规划一些操作以避免发生这样的情况是非常重要的！下面，我们就对数据库的日志原理和使用..我们经常接到客户的电话，我的数据库日志满了，有没有什么好办法快速清除?尤其对于一些初入门的DB2使用者去维护一个大数据量的系统，这几乎是他们必然会碰到的一个问题。
我们也经常接到客户更紧急的电话，我的数据库不能使用了，因为日志占用太多空间，文件系统满了，就把日志删除了，现在数据库无法使用，这个是生产系统，需要尽快恢复，有什么办法可以让数据库立刻使用?碰到这样的问题，我们可以不厌其烦的一遍遍向客户解释这个问题的原因，也可以给出非常明确的解决方案，但是对于很多客户看来，这似乎是一个比较无奈的解决方案，他们只能承担着这种操作带来的系统中断。
因此，对于数据库的设计人员，开发人员和维护人员来讲，非常清楚的了解数据库的日志原理与合理的规划一些操作以避免发生这样的情况是非常重要的！下面，我们就对数据库的日志原理和使用中经常遇到的问题以及其解决方法跟大家分享下。
1、DB2数据库的日志原理事务日志记录数据库中所有对象和数据的改变，在早前版本中最大可达256G，其大小为( logprimary + logsecond ) * logfilsiz，其中logprimary + logsecond的值小于或等于256，logfilsiz的最大为262144，在9.5版本中，日志最大已经可以达到512G，其中logfilsz的大小更改为524286。
事务日志已满的解决方法
1.清空日志 DUMP TRANSACTION 库名 WITH NO_LOG2.截断事务日志： BACKUP LOG 库名 WITH NO_LOG 3.收缩数据库文件(如果不压缩,数据库的文件不会减小企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩文件 --选择日志文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了 --选择数据文件--在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了也可以用SQL语句来完成 --收缩数据库 DBCC SHRINKDATABASE(库名) --收缩指定数据文件,1是文件号,可以通过这个语句查询到:select * from sysfiles DBCC SHRINKFILE(1) 4.为了最大化的缩小日志文件(如果是sql 7.0,这步只能在查询分析器中进行) a.分离数据库: 企业管理器--服务器--数据库--右键--分离数据库 b.在我的电脑中删除LOG文件 c.附加数据库: 企业管理器--服务器--数据库--右键--附加数据库此法将生成新的LOG，大小只有500多K 或用代码：下面的示例分离 pubs，然后将 pubs 中的一个文件附加到当前服务器。
a.分离 EXEC sp_detach_db @dbname = '库名' b.删除日志文件 c.再附加 EXEC sp_attach_single_file_db @dbname = '库名', @physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\库名.mdf' 5.为了以后能自动收缩,做如下设置: 企业管理器--服务器--右键数据库--属性--选项--选择"自动收缩" --SQL语句设置方式: EX EC sp_dboption '库名', 'autoshrink', 'TRUE' 6.如果想以后不让它日志增长得太大企业管理器--服务器--右键数据库--属性--事务日志 --将文件增长限制为xM(x是你允许的最大数据文件大小) --SQL语句的设置方式: alter database 库名 modify file(name=逻辑文件名,maxsize=20) ------------------------------------------------------2MSSQL2005日志的收缩１.右键在清除日志的数据库，如“TestDB”，点击[新建查询（Q）]２.输入以下SQL语句，其中“TestDB”是数据库名称DUMP TRANSACTION TestDB WITH NO_LOG３.执行该SQL，成功后继续以下操作４.右键该数据库节点，点击[任务（T）] -> [收缩（S）] -> [文件（F）]５.在弹出的“收缩文件”对话框中，将“文件类型（T）”选为“日志”，将“收缩操作”选中“在释放未使用的空间前重新组织页（O）”６.在“将文件收缩到（K）”文本框中输入后面提示的最小大小的数值，点击[确定]即可。
sybase数据库tempdb日志滿了
sybase数据库tempdb日志滿了开发数据库服务器遇到这样的一个问题，使用了一段时间之的后，突然之间数据库就用不了了，现象是新连接连接不上，已经连接的执行sql时，报出tempdb日志满了，无法进行操作的错误，而且控制台无法连接上服务器，所有操作都无法正常进行。
经过上网查询，得知是tempdb日志满了，缺省情况下，tempdb数据库是放置在master设备上，容量为2M，而临时数据库是活动最为平凡的数据库常常被用来排序、创建临时表、重格式化等操作，所以tempdb的优化应该受到特别的关注。
安装Sybase的时候就应该把tempdb的空间扩大，并且最好新建一个表空间给它专门用。
正常的时候可以用sp_helpdb tempdb命令查看tempdb，可以看到tempdb占用空间的情况。
如果日志满了，可以执行dump tran tempdb with truncate_only或者dump tran tempdb with no_log来清除日志，但是现在根本无法执行该语句，因为tempdb已经满了，根本没有空间来执行该语句，这该怎么办，好像进入了一个死循环里，日志满了要清除，但因为满了又无法清除，看来只能先扩容了，现在已经没有一个空闲的表空间了，控制台根本无法连接上数据库，只能用语句来新建一个表空间，下面是新建表空间的语句：disk initname="tempdblog",physname="c:/sybasedb/tempdblog.dat",vdevno=11,size= 409600go新建好表空间后，将该空间分配给tempdb存放日志用如下命令：alter database tempdb log on tempdblog=800如果要分配数据空间，用如下命令：alter database tempdb on tempdbdata=1024分配好后，就可以执行之前的清除日志的语句：dump tran tempdb with truncate_only或者 dump tran tempdb with no_log如果不想占用master的空间，可以执行如下语句将master上为tempdb的空间删除：sp_dropsegment "default",tempdb,mastersp_dropsegment logsegment,tempdb,master还可以将临时数据库与高速缓冲进行绑定tempdb数据库是活动最为平凡的数据库，常常被用来排序、创建临时表、重格式化等操作，它会频繁地使用数据缓存，所以应为临时数据库创建高速缓存，从而可以使其常驻内存并有助于分散I/O，根据服务器的实际情况，我们为tempdb数据库创建100M的高速缓存，实现方法如下：1、创建命名高速缓存sp_cacheconfig “tempdb_cache”,”100m”,”mixed”go2、重新启动server3、捆绑临时数据库到tempdb_cache高速缓存sp_bindcache “tempdb_cache”, tempdbgo以上操作已在系统中实现，硬件环境为IBMX系列服务器，操作系统为sco unix 5.0.6，系统优化后，性能得到较为明显的提高。
DB2崩溃后用事务日志恢复的原理和技巧
DB2崩溃后用事务日志恢复的原理和技巧DB2崩溃后用事务日志恢复的原理和技巧（1）在系统崩溃之后，使用DB2的事务日志恢复数据库。
您曾多少次碰到过错误消息“SQL0946C The transaction log for the database is full?”在尽力解决该问题时，您是否停下来思考如下两个问题：1. 为何存在事务日志；2. 事务日志记录服务的目的是什么呢？若没有事务，多个用户和应用程序同时与一个数据库进行交互时就必然会破坏数据。
而假如没有事务日志记录，DB2 UDB中的一些据库恢复方法就不会存在。
假如您还没有完全理解这些概念，也不必担忧。
我将解释事务是什么以及事务日志记录背后的机制。
然后，我将展示在系统崩溃或程序故障之后，如何使用数据库事务日志文件中所存储的信息来使数据库回归到一致、可用的状态。
您还可以通过这些重要的日志做更多事情。
在今后的专栏中，我将展示如何使用事务日志文件重现操作，以将数据库恰好恢复到给定时间点所处的状态。
事务事务（也称作工作单元）是指一个或多个SQL操作的序列，这些操作组合成一个单元且通常位于一个应用程序进程内。
该单元通常称作是“原子的”，因为它是不可分的——它的所有工作要么全都执行，要么全都不执行。
一个给定的事务可以执行任何数目的SQL操作（从一个到几千个，取决于业务逻辑里对于“一步”的定义）。
一个事务的开始和终止定义了数据库里数据一致性的点；要么将事务里所执行的所有操作的结果应用到数据库上，并使之成为永久的（已提交），要么将之都撤销（回滚），使数据库返回到启动该事务之前的状态。
事务是在建立到数据库的连接之后第一次执行SQL语句时或在现有事务终止时立即启动。
一旦启动，就可以使用名为原子提交的功能隐式地终止该事务。
通过原子提交，会将每条可执行的SQL语句当作一个事务。
假如该语句执行成功，那它所做的任何修改都将应用到数据库上，但假如语句失败，那修改将被丢弃。
- 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。