Customers face a glut of applications, including Automated Teller Machines (ATMs), Internet order processing, hotel check-in and check-out, cable television stations and retail clerks, to name a few. Customers demand the availability of accurate, timely data to complete their transactions.
As a DBA, the best way to support strategic applications such as these is to develop, identify, and apply best practices to “deliver on the availability promise.” These practices concentrate on:
- Minimizing and mitigating risk
- Using a clear, well-documented, problem-solving process
- Preventing, detecting, and correcting service disruptions.
One way to approach best practice development at a high level is via The Laws of Database Administration. Briefly, the laws are:
These laws are listed in order of importance. (For a discussion of the difference between important and urgent, see The Laws of Database Administration link at the end of this article.) Is recoverability really more important than data availability? See the sidebar for a short discussion.
Security and performance concerns can certainly be urgent, but they’re less important than the first two laws. Recoverability and data availability are highly strategic, as recoverability and data availability considerations must be taken into account during database design and throughout the application and transaction design project phases.
This leads to these corollaries:
- Attempts to tackle data availability concerns must be preceded by addressing data recoverability.
- Best practices in the data availability arena will concentrate on balancing risk management (recoverability) with customer service (availability).
- To ensure data availability, the enterprise must first have implemented recovery best practices.
Best practices can be summarized as implementing shared processes, documentation, and standards in an environment of continuous improvement.
Best practice implementation begins with requirements for processes, documentation, and process disciplines or standards. Sometimes, IT derives requirements by reacting to symptoms. Regrettably, this behavior makes it difficult to concentrate on the real (i.e., important) issues.
Certainly, you must deal with urgent issues such as production system outages; however, true best practice implementation requires moving forward through symptoms to real problems. It’s sometimes called root-cause analysis. You can then perform problem resolution, requirements definition, and cost/benefit analyses of alternatives.