This article explains on how to recover from a trail file corruption from Oracle GoldenGate 12cR2 (12.2) version. Prior to OGG 12.2, recovery from a trail file corruption has so many steps which is very tedious and if any one mistake in the step would lead to data integrity issues and replication would be messed up. Below are the steps to recover the trail file corruption prior to OGG 12.2 (OGG 11g, 12cR1)
Note down the Last Applied SCN and the Timestamp from the target. In the Source, scan the trail file for this Last Applied SCN. Re-Extract the data after this SCN by altering the Pump Extract process. Alter the Replicat process to read from the New Trail Seq#. Start the Pump and Replicat process.
From Oracle GoldenGate 12.2, a new feature is introduced called “Automated Remote Trail File Recovery”. In this article, I am going to explain with an example on how simple it is to recover from a trail file corruption from OGG 12.2
Server and configuration details are below.
Hostname - OGGR2-1.localdomain Database - GGDB1 Schema - SOURCE Table Name - T1 OGG - /vol3/ogg Extract - EXT1 Pump - PMP1
Hostname - OGGR2-2.localdomain Database - GGDB2 Schema - TARGET Table Name - T1 OGG - /vol3/ogg Replicat - REP1
The parameters of the oracle goldengate processes are below.,
USERID ggadmin, PASSWORD oracle
RMTHOST OGGR2-2, MGRPORT 7879
USERID ggadmin, PASSWORD oracle
MAP source.t1, TARGET target.t1;
In the target server, I have corrupted the trail file ft000000002. Now I am going to start the replicat process REP1 in the target side and it abends with the error “Incompatilbe Error”. Let us see it.
The replicat process will not move further since there is a bad record in the trail file. Let’s implement or use the new feature “Automated Remote Trail File Recovery” which is available in the OGG 12.2. Below are the steps,
1. The first and foremost thing is to stop the Pump process in the source side. 2. Delete all the trail files first from the corrupted seq#. 3. Start the Pump process in the source and any missing trails are now automatically rebuilt by bouncing the Extract Pump. 4. Start the Replicat process.
Below are the detailed steps,
How simple it is to recover from a corrupted trail file at the target. If you compare the steps involved in the versions prior to OGG 12.2 and steps involved from OGG 12.2. It is very simplified and easy. But there are some considerations or requirements which are needed to use this new feature Automated Remote Trail File Recovery.
1. At least one valid complete trail file should be present prior to the corrupted trail file. 2. Respective trail files in the source should be there. 3. Should not use NOFILTERDUPTRANSACTIONS.
You may think about the last point, NOFILTERDUPTRANSACTIONS. What if the replicat process after the restart reads and applies the records which are already applied in the target? You will end up with errors like “ORA-00010 Unique constraint”. To overcome this, a new parameter FILTERDUPTRANSACTIONS has been introduced from OGG 12c.
FILTERDUPTRANSACTIONS | NOFILTERDUPTRANSACTIONS
a)It causes replicat to ignore transactions that it has already processed.
b) Use when Extract was repositioned to a new start point (ATCSN or AFTERCSN option of “START EXTRACT”) and you are confident that there are duplicate transactions in the trail that could cause Replicat to abend.
c) This option requires the use of a checkpoint table.
d) If the database is Oracle, this option is valid only for Replicat in nonintegrated mode.
e) The default is FILTERDUPTRANSACTIONS
f) To override this, use NOFILTERDUPTRANSACTIONS
Hope you found this article useful.