背景说明：
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的文件。