OracleGoldenGate FAQ: long transaction processing

OGG is a transaction-level real-time replication tool. That is to say, OGG only copies committed transactions. Before a transaction's commit or rollback occurs, it stores the operations of each transaction

OGG is a transaction-level real-time replication tool. That is to say, OGG only copies committed transactions. Before a transaction's commit or rollback occurs, it stores the operations of each transaction

Long transaction impact

OGG is a transaction-level real-time replication tool. That is to say, OGG only copies committed transactions. Before a transaction's commit or rollback occurs, it stores the operations of each transaction in a managed virtual memory pool called cache. When the memory size is large enough, when the transaction data exceeds a certain threshold or the current idle memory cannot meet the allocation request, the OGG process will send the least used old buffer swap to the dirtmp on the disk.

When OGG encounters a long transaction, if the extract process is terminated for some reason, temporary data on the original file system will be deleted, after the restart, the recoverycheckpoint will be used to find the archive log where the long transaction start point is located for restoration. If the archive is deleted during the restart, the extract process will not be able to restart, you can only restore the archive or initialize it. Even if the archive exists, rediscovering after restart will greatly affect the OGG performance.

Long Transaction Processing

1. Monitor long transaction warnings in ggserr. log. You can adjust the warning frequency by configuring the extract process parameter warnlongtrans.

2. Monitor long transactions in the database

Selectstart_timefrom gv $ transaction;

3. ggsci provides the following command to process uncommitted transactions.

Send extract, showtrans to view the uncommitted transactions being processed

Send extract, skiptrans skip the transaction (not recommended)

Send extract, forcetrans force that the transaction has been committed (not recommended)

We recommend that all transaction commit or rollback operations be performed in the database.

4. note: In OGG11g, extract provides the BR parameter to set the long transaction cache and BR check point to the local hard disk (under the default dirtmp directory) at intervals (4 hours by default ), therefore, as long as the extract does not stop, the archive log generally requires no more than 8 hours (limit ). However, if extract is stopped, long transactions cannot be automatically cached, and the archiving log is dependent on the downtime.

Related reading:

Management OGG-HA in RAC Environment

Configure OGG synchronization in RAC Environment

GoldenGate unidirectional table DML Synchronization

Oracle GoldenGate series: restoration principles of Extract processes

Oracle GoldenGate installation Configuration

OGG-01004 OGG-1296 error for Oracle goldengate