Veritas InfoScale™ 7.4 Solutions Guide - Solaris

To set up a replica database for off-host decision support

1. If you have not already done so, prepare the off-host processing 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. On the primary host, 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 database_dg 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, prepare an empty volume for the snapshot.

   Then use the following command to create the snapshot:

   # vxsnap -g database_dg 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 database_dg make source=vol1/snapvol=svol1 \
   source=vol2/snapvol=svol2 source=vol3/snapvol=svol3

   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 the example. Note that if the replica database must be able to be rolled forward (for example, if it is to be used as a standby database), the primary database must be in LOGRETAIN RECOVERY mode.

   #!/bin/ksh
   #
   # script: backup_start.sh
   #
   # Sample script to suspend I/O for a DB2 database.
   #
   # Note: To recover a database using backups of snapshots, the database
   # must be in LOGRETAIN mode.
   
   db2 <<!
   connect to database
   set write suspend for database
   quit
   !

   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 the example.

   #!/bin/ksh
   #
   # script: backup_start.sh
   #
   # Sample script to quiesce example Sybase ASE database.
   #
   # Note: The "for external dump" clause was introduced in Sybase
   # ASE 12.5 to allow a snapshot database to be rolled forward.
   # See the Sybase ASE 12.5 documentation for more information.
   
   isql -Usa -Ppassword -SFMR <<!
   quiesce database tag hold database1[, database2]... [for external dump]
   go
   quit
   !

   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.

4. On the primary host, refresh the contents of the snapshot volumes from the original volume using the following command:

   # vxsnap -g database_dg refresh snapvol source=vol \
     [snapvol2 source=vol2]... syncing=yes

   The syncing=yes attribute starts a synchronization of the snapshot in the background.

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

   # vxsnap -g database_dg refresh svol1 source=vol1 \
      svol2 source=vol2 svol3 source=vol3

5. If you temporarily suspended updates to volumes in step 3 , 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 the example.

   #!/bin/ksh
   #
   # script: backup_end.sh
   #
   # Sample script to resume I/O for a DB2 database.
   #
   
   db2 <<!
   connect to database
   set write resume for database
   quit
   !

   As the Sybase database administrator, release the database from quiesce mode using a script such as that shown in the example.

   #!/bin/ksh
   #
   # script: backup_end.sh
   #
   # Sample script to release example Sybase ASE database from 
     quiesce mode.
   
   isql -Usa -Ppassword -SFMR <<!
   quiesce database tag release
   go
   quit
   !

6. Use the following command to wait for the contents of the snapshot to be fully synchronous with the contents of the original volume:

   # vxsnap -g database_dg syncwait snapvol

   For example, to wait for synchronization to finish for all the snapshots svol1, svol2 and svol3, you would issue three separate commands:

   # vxsnap -g database_dg syncwait svol1
   # vxsnap -g database_dg syncwait svol2
   # vxsnap -g database_dg syncwait svol3

   Note:

   You cannot move a snapshot volume into a different disk group until synchronization of its contents is complete. You can use the vxsnap print command to check on the progress of synchronization.

7. On the primary host, use the following command to split the disks containing the snapshot volumes into a separate disk group, snapvoldg, from the original disk group, database_dg:

   # vxdg split database_dg snapvoldg snapvol ...

   For example to split the snap volumes from database_dg:

   # vxdg split database_dg snapvoldg svol1 svol2 svol3

8. On the primary host, deport the snapshot volume's disk group using the following command:

   # vxdg deport snapvoldg

9. On the off-host processing host where the replica database is to be set up, use the following command to import the snapshot volume's disk group:

   # vxdg import snapvoldg

10. VxVM will recover the volumes automatically after the disk group import unless it is set to not recover automatically. Check if the snapshot volume is initially disabled and not recovered following the split.

    If a volume is in the DISABLED state, use the following command on the off-host processing host to recover and restart the snapshot volume:

    # vxrecover -g snapvoldg -m snapvol ...

11. On the off-host processing host, 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

    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/snapvoldg/snap1_dbase_vol
    # mount -F vxfs /dev/vx/dsk/snapvoldg/snap1_dbase_vol \ 
      /rep/dbase_vol

    Note:

    For a replica DB2 database, the database volume must be mounted in the same location as on the primary host.

12. Copy any required log files from the primary host to the off-host processing host.

    For a Sybase ASE database on the primary host, 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 database directory on the off-host processing host.

13. As the database administrator, start the new database:

    If the replica DB2 database is not to be rolled forward, use the following commands to start and recover it:

    db2start
    db2inidb database as snapshot

    If the replica DB2 database is to be rolled forward (the primary must have been placed in LOGRETAIN RECOVERY mode before the snapshot was taken), use the following commands to start it, and put it in roll-forward pending state:

    db2start
    db2inidb database as standby

    Obtain the latest log files from the primary database, and use the following command to roll the replica database forward to the end of the logs:

    db2 rollforward db database to end of logs

    For a Sybase ASE database, use a script such as that shown in the example.

    #!/bin/ksh
    #
    # script: startdb.sh <list_of_database_volumes>
    #
    # Sample script to recover and start replica Sybase ASE 
    # database.
    
    # Import the snapshot volume disk group.
    
    vxdg import $snapvoldg
    
    # Mount the snapshot volumes (the mount points must already 
    # exist).
    
    for i in $*
    do
       fsck -F vxfs /dev/vx/rdsk/$snapvoldg/snap_$i
       mount -F vxfs /dev/vx/dsk/$snapvoldg/snap_$i \
    ${rep_mnt_point}/$i
    done
    
    # Start the replica database.
    # Specify the -q option if you specified the "for external 
    # dump" clause when you quiesced the primary database.
    # See the Sybase ASE 12.5 documentation for more information.
    
    /sybase/ASE-12_5/bin/dataserver \
    [-q] \
    -sdatabase_name \
    -d /sybevm/master \
    -e /sybase/ASE-12_5/install/dbasename.log \
    -M /sybase
    
    # Online the database. Load the transaction log dump and 
    # specify "for standby_access" if you used the -q option
    # with the dataserver command.
    
    isql -Usa -Ppassword -SFMR <<!
    [load transaction from dump_device with standby_access
    go]
    online database database_name [for standby_access]
    go
    quit
    !

    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