Materializing the standby database in ASE 12.5.1 or later

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:

The snapshot materialization procedure mentions these setup tasks, but it does not describe them in detail. See the Mirror Activator Administration Guide, Chapter 2, “Setting Up and Configuring Mirror Replication Agent.”

NoteBefore 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. See the Mirror Activator Administration Guide, Chapter 2, “Setting Up and Configuring Mirror Replication Agent.”

Table 2-3 provides a checklist of the snapshot materialization tasks for a standby database in ASE version 12.5.1 or later. This checklist assumes that the standby ASE is already installed and configured identically to the primary ASE.

Table 2-3: Materializing a standby database in ASE 12.5.1 or later

Task

Description

1

In the standby ASE, create the same server logins and roles that are defined in the primary ASE.

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 ASE.

While the primary database is suspended during Replication Server Heterogeneous Replication Options system setup, you also need to:

  • Copy a snapshot of the primary database log devices to the mirror log devices, and configure synchronous replication from the primary log devices to the mirror log devices

  • Initialize the Mirror Replication Agent

4

Resume update activity in the primary database after all procedures in step 3 are complete.

5

In the standby ASE, mount the standby database devices (created in step 3) and bring the standby database online.

StepsMaterializing a standby database in ASE 12.5.1 or later

  1. In the standby ASE, create all server logins and roles defined in the primary ASE.

    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 ASE master database to the standby ASE master database:

    • sysloginroles

    • syslogins

    • sysroles

    • syssrvroles

    See the ASE Utility Guide for information about using the bcp utility.

  2. Quiesce the primary database to suspend all update activity, and generate a manifest file for the primary database.

    Log in to the primary ASE 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 ASE uses the manifest file to mount the devices created by the disk replication system in the following step.

  3. Use the disk replication system facilities to do the following:

    • Capture a snapshot (or point-in-time) image of all 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 ASE, 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

      See the Mirror Activator Administration Guide, Chapter 2, “Setting Up and Configuring Mirror Replication Agent.”

    See the documentation provided by your disk replication system vendor for more information about the procedures in this step.

  4. Resume update activity in the primary database after all procedures in step 3 are complete.

    NoteInitialize the Mirror Replication Agent before you resume update activity in the primary database.

    Log in to the primary ASE 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.

  5. Mount the standby devices in the standby ASE to recover the standby database, and then bring it online.

    1. Log in to the standby ASE 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 ASE for all primary database data and log devices.

      If necessary, invoke the mount command to remap the device paths to the standby devices in the standby ASE:

      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 ASE.

      When you invoke mount, ASE performs all 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 standby ASE completes the mount processing, bring the standby database online:

      online database sdb
      

      where sdb is the name of the standby database.

    NoteThe names of the standby database and primary database must be the same.