OGG-01028 encountered commit SCN that is not greater than the highest SCN already processed
when implementing the golden gate with the RAC then scn commit point error occur's the SCN commit point difference between the two nodes are not Captured the golden gate and the database heart beat cluster is not Captured by the Golden gate in the latest version of the golden gate This issue is resolved if you are in the older version 11.1.1.o then you may upgrade to the latest version there was the work around suggest by the meta link note and start the abended process if you have the pump extract then the master extract only fails and goes to the abended state
The steps to start the extract
go the gg root directory and issue info * and verify the process status
EXTRACT TRANE Last Started 2012-07-09 22:39 Status ABENDED
Checkpoint Lag 00:00:04 (updated 57:54:28 ago)
Log Read Checkpoint Oracle Redo Logs
2012-07-16 10:28:05 Thread 1, Seqno 71663, RBA 37061648
Log Read Checkpoint Oracle Redo Logs
2012-07-16 10:28:05 Thread 2, Seqno 83522, RBA 97637256
EXTRACT TRANP Last Started 2012-07-10 00:10 Status RUNNING
Checkpoint Lag 00:00:00 (updated 00:00:07 ago)
Log Read Checkpoint File ./dirdat/tt000132
2012-07-15 23:55:11.000000 RBA 1614803
In the ggsci command prompt type the command to view report of the extract which is failing view report TRANE
Source Context :
SourceModule : [er.main]
SourceID : [/home/ecloud/workspace/Build_OpenSys_r11.1.1.0.0_07
8_[34100]/perforce/src/app/er/rep.c]
SourceFunction : [process_extract_loop]
SourceLine : [22135]
2012-07-16 10:28:19 ERROR OGG-01028 encountered commit SCN 3.2740850914 (156
25752802) that is not greater than the highest SCN already processed 3.274085101
3 (15625752901) Redo Thread 1 (1) xid 124.15.403910 (0x007c.000f.000629c6), star
ting seq.rba 71663.37062672, scn 3.2740850913 (15625752801), commit seq.rba 7166
3.37095672 commit timestamp 2012-07-16 10:28:17.000000.
In the ggsi command prompt do the info <extract name> ,showch and conform the read and write check point of the current EXTRACT
1]Do an ETROLLOVER on Extract, and take note of the new sequence number of the trail file
Before doing the extract etrollover make a note of the trail file write check point .. to know the trail file checkpoint
in the ggsci command prompt type info <extract name > ,showch
Write Checkpoint #1
GGS Log Trail
Current Checkpoint (current write position):
Sequence #: 132
RBA: 1614803
Timestamp: 2012-07-16 10:28:09.090854
Extract Trail: ./dirdat/tt
2012-07-18 20:43:15 INFO OGG-01520 Rollover performed. For each affected output trail of Version 10 or higher format, after starting the source extract, issue ALTER EXTSEQNO for that trail's reader (either pump EXTRACT or REPLICAT) to move the reader's scan to the new trail file; it will not happen automatically
EXTRACT altered.
after doing the extract etrollover you can see the new sequence number of the trail file had been created at the write checkpoint the previous was 132 and after rollover you can see the new trail file number 133 at the write check point
Write Checkpoint #1
GGS Log Trail
Current Checkpoint (current write position):
Sequence #: 133
RBA: 856
Timestamp: 2012-07-18 20:50:28.313045
Extract Trail: ./dirdat/tt
GGSCI (db) > START EXTRACT TRANE
Sending START request to MANAGER ...
EXTRACT TRANE starting
2a} check whether the extract is in the running state
EXTRACT TRANE Last Started 2012-07-18 20:44 Status RUNNING
Checkpoint Lag 58:16:47 (updated 00:00:05 ago)
Log Read Checkpoint Oracle Redo Logs
2012-07-16 10:28:05 Thread 1, Seqno 71663, RBA 37061648
Log Read Checkpoint Oracle Redo Logs
2012-07-16 10:28:05 Thread 2, Seqno 83522, RBA 97637256
3]Send PUMP, LOGEND, and note the trail file number as it moves to the previous trail file
GGSCI (db) > info TRANP
EXTRACT TRANP Last Started 2012-07-10 00:10 Status RUNNING
Checkpoint Lag 00:00:00 (updated 00:00:02 ago)
Log Read Checkpoint File ./dirdat/tt000132
2012-07-15 23:55:11.000000 RBA 1614803
Sending LOGEND request to EXTRACT TRANP ...
YES.
wait until the log end command end's with YES
4. Once you have got the output as YES then , You must stop the pump, and do an ETROLLOVER for it too. Take note of the new trail file sequence number that is created from this step
GGSCI (db) > info TRANP
EXTRACT TRANP Last Started 2012-07-10 00:10 Status RUNNING
Checkpoint Lag 00:00:00 (updated 00:00:00 ago)
Log Read Checkpoint File ./dirdat/tt000132
2012-07-15 23:55:11.000000 RBA 1614803
GGSCI (db) > info TRANP showch
Write Checkpoint #1
GGS Log Trail
Current Checkpoint (current write position):
Sequence #: 135
RBA: 1614836
Timestamp: 2012-07-18 20:56:50.275291
Extract Trail: ./dirdat/t1
GGSCI (db) > STOP EXTRACT TRANP --- stop the extract
Sending STOP request to EXTRACT TRANP ...
Request processed.
GGSCI (db) > info tranp --check the status of the extract
EXTRACT TRANP Last Started 2012-07-10 00:10 Status STOPPED
Checkpoint Lag 00:00:00 (updated 00:00:05 ago)
Log Read Checkpoint File ./dirdat/tt000132
2012-07-15 23:55:11.000000 RBA 1614803
GGSCI (db) 34> ALTER EXTRACT TRANP ETROLLOVER
2012-07-18 21:00:50 INFO OGG-01520 Rollover performed. For each affected output trail of Version 10 or higher format, after starting the source extract, issue ALTER EXTSEQNO for that trail's reader (either pump EXTRACT or REPLICAT) to move the reader's scan to the new trail file; it will not happen automatically.
EXTRACT altered
GGSCI (db) > info TRANP showch
Write Checkpoint #1
GGS Log Trail
Current Checkpoint (current write position):
Sequence #: 136
RBA: 0
Timestamp: 2012-07-18 20:59:06.625434
Extract Trail: ./dirdat/t1
Make a note of this number which we need to use in the replicate etrollover
5.] Alter the pump to SEQNO to the new trail file created from step #1
At this scenario we have got the new trail file number in the first step write checkpoint and from 132 to it is changed to 133 after the etrollover and now the TRANP is in the 132 trail file and we have to change it to the new trail file 133...
GGSCI (db) 38> ALTER EXTRACT TRANP EXTSEQNO 133 EXTRBA 0
EXTRACT altered.
6.] Start pump Extract
GGSCI (db) > start EXTRACT TRANP
Sending START request to MANAGER ...
EXTRACT TRANP starting
GGSCI (db) > info EXTRACT tranp
EXTRACT TRANP Last Started 2012-07-18 21:09 Status RUNNING
Checkpoint Lag 00:00:00 (updated 00:00:03 ago)
Log Read Checkpoint File ./dirdat/tt000133
2012-07-16 15:36:02.000000 RBA 1207
Now you can see the extract Pump tranp had been switched to the new trail file which is created at the master extract etrollover
These are the steps we have done in the source system and in the target system replicate we have run the LOGEND and Change the trail file t th new trail file created at the step 4
1] Login to the ggsci fo the target system where replicate is running
REPLICAT TRANR1 Last Started 2012-07-11 19:28 Status RUNNING
Checkpoint Lag 00:00:00 (updated 00:00:09 ago)
Log Read Checkpoint File ./dirdat/t1000135
2012-07-16 00:03:32.629052 RBA 1614836
2]Send the replicate to the log end and wait until the out YES and stop the replicate
GGSCI (fahdb) > SEND REPLICAT TRANR1 LOGEND
Sending LOGEND request to REPLICAT TRANR1 ...
YES.
GGSCI (fahdb.) > STOP REPLICAT TRANR1
Sending STOP request to REPLICAT TRANR1 ...
Request processed.
3 ]Alter the extract to the sequence number generated the PUMP extract had been etrollover in our scenario it is 136 is the new trail file number...
GGSCI (fahdb) > ALTER REPLICAT TRANR1 EXTSEQNO 136 EXTRBA 0
REPLICAT altered.
GGSCI (fahdb) > START REPLICAT TRANR1
Sending START request to MANAGER ...
REPLICAT TRANR1 starting
GGSCI (fahdb) > info TRANR1
REPLICAT TRANR1 Last Started 2012-07-18 21:46 Status RUNNING
Checkpoint Lag 00:00:00 (updated 00:00:04 ago)
Log Read Checkpoint File ./dirdat/t1000136
2012-07-16 15:44:22.657553 RBA 1240
Now you can notice the same number in the RBA between both the source and the
target now both the node are in the synchronous and this is the way to start the Extract and we have to add two parameter in your master extract
THREADOPTIONS MAXCOMMITPROPAGATIONDELAY 15000 IOLATENCY 80000
As per metalink note this is the workaround and you shoud upgraded the GG to the new version
To cross verify the RBA you can check the trail file created in the both the GG's the RBA number will be as same as the trail file record size
IN extract GG
GGSCI (db) 5> sh ls -latr /fah/oracle/gg/dirdat/tt00013*
-rw-rw-rw- 1 oraprod oinstall 9999233 Jul 12 09:31 /fah/oracle/gg/dirdat/tt000130
-rw-rw-rw- 1 oraprod oinstall 9998804 Jul 15 17:19 /fah/oracle/gg/dirdat/tt000131
-rw-rw-rw- 1 oraprod oinstall 1614803 Jul 15 23:55 /fah/oracle/gg/dirdat/tt000132
-rw-rw-rw- 1 oraprod oinstall 1207 Jul 18 20:50 /fah/oracle/gg/dirdat/tt000133
IN Replicate GG
GGSCI (fahdb.oasiserp.com) 4> sh ls -latr /u01/app/oracle/oracle/product/gg/dirdat/t100013*
-rw-rw-rw- 1 oracle oinstall 6850827 Jul 9 22:31 /u01/app/oracle/oracle/product/gg/dirdat/t1000130
-rw-rw-rw- 1 oracle oinstall 7418909 Jul 10 00:09 /u01/app/oracle/oracle/product/gg/dirdat/t1000131
-rw-rw-rw- 1 oracle oinstall 9235743 Jul 10 00:19 /u01/app/oracle/oracle/product/gg/dirdat/t1000132
-rw-rw-rw- 1 oracle oinstall 9999384 Jul 12 09:39 /u01/app/oracle/oracle/product/gg/dirdat/t1000133
-rw-rw-rw- 1 oracle oinstall 9998837 Jul 15 17:28 /u01/app/oracle/oracle/product/gg/dirdat/t1000134
-rw-rw-rw- 1 oracle oinstall 1614836 Jul 16 00:03 /u01/app/oracle/oracle/product/gg/dirdat/t1000135
-rw-rw-rw- 1 oracle oinstall 1240 Jul 18 21:18 /u01/app/oracle/oracle/product/gg/dirdat/t1000136
No comments:
Post a Comment