Redo Logs and Rollback Segments

The database activity that drives the replication system generates a tremendous amount of redo and rollback activity—at least five times that of a nonreplicated environment by Oracle Corporation’s own estimates. Most of this overhead is associated with internal transactions that modify data dictionary tables:

  • Enqueuing and dequeueing deferred transactions update the tables SYSTEM.DEF$_AQCALL and SYSTEM.DEF$_AQERROR in Oracle8, and SYSTEM.DEF$_CALL in Oracle7.

  • The scheduled jobs that propagate DML and DDL update SYS.JOB$ every time they run. These updates alone can account for many megabytes of redo logs per hour depending on the frequency with which these jobs run.

  • Collecting statistics about resolved conflicts updates SYSTEM.REPCAT$_RESOLUTION_STATISTICS.

  • Snapshot refreshes update the tables SYSTEM.SNAP$, SYSTEM.RGCHILD$, and (in Oracle8) SYSTEM.SNAP_REFTIME$.

Because of this additional activity, you should use more and larger redo logs and rollback segments than you would for a nonreplicated environment. A good starting point is to have five redo groups using 32MB redo logs and at least five rollback segments, with an optimal size of 64MB. This configuration is easiest to do at the time you create the database.

Get Oracle Distributed Systems now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.