OGG低版本Trail文件6位,如何达到序列阈值999999后如何处理? 您所在的位置:网站首页 trail文件怎么用 OGG低版本Trail文件6位,如何达到序列阈值999999后如何处理?

OGG低版本Trail文件6位,如何达到序列阈值999999后如何处理?

2023-12-09 07:56| 来源: 网络整理| 查看: 265

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 , TRANLOG, EXTSEQNO , EXTRBA

GGSCI > ALTER EXTRACT , IOEXTSEQNO , IOEXTRBA

GGSCI > ADD RMTTRAIL./dirdat/, METGABYTES xx, SEQNO , RBA , EXTRACT  

这样新增的抽取进程与STOP 达到阈值的OGG抽取进程抽取的时间点,达到一致,这样可以认为数据一致!当然如果能初始化就不用这么费劲了,直接begin now就完事了!

详细抽取进程的操作及MOS可以见如下,博客不方便发Wordhttps://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 , 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 , detail Remote Trail Name Seqno RBA Max MB 0 0 100 But once EXTRACT is started, it continues to write a 7 digit sequence: Info , detail EXTRACT 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 1000001 53819 100 To get around this, we had to delete EXTTRAIL and add it back using a different trail prefix: GGSCI> DELETE exttrail GGSCI> add exttrail , megabytes 100, extract 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


【本文地址】

公司简介

联系我们

今日新闻

    推荐新闻

    专题文章
      CopyRight 2018-2019 实验室设备网 版权所有