Materializing the standby database is one of the tasks required to set up the Mirror Activator system. Therefore, the following Mirror Activator system setup tasks (which are not strictly materialization tasks) must be performed during the standby database materialization procedure:
Materialize the mirror log devices at the standby site, and set up the disk replication system for synchronous replication to the mirror log devices.
Initialize the Mirror Replication Agent.
The snapshot materialization procedure mentions these setup tasks, but it does not describe them in detail. For detailed information, see the Mirror Activator Administration Guide, Chapter 2, “Setting Up and Configuring Mirror Replication Agent.”
Before you materialize a standby
database, create the Replication Server database objects in the
primary database, and then initialize the primary database using
the Mirror Replication Agent pdb_init command. For
more information, see the Mirror Activator Administration
Guide, Chapter 2, “Setting Up and Configuring
Mirror Replication Agent.”
Table 3-3 provides a checklist of the snapshot materialization tasks for a standby database in Adaptive Server version 12.5.1 or later. This checklist assumes that the standby Adaptive Server is already installed and configured identically to the primary Adaptive Server.
Task |
Description |
|---|---|
1 |
In the standby Adaptive Server, create the same server logins and roles that are defined in the primary Adaptive Server. |
2 |
Quiesce the primary database to suspend update activity and generate a manifest file for the primary database. |
3 |
Use the disk replication system to copy a snapshot of all primary database data and log devices to the standby site, on devices accessible to the standby Adaptive Server. While the primary database is suspended during Replication Server—Heterogeneous Replication Options system setup, you also need to:
|
4 |
Resume update activity in the primary database after all procedures in step 3 are complete. |
5 |
In the standby Adaptive Server, mount the standby database devices (created in step 3) and bring the standby database online. |
Use the following procedure for snapshot materialization of a standby database in Adaptive Server version 12.5.1 or later.
To materialize a standby database in ASE 12.5.1
or later
In the standby Adaptive Server, create all server logins and roles defined in the primary Adaptive Server.
The most efficient way to complete this task is to use an external copy utility (such as bcp) to copy the contents of the following tables from the primary Adaptive Server master database to the standby Adaptive Server master database:
sysloginroles
syslogins
sysroles
syssrvroles
See the Adaptive Server Utility Guide for more information about using the bcp utility.
Quiesce the primary database to suspend all update activity, and generate a manifest file for the primary database.
Log in to the primary Adaptive Server with a System Administrator user role, and execute the following command:
quiesce database MA_setup hold pdb for external dump to pdb_manifest
where:
MA_setup is a user-defined tag that identifies the database.
pdb is the name of the primary database.
pdb_manifest is the name of the manifest file.
The standby Adaptive Server uses the manifest file to mount the devices created by the disk replication system in the following step.
Use the disk replication system facilities to do the following:
Capture a snapshot (or point-in-time) image of all of the primary database data and log devices
Transfer the snapshot to the standby devices at the standby site
The standby devices must be accessible to the standby Adaptive Server, for use as database devices.
While the primary database is suspended during Replication Server—Heterogeneous Replication Options system setup, you must also:
Transfer the snapshot of the primary database log devices to the mirror log devices, and configure the disk replication system for synchronous replication from the primary log devices to the mirror log devices
Initialize the Mirror Replication Agent, using the ra_init command
For more information see the Mirror Activator Administration Guide, Chapter 2, “Setting Up and Configuring Mirror Replication Agent.”
Refer to the documentation provided by your disk replication system vendor for more information about the procedures in this step.
Resume update activity in the primary database after all procedures in step 3 are complete.
You must initialize the Mirror Replication Agent before you
resume update activity in the primary database.
Log in to the primary Adaptive Server with a System Administrator user role, and execute the following command:
quiesce database MA_setup release
where MA_setup is a user-defined tag that identifies the suspended primary database.
Mount the standby devices in the standby Adaptive Server to recover the standby database, and then bring it online.
Log in to the standby Adaptive Server with a System Administrator user role, and execute the following command:
mount database all from pdb_manifest with listonly
where pdb_manifest is the manifest file created by the quiesce command at the primary database.
The mount command with listonly option returns the device paths specified at the primary Adaptive Server for all primary database data and log devices.
If necessary, invoke the mount command to “re-map” the device paths to the standby devices in the standby Adaptive Server:
mount database all from pdb_manifest using "sdb_path" = "pdb_data"
where:
pdb_manifest is the manifest file created by the quiesce command at the primary database.
sdb_path is the path to the standby database data device.
pdb_data is the device name of the primary database data device specified in the primary Adaptive Server.
When you invoke mount, Adaptive Server performs all of the required supporting activities, including adding database devices and activating them, creating the catalog entries for the new database, and recovering the database.
After the standby Adaptive Server completes the mount processing, bring the standby database online:
online database sdb
where sdb is the name of the standby database.
The names of the standby database and primary database
must be the same.
