Goldengate Checkpoint Table Is Corrupted

Replicat maintains checkpoints that provide a known position in the trail from which to
start after an expected or unexpected shutdown. By default, a record of these checkpoints
is maintained in a file on disk in the Oracle GoldenGate directory. Optionally, the
checkpoint record can also be maintained in a checkpoint table in the target database.

Using database checkpointing is recommended because it enables the checkpoint to be
included within Replicat's transaction, which improves recovery in certain situations.

但是如果Checkpoint出现问题，我们在恢复的时候将无法使用它。

MOS上给出了相关的解决方法：

My Checkpoint Table Is Corrupted. What Do I Do? (文档 ID 965703.1)

转到底部

---

 

In this Document Goal   Fix APPLIES TO: Oracle GoldenGate – Version 4.0.0 and later Information in this document applies to any platform. ***Checked for relevance on 14-12-2012*** FIX Problem How do I restore the checkpoint table so Replicat can use it again? Typical error Depending on the problem, these errors can appear as "No data found" or "Table does not exist". Such as: GGS ERROR 516 Extract read, No data found selecting position from checkpoint table HR.REPCHECK for group REPORA, key 1181389907 (0×4669453). Or… 2005-10-25 13:22:16 GGS ERROR 516 Extract read, Checkpoint table HR.REPCHECK does not exist. Please create the table or recreate the REPORA group using the correct table. Cause The table is probably corrupt, was deleted, or is missing a row(s). Solution 1. Issue the INFO REPLICAT <group> command in GGSCI to verify that the checkpoint FILE on disk is intact. If it errors, the file is missing or corrupt, and you should contact GoldenGate technical support. If the file is intact, continue with these steps. 2. If the table was deleted, recreate it with same schema and name as before … or, if it is corrupt or missing a row, truncate it. 3. From the GoldenGate home location, run the convchk utility with the following command, specifying the checkpoint table as shown: convchk <group name> <schema>.<table> 4. Restart Replicat. 5. SELECT from the checkpoint table to verify that checkpoints are being added again. Running convchk causes the checkpoint FILE to become the master source for the group's checkpoints. On restart, Replicat will populate the new or truncated checkpoint table with the data from the checkpoint file, in effect resynchronizing them.  ***Checked for relevance on 19-May-2011***