Preparing Hosts and Storage for Database FlashSnap

Setting Up Hosts

Database FlashSnap requires sufficient VERITAS Volume Manager disk space, and can be used on the same host that the database resides on (the primary host) or on a secondary host. Setting up a storage configuration for Database FlashSnap operations is a system administrator's responsibility and requires superuser (root) privileges. Database FlashSnap utilities do not address setting up an appropriate storage configuration.

Single-Host Configuration

The following figure, Example of a Database FlashSnap Solution on a Primary Hostshows the suggested arrangement for implementing Database FlashSnap solutions on the primary host to avoid disk contention.

Example of a Database FlashSnap Solution on a Primary Host

Click the thumbnail above to view full-sized image.

Two-Host Configuration

As shown in the figure below, Example of an Off-Host Database FlashSnap Solution,a Database FlashSnap configuration with two hosts allows CPU- and I/O-intensive operations to be performed for online backup and decision support without degrading the performance of the primary host running the production database. A two-host configuration also allows the snapshot database to avoid contending for I/O resources on the primary host.

For off-host processing applications, both the primary and secondary hosts need to share the storage in which the snapshot database is created. Both the primary and secondary hosts must be able to access the disks containing the snapshot volumes.

Example of an Off-Host Database FlashSnap Solution

Click the thumbnail above to view full-sized image.

Host and Storage Requirements

Before using Database FlashSnap, ensure that:

• All files are on VxFS file systems over VxVM volumes. Raw devices are not supported.
• Symbolic links to datafiles are not supported.
• ORACLE_HOME is on a separate file system.
• Archive logs are on a separate VxFS file system and are on a different VxFS file system than Oracle datafiles or ORACLE_HOME.
• The database does not contain BFILES and external tables.
• Oracle datafiles, archive logs, redo logs, and control files are in a single disk group.

In addition, before attempting to use Database FlashSnap with two hosts, ensure that:

• The versions of VERITAS Storage Foundation for Oracle on the primary and secondary hosts are the same.
• The same version of Oracle is installed on both hosts the Oracle binaries and datafiles are on different volumes and disks.
• The UNIX login for the database user and group must be the same on both hosts.
• You have a VERITAS Storage Foundation 4.1 for Oracle Enterprise Edition license on both hosts.

Creating a Snapshot Mirror of a Volume or Volume Set Used by the Database

With Database FlashSnap, you can mirror the volumes used by the database to a separate set of disks, and those mirrors can be used to create a snapshot of the database. These snapshot volumes can be split and placed in a separate disk group. This snapshot disk group can be imported on a separate host, which shares the same storage with the primary host. The snapshot volumes can be resynchronized periodically with the primary volumes to get recent changes of the datafiles. If the primary datafiles become corrupted, you can quickly restore them from the snapshot volumes. Snapshot volumes can be used for a variety of purposes, including backup and recovery, and creating a clone database.

You must create snapshot mirrors for all of the volumes used by the database datafiles before you can create a snapshot of the database. This section describes the procedure used to create snapshot mirrors of volumes.

You can use the vxsnap CLI command or the GUI to create a snapshot mirror. Creating a snapshot mirror using the GUI is relatively easy. Because the time required to synchronize a snapshot mirror can be long, using the command line is recommended when resynchronizing snapshot mirrors.

Prerequisites

• You must be logged in as superuser (root).
• The disk group must be version 110 or later. For more information on disk group versions, see the vxdg(1M) online manual page.
• Be sure that a data change object (DCO) and a DCO log volume are associated with the volume for which you are creating the snapshot.
• Persistent FastResync must be enabled on the existing database volumes and disks must be assigned for the snapshot volumes. FastResync optimizes mirror resynchronization by tracking updates to stored data that have been missed by a mirror. When a snapshot mirror is reattached to its primary volumes, only the updates that were missed need to be re-applied to resynchronize it. FastResync increases the efficiency of the volume snapshot mechanism to better support operations such as backup and decision support. For detailed information about FastResync, see the VERITAS Volume Manager Administrator's Guide.
• Snapshot mirrors and their associated DCO logs should be on different disks than the original mirror plexes, and should be configured correctly for creating snapshots by the system administrator.
• When creating a snapshot mirror, create the snapshot on a separate controller and separate disks from the primary volume.
• Allocate separate volumes for archive logs.
• Do not place any datafiles, including control files, in the $ORACLE_HOME/dbs directory.

Usage Notes

• Create a separate disk group for Oracle database-related files.
• Do not share volumes between Oracle database files and other software.
• ORACLE_HOME cannot be included in the snapshot mirror.
• Resynchronization speed varies based on the amount of data changed in both the primary and snapshot volumes during the break-off time.
• Do not share any disks between the original mirror and the snapshot mirror.
• Snapshot mirrors for datafiles and archive logs should be created so that they do not share any disks with the data of the original volumes. If they are not created in this way, the VxVM disk group cannot be split and, as a result, Database FlashSnap will not work.

---

  Note    Database FlashSnap commands support third-mirror break-off snapshots only. The snapshot mirror must be in the SNAPDONE state.

---

---

 Caution    The procedure given in this section is for existing volumes without existing snapshot plexes or associated snapshot volumes.

---

  To create a snapshot mirror of a volume or volume set

1. To prepare the volume for being snapshot, use the vxsnap prepare command:
     # vxsnap -g diskgroup prepare volume \
     alloc="storage_attribute ..."

   ---

     Note    The vxsnap prepare command automatically creates a DCO and DCO volumes and associates them with the volume, and enables Persistent FastResync on the volume. Persistent FastResync is also set automatically on any snapshots that are generated from a volume on which this feature is enabled.

   ---

   ---

     Note    For enabling persistent FastResync on a volume in VxVM 4.1, either from the command line or from within a script, use the vxsnap prepare command as described above.

   ---

2. To verify that FastResync is enabled on the volume, use the vxprint command:
      # vxprint -g diskgroup -F%fastresync volume_name

   This returns on if FastResync is on. Otherwise, it returns off.

3. To verify that a DCO and DCO log volume are attached to the volume, use the vxprint command:
      # vxprint -g diskgroup -F%hasdcolog volume_name

   This returns on if a DCO and DCO log volume are attached to the volume. Otherwise, it returns off.

4. Create a mirror of a volume:
      # vxsnap -g diskgroup addmir volume_name alloc= diskname

   ---

     Note    There is no option for creating multiple mirrors at the same time. Only one mirror can be created at a time.

   ---

5. List the available mirrors:
      # vxprint -g diskgroup -F%name -e"pl_v_name in \"volume_name\""

   ---

     Note    The following two steps enable database FlashSnap to locate the correct mirror plexes when creating snapshots.

   ---

6. Set the dbed_flashsnap for the data plex you want to use for breaking off the mirror. You can choose any tag name you like, but it needs to match the tag name specified in the snapplan.
      # vxedit -g diskgroup set putil2=dbed_flashsnap plex_name
7. Verify that the dbed_flashsnap tag has been set to the desired data plex:
   # vxprint -g diskgroup -F%name -e"pl_v_name in \"volume_name\" \
   && p2 in \"dbed_flashsnap\""

If you require a backup of the data in the snapshot, use an appropriate utility or operating system command to copy the contents of the snapshot to tape or to some other backup medium.

Example

The following example shows the steps involved in creating a snapshot mirror for the volume data_vol belonging to the disk group PRODdg.

Prepare the volume data_vol for mirroring:

Verify that FastResync is enabled:

Verify that a DCO and a DCO log are attached to the volume:

Create a snapshot mirror of data_vol:

List the data plexes:

Decide which data plex you want to use and set the dbed_flashsnap tag for it:

Verify that the dbed_flashsnap tag has been set to the desired data plex, data_vol-02:

To verify that the snapshot volume was created successfully, use the vxprint -g <dg> command as follows:

Identify that the specified plex is in the SNAPDONE state. In this example, it is data_vol-02.

The snapshot mirror is now ready to be used.

Upgrading Existing Volumes to Use VERITAS Volume Manager 4.1

The procedure described in this section describes how to upgrade a volume created using a version older than VxVM 4.1 so that it can take advantage of database FlashSnap.

  To upgrade an existing volume created with an earlier version of VxVM:

1. Upgrade the disk group that contains the volume, to a version 120 or higher, before performing the remainder of the procedure described in this section. Use the following command to check the version of a disk group:
     # vxdg list diskgroup

   To upgrade a disk group to the latest version, use the following command:

   
     # vxdg upgrade diskgroup
2. If the volume to be upgraded has a DRL plex or subdisk from an earlier version of VxVM, use the following command to remove this:
     # vxassist [-g diskgroup] remove log volume [nlog=n]

   Use the optional attribute nlog=n to specify the number, n, of logs to be removed. By default, the vxassist command removes one log.

3. For a volume that has one or more associated snapshot volumes, use the following command to reattach and resynchronize each snapshot:
     # vxsnap [-g diskgroup] snapback snapvol

   If persistent FastResync was enabled on the volume before the snapshot was taken, the data in the snapshot plexes is quickly resynchronized from the original volume. If persistent FastResync was not enabled, a full resynchronization is performed.

4. Use the following command to turn off persistent FastResync for the volume:
     # vxvol [-g diskgroup] set fastresync=off volume
5. Use the following command to dissociate a DCO object from an earlier version of VxVM, DCO volume and snap objects from the volume:
     # vxassist [-g diskgroup] remove log volume logtype=dco
6. Use the following command on the volume to upgrade it:
     # vxsnap [-g diskgroup] prepare volume  
     alloc="disk_name1,disk_name2"

   Provide two disk names to avoid overlapping the storage of the snapshot DCO plex with any other non-moving data or DCO plexes.

   ---

     Note    The vxsnap prepare command automatically enables persistent FastResync on the volume and on any snapshots that are generated from it. It also associates a DCO and DCO log volume with the volume to be snapshot.

   ---

7. To view the existing DCO plexes and see whether there are enough for the existing data plexes, enter:
     # vxprint -g diskgroup

   There needs to be one DCO plex for each existing data plex.

8. If there are not enough DCO plexes for the existing data plexes, create more DCO plexes:
   # vxsnap [-g diskgroup] addmir dco_volume_name
   [alloc=disk_name]

   where dco_volume_name is the name of the DCO volume you are creating.

9. If the plex is in a SNAPDONE state, convert it to an ACTIVE state:
     # vxplex [-g diskgroup] convert state=ACTIVE data_plex
10. Convert the data plexes to a SNAPDONE state and associate a DCO plex with the data plex that will be used for snapshot operations:
    # vxplex [-g diskgroup] -o dcoplex=dco_plex_name convert \
    state=SNAPDONE data_plex

    where dco_plex_name is the name of the DCO plex you are creating.

Example

Upgrade the disk group, PRODdg.

Remove the DRL plexes or subdisks, belonging to an earlier version of VxVM, from the volume to be upgraded.

Reattach any snapshot volume back to the primary volume to be upgraded.

Turn off FastResync on the volume to be upgraded.

Disassociate and remove any older DCO object and DCO volumes.

Upgrade the volume by associating a new DCO object and DCO volume.

View the existing DCO plexes and plex state.

Scenario 1

In this scenario, there are enough DCO plexes for the data plexes. Also, no data plex is associated with a DCO plex.

Convert the data plex state from SNAPDONE to ACTIVE.

Associate the data plex with a new DCO plex and convert it back to a SNAPDONE state.

Scenario 2

In this scenario, there are fewer DCO plexes than data plexes.

Add a DCO plex to the DCO volume using the vxassist mirror command.

Associate the data plex with the new DCO plex and convert it to a SNAPDONE state.