今天查看gg的error log发现一直警告有长事务在执行,具体信息如下:
2012-04-20 14:40:52 WARNING OGG-01027 Oracle GoldenGate Capture for Oracle, extksr1.prm: Long Running Transaction: XID 747.6.1036520, Items 353, Extract EXTKSR1, Redo Thread 3, SCN 17.4265175431 (77279619463), Redo Seq #16378, Redo RBA 12319760.
2012-04-20 14:44:10 INFO OGG-00538 Oracle GoldenGate Capture for Oracle, extksr1.prm: Metadata not invalidated for [MYNET_APP.M_GOODS_STOCK2] because of TRUNCATE.
2012-04-20 14:44:10 INFO OGG-01487 Oracle GoldenGate Capture for Oracle, extksr1.prm: DDL found, operation [truncate table m_goods_stock2 (size 30)], start SCN [77315214174], commit SCN [77315214348] instance [yesmynet1 (1)], DDL seqno [1238], marker seqno [1238].
2012-04-20 14:44:10 INFO OGG-00487 Oracle GoldenGate Capture for Oracle, extksr1.prm: DDL operation included [INCLUDE MAPPED], optype [TRUNCATE], objtype [TABLE], objowner [MYNET_APP], objname [M_GOODS_STOCK2].
2012-04-20 14:44:10 INFO OGG-00497 Oracle GoldenGate Capture for Oracle, extksr1.prm: Writing DDL operation to extract trail file.
2012-04-20 14:45:52 WARNING OGG-01027 Oracle GoldenGate Capture for Oracle, extksr1.prm: Long Running Transaction: XID 747.6.1036520, Items 353, Extract EXTKSR1, Redo Thread 3, SCN 17.4265175431 (77279619463), Redo Seq #16378, Redo RBA 12319760.
登陆到gg命令行界面查看详细信息如下:
GGSCI (rac3) 12> send extract extksr1,showtrans thread 3
Sending showtrans request to EXTRACT EXTKSR1 ...
Oldest redo log files necessary to restart Extract are:
Redo Thread 1, Redo Log Sequence Number 29263, SCN 18.5141377 (77314552705), RBA 23003664
Redo Thread 2, Redo Log Sequence Number 27746, SCN 18.5141481 (77314552809), RBA 3775504
Redo Thread 3, Redo Log Sequence Number 16378, SCN 17.4265175431 (77279619463), RBA 12319760
------------------------------------------------------------
XID: 747.6.1036520
Items: 353
Extract: EXTKSR1
Redo Thread: 3
Start Time: 2012-04-19:04:16:49
SCN: 17.4265175431 (77279619463)
Redo Seq: 16378
Redo RBA: 12319760
Status: Running
通过xid在数据库里可以查看到对应的语句如下:
SYS@ yesmynet3 >col sql_fulltext for a200
SYS@ yesmynet3 >select addr from v$transaction where XIDUSN||XIDSLOT||XIDSQN=74761036520;
ADDR
----------------
0000000516EF0EC0
SYS@ yesmynet3 >select prev_sql_id from v$session where taddr in ('0000000516EF0EC0');
PREV_SQL_ID
-------------
08kc5bgraw6jn
SYS@ yesmynet3 >select sql_fulltext from v$sql where sql_id in ('08kc5bgraw6jn');
SQL_FULLTEXT
---------------------------------------------------------------------------------------------------------------------------------------
update m_edm_result set cancel_flag=:1, content=:2, email=:3, fail_reason=:4, member_id=:5, order_id=:6, plan_send_time=:7, result=:8, send_count=:9, send_time=:10, sender_email=:11, subject=:12, submit_time=:13, template_path=:14, version=:15 where id=:16 and version=:17
由于这条语句从昨天凌晨4点多就开始执行了,所以在v$session里面查出来的sql_id可能已经没有了,我这里就是匹配之前执行的sql_id。
由于该语句是在节点3上执行的,联系相关人员,发现这条语句的相关java代码条件有问题,待修改完毕,再观察观察吧。
另:由于该语句是在源库的gg error log里出现的警告,如果想让gg跳过该语句不执行的话,执行如下命令:
GGSCI (rac3) 14> SEND EXTRACT EXTKSR1, SKIPTRANS <747.6.1036520> THREAD 3
执行如下命令,强制认为该事务已经提交 :
GGSCI (rac3) 14> SEND EXTRACT EXTKSR1, FORCETRANS <747.6.1036520> THREAD 3
不过还是建议在数据库里对该事务进行提交或者回滚操作,最好别让gg来处理!
我这里的实际情况,还等开发修改完代码,再行决定。
记录一下~
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/25618347/viewspace-721809/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/25618347/viewspace-721809/