Each instance of Mirror Replication Agent depends on the information in its RASD to recognize database structure or schema objects in the transaction log and to keep track of mirror log devices.
The Mirror Replication Agent RASD is an important fault-tolerance feature of the Mirror Activator system. It allows the Mirror Replication Agent to recover from failures in its own environment, so that all logged transactions on the mirror log devices can be replicated when the Mirror Replication Agent starts, even when the primary database is offline.
When you create a Mirror Replication Agent instance, the RASD is created automatically, but it contains no information until you initialize the Mirror Replication Agent instance using the pdb_init command. When you initialize a Mirror Replication Agent instance, it does the following:
Queries the primary database to get information about the database structure or schema
Queries the primary database to get information about the transaction log devices
Stores information about the database schema and transaction log devices in its RASD
Initializing Mirror Replication Agent is one of the
tasks required to set up the replication system, and it has several
prerequisites. For more information about these tasks and how to
initialize the Mirror Replication Agent, see “Create the Mirror Replication Agent instance”.
After the RASD is initially populated, its contents are synchronized with the primary database automatically during normal replication (without intervention).
If replication does not occur, the contents of the RASD become stale (not synchronized with the primary database), and you should rebuild the contents before using the RASD.
Most of the common data definition language (DDL) commands and system procedures executed in the primary database are recorded in the transaction log, and they are replicated to the standby database. When it processes those DDL transactions for replication, the Mirror Replication Agent updates the RASD automatically.
If the Mirror Replication Agent does not recognize a DDL command or system procedure that has produced a change in the primary database schema, then Mirror Replication Agent cannot automatically update its RASD. A replication failure results if a subsequent transaction changes data in an object that is not recorded in the RASD. In that event, you must quiesce the primary database and reinitialize Mirror Replication Agent to force an update to the RASD. See “Updating the RASD”.
Each time it processes a DDL transaction that affects an existing database object, the Mirror Replication Agent creates a new version of the object metadata in its RASD. The version of each object is identified by the LTM Locator value of the DDL transaction that changed it.
Previous versions of objects must be kept in the RASD long enough to allow system recovery. For example, replaying a transaction that involved an object before it was changed by DDL could produce an error (or data inconsistency) with the current version of the object.
The Mirror Replication Agent does not support replaying
transactions from a restored transaction log.
The Mirror Replication Agent determines which version of each object to use by comparing the current object version string with the current LTM Locator value. If the current LTM Locator value is greater than or equal to the value of the object version, the current object metadata is used. If the current LTM Locator value is less than the value of the object version, a previous version of the object metadata must be used.
Without periodic truncation, the size of the RASD can grow indefinitely, as more and more versions of object metadata are added. See “Truncating the RASD”.
