记录一次宕机后，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的文件。