DEVELOP A CONTINGENCY PLAN

JOSE ENRIQUE CORDOVA BOBADILLA

 DEVELOP A CONTINGENCY PLAN
A disaster recovery plan, it needs to look at all of its business functions and operational activities
customer 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. Yet another approach is to sign up with a disaster recovery service provider. 

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. 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. 

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. Be sure that your DBA procedures automatically include disaster recovery plan
updates. 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. The
disaster recovery plan is a living document. Writing out the specific procedures and policies to
follow for an off-site disaster recovery has several benefits. 

It documents the location where all the required information is stored and how it is to be made
available at the recovery site. Another benefit of creating a detailed disaster recovery plan is that it
will highlight areas that need to be improved within your backup procedures and organization. Be
sure to include all of the interested parties in the disaster recovery planning process. 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. 

Be sure to provide 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. 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. 

The disaster recovery plan should be written in accordance with your specific recovery
goals. Testing Your Disaster Plans 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. 

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 recovery although 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 also helps you to become familiar with the tools and
procedures you will use during an actual disaster recovery. 

Regular disaster recovery tests assure the readiness of your personnel. 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 doesn't give you the opportunity to prepare.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 organization's 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. The disaster recovery test should include all of the components of the written
plan. Personnel 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. 

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 recovery at 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 task especially
if no one is around with the authority to grant authorizations, which could be the case during a
disaster.