Re-materializing the primary database for failback in ASE 12.5.1 or later

Normally, the primary database is the source of all data and transactions replicated in the Replication Server—Heterogeneous Replication Options system. Re-materializing the primary database is required only as part of a failback procedure, to restore normal system operations after a failover.

After a failover event, the standby database becomes the “active” database in the system, and the primary database must be re-materialized from the standby database to restore the normal operating condition, and resume replication from the primary database to the standby database.

When you re-materialize a primary database, the primary database is the target, and the standby database is the source in the materialization procedure.

Table 3-4 provides a checklist of the snapshot re-materialization tasks for a primary (target) database in Adaptive Server version 12.5.1 or later. This checklist assumes the following:

The primary (target) Adaptive Server is already installed and configured identically to the standby (source) Adaptive Server.

The primary (target) database exists in the primary (target) Adaptive Server, and its database options and devices are configured identically to the standby (source) database.

All server logins defined in the standby (source) Adaptive Server exist in the primary (target) Adaptive Server, with identical suid values and names, and all server roles defined in the standby (source) Adaptive Server exist in the primary (target) Adaptive Server.

**Table 3-4: Re-materializing a primary database in ASE 12.5.1 or later**
Task	Description
1	Quiesce the standby (source) database to suspend all update activity and generate a manifest file for the standby (source) database. The standby (source) database will remain suspended during failback, until after the materialization procedure is complete for the primary (target) database.
2	Use the disk replication system to copy a snapshot of all standby (source) database data and log devices to the primary (target) database devices.
3	In the primary (target) Adaptive Server, mount the primary (target) database devices (created in step 3) and bring the primary (target) database online.

After you complete the primary database re-materialization, you must perform additional tasks to complete the failback procedure. For more information, see the Mirror Activator Administration Guide.

Use the following procedure for snapshot re-materialization of a primary database in Adaptive Server version 12.5.1 or later.

Quiesce the standby (source) database to suspend all update activity, and generate a manifest file for the standby (source) database.

Log in to the standby (source) Adaptive Server with a System Administrator user role, and execute the following command:
```
quiesce database MA_setup hold sdb
for external dump to sdb_manifest
```
where:
- MA_setup is a user-defined tag that identifies the database.
- sdb is the name of the standby (source) database.
- sdb_manifest is the name of the manifest file.
The primary (target) 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 standby (source) database data and log devices
- Transfer the snapshot to the primary (target) devices at the primary (target) site
While the standby (source) database is suspended during failback, you must also:
- Transfer the snapshot of the standby (source) database log devices to the mirror log devices
- Configure the disk replication system for synchronous replication from the primary (target) log devices to the mirror log devices (to prepare for normal system operation after failback)
Refer to the documentation provided by your disk replication system vendor for more information about the procedures in this step.
Mount the primary (target) devices in the primary (target) Adaptive Server to recover the primary (target) database, and then bring it online.
1. Log in to the primary (target) Adaptive Server with a System Administrator user role, and execute the following command:
```
mount database all from sdb_manifest
with listonly
```
  where sdb_manifest is the manifest file created by the quiesce command at the standby (source) database.
  
  The mount command with listonly option returns the device paths specified at the standby (source) Adaptive Server for all standby (source) database data and log devices.
  
  If necessary, invoke the mount command to “remap” the device paths to the primary (target) devices in the primary (target) Adaptive Server. For example:
```
mount database all from sdb_manifest 
using "pdb_path" = "sdb_data"
```
  where:
  - sdb_manifest is the manifest file created by the quiesce command at the standby (source) database.
  - pdb_path is the path to the primary (target) database data device.
  - sdb_data is the device name of the standby (source) database data device specified in the standby (source) 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.
2. After the primary (target) Adaptive Server completes the mount processing, use the following command to bring the primary (target) database online:
```
online database pdb
```
  where pdb is the name of the primary (target) database.
The names of the primary database and standby database must be the same.