| Craig S. Mullins
Database Performance Management
The DBA Corner
by Craig S. Mullins
Database Disaster Planning
A disaster recovery plan is like insurance – you're glad you have it, but you hope you don't need it. With automobile insurance, you pay a regular fee so that you are covered if you have an accident. A disaster recovery plan is similar because you pay to implement your disaster recovery plan by designating a disaster recovery site, shipping backup copies of the data off-site, preparing recovery jobs, and practicing the recovery procedures.
But what is a disaster? One definition of a disaster is “any event that has a small chance of transpiring, a high level of uncertainty, and a potentially devastating outcome.” Most of us have witnessed a disaster situation, at least on television. Floods, earthquakes, hurricanes, and fires are some examples of natural disasters. Disasters can also be man-made, such as electric failure, bursting pipes, and war. The terrorist attacks of September 11, 2001 certainly qualify as disasters, especially for the former tenants of the World Trade Center towers.
Even though most of us have never personally lived through a disaster like those we see on television, many of us have had our basements flooded or been in an automobile accident. A disaster does not have to have global consequences in order for it to be a disaster to you.
Location plays a part in
disaster planning (tornadoes and hurricanes near a coast, snow and ice
in the north, etc.). But many types of disasters are not
location-specific. Terrorism, sabotage, computer viruses, vandalism,
air conditioning or heating failures, and health hazards can happen
anywhere on the planet. So every company should have a comprehensive
and tested disaster plan that details how to resume business
operations in the event of a disaster. Companies with a disaster plan
will be able to service their customers again after a disaster much
quicker than those companies without a disaster plan. Indeed, a
company facing a disaster without a disaster recovery plan may never
resume business. So even though disasters are unpredictable and
unlikely, every organization should have a plan to cope with them.
Your disaster recovery plan must handle business issues such as alternate locations for conducting business, communication methods to inform employees of new locations and procedures, and publicity measures to inform customers how to transact business with the company post-disaster. A component of that plan must be the overall plan for resuming data processing and IT operations.
A big component of the plan is the resumption of DBMS operations. It is the responsibility of the DBA to ensure that the DBMS is restartable at a remote location and that all critical databases are accounted for in the disaster recovery plan. The key for the DBA is to be able to integrate at two levels: the disaster recovery planning level and the day-to-day backup and recovery planning level. Database backups are required both on-site for regular recovery and off-site for disaster recovery. The DBA must incorporate both levels of recovery planning into the regular backup mechanisms deployed for the company’s databases.
But before your company can ascertain the appropriate level of (disaster) recoverability, you must analyze the risks and determine your objectives. One goal of disaster recovery is to minimize costs resulting from losses of, or damages to, the resources or capabilities of your IT facilities. The success of any database disaster recovery plan depends a great deal on being able to determine the risks associated with data loss. What is the impact to your business if the data is lost? It will differ for each piece and type of data.
There are three different types of business risk associated with data loss: financial loss, business service interruption, and legal responsibilities. Within each category, there are varying degrees of risk. Each application has a different impact on the company's bottom line the longer it is unavailable.
Different data and applications also will have different impacts on business service interruption and legal responsibilities. Data and application should be performed to determine the level and type of risk. The disaster recovery plan needs to factor all types of risk into the resulting plan to determine which applications and database objects are most critical.
As you create your database disaster recovery plan, remember that business needs must dictate your priorities – not technical needs and issues. It is a good idea to rank your applications into groups to determine which applications have the biggest impact if they are not available:
The criticality of an application must be determined based on the overall importance of the application to the organization. As a DBA you must create the disaster recovery plans with application criticality in mind. In this way the most important data that is absolutely necessary can be recovered and made available immediately in the event your company experiences a disaster.
Portions of this column were adapted
from Craig’s forthcoming book Database Administration: Practices and
Policies, to be published by Addison Wesley early in 2002.
Trends and Applications, November 2001.
© 2001 Craig S. Mullins, All rights reserved.