Compaq ProLiant 1000 Compaq Backup and Recovery for Microsoft SQL Server 6.X - Page 13

Compaq Backup and Recovery for Microsoft SQL Server 6.x Page 13 The recovery operation consists of restoring your data from the backup media. You will use the same utility to restore your data as you used to back it up - if you used a file based backup utility, you will use the same utility to restore your data, and if you used SQL Server to dump the database or the transaction log, you will use SQL Server to load your data. The same considerations that apply to backups also apply to restores. Restoring your database from an off-line backup involves restoring all database and transaction log files, including your master database file. All SQL Server databases remain unavailable until all files are restored. Restoring your database from an on-line backup typically involves dropping the damaged database and lost devices, and recreating both11. This creation of the database framework can be very timeconsuming, depending on the size of your database, and adds to the total time needed to restore your data. Then, after all database devices are created and an empty database is built, the most recent database dump can be loaded, followed by loading all subsequent dumps of the transaction log. The entire restore procedure locks the database and disallows any use. Other undamaged databases remain on-line and accessible. The level of success to recover all your data and the time required to do so depend on your backup strategy. The most important consideration is, if you can't restore your data, your backups are worthless. Therefore, spend time and effort to test your backup AND recovery strategy! More details on various SQL Server-based recovery scenarios, load requirements and other considerations can be found in the System Administrator's Guide or the manuals available with your backup software. We will analyze some considerations and performance characteristics later in this document. With SQL Server dumps to a disk device, each subsequent dump automatically adjusts the size of the existing file to reflect the amount of data dumped. For example, you initially dump 100MB to a DISKDUMP.DAT file, copy it onto tape, but do not delete the file. Then, the next day, you dump a transaction log (25MB of data) to the same dump device. SQL Server for Windows NT will adjust the size of the file to 25MB. Alternatively, you can have SQL Server append successive dumps to the same file (this is now the default in SQL Server 6.x). Microsoft recommends running database consistency checking on the database before performing database dumps. This checking includes DBCC CHECKDB, DBCC CHECKALLOC and DBCC CHECKCATALOG. If the database contains consistency errors, these errors will be included in the dump, and in the database once it is reloaded. These consistency errors may even prevent the database from being loaded. The execution of these consistency commands may, however, take extended periods of time. Refer to Microsoft SQL Server documentation for more information. Databases can be transferred between SQL Servers by doing an online dump at one server and then loading the dump into a database of the same size or larger at another server. However, when exchanging data this way, certain compatibility issues must be kept in mind: 1. Both SQL Servers must have the same Code Page and Sort Order. 2. Both servers must be of the same processor architecture (x86, MIPS, etc). 3. A dump done at a version 4.21x SQL Server can be loaded at a version 6.x SQL Server, but not vice versa. 4. A dump done at a version 6.0 SQL Server can be loaded at a version 6.5 SQL Server, but not vice versa. 5. A dump done at a Microsoft SQL Server cannot be loaded at a non-Microsoft SQL Server. If you encounter any of the above issues your 11 If the database is not damaged, you can reload the backup over the old database. 1997 Compaq Computer Corporation, All Rights Reserved Doc No 444A/0797