ITPub博客

首页 > Linux操作系统 > Linux操作系统 > TimesTen长事务处理

TimesTen长事务处理

原创 Linux操作系统 作者:mike_salon 时间:2009-03-26 10:56:31 0 删除 编辑

1,大约在早上6点多的时候收到一些网管发出来的告警短信,就连接到现场看了一下,首先看到文件系统空间,发现TimesTen数据文件所在的空间异常
   bdf 命令(HPUX平台)检查发现/tt/DS空间超过了10%,而在正常的情况下该文件系统空间约为8%且没有大的变动,
   /dev/vgtt1/lvttds1 157286400 12186712 136031195    8% /tt/DS

2,登录TimesTen检查使用情况,发现复制器异常且存在长事务
Command> call ttlogholds;
    ID       Seq       Tran-Name                      XID
< 189636, 35832968, Replication                   , KBOCSER2:OCS >   --正常情况下复制器(Replication)的ID和序号应该是最大
< 189636, 35832968, Long-Running Transaction      , 46.18918741 >    --长时间没有释放的事务
< 189642, 63464272, Checkpoint                    , ocs.ds1 >
< 189642, 112075416, Checkpoint                    , ocs.ds0 >
4 rows found.

3,联系相关人员,同时检查TimesTen状态
   ttstatus;          --检查数据库服务状态,服务正常
   ttxactadmin  ocs;     --检查数据库事务状态,发现有锁存在且没有释放

4,检查TimesTen日志
   cd /tmp; cp timestend.log timestend1.log;     --复制TimesTen服务日志
   cat timestend1.log|egrep "Err|Warn"|more      --检查日志,发现有错误和告警,根本原因在于系统执行定时任务的时候对数据库做了批量操作,在此过程中主机做了双机切换,导致SUBS_ACM_DAILY锁表

5,确认锁表的客户端是从mml1接口机过来的,所以回滚了该事务,并且重启了mml1机器上的Jobservices服务
   ttxactadmin -xactIdRollback 46.18918741 ocs   --经过老沈的确认,回滚事务对系统没有影响,只是影响产生该事务的客户端应用,经确定该客户端非在线业务,所以执行了此回滚操作。
   mml1: ocstool stop jobservices; sleep 60; ocstool start jobservices; --重启服务

6,检查TimesTen恢复正常,文件系统空间得到释放,应该是系统定时CheckPoint工作了
Command> call ttlogholds;
< 189645, 85770832, Checkpoint                    , ocs.ds1 >
< 189646, 34548696, Checkpoint                    , ocs.ds0 >
< 189646, 112007344, Replication                   , KBOCSER2:OCS >
3 rows found.
Command> call ckpt;   --如果还没有释放,可以手工执行CheckPoint

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/22698/viewspace-578459/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-12-09

  • 博文量
    10
  • 访问量
    40564