Timesten日志不及时清理的故障处理

昨天一早到公司，有同事就提醒说是装Timesten的服务器的磁盘空间满了，首先看到的是timesten生成了N多core文件，400多M一个，当时下意识就把core文件删掉了，看了一下日志，有很多提示分配空间错误的。 到了中午，那个同事又告诉我空间又不够了，我查了一下core文件，没有core文件，用du查了一下，在timesten的日志目录下，有900多个日 志文件，照理根据配置，timesten10分钟做一次checkpoint，做完后会把相关的日志删掉的啊，有幸在抓虾上看到了下面这篇文章（实在不好 一下，可能是抓虾编辑过了，找不到原出处）

最近碰到一个比较少见的一个问题，就是由于某种原因导致TimesTen的日志无法自动删除，导致在磁盘上有大量的日志累积，磁盘的使用空间有被耗尽的危险。通过仔细排查相关的TimesTen 系统日志等相关信息，并没有发现异常情形。通过ttlogholds命令才发现有一个长的事务因为某种原因一直未提交，从而导致了日志的无法自动删除。解决过程如下：  通过ttlogholds查看相关信息 2.    Command> call ttlogholds; < 41, 231442592, Replication                   , AHOCSRB1:_ORACLE > < 41, 231442592, Replication                   , AHOCSRB2:DATA > < 41, 231442592, Long-Running Transaction      , 138.1089 > < 121, 30922688, Checkpoint                    , DATA.ds0 > < 121, 84106376, Checkpoint                    , DATA.ds1 > 5 rows found. 发现第3行存在一个长的事务（Long-Running Transaction），事务号为138.1089 ，导致了从41号日志之后无法删除。 通过ttxactadmin查看该事务详细情形 4.    ttxactadmin <DSN> Program File Name: ****** 2730    0×6000000000080020  138.1089   Active          Database  0×01312d0001312d00   IX                                                          HashedKey -6667089929831852570 X     ODS30.TB_BIL_ACCT_BALANCE_LIMIT                                                        Row       0×000000001b 8306f 0   Xn    ODS30.TB_BIL_ACCT_BALANCE_LIMIT                                                        Command   6455310528           S    发现在目前的活动事务中确实存在这个事务。 回滚该事务 ttxactadmin -xactIdRollback <xid> <DSN>  通过上述命令回滚该事务。          之后不久当checkpoint被触发后，就可以看到日志被自动清除了。当然也可以手工强制checkpoint( call ttckpt;) 。         从这个问题的表现来看，个人认为应用中出现异常的可能性较大。一种可能性是应用中有个长的事务忘记提交，导致日志一直被Block在那里。

 

于是，我进行了如下操作

1.  通过ttlogholds查看相关信息

Command> call ttlogholds;

发现日志号2被两个xlasample的程序挂着了，估计是同事做测试的时候出现的一些异常。

2.  通过xladeletebookmark查看相关信息

Command> xladeletebookmark;

显示出来这两个xla的相关情况，用这个命令把它们清除掉

3.  通过ttCkpt手工做checkpoint

Command> call ttCkpt;

等做完了，一看日志已经正常了。

 

总结，TimesTen出现日志挂起，不能删除的情况在实际生产环境中是一个很危险的事情，如果出现大量的同步操作，会产生大量的日志，这些日志如果不及时checkpoint清除掉的话，会很快把磁盘空间消耗掉。

由于使用的时间不多，从目前了解到的情况来看，一般都是先用ttlogholds看是什么原因导致日志不能清楚，然后挂起日志的原因进行针对性的处理