Long transaction analysis when the OGGe process is stopped

During routine database maintenance, the ogg process is often stopped. Sometimes there is an error prompting that a transaction has been executed for a long time. The OGG prompts that SENDEXTRACT can be used.

The ogg process is often stopped during routine database maintenance. Sometimes there is an error prompting that a transaction has been executed for a long time. The OGG prompts you to use send extract.

The ogg process is often stopped during routine database maintenance. Sometimes there is an error prompting that a transaction has been executed for a long time. The OGG prompts you to use send extract EHXZG001, the FORCESTOP Command forces the process to stop. Then, restart the process to read the 20939 and 12852 redo logs.

GGSCI (gdlt2hxzgdb02) 21> stop *
Sending STOP request to EXTRACT EHXZG001...
There are open, long-running transactions. before you stop Extract, make the archives containing data for those transactions available for when Extract restarts. to force Extract to stop, use the send extract EHXZG001, FORCESTOP command.
Oldest redo log files necessary to restart Extract are:
Redo Thread 1, Redo Log Sequence Number 20939, SCN 3340.2050804863 (14347241573503), RBA 47790608
Redo Thread 2, Redo Log Sequence Number 12852, SCN 3340.2057322291 (14347248090931), RBA 4788752.

Key Point Analysis:
1. When a transaction in the database is initiated, the e process of OGG will capture the transaction and then scan the related redo logs or archive logs.
2. When a transaction in the database is not committed for a long time or rolled back, OGG keeps the transaction keep in the memory, so the transaction remains unchanged without committing or interrupting.
3. When you need to stop the OGG e process, the transaction is being executed.

Measures:
Measure 1: Use the send extract EHXZG001 and FORCESTOP commands to force stop the process. However, you must ensure that the log files containing the transaction exist and are available at the restart, this means that when the ogg process restarts, it will resume capturing the transaction again. When the corresponding log file does not exist, OGG will report an error and generally cannot find the archive, in fact, it is recommended that you do not do it unless you have. An article describes the process and summarizes it:
Measure 2: If you do not perform operations at the OGG level, roll back or submit the data directly from the source database. In this way, although you have to wait for a certain period of time, it is relatively safe.

Extended analysis of OGG transaction processing:
1. the extraction process of OGG captures transactions in real time, but when it is delivered to the target end, if the transaction is not committed, the replication process will not write it into the target database, thus avoiding inconsistency.
2. OGG has a Bounded Recovery mechanism that performs a check at intervals. If a long transaction is detected, OGG saves long transactions that have not been committed or rolled back in the time period from the memory to the disk, and then performs the same check at intervals. The above time range is the br brinterval 2 H that can be customized through the parameter. (Two hours ).
3. when you force stop the extraction process and restart it, you do not need to read the entire transaction from the database log, the transaction process saved in the checkpoint can be read through the BR file saved by OGG.
4. During a long transaction that is not detected and saved by Bounded Recovery, OGG reads data from the archive through the record checkpoint.

This article permanently updates the link address: