记录一次宕机后,OGG出现故障,OGG-01705的解决方法

背景说明:

2021年4月14日,晚上20点07分,数据库一个节点由于故障导致出现宕机情况。宕机原因,根据黑屏显示,大概是kernel的问题,这个不做深入研究,重启后,数据库启动正常。

启动ogg进程的时候,由于源端包含ext抽取进程,dump传输进程。逐一将其进行重启。ext抽取进程启动后正常传输。dmp进程abended,发现启动不了。我对其进行了分析,发现该问题还是第一次遇到。

通过查看报错日志,view report dmpxxxx。 由于不能拍图,还有内网原因,我就从网上找了这个告警。

ERROR OGG-01705 Input checkpoint position 160374765 for input trail file '/odc/xxxx/s027505' is greater than the size of the file (160301092).Please consult Oracle Knowledge Management Doc ID 1138409.1. for instructions.

处理方法:

1. 首先通过metalink查看报错的 ID号,有了metalink 真好,涉及到Oracle方面的真是不愁找不到案例。

通过metalink查看,说的是ogg首先是通过cache里面的数据,传输到目标端,然后再写到trail文件中。看metalink,需要强大到英文理解能力。我继续百度,看看其他的案例。果然有很多这样的案例。

以下是案例的地址:

http://blog.itpub.net/29302187/viewspace-2128573

而在goldengate中,datapump和extract在交换数据的时候data pump是从cache区域中去抓取数据传送到目标端(而不是等到真的写到磁盘后,可以提高性能)。当意外down机时系统来不及将cache中的内容写到磁盘,出现了datapump新建的检查点是基于cache中的信息更新的,而trail文件的大小实际上是要比检查点写的RBA小。当下次启动时,前一个进程进行恢复动作,并将比文件大的一部分内容写到了下一个trail文件中(extract启动的时候会etrollover)。所以,要么将进程的检查点跳到下一个trail的指定RBA,要么重新初始化。

从这篇文章中可以看到,讲了很多,主要的意思是如何计算rba,然后确定后如何解决。

通过查看,发现还是有点复杂。

2. 我们之前遇到过很多次trail损坏的问题。而且对其也经过总结。 经验总结还是很有必要的。

操作大概步骤:

按照我们的方法来做。

分析:  由于源端抽取是全量抽取,到了目标端是通过拆分来实现并行的,因此需要确定目标端的scn号。我们看dirdat目录下的trail,发现有很多1.5k 的文件,说明传输的文件都没有数据。那我们就找到一个不是1.5k的看着正常的trail文件的最后一个(也就是出问题以后)。

首先查看目标端的info repxxx信息,

./ggsci

info repxxx*    --->可以查看到seqno ,还有rba. 我们这次可以看到seqno,rba都一致了,也就是都应用了。

info repxxx1,detail   -->可以查询到 ogg_checkpoint表。

查询下select max(xx传输过来的scn列), max(实际应用的scn列) from odc.ogg_checkpoint。 这两个max里面的列,我忘了。 通过查询,这两个列是一致的。

将数值记录下来。  如果目标端有断裂,这个最大值可能不一致。我们选择的时候选择这里面所有不一致的最大值里面的最小值。之前我们遇到过,目标端trail文件都损坏的情况。

目标端操作:

通过logdump进行搜索scn。进行核验,是否checkpoint查询出的scn是否一致,搜索步骤

Logdump 1 >open ./dirdat/r027506     ----->这个是目标端最后一个正常的trail

Current LogTrail is ./dirdat/r027506

Logdump  2 >ghdr on                     ------->查看header record信息

Logdump 4 >detail on   ---查看列信息,包括number和长度

Logdump 5 >GGSTOKEN ON  ------->OGG⽣成的tokens包括有事务ID(XID), DML操作的rowid,其它⼀些辅助信息。

Logdump 6 >pos 59193235    ------>是通过info查询到的信息。

Logdump 7 >n               ---->如果往下翻查询不到了,那就往上翻

Logdump 8 >pos 59193235 reverse   -->  reverse 这个是往上查询的。可以实际help下。大概就是这样的。

Logdump 8 >n   翻了几页,就会发现有scn。 经过对比跟ogg_checkpoint查询出来的一致。

源端操作:

我们拿着这个scn去源端进行查看。

源端查看dirdat的文件,发现已经生成了很多trail文件了。其中20.07分的文件,貌似不全。因为每个正常trail文件都是固定大小99M ?(记不清楚多大了)

通过info dmpxxx可以查看到seqno,rba。

seqno对应的就是这个有问题的trail,我们查看seqno号码是假定是 sp556642吧。现在通过logdump查看下一个sp556643的开始的scn

cd /odc

./logdump

open ./dirdat/sp556643

ghdr on                     ------->查看header record信息

detail on   ---查看列信息,包括number和长度

GGSTOKEN ON  ------->OGG⽣成的tokens包括有事务ID(XID), DML操作的rowid,其它⼀些辅助信息

n   -->往下查找

n    -->往下查找可能很多次。

可以查看到第一个scn  这个scn值是m吧。而目标端的是n。

发现m<n。那就说明556643这个文件数据再n之前,也就是数据没丢。

我们就执行下

alter extract dmpxxx ,extseqno 556643,extrba 0 

这样就能让dmp端从556643 这个文件开始向下扫描,并且数据不会丢。执行正常后,查看目标端的进程,都是running,并且有数据写入,rba,seqno都在变。查看目标端的文件,都跳过了1.5k的文件。


上一篇:【DB笔试面试356】在Oracle数据库中,丢失归档的情况下数据文件如何恢复?


下一篇:1338231-09-6,NOTA-NHS ester,活化脂修饰NOTA