A hardware-based availability solution for SQL Server 2000
Split-mirror backup technology can help you achieve higher database availability by letting you back up the database very quickly, typically in a matter of seconds. This speed lets you make database backups more frequently. Also, you can restore a database from a split-mirror backup quickly, dramatically reducing the time a database is unavailable during a restore operation. Split-mirror backup can nearly eliminate the use of the database server's resources to perform the backup. Plus, you can initialize a secondary server much more quickly than with the standard SQL Server backup-and-restore technology.
Keep in mind that split-mirror backup requires specialized hardware and software. It requires that database data be stored on a disk subsystem with mirroring—typically RAID 10 on a SAN. In addition, it requires a specialized volume-management software utility to communicate with SQL Server 2000. You must balance the benefits of split-mirror technology against the cost of the required disk system hardware and software. For more information about required hardware and software, see the sidebar "Split Mirror, SAN, and NAS."
How Split-Mirror Backup Works
To understand how split-mirror backup works, start by thinking of three distinct mirrored volume sets, as Figure 1 shows. Assume you've configured them as RAID 10 in a SAN. The original database was created on two mirrored volume sets for fault tolerance. Let's say that since that time, you've added a third mirrored set of drives, which you've synchronized with the first two mirrors, and you're keeping a full copy of all the data current on the third set as well. All the mirrored sets are in the same disk subsystem, so SQL Server's disk writes go to all three drive sets simultaneously. With all this in place, you can make a split-mirror backup.
When you make a split-mirror backup, you use the SAN vendor's software and hardware to separate or "split off" the third mirrored drive set from the database's two primary mirrored drive sets. This nearly instantaneous split creates a backup of the database on the split drive set at a given point in time. (Note that the data copying occurs before the split, during the initial synchronization process.) The drive set that's split off is called a Business Continuance Volume (BCV) or a clone. The mirrored sets that remain behind ensure disk-system fault tolerance for the database data.
You accomplish the split-mirror backup by using a software utility supplied by the storage vendor or third-party backup-software supplier. When you make the backup, the split-mirror utility software issues a backup command to SQL Server's backup Virtual Device Interface (VDI) API. The backup utility software receives the backup set metadata from SQL Server and stores it on the cloned drive set.
During the splitting process, a checkpoint occurs, and although SQL Server might still accept writes to the database, depending on the vendor's implementation of split-mirror technology, writes to the physical disk volumes are suspended. If disk writes were allowed during the split, one possible result is that only a portion of the disk blocks belonging to a SQL Server data page would be written to the third drive set. This result is called a torn page. The suspension of writes to disk prevents the clone from potentially capturing a torn data page during the splitting process. During the splitting process, disk reads are unaffected, so SQL Server can still read data from disk. The splitting process generally takes a few seconds or less—the exact amount of time depends on the storage vendor and your storage-subsystem hardware configuration.
After the splitting process, database write activity to the storage subsystem resumes, but only to the original two mirrored drive sets, as Figure 2 shows. You can use split-mirror technology to make a fast copy of a large database to another server. Using the resulting BCV as a backup set, you can restore it to another database server on the SAN, or you can archive the BCV to tape.
Remirroring the Original Database
Like all backups, the BCV becomes out of date as soon as the original database data changes. So, depending on your disk resources, you might want to reuse the BCV volume set for making another split-mirror backup later. Figure 3 shows how you can resynchronize the BCV with the original database mirrored set. Of course, as soon as you let SQL Server write to the BCV drive set, you can no longer use that drive set as a backup image for restoring. If you have only one BCV, remirroring can leave you vulnerable. To remedy this, make split-mirror backups to two BCV sets in rotation, and remirror only the older one. That way, if the remirroring fails, the newer BCV is available as a backup.
Synchronization takes much longer than splitting. The time required for synchronization depends on the storage vendor's technology and the amount of data involved, but it could take several hours. When the synchronization is complete, your server's array returns to the state that Figure 1 shows: You have three complete mirrored sets, and you're ready to make another backup.
Because these backups occur quickly and don't affect the database server's resources, you could make full database or database file backups several times a day, if necessary. The only limiting factor is the time that synchronization requires.
Prev. page
[1]
2
next page 
