如何查看db2的数据库的日志文件

在日常DB2的维护中，transaction log full是比较常见的问题，日志空间使用情况也是我们比较重视的问题，那么如何查看日志空间使用情况呢？

其实昨天在提到归档设置，我们知道DB2 在DATABASE级别有几个参数，如下决定了事物日志的使用空间大小

Log file size (4KB)(LOGFILSIZ) = 60000

Number of primary log files(LOGPRIMARY) = 16

Number of secondary log files (LOGSECOND) = 200

Changed path to log files (NEWLOGPATH) =

Path to log files = /db2inst1_log01/sample

如此我们可以计算分配给日志的空间大约是（200+16)*60000*4/1024/1024大约50GB。

如果日志是单独的文件系统分区，我们在 *** 作系统上即可看到日志空间使用情况，对日志使用情况进行监控，可以看到如下信息：

$ df -g

Filesystem GB blocks Free %UsedIused %Iused Mounted on

/dev/db2inst1_log0160.0054.50 10%14581% /db2inst1_log01

这个需要登录到系统，其实db2pd也是可以看到日志信息的

db2pd -d sample -logs

Database Partition 0 -- Database SAMPLE -- Active -- Up 34 days 17:30:12 -- Date 2013-11-26-10.42.49.558342

Logs:

Current Log Number117123

Pages Written33697

Cur Commit Disk Log Reads0

Cur Commit Total Log Reads0

Method 1 Archive Status Success

Method 1 Next Log to Archive 117123

Method 1 First Failuren/a

Method 2 Archive Status n/a

Method 2 Next Log to Archive n/a

Method 2 First Failuren/a

Log Chain ID 2

Current LSN 0x00001A2DDE649E70

AddressStartLSNState Size Pages Filename

0x0700000177B795D0 00001A2CBFD88010 0x00000000 60000 60000 S0117104.LOG

0x0700000177B806D0 00001A2CCE7E8010 0x00000000 60000 60000 S0117105.LOG

0x0700000177B8B450 00001A2CDD248010 0x00000000 60000 60000 S0117106.LOG

0x0700000177B82EF0 00001A2CEBCA8010 0x00000000 60000 60000 S0117107.LOG

0x0700000177B9ECD0 00001A2CFA708010 0x00000000 60000 60000 S0117108.LOG

0x0700000177BA27D0 00001A2D09168010 0x00000000 60000 60000 S0117109.LOG

0x0700000177B79E30 00001A2D17BC8010 0x00000000 60000 60000 S0117110.LOG

0x0700000177BAAD50 00001A2D26628010 0x00000000 60000 60000 S0117111.LOG

0x0700000177B9FFD0 00001A2D35088010 0x00000000 60000 60000 S0117112.LOG

0x0700000177BB44D0 00001A2D43AE8010 0x00000000 60000 60000 S0117113.LOG

0x0700000177BD45D0 00001A2D52548010 0x00000000 60000 60000 S0117114.LOG

0x0700000177B7F0D0 00001A2D60FA8010 0x00000000 60000 60000 S0117115.LOG

0x0700000177B9C850 00001A2D6FA08010 0x00000000 60000 60000 S0117116.LOG

0x0700000177B84750 00001A2D7E468010 0x00000000 60000 60000 S0117117.LOG

0x0700000177B877D0 00001A2D8CEC8010 0x00000000 60000 60000 S0117118.LOG

0x0700000177B857D0 00001A2D9B928010 0x00000000 60000 60000 S0117119.LOG

0x0700000177B7DC50 00001A2DAA388010 0x00000000 60000 60000 S0117120.LOG

0x0700000177B83750 00001A2DB8DE8010 0x00000000 60000 60000 S0117121.LOG

0x0700000177B907B0 00001A2DC7848010 0x00000000 60000 60000 S0117122.LOG

0x0700000177B91010 00001A2DD62A8010 0x00000000 60000 60000 S0117123.LOG

0x0700000177B9A150 00001A2DE4D08010 0x00000000 60000 60000 S0117124.LOG

不过之只能看到当前使用日志和日志文件对应的LSN信息和归档情况，对于使用率还真不能看到。

另外还可以在实例快照中看到，不过在此不示例了。

但是上面我们需要登录到 *** 作系统上，如何在远端通过SQL查询呢，其实DB2还是提供了蛮多的方法。

a.通过管理视图查询：

select DB_NAME, LOG_UTILIZATION_PERCENT, TOTAL_LOG_USED_KB,TOTAL_LOG_AVAILABLE_KB,TOTAL_LOG_USED_TOP_KB, DBPARTITIONNUM from SYSIBMADM.LOG_UTILIZATION

DB_NAMELOG_UTILIZATION_PERCENT TOTAL_LOG_USED_KBTOTAL_LOG_AVAILABLE_KB TOTAL_LOG_USED_TOP_KB DBPARTITIONNUM

-------------------------------------------------------------------------------------------------------------------------------- ----------------------- -------------------- ---------------------- --------------------- --------------

DSS8.97 4631824 46955050 16655013 0

非常清楚一目了然吧，对于监控事物日志使用情况，及早发现事务日志空间满问题很有帮助。

b.还有一种方法，就是查看快照视图：

select int(total_log_used/1024/1024) as "Log Used (Mb)",int(total_log_available/1024/1024) as "Log Space Free(Mb)",

int((float(total_log_used)/float(total_log_used+total_log_available))*100) as "Pct Used",int(tot_log_used_top/1024/1024) as "Max Log Used (Mb)",

int(sec_log_used_top/1024/1024) as "Max Sec. Used (Mb)",int(sec_logs_allocated) as "Secondaries" from sysibmadm.snapdb

Log Used (Mb) Log Space Free(Mb) Pct UsedMax Log Used (Mb) Max Sec. Used (Mb) Secondaries

------------- ------------------ ----------- ----------------- ------------------ -----------

4544 45833 916264 12532 5

1 record(s) selected.

其实还有一种通过表函数的方法，不过需要带入参数：

select DB_NAME,TOTAL_LOG_AVAILABLE,TOTAL_LOG_USED,SEC_LOG_USED_TOP,SEC_LOGS_ALLOCATED from table(SNAP_GET_DB('SAMPLE',0))

DB_NAME TOTAL_LOG_AVAILABLE TOTAL_LOG_USED SEC_LOG_USED_TOPSEC_LOGS_ALLOCATED

-------------------------------------------------------------------------------------------------------------------------------- -------------------- -------------------- -------------------- --------------------

SAMPLE 48045192251 4779767749 131417734175

1 record(s) selected

看吧，DB2查看日志空间的方法真的很多，不能不说提供了强大的用户接口，就看大家怎么用了。

转载仅供参考，版权属于原作者。祝你愉快，满意请采纳哦

具体空间大小时如何计算出来的，我觉得不是IBM内部人员，又不是要去Debug DB2的源程序，未必需要深究。

我了解的是DB2 UDB V8.2，现在没什么机会使用DB2了，也不好随便说。只能大致说下以前了解到的一些内容供你参考。

假设在某一个时刻，其他事务都已经提交，从这个时刻起有一个DB2的进程A开始一个事务T1，DB2实例就会记住这个进程的APPL HANDL，就是进程的句柄，上面db2bp都有显示的，只要进程A一直没有将它的事务提交，数据库实例服务就会一直保持着进程A的句柄，这个值在抓取DB快照有专门的一个指标：APP ID HOLDING THE OLDEST TRANSACTION。只要事务T1一直没有提交，就会导致随后其他进程所开始的事务都会占用住实例的活动日志文件，即使日志文件的空间被全部占满了，也不能正常的日志文件归档到DB参数指定的归档日志路径。当DB参数配置的所有活动日志空间，即：（LOGPRIMARY +LOGSECOND ）* LOGFILSIZ 都全部被占满，数据库就会报出：SQL0964C The transaction log for the database is full，这样的一个错误提示。之后整个数据库的所有数据变更 *** 作都会无法继续进行，理论上查询的语句不会受到影响，可以正常返回结果。

如果遇到这样的问题，最好的解决方法，不是直接中断所有的进程，只要

db2 get snapshot for db on DBNAME

找出APP ID HOLDING THE OLDEST TRANSACTION对应的那个进程的句柄

之后再用

db2 force application agentdi APPLID

这样最多只是中断一个进程，将一直没有提交的事务回滚，所有活动日志文件都能顺利归档，并成功释放。

扩展的说，对于一个繁忙的OLTP数据库日常监控，可以用SNAPSHOT_DATABASE这个监控表函数，监控APPL_ID_OLDEST_XACT是否在很长的一段时间（例如两个小时）都是同一个ID，而且TOTAL_LOG_USED在不断增大，TOTAL_LOG_AVAILABLE在持续的减少，这样就可能是应用程序出现问题长时间未能提交事务，或者程序有BUG，没有正确提交结束事务了。

---