Creating a Replica Database on the Same Host

As illustrated in Example System Configuration for Decision Support on the Primary Host, the primary database volumes to be backed up, dbase_vol and dbase_logs, are configured on disks attached to controllers c1 and c2, and the snapshots are created on disks attached to controllers c3 and c4.

Example System Configuration for Decision Support on the Primary Host

Click the thumbnail above to view full-sized image.

To set up a replica database to be used for decision support on the primary host:

1. If you have not already done so, prepare the host to use the snapshot volume that contains the copy of the database tables. Set up any new database logs and configuration files that are required to initialize the database.
2. Use the following command to make a full-sized snapshot, snapvol, of the tablespace volume by breaking off plexes from the original volume:
   # vxsnap -g volumedg make source=volume/newvol=snapvol/nmirror=N

   The nmirror attribute specifies the number of mirrors, N, in the snapshot volume.

   If the volume does not have any available plexes, or its layout does not support plex break-off, use the procedure described in Creating a Volume for Use as a Full-Sized Instant Snapshot to prepare an empty volume for the snapshot, and then use the following command to create the snapshot:

   
   # vxsnap -g volumedg make source=volume/snapvol=snapvol

   If a database spans more than one volume, specify all the volumes and their snapshot volumes as separate tuples on the same line, for example:

   
   # vxsnap -g dbasedg make source=vol1/newvol=svol1/nmirror=2 \
   source=vol2/newvol=svol2/nmirror=2 \
   source=vol3/newvol=svol3/nmirror=2

   If you want to save disk space, you can use the following command to create a space-optimized snapshot instead:

   
   # vxsnap -g volumedg make \
   source=volume/newvol=snapvol/cache=cacheobject

   The argument cacheobject is the name of a pre-existing cache that you have created in the disk group for use with space-optimized snapshots. See Creating a Shared Cache Object for more information.

   If several space-optimized snapshots are to be created at the same time, these can all specify the same cache object as shown in this example:

   
   # vxsnap -g dbasedg make source=vol1/newvol=svol1/cache=dbaseco \
   source=vol2/newvol=svol2/cache=dbaseco \
   source=vol3/newvol=svol3/cache=dbaseco

   See the section "Creating a Share Cache Object" in the "Administering Volume Snapshots" chapter of the VERITAS Volume Manager Administrator's Guide for more information.

   ---

     Note    This step sets up the snapshot volumes, and starts tracking changes to the original volumes. When you are ready to create the replica database, proceed to step 3.

   ---

3. If the volumes to be backed up contain database tables in file systems, suspend updates to the volumes:
   • DB2 provides the write suspend command to temporarily suspend I/O activity for a database. As the DB2 database administrator, use a script such as that shown in Script to Suspend I/O for a DB2 Database. Note that to allow recovery from any backups taken from snapshots, the database must be in LOGRETAIN RECOVERY mode.
   • Oracle supports online backup by temporarily suspending updates to the datafiles of the tablespaces, provided that the database is running in archive mode and the tablespaces are online. As the Oracle database administrator, put each tablespace into hot backup mode using a script such as that shown in Script to Put Oracle Database into Hot Backup Mode.
   • Sybase ASE from version 12.0 onward provides the Quiesce feature to allow temporary suspension of writes to a database. As the Sybase database administrator, put the database in quiesce mode by using a script such as that shown in Script to Quiesce Sybase ASE Database.

   If you are using Sybase ASE 12.5, you can specify the for external dump clause to the quiesce command. This warm standby method allows you to update a replica database using transaction logs dumped from the primary database. See Updating a Warm Standby Sybase ASE 12.5 Database for more information.

4. Refresh the contents of the snapshot volumes from the original volume using the following command:
   # vxsnap -g volumedg refresh snapvol source=vol \
     [snapvol2 source=vol2]...

   For example, to refresh the snapshots svol1, svol2 and svol3:

   
   # vxsnap -g dbasedg refresh svol1 source=vol1 svol2 source=vol2 \
   svol3 source=vol3
5. If you temporarily suspended updates to volumes in step 2, release all the tablespaces or databases from suspend, hot backup or quiesce mode:
   • As the DB2 database administrator, use a script such as that shown in Script to Resume I/O for a DB2 Database.
   • As the Oracle database administrator, release all the tablespaces from hot backup mode using a script such as that shown in Script to End Oracle Database Hot Backup Mode.
   • As the Sybase database administrator, release the database from quiesce mode using a script such as that shown in Script to Release Sybase ASE Database from Quiesce Mode.

   If you are using Sybase ASE 12.5, you can specify the for external dump clause to the quiesce command. This warm standby method allows you to update a replica database using transaction logs dumped from the primary database. See Updating a Warm Standby Sybase ASE 12.5 Database for more information.

6. For each snapshot volume containing tablespaces, check the file system that it contains, and mount the volume using the following commands:
   # fsck -F vxfs /dev/vx/rdsk/diskgroup/snapvol
   # mount -F vxfs /dev/vx/dsk/diskgroup/snapvol mount_point

   ---

     Note    On Linux, use the -t option, and on AIX, use the -V option, instead of the -F option for both commands.

   ---

   For example, to check the file system in the snapshot volume snap1_dbase_vol, and mount it on /rep_dbase_vol:

   
   # fsck -F vxfs /dev/vx/rdsk/dbasedg/snap1_dbase_vol
   # mount -F vxfs /dev/vx/dsk/dbasedg/snap1_dbase_vol \ 
     /rep_dbase_vol
7. Copy any required log files from the primary database to the replica database.
   • For an Oracle database, copy the archived log files that were generated while the database was in hot backup mode to the new database's archived log directory (for example, /rep_archlog).
   • For a Sybase ASE database, if you specified the for external dump clause when you quiesced the database, use the following isql command as the database administrator to dump the transaction log for the database:
   
      dump transaction to dump_device with standby_access

   Then copy the dumped transaction log to the appropriate replica database directory.

8. As the database administrator, start the new database:
   • For an Oracle database, use a script such as that shown in Script to Complete, Recover and Start Replica Oracle Database.
   • For a Sybase ASE database, use a script such as that shown in Script to Start Replica Sybase ASE Database.

   If you are using the warm standby method, specify the -q option to the dataserver command. Use the following isql commands to load the dump of the transaction log and put the database online:

   
      load transaction from dump_device with standby_access
      online database database_name for standby_access

   If you are not using the warm standby method, use the following isql command to recover the database, roll back any uncommitted transactions to the time that the quiesce command was issued, and put the database online:

   
      online database database_name

When you want to resynchronize a snapshot with the primary database, shut down the replica database, unmount the snapshot volume, and go back to step 3 to refresh the contents of the snapshot from the original volume.