TimesTen长事务处理

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/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/22698/viewspace-578459/