15.10. Restoring an RDBMS The process of restoring an RDBMS varies according to the backup methods that you used, of course. How you proceed to restore is based on the status of your nondata and data disks and whether you are able to do partial restores online. 15.10.1. Loss of Any Nondata Disk A data disk is defined as any disk that contains a database object. (Database object and other terms are defined earlier in this chapter.) If you keep your database objects intact, you actually don't need to restore the database, you've just got to restore all the parts that make it work! This can range from a restore of a single database setup file to a complete restore of everything on another system.
Executables -
Your database can't work if its executables aren't there. This part of the recovery is much simpler if you have all your executables located in a special filesystem.
Setup files -
In a pinch, you can restore the executables by copying them from a known good system, but that won't work for your database setup files. Each instance often has an initialization file that sets up certain variables like the instance name and the location of the master database. These setup files usually can be recreated if you have good logs that tell you how you made them the first time, but it is probably easier to recover them from backup.
Customized OS files -
Databases often require you to edit system configuration files such as /etc/system. Changes to these files might include things like customizing shared memory or changing the TCP port over which software will communicate. If you are restoring onto a brand new install or onto another system, these changes will need to be repeated, and often changes to your OS files are forgotten or poorly documented. Unless you properly prepare for this situation, it's probably easier to just follow the installation instructions for a standard installation. If you're reading this in advance of such an outage, now is the time to find out what these changes are and document them. If you know what files are typically changed, you can even write a program that automatically documents them for you.
License setup files -
Database products have not typically used heavy licensing enforcement systems, but this will probably change over time. If yours does use such a system (e.g., FlexLM), you need to restore these files before your database will function properly. 15.10.2. Loss of a Data Disk The complexity and difficulty of your restore can vary greatly depending on which data disk you lost and how well you prepared in advance for such a loss.
Master database -
The complete loss of a Sybase or SQL Server's master database, Informix rootdbs, DB2's catalog, or Oracle's control file is very difficult to recover fromso much so that you need to ensure that it never happens. (You'll be sorry if you don't!) Mirror your Sybase master database. Mirror your DB2 catalog. Mirror your Oracle control files. Just do it. Even if you can't afford enough disk to mirror anything else, mirror this. It doesn't take up that much extra disk space, and the amount of time and frustration you will save yourself is immense. This is the easiest thing you can do to save huge amounts of time in a major restore.
Other databases -
Unless you are using Oracle (which has a one-to-one database-to-instance relationship), you may have multiple databases within an instance. If you lose only one device within a database (other than the master database), recovering from this is not too bad. You also probably can leave the rest of the instance and any other databases online while you are doing the restore. The best thing you can do to automate restoring single databases is to properly document where they are and what devices they consist of.
Backups -
One of the most popular ways to back up a database is to save it to disk and then allow the filesystem backup program to put it onto a backup volume. This is a very efficient method for many reasons. However, it does have one downside. Suppose you lost a data disk and the disk on which you store the backups. You would first have to restore the disk backup file from the backup volume, then restore the database from the disk file. If this two-step procedure is required, it will take longer than recovering straight from a backup volume.
Transaction log backups -
The same rule applies to the backups of your transaction logs. You will need every one of these that were made since the last full or incremental database backup. Before you start a large restore, check the time that the backup was made and make sure that you have all the transaction log backups since then. If you don't, you can start restoring them before you actually need them. Losing the Master Database Recovering the master database is full of Catch-22s because a lot of configuration and status information is stored inside that database. This information can be recreated if you lose it, but it must be recreated manually. You must have a complete history of the instance, how it was put together, where the database file and logfiles are, and what status they are in. Then you have to tell the master database all the things that it should know already. This won't be too hard if you saved all this information in an easy-to-find location up front. If not, you're in for a long, painful recovery. |
 | If you do database backups infrequently, you may need a significant number of transaction log backups to complete the restore. While restoring them, you must be careful to have enough space to do so. You may have to restore them into an alternate location or compress them. You then can move (or uncompress) them a few at a time as the restore program asks for them. |
|
Online transaction logs -
This is where you can suffer data loss. Even if you have a good backup and all the transaction logs since the last backup, you can be in trouble if you lose the data with the online logs in it. This would be the disk with Informix's logical log or Oracle's online redo logs. (Sybase, SQL Server, and DB2 store the online transaction log in the master database.) One way to prevent this tragedy is to mirror this log. 15.10.3. Online Partial Restores Some databases allow you to bring part of the database online while leaving one tablespace or datafile offline. This partial availability may allow you more time to complete a difficult restore or reduce the overall impact to your user community. This is especially true if the portion of the database that you are restoring contains a table that is not accessed frequently. Before considering such a restore, though, consider these factors:
Interdependency of data within the database -
If the table contains data that is not accessed frequently, this may be a perfect candidate for a partial restore. You also might consider such a restore if the rest of the database can function normally (or in a slightly diminished capacity) without this table. However, suppose the database is the sales database, and this table contains all the actual sales transactions. The rest of the database is fine (e.g., names, phone numbers, addresses), but the sole purpose of this database is to track these sales. Without this table of transaction data, the database is useless. Since doing a partial restore increases the overall restore time, doing a partial restore would be a bad idea in this case.
Physical relationship between tables and tablespaces -
Most database backup products do not allow you to restore on the table level. They sometimes allow you to restore on the tablespace level, however. Suppose you have lost one disk. You need to recover the tablespace that this disk resides in, right? Suppose that you had a partitioned table that resides on multiple tablespaces. That would mean that the entire table would be unavailable. If this table is not needed for normal operation, as described before, you might consider a partial restore. Again, however, remember that a partial restore increases your overall restore time.
Time requirement for a complete restore -
Some environments don't want to hear about partially functioning databases. "Tell me when it's up. Don't say it's almost up or partially up, just tell me when you're done!" These environments are more concerned with overall downtime and should be treated thusly. You need to restore the database in the fastest way possible. That probably would be to shut down the database and restore the affected tablespace. |
