Each Mirror Replication Agent instance depends on the information in its Replication Agent System Database (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.
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. See Chapter 2, “Setup and Configuration,” for more information.
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 the Mirror Replication Agent is one of the tasks required to set up the Mirror Activator system, and it has several prerequisites. See “Setting up the Mirror Activator system” for more information about these tasks, and initializing the Mirror Replication Agent.
After the Mirror Replication Agent is initialized, the RASD cannot be updated without completely rebuilding the RASD (by re-initializing the Mirror Replication Agent).
During normal Mirror Activator system operation, the Mirror Replication Agent maintains its RASD automatically, without manual intervention.
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, Mirror Replication Agent updates its RASD automatically.
There are, however, some DDL commands and system procedures that cannot be replicated, and the Mirror Replication Agent does not update its RASD to reflect the schema changes produced by those commands and procedures.
Examples of DDL commands and system procedures that the Mirror Replication Agent cannot replicate include:
select into
update statistics
sp_configure
sp_dboption
If a DDL command or system procedure produces a change in the primary database schema, and the Mirror Replication Agent cannot replicate 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. See “Updating the RASD” for more information.
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.
Mirror Replication Agent determines which version of each object to use by comparing the object’s version string with the LTM Locator value. If the LTM Locator value is greater than or equal to the value of the current version, the current object is used. If the LTM Locator value is less than the value of the current version, a previous version must be used.
Without periodic truncation, the size of the RASD can grow indefinitely, as more and more versions of objects are added. See “Truncating the RASD” for more information.
