Each Mirror Replication Agent instance 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 up, 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. When you initialize a Mirror Replication Agent instance, it does the following:
Before you can start replication with the Mirror Activator system,
you must initialize the Mirror Replication Agent instance after the instance is created
and its connection configuration parameters are set. You must execute the ra_init command
to load the RASD. For more information, see Chapter 2, “Setting Up and Configuring Mirror Replication Agent.”
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 the Mirror Replication Agent is one of the tasks required to set up the Mirror Activator system, and it has several prerequisites. For more information about these tasks and how to initialize the Mirror Replication Agent, see “Setting up the Mirror Activator system”.
After the RASD is initially populated, its contents will be synchronized with the primary database automatically during normal replication (without intervention).
If replication does not occur, the contents of the RASD becomes stale (out of sync with the primary database), and you should rebuild them before you use it.
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 a DDL command or system procedure produces a change in the primary database schema and the Mirror Replication Agent cannot recognize that command or procedure and update its RASD automatically, a replication failure will occur if a subsequent transaction changes data in an object that is not recorded in the RASD. In that event, you must re-initialize and quiesce the primary database, and force the Mirror Replication Agent to update its RASD. For more information, 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 object’s current 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. For more information, see “Truncating the RASD”.
