OGG故障处理事记

IT那活儿 2021-07-15

712

一. 故障背景

记一次出账期间，日常稳定的OGG突然出现告警异常抽取进程异常，无法自动拉起，有历史的长事务无法解决。

二. 分析过程

查看异常进程日志view report name 可知，无法找到序列号89241的归档日志，看到这个，首要想的就是直接查看数据库的归档应用情况，以及现有保留的归档序列号，发现已经被删除，ADG没有同步到，自然到主库上找到，然后传输，注册再重新应用就OK。

但事情远远没有想象中处理的那么顺利，应用完归档后，重启抽取进程，启动后异常无法停止，只能强制停止了send name,forcestop

和原厂工程师确定，只要长事务中不涉及到抽取表的操作，可以在OGG端提交该事物或跳过该事物，根据日志中的Long Running Transaction: XID 1253.22.58349755 在源端数据库中确定SQLID

在此贴上SQL方便需要的兄弟续使用

▼▼▼
set lines 300 pages 1000col program for a30col SCHEMANAME for a10col machine for a35col progran for a45select s.inst_id,t.ADDR,t.start_time,s.sid,s.serial#,nvl(s.sql_id,s.prev_sql_id) sql_id,s.machine,s.program,s.schemaname,s.statusfrom gv$transaction t,gv$session swhere t.addr=s.taddr and t.INST_ID=s.INST_IDand t.xidusn in (1253) and t.xidslot in (22) and xidsqn in (58349755);

跳过之后重启，恢复正常，但恢复一段时间，发现队列文件没有增长，而且应用序列号也没有变换，stats统计信息也是原地不动，尝试多次重启，生成了多个队列文件但仍然没有增长，不明所以。

查询资料发现是存在需要恢复的长事务，这种情况需要看showtrans

info name,showch

根据Recovery checkpoint找到事务ID，是一个月前的长事务，跟踪sql信息后，发现是可以跳过的。send extract name,skiptrans 1079.8.71844665 后重启抽取进程，队里文件开始正常增长。

三. 故障总结

此次事故的主要原因还是因为在以前进程重启后出现长事务没有处理，导致后面故障重启出现多次长事务恢复需求，幸运的是和涉及的长事务和抽取的表没有关系，否则只能丢数据了。未避免这种情况的再次发生，我们针对OGG长事务进行监控，确保在归档保留周期外的长事务能第一时间处理，同时在存储条件有限的情况下，对归档的保留周期做了延期，让自己有充足的时间去处理。

END

更多精彩干货分享

点击下方名片关注

IT那活儿

数据库

文章转载自IT那活儿，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

OGG故障处理事记

评论