背景说明：

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的文件。