Skip to Main Content
  • Questions
  • how does replicat recover without data loss after crash

Breadcrumb

Dev Live Dev Intro

We are celebrating Developers at AskTOM. We welcome Developers of all levels of experience to join us at our FREE Developer Live events coming in August and September. Just click on the left to register today! If you are brand new to Database Technology, then we also have got you covered. Just click on the right for your comprehensive FREE training program to kick start your Oracle Database Development journey!

Question and Answer

Connor McDonald

Thanks for the question, david.li.

Asked: July 16, 2020 - 8:50 am UTC

Answered by: Connor McDonald - Last updated: September 14, 2020 - 2:49 am UTC

Category: Golden Gate - Version: ogg 12.2 integrated replicate

You Asked

in goldengate replicate checkpoint table, there is low position and high position , if ogg crash, how does it recover without data loss? recover from low position? but between low position and high position, some data are applied and some are not, how does replicate know which has been applied? it is recorded some where? could you please explain a little bit,thanks!

TESTCAP> select server_name, processed_low_position, applied_low_position, applied_high_position from dba_gg_inbound_progress;

SERVER_NAME                    PROCESSED_LOW_POSITION         APPLIED_LOW_POSITION           APPLIED_HIGH_POSITION
------------------------------ ------------------------------ ------------------------------ ------------------------------
OGG$RP_FIN                     10249060774539                 10249060774539                 10249060775980
OGG$RP_ALL                     10249064445975                 10249064445975                 10249064451882


APPLIED_LOW_POSITION

VARCHAR2(4000)

All messages with commit position less than this value have been applied.

This column should be used to view the progress of the GoldenGate apply. This column will hold an Oracle SCN numeric value in text format for an Oracle source database. For a non-Oracle source database, this column will hold the apply low position in GoldenGate CSN text format for that specific source database.

APPLIED_HIGH_POSITION

VARCHAR2(4000)

Highest commit position of a transaction that has been applied


and we said...

Thanks for your patience, and big shout out to community Ace Director Veeratteshwaran Sridhar for his assistance with this one.


APPLIED_LOW_POSITION - This is the confirmed SCN which is applied to the Target by the Replicat process. This is the record or transaction which is applied lastly by the replicat process. With this we can confirm till this SCN, the target database or table is synced with Source. For any issues, if we need to start the replicat process or recreate the replicat process and start it, we need to use this scn,

start replicat <rep_name>, AFTERCSN <applied_low_position>


APPLIED_HIGH_POSITION - The Highest position (SCN) record or transaction replicat process applied to the Target. The point in here is, there may or may not be transactions between low_position and high_position. For example, let's take your case itself, between these positions (SCN) there may be transactions,

Case-1 - There are transactions between LOW and HIGH

APPLIED_LOW: 2000
________
T1 - 2200 |
T2 - 2500 | _______ We are not sure if these transactions are applied or not. It may or may not be applied by the replicat process.
T3 - 2900 |
_________
APPLIED_HIGH: 3000

So there are some transactions between LOW and HIGH. Replicat process has applied both LOW and HIGH but not sure if it applied the transactions between LOW and HIGH.
In this example, we need definitely consider APPLIED_LOW_POSITION

Case-2 - There are no transaction between LOW and HIGH

APPLIED_LOW: 2000

No Transactions ----- The next immediate position after LOW is HIGH

APPLIED_HIGH: 3000

So there are no transactions between LOW and HIGH. The next immediate position after LOW is HIGH. In this case, we can consider the APPLIED_HIGH_POSITION

To confirm this, we need to use the LOGDUMP utility and scan the trail files.

OS> ./logdump

Logdump> open <trail_file>
Logdump> ghdr on
Logdump> detail data on
Logdump> ggstoken detail
Logdump> usertoken detail
logdump>filter include ggstoken logcsn >= <applied_low_position>
Logdump> n

If the record is not found in the specific trail file, move to next trail file by issuing the below command,

Logdump> nt
Logdump> n

Please do next until you find the SCN.

Logdump> nt
Logdump> n

Once you find the SCN, issue the below command to stop the filter.

Logdump>filter clear

Now again issue the below command,

Logdump> n

This will give you the next record.

Logdump>
Logdump>



OLDEST_POSITION

Earliest position of the transactions currently being applied. These are the transactions between APPLIED_LOW and APPLIED_HIGH.


Also, you need to know about checkpoints.

Each and every process in GoldenGate has it's own Checkpoint file. So, whenever a replicat process is started or restarted, it will refer it's checkpoint file info and compare them with the ALL_GG_INBOUND_PROGRESS and then starts.

https://www.oracle-scn.com/oracle-goldengate-checkpoints/

https://docs.oracle.com/en/cloud/paas/goldengate-cloud/gwuad/replicat-checkpoints.html#GUID-9B28A222-B5EF-4520-AAA6-89F0D8E94B0E

INFO REPLICAT <replicat_name> showch

The above command gives the checkpoint information. This differs for Classic and Integrated Replicat processes.

Hope this gives clarification. Please let me know if you need further info.


More to Explore

Administration

Need more information on Administration? Check out the Administrators guide for the Oracle Database