标签：文件 scn 查看 宕机 seqno Logdump trail 01705 OGG

背景说明：

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

标签：文件,scn,查看,宕机,seqno,Logdump,trail,01705,OGG
来源： https://blog.51cto.com/lishiyan/2706994

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。