一、问题
序列号的问题可以参考这个链接 https://www.cnblogs.com/lvcha001/p/14762355.html Oracle MOS 2538448.1，2120995.1 两篇文章清晰的告诉了我们，OGG12.1 以及之前Trail文件是6位，OGG版本大于等于12.2 Trail文件格式转为9位！ 那么现在的问题是，某客户一天源端会出现进3k的Trail文件，这种情况下序列客户担心后面达到6位数上限，xx999999，之后OGG如何处理呢？？？
二、寻找资料
2.1已有的处理方式
https://blog.csdn.net/u014237598/article/details/100558507 Ogg投递进程abend，报错如下： 2017-09-27 13:35:51 ERROR OGG-06498 The sequence number 999000 for output trail file '/ggscenter/dirdat/b8' has exceeded
the maximum threshold (998999). Please consult Oracle Knowledge Management Doc ID 1559048.1 for further actions. 2017-09-27 13:35:51 ERROR OGG-01668 PROCESS ABENDING. ———————————————— 版权声明：本文为CSDN博主「清风果果果」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/u014237598/article/details/100558507 删除原有的rmttrail文件，新增新的rmttrail文件： delete rmttrail /ggscenter/dirdat/b8 delete rmttrail ./dirdat/b8 add rmttrail ./dirdat/28,extract b_p_28 可以根据删除进程之前,记录最后读取抽取进程的seq,rba alter修改一下
总结一下：处理的方法,可以等同于进行拆分的套路！
2.2 MOS 1060554.1
1.如下的MOS主要是说，抽取进程如果抽取的序列名称达到了999999，如何处理；
2.很啰嗦了说了一堆，说其实是支持序列号大于999999更大的值,但是alter 修改抽取进程序列，报错parameter EXTSEQNO. Range is 0 to 999999序列号只能在之间；
3.如果要处理这个问题，可以删除抽取进程，新建抽取进程，这样让Trail文件的序列号又会从0开始，避免了阈值的问题！
！！！重点但是MOS的这篇文章很不严谨！ 如果按照这个说法，新建的抽取进程begin now，很容易造成数据的不一致问题！ 原来的抽取进程最后的scn ->新抽取进程scn直接的差异数据丢失！
4.补充，我们可以学习 MOS 964684.1 、1267901.1 两篇文档，其中是将关于抽取进程拆分；
GGSCI > ADD EXTRACT <extract>, TRANLOG, EXTSEQNO <Current Checkpoint sequence #>, EXTRBA <Current Checkpoint RBA>
GGSCI > ALTER EXTRACT <extract>, IOEXTSEQNO <Recovery Checkpoint #>, IOEXTRBA <Recovery Checkpoint RBA>
GGSCI > ADD RMTTRAIL./dirdat/<extrail trail>, METGABYTES xx, SEQNO <current write position Sequence #> , RBA <current write position RBA>, EXTRACT <extract>
这样新增的抽取进程与STOP 达到阈值的OGG抽取进程抽取的时间点,达到一致，这样可以认为数据一致！当然如果能初始化就不用这么费劲了，直接begin now就完事了！
详细抽取进程的操作及MOS可以见如下,博客不方便发Word
https://www.modb.pro/doc/35751
What Happens When The Maximum Number Of Trail Files (999999) Is Exceeded? (Doc ID 1060554.1) Oracle GoldenGate - Version 4.0.0 and later Provide additional information to the user on what happens when the maximum number of Trail files (999999) has been exceeded. SOLUTION Issue: What will happen if the next output trail file number will be larger than 999999? Consequences: GoldenGate trail names are a composite of a two character prefix, such as 'et', and an incrementing trail number in the range of 0 to 999999.
Incrementing the trail past 999999 has adverse consequences.
1. The next trail file number will go to 1000000. Because four bytes are used in the Extract checkpoint file as a signed number for the output trail file number, the trail number can go as large
as ~2 billion (2147483647). Beyond that, there will be a mis-match between the trail number in the file name and in the INFO EXTRACT output,
because the number is signed. The number will be recycled after reaching 4294967295 (FFFFFF). 2. It has been tested that Replicat will process et1000000, after processing et999999. But the replicat may not be able to process
the next trail 1000001, and will hang. 3, Certain functions may not work for a trail number larger than 999999. For example: GGSCI (dosi) 9> alter replicat <replicat_name>, extseqno 1000000 ERROR: Number out of range (1000000) for parameter EXTSEQNO. Range is 0 to 999999. 4. purgeoldextracts parameter may purge the trails before finishing processing them. Solution and Workaround: 1. If the user has an extract with a trail file number approaching 999999, he should do the following. First, the trail sizes should
probably be defined to be larger. Second, the user should stop the extract, saving the current time and rba being processed.
The user should then delete the extract and existing trails once they are all processed. Next, the user should re-add the extract,
preferably with suitable large trail sizes. 2. When the trail goes to 7 digits 1000000, the purgeoldextracts should be disabled immediately. then stop the replicat and upstream pump (or extract if the pump is not in use), and do following manual changes: - make backup of the checkpoint files of replicat and pump - delete and re-add the pump rmtfile with appropriate seq#, then rename the trail files to appropriate 6 digit number. example, there are 2 replicat trails rt1000000 and rt1000001. (1) change them to rt100000 and rt100001 respectively (2) add the pump rmttrail with "seqno 2, rba 0" option. - reposition the replicat checkpoint. 3. If the new trails are delete by purgeoldextracts, the pump may be re-positioned to the local trail based on the replicat timestamp .
But there can be duplicate transactions within 1 second. In addition, attention has to be paid on if the source and target servers
are on same time zone. Note: As found in previous issues , a delete and re-add of the exttrail is not changing the write 7th digit sequence. And it doesn't show
this info detail after the exttrail is re-added: GGSCI> info extract <name>, detail Remote Trail Name Seqno RBA Max MB <trail_file_path> 0 0 100 But once EXTRACT is started, it continues to write a 7 digit sequence: Info <extract_name>, detail EXTRACT <extract_name>Last Started 2012-03-31 13:33 Status RUNNING Checkpoint Lag 07:18:59 (updated 00:00:07 ago) Log Read Checkpoint Oracle Redo Logs 2012-03-31 06:14:55 Thread 1, Seqno xxxxxx, RBA xxxxxxxx Log Read Checkpoint Oracle Redo Logs 2012-03-31 06:14:55 Thread 2, Seqno xxxxxx, RBA xxxxxxxx Target Extract Trails: Remote Trail Name Seqno RBA Max MB <trail_path> 1000001 53819 100 To get around this, we had to delete EXTTRAIL and add it back using a different trail prefix: GGSCI> DELETE exttrail <trail_path> GGSCI> add exttrail <trail_path>, megabytes 100, extract <extract_name> Also refer GoldenGate Trail file Sequence Number Does Not properly Reset After 999999 (Doc ID 1453979.1) for step by step instructions Enhancement Request: This issue is tracked in bug 10424514, as an enhancement request. REFERENCES NOTE:1453979.1 - GoldenGate 11g Trail File Sequence Number Does Not Properly Reset after 999999
2.3 MOS 1453979.1
1.如下的MOS主要是针对投递进程如果序列达到999999之后如何进行处理；
2.套路和2.1的大哥处理的方法一样，删除进程，新建一个进程指定新的trail投递过去的名称，这样seq就能从0开始重新计数；
3.抽取、投递进程都有了解决方法，复制进程可以忽略，复制进程就是投递进程投递过去的trail文件！
4.新版本大于等于12.2 OGG版本Trail文件是9位数，从这个角度看Oracle也是希望避免出现这个问题！
5.有客户从11.2 OGG 原地升级到12.3，但是OGG抽取进程的Trail文件位数还是6，因此升级的小伙伴建议关注这个问题！！！
GoldenGate 11g Trail File Sequence Number Does Not Properly Reset after 999999 (Doc ID 1453979.1) Oracle GoldenGate - Version 11.1.1.0.0 to 11.2.1.0.39 [Release 11.1.1 to 11.2] GOAL How to reset the a GoldenGate trail sequence manually ? SOLUTION Steps to reset the sequence manually. This is resetting the trail file written by the pump. Instructions for resetting trails written by
a log extract are similar and may be derived from the following information. ---------------------------------------------- 1)Stop the main extract stop extract 2) Make sure that pump has read all the extract trail file generated by the main extract and is at the end of the last generated trail
file and the lag is 0 SEND EXTRACT [pump_name], LOGEND This should give the output as "YES" 3) Stop the pump stop extract 4) Make sure that replicat has read all the extract trail file generated by the pump extract and is at the end of the last generated trail
file and the lag is 0 SEND REPLICAT [replicat_name], LOGEND This should give the output as "YES" 5)Stop the replicat stop replicat 6) make a note of the the "info pump_name ,detail" output and "info replicat_name ,detail" as backup 7) backup all the trail files generated by the pump on the target server to a new folder and remove all the corresponding trail files on
the target side and delete all the trail files generated by the pump on the target side ie for eg:- rm ./dirdat/el* on the target side
(where replicat is running) 8) delete the rmttrail file of the pump extract ex:- suppose the rmttrailfile name is ./dirdat/el use ggsci> DELETE RMTTRAIL ./dirdat/el 9) Add back the rmttrail with the sequence 0 and rba 0 ex:- add rmttrail ./dirdat/el, megabytes 1000, seqno 0 , rba 0, extract test 10)make sure that the "info pump_name ,detail" output is showing trail file sequence as 0 11)start the extract 12) start the pump 13)point the replicat to the the first generated trail file by pump ie 0 alter replicat ,extseqno 0 , extrba 0 14) start the replicat start replicat NOTE:Manager PURGEOLDEXTRACTS USECHECKPOINTS may incorrectly purge sequences from 1000000 (1 million) as it deem to be sequence
0 and 1000001 to be 1, etc. on the target. Starting in GoldenGate 12.1, we support trail sequences up to 9 digits instead of 6.