 |
|
||||
|
Disaster Recovery and Continuity Planning for the Database Administrator - Part 1By Kevin MedlinAugust 13, 2008
IntroductionThe most important information in most businesses can be found in the database. A lot of time and attention goes into planning for any new database application. Storage, servers, high availability, capacity, and clustering are just some of the considerations. The same planning process must take place for disaster recovery and business continuity planning of databases. All actions taken to make business critical applications available must be methodical and deliberate. Disruptions are serious events and should not be taken lightly. "It's not about seeing the [recovered] data on your screen, but conducting business." (Day, Jo, Day, Kevin, 2006) Databases that are at the heart of the business today fall squarely on the critical path of the disaster recovery actions taken when a disruption strikes. Partial or complete disruptions of a business can be devastating. Business continuity planning can ensure that capacity is available for critical business operations in the time of need. Practiced professionals in the area of business continuity understand that life and opportunities can continue after a disaster. Understanding the steps involved with keeping a business viable is where some planning is needed. Destruction of assets can be devastating. Insurance may cover the expense to replace those assets but it will not put a business back in place overnight. This takes a huge mental and physical toll on workers. These conditions create burdens and stress on employees and their customers. Without a disaster recovery plan in place, there is little hope of ever getting a business back on its feet. RequirementsOne of the first things needed are the requirements for each database supported. Recovery times are probably the most important of these requirements. The difference between a few seconds of downtime and a few minutes of downtime can be quite substantial. Some business units may have a tolerance for a few hours. This must be known for each database for your plan to be effective. "...you have to prioritize what you need in order to function... you have to figure out what is actually mission-critical." (O'Hanlon, 2007) Another important answer needed is in reference to data loss. If little to no data loss is acceptable, then a disaster recovery solution can become a budgetary concern. If the backup from last night will suffice, then this can lead to major cost savings. Capacity can be a concern at the disaster recovery site. Customers should be asked about performance degradation and what is acceptable. This can be a tricky question to answer, and customers will usually need assistance to figure it out. If left to themselves, they will almost always answer that no degradation is acceptable. Another question that should accompany performance degradation is finding out about the number of users that will be accessing the system during the disruption. These two answers will help to identify a more accurate capacity. What should be explained is that during the disruption, the entire corporate population may not need access to the enterprise application. Possibly only power users may need the system to run business critical functions for the enterprise. One example is Human Resources applications. An HR application may be available to the corporate population during normal operations for viewing pay stubs, updating W-2s, etc. During a disruptive event, these rights could be suspended but power users could continue to run payrolls, enter benefits, hire and fire employees, etc. It is possible far less capacity is needed than originally thought necessary, which can mean more databases on the same servers, as long as the databases will not interfere with one another's processing. Virtual servers can be used as well, "... you would re-instantiate the virtual machines at a higher ratio (density) of virtual-to-physical. Consequently, organizations that can tolerate a slight drop in performance can build a much cheaper secondary data center to handle temporary disruptions." (Antonopoulos, 2006)
|
|
|
Email
Print
Digg This
Add to del.icio.us
