Database Administration: The Complete Guide to Practices and Procedures

Database Administration:The Complete Guide to Practices and ProceduresChapter 17Disaster Planning

1

AgendaThe Need for PlanningGeneral Disaster Recovery GuidelinesBacking Up The Database for Disaster RecoveryDisaster PreventionQuestions

A disaster recovery plan is like insuranceyoure glad you have it, but you hope you never need it. With automobile insurance, you pay a regular fee so that you are covered if you have an accidentin other words, its an investment. A disaster recovery plan is similar in that you invest in it by designating a disaster recovery site, shipping backup copies of the data off-site, preparing recovery jobs, and practicing the recovery procedures.

2

What is a Disaster?Sungard Recovery Services defines a disaster as any unplanned, extended loss of critical business applications due to lack of computer processing capabilities for more than a 48-hour period.An alternative definition: any event that has a small chance of transpiring, a high level of uncertainty, and a potentially devastating outcome.

Disaster recovery planning, also called contingency planning, is the process of preparing your organizations assets and operations in case of a disaster. But what is a disaster? Sungard Recovery Services (1995) provides a good definition of disaster: any unplanned, extended loss of critical business applications due to lack of computer processing capabilities for more than a 48-hour period. Your own definition may be more or less stringent with regard to the timeframe, but the basic definition is a sound one.

The DB2 Developers Guide (Mullins 2012) defines a disaster as any event that has a small chance of transpiring, a high level of uncertainty, and a potentially devastating outcome. This too, is a workable definition for a disaster.

3

The Need for PlanningA disaster does not have to have global consequences in order for it to be a disaster for you.How a disaster might impact your business is the sole purpose of disaster recovery planning. Recognize likely situations:If your business is on a coast, the likelihood of hurricanes, floods, and tornadoes increases. If your business is located in the north, blizzards and severe cold weather will pose more of a risk. California businesses are more apt to worry about earthquakes.

Most of us have witnessed a disaster, at least on television. Floods, earthquakes, hurricanes, and fires are some examples of natural disasters. Disasters can be man-made, such as electrical failure, bursting pipes, and war. 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 for you.

You must recognize potential disasters and understand their consequences. How these disasters might impact your business is the sole purpose of disaster recovery planning. If your business is on a coast, the likelihood of hurricanes, floods, and tornadoes increases. If your business is located in the north, blizzards and severe cold weather will pose more of a risk. California businesses are more apt to worry about earthquakes.

4

Even if your organization has not yet experienced a disaster, or is not in a high-risk area, does not absolve you from the need for contingency planning.Database disaster recovery must be an integral component of your overall business recovery plan.

Just because your organization has not yet experienced a disaster, or is not in a high-risk area, does not absolve you from the need for contingency planningespecially for your databases. In the wake of a disaster, companies with a disaster plan will be able to service their customers again much more quickly than those companies without one. Indeed, a company facing a disaster without a disaster recovery plan may never resume business.

Database disaster recovery must be an integral component of your overall business recovery plan. A disaster recovery plan must be global in scope. It 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. It must restore the IT infrastructure. Finally, and most important to our discussion, a component of that plan must be for the recovery of database and DBMS operations.

5

Risk and Recovery

Importance of the dataVolatility of the dataStaticDynamicCriticalNon-critical4231

To what extent should a company take disaster planning? Before your company can ascertain the appropriate level of recoverability, you must analyze the risks and determine the objectives.

The goal of a disaster recovery plan is to minimize the 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?

As with local database recovery, the DBA must perform an evaluation of each database object for disaster recovery. Recall from our previous lesson (Chapter 16) the grid we used to evaluate database objects for criticality and volatility. Although the emphasis in disaster recovery is more on criticality than volatility, the dynamism of the data still plays a role. Although it is quite likely that each database object will be graded similarly for disaster recovery purposes, it is still a good practice to reevaluate each database object in terms of its complete loss in a disaster.

6

BusinessOperationsITOperationsDBMSOperations

Business Needs Dictate PrioritiesVery critical applications. The most-critical applications in your organization will require current data upon recovery. Business-critical applications. Important to your organization and should be the next group to recover after the very critical applications.Critical applications. Differentiated from a business critical application by its immediacy or data currency needs. This group of applications, though important, need not be available immediately. Required Applications. Not critical but must be backed up such that they can be recovered at the remote site if needed. Noncritical applications. Need not be supported in the event of a disaster. Very few applications fall into this category.

Very critical applications. The most-critical applications in your organization will require current data upon recovery. These applications are the most difficult for which to develop a disaster plan because more steps are required for off-site backup and recovery. Additionally, the most-critical applications in your shop will be the first ones that must be made operational at the recovery site. Try to limit the number of applications designated as very critical; any more than a half dozen or so will be unmanageable in a disaster situation.Business-critical applications. Business-critical applications are important to your organization and should be the next group to recover after the very critical applications. A business-critical application frequently requires current data, but it may not be available at the remote site within the first couple of days. For example, consider the applications for a telephone service provider. The system that delivers phone service would be a very critical application; customer billing would be a business-critical application.Critical applications. A critical application differentiates itself from a business critical application by its immediacy or data currency needs. This group of applications, though important, need not be available immediately. However, if the disaster persists for a week or longer, the business requires the application. Critical applications should not be recovered until the very critical and business-critical applications are up. The requirements of these applications vary from up-to-date to possibly day-old or week-old data.Required Applications. Required applications are not critical but must be backed up such that they can be recovered at the remote site if needed. Data from the last available backup is usually sufficient to support such applications.Noncritical applications. Noncritical applications need not be supported in the event of a disaster. Very few applications fall into this categoryif the application is not critical, why was it developed in the first place?

8

General Disaster Recovery GuidelinesMinimize downtime and loss of data.Planning for disaster recovery is an enterprise-wide task. The DBMS and database recovery is just one component of an overall disaster recovery plan. When your organization creates a disaster recovery plan, it needs to look at all of its business functions and operational activities:Customer interfacesPhone centersNetworksApplicationsEvery company function that can be impacted by a disaster. However, this lesson addresses only DBMS and database-related recovery issues.

During a disaster recovery, your goals are to minimize downtime and loss of data. Whether you achieve these goals is primarily determined by the preparations you have made.

Planning for disaster recovery is an enterprise-wide task. Remember that DBMS and database recovery is just one component of an overall disaster recovery plan. When your organization creates a disaster recovery plan, it needs to look at all of its business functions and operational activitiescustomer interfaces, phone centers, networks, applications, and every company function that can be impacted by a disaster. However, this chapter addresses only DBMS and database-related recovery issues. For a comprehensive discussion of disaster recovery, consult the books listed at the end of the chapter.

9

The Remote SiteOff-site location to setup operations.Must be located far enough away from primary site so as not to be impacted by the disaster.You may need multiple remote sites.Options:Dual data centersBackup data centerRecovery service provider

When a disaster strikes, you will need an off-site location where you can set up your companys operations. The site must be located far enough away from your primary site so that a natural disaster will not disrupt both sites. Sometimes the difference between success and failure is simple common sense. For example, your remote location should not be on the same power grid, in the same floodplain, or along the same earthquake faultline as your primary site. Your company may even select several sites for different corporate functions.

If your company is large enough to have more than one data center, you may be able to use each site as a backup for one of the others. For example, if your Houston data center is destroyed, you can move operations to your Pittsburgh data center.

Other companies set up a specific remote location where they send their data on a regular basis. In the event of a disaster, they simply connect to the backup system. This is an expensive alternative, but necessary for some businesses.

Yet another approach is to sign up with a disaster recovery service provider. The service provider maintains the equipment necessary for you to recover your operations on their computers in the event of a disaster. In this case, you are responsible for ensuring that the proper applications and data are available to be installed at the service providers location if a disaster strikes your site.Storage of backup materials is another issue. Ideally, they would be stored for safekeeping at the recovery site, but if this is not possible, another off-site storage location should be designated. If a disaster occurs, you will need to provide a mechanism to move the recovery materials from the storage location to the recovery location.

10

The Written PlanThe disaster recovery plan needs to be in writing.Should be distributed to all key personnel.The disaster recovery plan is a living document.It needs to be updated as the business and IT environment changes.Whenever the plan changes, be sure to destroy all of the outdated copies of the plan and replace them with the new plan.

A written plan is the foundation of any good disaster recovery plan. The plan should be distributed to all key personnel in the disaster recovery scenario. Each participant should keep a copy of the plan at home as well as at the office. A copy of the disaster plan should be kept at the recovery site, as well.

Perhaps the biggest challenge to implementing a successful disaster recovery plan is keeping the plan current and relevant. Maintain the plan as a part of your everyday activities. Be sure that your DBA procedures automatically include disaster recovery plan updates. For example, whenever you create a new database object, be sure to incorporate that object into the disaster recover plan. Likewise, whenever a database object is dropped, remove it from the disaster recovery plan. Furthermore, whenever you add a new application to the system, be sure to evaluate the criticality of the application and include it in the disaster recovery plan.

Simply stated, the disaster recovery plan is a living document that will change as your systems, requirements, and usage change. Whenever the plan changes, be sure to destroy all of the outdated copies of the plan and replace them with the new plan.

11

The Benefits of a Written PlanIt causes you to formulate the explicit actions to be taken in the event of a disaster.It makes you order these actions into specific sequential steps.It forces you to be specific about the tools to be used and the exact backup information required.It documents the location where all the required information is stored and how it is to be made available at the recovery site.It provides a blueprint for others to follow, in case those who are most familiar with the plan are not available.

Required Components of the Written PlanOff-site location. The address of the remote location(s), along with the phone number, fax number, and address of the contact at each remote site. Additional useful details could include a list of nearby hotels, options for travel to the recovery site, details of how expenses will be handled, and other pertinent information.Personnel. The name and contact information for each member of the recovery team. Be sure to include the work, home, and mobile phone numbers for each team member. Authorizations. The security authorizations necessary for the recovery operations and the personnel to whom theyve been granted.Recovery procedures and scripts for all system software, applications, and data. The complete step-by-step procedures for the recovery of each piece of system software, every application, and every database object, and the order in which they should be restored. Part of this section should be a listing of all the installation tapes for system software as well as the tapes for all maintenance that has been applied. Options for database recovery procedures will be covered later in this chapter.Reports. List the reports you will need at the recovery site to ensure a complete recovery. The reports should list each backup tape, its contents, when it was produced, when it was sent from the primary location, and when it arrived at the remote site. As an additional component, include a description of the naming conventions for the remote site backup files.

Be sure to include all of the interested parties in the disaster recovery planning process. This includes not just DBAs and systems programmers, but also end users, system operators, business managers, and perhaps even your customers. Your disaster recovery plan should include the sections outlined on the slide here.

The disaster recovery plan should include instructions for a complete off-site disaster recovery. However, before you commit your disaster recovery procedures to paper, you need to make a number of decisions. The first decision to be made is to prioritize your disaster recovery goals. Do you want to get the system up as quickly as possible? Or is it more important to lose as little data as possible? Or perhaps your most important goal is to avoid reprocessing data as much as possible. The disaster recovery plan should be written in accordance with your specific recovery goals.

13

Testing Your Disaster PlansTest the plan at least once and year and after the following events:Significant change in daily operations Change in system hardware configurationUpgrade of the DBMS (or related system software)Loss (or hire) of personnel responsible for the recoveryMove of primary data center to a new locationChange in daily backup proceduresAddition of major new applications or significant upgrades of existing critical applicationsMajor increase in the amount of data or the number of daily transactions

Once the disaster recovery plan is written, be sure to schedule regular tests. It is a good practice to test your disaster recovery plan at the remote recovery site at least once a year. You should also consider testing the plan after the events listed on the slide.

14

Testing GoalsA disaster recovery test can discover weaknesses and errors in the plan. A valid disaster recovery test need not end in a successful recoveralthough that is the desired result. A disaster recovery test that reveals weaknesses in the plan serves a useful purpose.Afterward, be sure to address all problems encountered during the testUse tests to assure the readiness of your personnel. The best way to prepare for a disaster is to practice disaster recovery. The process of actually implementing the plan forces you to confront the many messy details that need to be addressed during the recovery process. Testing can help to identify issues that would never spring to mind without a test. Testing also helps you to become familiar with the tools and procedures you will use during an actual disaster recovery.

Use a disaster recovery test to discover weaknesses and errors in the plan. After the test, be sure to update the disaster recovery plan to address the problems. A valid disaster recovery test need not end in a successful recoveralthough that is the desired result. A disaster recovery test that reveals weaknesses in the plan serves a useful purpose.

Another consideration for scheduling regular disaster recovery tests is to assure the readiness of your personnel. The best way to prepare for a disaster is to practice disaster recovery. The process of actually implementing the plan forces you to confront the many messy details that need to be addressed during the recovery process. Testing can help to identify issues that would never spring to mind without a test. Testing also helps you to become familiar with the tools and procedures you will use during an actual disaster recovery.

15

Scheduling a Test?A scheduled test of the disaster recovery plan is not a good idea. A disaster recovery test should work more like a pop quiz that doesnt give you the opportunity to prepare. One day your boss should come to work and announce that the building was just destroyed. Who should be called? Is everyone available? How can you get the right people to the remote site for recovery? Can you get your hands on the disaster recovery plan?

Actually, a scheduled test of the disaster recovery plan is probably a poor idea. A disaster recovery test should work more like a pop quiz that doesnt give you the opportunity to prepare. One day your boss should come to work and announce that the building was just destroyed. Who should be called? Is everyone available? How can you get the right people to the remote site for recovery? Can you get your hands on the disaster recovery plan?

The goals of recovery practice are to discover problems with the recovery plan, to provide on-the-job training for key personnel to become familiar with the procedures and tools to be used for disaster recovery, and to raise awareness of the organizations actual level of readiness to confront an actual disaster.

Of course, you might decide that it is impractical to conduct disaster recovery testing without advance warning. This is especially true if out-of-town travel is involved. However, to keep the test as close to the real thing as possible, do not use the advance warning as an opportunity to cheat (perhaps by sending additional materials to the off-site location that would not have been there otherwise).

The disaster recovery test should include all of the components of the written plan. This will include setting up the operating systems, installing the DBMS, recovering applications and data, and testing the recovered environment for success or failure.

As mentioned earlier, you should periodically review the contents of your off-site tapes to ensure that they contain the correct backup data, and not just during a test. At the same time, you should review all additional materials sent off-site to assure that everything that is supposed to be there actually is there.

16

PersonnelChoosing the right team is essential.From the perspective of the DBMS, must be capable of:installing and configuring the DBMS system softwareassuring the integration of the DBMS with other system software componentsrecovering individual databasestesting the integrity of the databasesrecovering related data that may not be stored in a databaseinstalling and configuring application softwaretesting the applicationstaking care of the numerous details along the way.

Choosing the right team to design and carry out your disaster recovery plan is essential to the success of that plan. From the perspective of the DBMS, the disaster recovery team must be capable of installing and configuring the DBMS system software, assuring the integration of the DBMS with other system software components, recovering individual databases, testing the integrity of the databases, recovering related data that may not be stored in a database, installing and configuring application software, testing the applications, and taking care of the numerous details along the way. In other words, the team must be multiskilled and very adaptable. Moreover, the team members must possess a combination of IT skills and business skills.

Once the team is assembled, it is imperative that each member be trained to understand the ramifications of disaster recovery. This also means that the DBAs, programmers, and SAs on the team need to understand the business aspect of disaster recovery and the business users need to understand the IT dimension of disaster recoveryat least at a very high level.The entire team should meet regularly for cross training and to perform at least annually a disaster recovery test. Remember that each member must be granted the proper authorizations at the remote site to perform his or her part of the disaster recovery. Nothing can stop a disaster recovery faster than lack of authority to perform a crucial taskespecially if no one is around with the authority to grant authorizations, which could be the case during a disaster.

17

Backing Up the Databasefor Disaster RecoveryThere are multiple techniques that can be deployed.Tape BackupsStorage Management BackupsOther Approaches

Your disaster recovery procedures will be determined in large part by the method you use to back up your data. If you rely on disk volume backups, then your recovery will be one volume at a time. If you create image copies, you will probably use the DBMSs RECOVER utility or a third-party recovery tool. Of course, you might combine several different techniques for off-site backups, depending on the sensitivity and criticality of the data. Lets look at several different backup strategies for disaster recovery.

18

Tape BackupsYou can use similar techniques as deployed to create local backup files.Multiple output from image copy backups:LocalRemoteUsually not a good idea to backup indexes for disaster recovery purposes.Create a report of all backups created/required.

A valid strategy for disaster recovery backups is to use the same techniques deployed to create local backup files. Create multiple output files from the image copy backup process, and send tapes (or optical disks) of at least one of the copies to the remote disaster recovery site. Be sure to send the backup files to the disaster site as soon as possible after their creation. The sooner the backup media are shipped off-site, the less likely they can be destroyed in a disaster.

For disaster recovery purposes, you usually dont need to back up indexes. They can always be recreated from the data after it is recovered at the disaster recovery site.

Be sure to produce a daily report of all the backup files that were sent to the remote site. Keep a copy of the report at the local site and ship one to the remote site as well. The report should detail all of the information required to perform a recovery, including file name, type of backup (full or incremental), how the image copy was created (database utility or file system command), date and time of the backup, date and time it was shipped off-site, and the date and time it was received off-site (if possible).

19

Timeline

Image copy backups are taken and one is sent off-site to the remote location.BackupsLogLog(s)

Database modifications applied and logged at the local site.Disaster occurs taking down the local site.

Ship Backups & Logs Off-Site

20Additionally, you will need to back up the database logs and ship them to the remote site. Failure to ship the log files to the remote site means that you will only be able to recover each database object to the point when the last backup was taken. Refer to the figure shown here.

In this case, we have backed up the database object and sent a copy to the remote site. The copy may be sent to the remote site by packaging it up and physically shipping it to that location or it may be shipped over a broadband connection to the remote location. Subsequent modifications occur to the database object and then a disaster strikes. Without a backup of the database log for the period between the image copy backup and the disaster, all of those changes will be lost. The amount of data lost in an offsite recovery depends on the timeliness of the backup of database log files.

Recovery Using Tape BackupsRecovery at the remote site is performed for each database object one by one. Indexes are rebuilt or recreated after the data is recovered. Additional preparation may be required, depending on the DBMS and operating system(s) in use. The system catalog will need to be recovered at the remote site regardless of the DBMS in order to recover any database objects at all. Other DBMS-related files may need to be recovered after the DBMS is installed, as well.Keep at least three backup tapes at your remote site for each database object. This provides a cushion in case one or more of the image copy tapes is damaged. Be sure to consult the documentation provided by the DBMS vendor for the particulars of remote site recovery for that DBMS.

Recovery at the remote site is performed for each database object one by one. Indexes are rebuilt or recreated after the data is recovered. After recovery, the DBA should use whatever tools and utilities are available to identify and resolve any data integrity problems and constraint violations.Additional preparation may be required, depending on the DBMS and operating system(s) in use. For example, if the DBMS keeps a record of the image copy backups, then the system catalog will need to be recovered to a point where all of the offsite backups are listed in the system catalogor some of the offsite image copy backups may not be able to be applied. Of course, the system catalog will need to be recovered at the remote site regardless of the DBMS in order to recover any database objects at all. Other DBMS-related files may need to be recovered after the DBMS is installed, as well.Keep at least three backup tapes at your remote site for each database object. This provides a cushion in case one or more of the image copy tapes is damaged. The extra tapes will allow you to fall back to an older backup in the event of a tape failure. Furthermore, if you have the database logs, you may be able to recover the database object completely, even if the recovery does take longer.Finally, when using this approach, be sure to consult the documentation provided by the DBMS vendor for the particulars of remote site recovery for that DBMS. 21

Storage Management BackupsStop the DBMS to create a system-wide point of stability for recovery.Copy all of the database objects, using storage management software to dump complete disk volumes to tape. When all of the disk volumes containing database objects have been successfully copied, restart the DBMS.Copy the backup tapes and send them to the remote site.

Another approach to disaster recovery backups is to use storage management software to make point-in-time copies of entire disk packs. Such an approach greatly simplifies disaster recovery preparation and execution, but this strategy can require a significant system outage to accomplish properly. To perform a backup using storage management software, follow the steps outlined on the slide.

22

Recovery Using Storage Management System BackupsRecovery at the remote site is performed a complete disk volume at a time using the storage management software. The biggest problem with this approach is the requirement to stop the DBMS. Most organizations cannot tolerate such an outage, due to e-business or global 24/7 requirements.

Recovery at the remote site is then performed a complete disk volume at a time using the storage management software. The biggest problem with this approach is the requirement to stop the DBMS. Most organizations cannot tolerate such an outage, due to e-business or global 24/7 requirements.

23

Other ApproachesWAN for delivery of backups to the remote site.Remote mirroring of data to the alternate site over the network.Standby Database

Although the first two approaches are the most commonly implemented disaster recovery strategies, many other approaches and options exist. Deploying a wide-area network (WAN) to assist in the delivery of backups to the remote site is a good tactic to consider. If your primary site can be connected to the remote site using a WAN connection, you can direct your offsite backups to an electronic tape vault at the remote location. Of course, any direct connection between the primary site and the remote site increases the chances of a disaster at one location impacting the other locationalthough a network connection is probably a very small risk if implemented properly.

Another approach to disaster recovery preparation is the remote mirroring of data to the alternate site over the network. This approach minimizes the amount of preparation required for recovery at the remote site because the data is mirrored there. For this strategy to be effective, all changes at the primary site must be mirrored at the remote site including regular database changes (INSERTs, UPDATEs, and DELETEs), database utility operations (LOAD and REORG), and local database recovery operations.

The standby database option for Oracle databases can be used as a disaster recovery approach. As long as the standby database is located at a different physical site than the primary database, the standby database can be a good choice for implementing a disaster recovery plan for an Oracle instance.

24

GuidelinesAdhere to the written plan.The DBA must be part of a multidiscipline team for disaster recovery.Pay attention to the order of recovery.Understand data latency.Remember vital data.Beware of compression and encryption.Post-recovery image copies.

Order of Recovery Make sure the operating system and DBMS are installed at the correct version and maintenance level before proceeding with any database object recovery at the disaster site. Be sure to follow rigorously the recovery steps as documented in the written plan.Data LatencyHow old is the data? If you take nightly backup tapes to another location, your data could be up to 24 hours old. Sometimes having data that old is unacceptable, and sending backup media to off-site storage more than once a day is too expensive. One solution is to get the data to another locationvia log shipping or replication, for example.Database logs at the time of the disaster may not be available to apply at the off-site recovery location. Some data may not be fully recoverable, and there is really no way around this. The more quickly that backup copies of database objects and database logs are sent off-site, the better the disaster recovery will be in terms of data currency.Some data may not be fully recoverable.Remember Other Vital DataCreating off-site backups for database objects may not be sufficient to ensure a complete disaster recovery plan for each application. Be sure to back up related data and send it off-site as well. Additional data and files to consider backing up for the remote site includeDDL libraries for database objects, recovery and test scriptsApplication program source and executable filesStored procedure program source and executable filesUser-defined function source and executable filesLibraries and passwords for critical third-party DBA toolsRelated data files used by the applicationBeware of Compression and EncryptionIf your site uses tape-compression software, be sure that the remote recovery site uses the same tape-compression software. If it does not, the image copy backups will not be readable at the remote site. Turn off compression at the primary site for the disaster recovery backups if the remote site cannot read compressed tape files.Be sure that the remote recovery site uses the same tape-compression software.Similarly, if the backup copies are encrypted, be sure that the decryption key is available at the remote site or the backup copies will not be able to be read rendering them useless.Post-Recovery Image CopiesAn essential part of the disaster recovery process is to create an image copy backup for each database object after it has been recovered at the remote site. Doing this enables easier recoverability of the data should an error occur after processing begins at the remote site. Without the new image copy backups, the disaster recovery procedure would have to be performed again if an error occurs after remote site processing begins.

25

Disaster PreventionEstablish procedures and policies to prevent problems in the first place.Although you cannot prevent an earthquake or flood, you can implement policies to help prevent man-made disasters. For example, use surge protectors to prevent power surges from destroying computing equipment and have backup generators on standby in case of electrical outages.Document and disseminate procedures to end users teaching them how to deal with error messages. Guidelines can help avoid errorsand manmade disasters.

DBAs and IT professionals, in general, create procedures and enforce policies. Many of these procedures and policies, such as a disaster recovery plan, are geared toward dealing with situations once they occur. Having such procedures and policies is wise. However, isnt it just as wise to establish procedures and policies to prevent problems in the first place? Although you cannot prevent an earthquake or flood, you can implement policies to help prevent man-made disasters. For example, use surge protectors to prevent power surges from destroying computing equipment and have backup generators on standby in case of electrical outages.

Another good idea is to document and disseminate procedures to end users teaching them how to deal with error messages. You cannot expect every user to understand the impact of responding to every error message. Depending on the application, the wrong user response to an error message can result in data loss. Guidelines can help avoid errorsand manmade disasters.

26

Disaster and Contingency Planning Web Siteshttp://www.thebci.orghttp://www.globalcontinuity.comhttp://www.sungard.com

Questions

A key part of a DBAs job is developing a plan to mitigate damages in the event of a disaster. The primary goal is to bring the applications back online with as little data loss and interruption as possible. There are many components required to create a viable disaster recovery plan, but it is imperative that a comprehensive written plan is created and maintained. Although the DBAs scope of responsibility is primarily assuring database availability and data integrity, the DBA must be part of a multidiscipline team for disaster recovery. Regular planning, testing, and revising are crucial to the creation of a usable disaster recovery plan.28