OGG-01028 Recovery record is missing ERROR

今天重启一个Extract失败，状态为ABENDED，在ggserr.log查看错误信息如下：
Normal 0 false false false EN-US ZH-CN X-NONE 2011-09-21 23:03:47  ERROR   OGG-01028  Oracle GoldenGate Capture for Oracle, E130RKS2.prm:  Recovery record is missing from log with seqno 9703 when extract has reached log with seqno 9704, block size 512, and next_checkpoint RBA at 57759732. 后来查看metalink的一篇文章（ Normal 0 false false false EN-US ZH-CN X-NONEGoldengate Extract Abended - Recovery Record Is Missing (Doc ID 1094767.1)，原来是一个bug，原因如下：

The extract was manually stopped and current/next checkpoint is set to a zero length record in redo. This is a very rare condition, and the chance of hitting it is also low. When this extract was restarted, the error occurred. Extract's Current/Next checkpoint is set to a zero length record at the end of a log and on restart this zero length record is skipped as it has no useful data. Since this record is skipped the recovery code thinks this record was missed and generates an error.

This is bug 12693183, 12693291.

简单来说，当stop extract时，current/next checkpoing正好指向一个0长度的redo记录，当extract再次启动时，回跳过该redo记录，导致出现redo记录丢失的错误，这种情况是很罕见的。

Metalink 提供的解决方法如下：

This bug is fixed in v11.1.1.1 with patches for bugs 12693183, 12693291.

The following workaround may also be used with no data loss.
Workaround: change the current checkpoint RBA to next block boundary, keep the recovery checkpoint the same

1. Get block size of your platform.
The block size is shown in the error message.
2010-05-04 15:42:23 GGS ERROR 190 Recovery record is missing from log with seqno 14496 when extract has reached log with seqno 14497, block size 512, and next_checkpoint RBA at 149274704.

For reference the following lists the block size of major platforms:
AIX, Linux, Sun, Windows & VMS: 512 Bytes
HP-UX, Tru64: 1024 Bytes
S390, MVS: 4096 Bytes.

2. Backup the checkpoint file in directory dirchk

3. info showch
Get current and recovery checkpoints, example:

EXTRACT EIDLD Last Started 2010-05-04 16:39 Status ABENDED
Checkpoint Lag 01:14:54 (updated 01:14:41 ago)
Log Read Checkpoint Oracle Redo Logs
2010-05-04 15:24:21 Seqno 14496, RBA 149274704
Current Checkpoint Detail:
Read Checkpoint #1
Oracle Redo Log
Startup Checkpoint (starting position in the data source):
Sequence #: 14496
RBA: 149273104
...................
Recovery Checkpoint (position of oldest unprocessed transaction in the data source):
Sequence #: 14496
RBA: 149273104
...................
Current Checkpoint (position of last record read in the data source):
Sequence #: 14496
RBA: 149274704
..................

4. Alter both recovery checkpoint and current checkpoint to the start point of next block number

alter , extseqno , extrba

In the above example:
SQL> select ceil (149274704/512) * 512 from dual;
CEIL(149274704/512)*512
-----------------------
149275136

seq# remains the same as in the showch display.  

ggsci> alter extract , extseqno 14496, extrba 149275136

If the new rba number is bigger than the current file size of the archivelog file, you have to alter both checkpoint to start from RBA 0 in next seqno file.

For example, if the size of archived log that has seqno 14496 is only 149275000, which is smaller than the new RBA calculated, 149275136, you have to issue the following command

ggsci> alter extract , extseqno 14497, extrba 0

5. Alter the extseqno and extrba of recovery checkpoint back to its original recovery checkpoint position

In this example,
ggsci> alter extract , ioextseqno 14496, ioextrba 149273104

6. info , showch
 Confirm the change.

7. start


Note:  Above example is for extract without threads option.  For extract with threads option, "thread " is needed for "alter extract " command.
e.g.,  "ggsci> alter extract , extseqno 14497, extrba 0" will be "ggsci> alter extract , thread , extseqno 14497, extrba 0"   (here, is the ogg thread number).

简单的说就是手动把current checkpoint设置为下一个block，从而跳过长度为0的redo记录。

已写信给app那边的人确认，等他们同意就可以开始做了。

要彻底解决这个问题，还需要为所有的Golden Gage软件打上补丁。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/26277071/viewspace-708088/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/26277071/viewspace-708088/