SnapManager uses Database Consistency Checker (DBCC) to verify SQL Server databases. DBCC is a Microsoft SQL Server utility that verifies the page-level integrity of databases. See the following topics for more information:
SnapManager uses the DBCC CHECKDB command to verify the integrity of live databases as well as databases in SnapManager backup sets.
Live databases can be verified as a part of database migration and also as a part of a full database backup.
Databases in backup sets can be verified upon creation, separately, or before a restore.
Attention
The SnapManager Restore tab lists the backups that have been taken and the backup verification status of each. For more information, see Importance of verifying databases to be restored.
When you verify the databases in a backup set (as opposed to live databases), Microsoft DBCC requires that all of the databases files are mounted at the same time. At a more granular level this means that SnapManager, using SnapDrive commands, mounts all the LUNs that contain the backup sets selected for database verification.
In order to run the DBCC CHECKDB command, the verification server (whether local or remote) must have a sufficient number of drive letters available to mount all the LUNs that store the database backup sets you are verifying.
For example, suppose you want to run database integrity verification against backup sets containing five file groups using three transaction logs stored on on eight separate LUNs. In this case, the verification server would need to have a minimum of eight drive letters available.
If the verification server runs out of available drive letters while attempting to run DBCC CHECKDB for a SnapManager operation, the SnapManager operation will fail with the following message in the report log:
[SnapDrive Error]: There are no remaining drive letters available on the system. Please delete or disconnect a drive and retry.
The SnapManager operations that enable you to verify the databases in backup sets are as follows:
Running database verification on a production SQL Server is CPU-intensive for the host running the verification and also involves a substantial amount of activity on the storage system. For this reason, verification can degrade SQL Server response, particularly during work hours.
By default, a SnapManager full database backup operation runs DBCC immediately after the backup is finished. However, SnapManager provides the two options that enable you to separate the process of verification from the backup itself: deferred database verification and remote database verification.
Instead of allowing a full database backup to automatically verify the databases when the operation is finished, you can disable that feature. You can then run a separate database verification operation any time after the full database backup operation is finished.
To prevent database verification from affecting the performance of your production SQL Server computer, you can run verification on another SQL Server computer.
You can verify the databases in your SnapManager backup sets at various times.
By default, SnapManager verifies the databases in a backup set at the time the backup is created. This is simple and ensures that each database in the backup set is verified. However, this method significantly increases the time required to complete the backup. For a detailed description of how to start or schedule a full database backup with automatic database verification, see Creating a full database backup using SnapManager.
With this method, a single operation can be initiated to verify the databases contained in one or more backup sets that have already been created. You can start the verification immediately, or you can schedule the verification to occur later, when it does not affect performance or delay later backups. For a detailed description of how to start or schedule database verification, see Performing database verification using SnapManager.
If you attempt to restore from a backup set on which a database consistency check has not been run successfully, SnapManager prompts (but does not require) you to first verify the databases in that backup set. See Importance of verifying databases to be restored.
Regardless of when you verify the databases in a backup set, the verification can be done on the production SQL Server (the Windows host system running the SQL Server instance used to create the databases) or on a remote verification system (another SQL Server).
In the simplest SnapManager for SQL Server configuration, verification is run from the production SQL Server. However, because the Microsoft DBCC command used for the verification is CPU-intensive, performing the verification on the production SQL Server host system during peak usage could affect SQL Server performance.
Performing the verification on a remote system minimizes the impact of verification on SQL Server system resources and backup schedule. The requirements for a remote verification server are described in Requirements for a remote verification server. The procedure specifying a different SQL Server as the remote verification server is described in Selecting the database verification server.
Note
You cannot run database verification from a virtual SQL Server. For more information, see Requirements for a remote verification server.
Be aware of how SQL Server DBCC handles backward-compatibility between SQL Server versions of the verification server and SQL Server versions of the databases in the backup set.
Note
This combination is not optimal, because additional processing overhead is incurred each time an SQL Server 2000 database backup set is verified using an SQL Server 2005 verification server.
Copyright © 1994-2006, Network Appliance, Inc. All rights
reserved.
Part No. 215-01752_A0
File: bkpabou4.htm
Last updated: 01-Sep-2006 07:41:13