2. Backup checksums
One
of the features introduced in SQL Server 2005 was the ability for
backups to verify the validity of pages as part of the backup process,
and for the backup itself to include a checksum.
When using the optional WITH CHECKSUM option of the BACKUP command as shown here, the backup process verifies the checksum of each page as the backup is performed, assuming the PAGE_VERIFY database option, is set to CHECKSUM (which is the default).
-- Verify Page Validity during backup with CHECKSUM
BACKUP DATABASE [AdventureWorks2008]
TO DISK = N'G:\SQL Backup\AdventureWorks.bak'
WITH CHECKSUM
The PAGE_VERIFY
option calculates and stores a checksum value for each database page
written to disk. When read from disk, the checksum is verified against
the page read and used to alert the presence of suspect pages.
The WITH CHECKSUM option of the BACKUP
command calculates and verifies the checksum value of each page as it's
read by the backup process. If a checksum error occurs, the backup
fails, unless the CONTINUE_AFTER_ERROR option is used. In
that case, the backup is flagged as containing errors and the suspect
page(s) are marked in the suspect_pages table in the msdb database.
In addition to verifying the checksum of each page, the WITH CHECKSUM
option calculates a checksum for the entire backup process. When a
database is restored from a backup created with the checksum option,
the restore process verifies the checksums as part of the restore
process, unless the NO_CHECKSUMCONTINUE_AFTER_ ERROR option is used. option is used. If a checksum error is found as part of the restore, the restore will fail, unless the
Although
backup checksums provide additional confidence in the validity of the
backups, they do introduce additional CPU overhead during the backup
process. Before enabling this option, ensure the overhead is measured
on a test system, particularly in cases where the additional overhead
may extend the backup window beyond the desired time frame. That being
said, the additional confidence this option provides is well worth the
typically small CPU overhead.
Another technique commonly used for backup assurance is the mirroring option.
3. Backup mirroring
There is no such thing as too many backups. One of the optional backup clauses is MIRROR TO. Here's an example:
-- Mirror the backup to a separate backup server using a UNC path
BACKUP DATABASE [AdventureWorks2008]
TO DISK = N'G:\SQL Backup\AdventureWorks-20080701.bak'
MIRROR TO DISK = '\\BACKUP-SERVER\SQL-Backups\AdventureWorks-20080701.bak'
WITH FORMAT
The MIRROR TO
clause allows a backup to be streamed to multiple destinations. The
typical use of this option is for making a duplicate backup on a file
server using a Universal Naming Convention (UNC) path to a file share
(in the previous example, \\BACKUP-SERVER\SQL-Backups). This option
provides multiple advantages:
Additional backups for protection against media failure.
Different
retention periods for different locations; for example, the file server
backups can be retained for a longer period on disk when compared to
the backup file on the database server.
The
tape archive process can archive from the file share rather than the
database server. Not only does this reduce the additional load the tape
archive process places on the database server, it also avoids the need
for tape drivers and associated software to be installed on the
database server.
In concluding this section, let's take a look at the challenge of coordinating backups across multiple databases.
4. Transaction log marks
A
common backup requirement is for coordinated backups across multiple
databases. This is usually a requirement for the restore process rather
than the backup—when a database is restored, all associated databases
must be restored to exactly the same point.
Synchronized restores are enabled using transaction log marks.
Before we take a look at using them in a restore scenario, let's see
how they're used in recovering from an unintended action. Consider the
following statement, which increases product prices by 2 percent:
-- Update all prices by 2%
BEGIN TRANSACTION updatePrices WITH MARK 'Updating Prices Now';
UPDATE Products
SET Price = Price * 1.02
COMMIT TRANSACTION updatePrices
Let's imagine we only intended to update some products, not all
of them, as shown in the previous statement. Short of running
additional commands to roll back the price increase (and other flow-on
effects), we'd be looking at a database restore, but if we can't
remember the time of the update, a transaction log recovery using the STOPAT option won't help.
One of the optional clauses we used in the update price transaction was WITH MARK,
and we can use that in a restore command. After performing a restore of
a full backup in NORECOVERY mode, we can then restore a transaction log
backup made after the transaction to the point immediately before the
mark, using the STOPBEFOREMARK option:
-- After restoring the full backup, roll forward the transaction log
-- Use the STOPBEFOREMARK option to stop before the marked transaction
RESTORE LOG [AdventureWorks2008]
FROM DISK = N'G:\SQL Backup\AdventureWorks-log.bak'
WITH RECOVERY, STOPBEFOREMARK = 'updatePrices'
GO
Now
that's all well and good (and very handy), but how does that help us
with coordinating backups and restores across multiple databases? Well,
by encapsulating statements that update multiple databases within a
single marked transaction, we can achieve the desired result (see listing 1).
Example 1. Marking multiple transaction logs for coordinated restores
-- Use a dummy transaction to mark multiple databases
-- If required, each database can be restored to the same point in time
BEGIN TRANSACTION backupMark WITH MARK
UPDATE db1.dbo.dummytable set col1 = 1
UPDATE db2.dbo.dummytable set col1 = 1
-- other databases here ...
COMMIT TRANSACTION backupMark
|
By executing a simple update statement in multiple databases within one transaction,
we're marking the transaction log of each database at the same time.
Such an update statement could be executed immediately before
transaction log backups are performed, thus enabling the backups to be
restored to the same point in time using the STOPBEFOREMARK that we saw earlier. Bear in mind, however, that data entered in the databases after this transaction will be lost, and this is an important consideration in a coordinated restore scenario.
Using
transaction marks to enable synchronized restores across multiple
databases is one example of using backup/restore features beyond the
basics. While a basic backup/restore approach may suffice for small
databases, it's insufficient for very large databases (VLDBs). We covered the use of filegroups as a mechanism for
enabling enhanced administration options. We also explored a best
practice whereby user objects are placed on secondary filegroups so
that the only objects in the primary filegroup are system objects.
Let's take a look at that process in more detail, and see how it can be
used to minimize the user impact of a restoration process.
