Database administrators (DBAs) need to move away from reactive, repetitive tasks. Use the ideas presented here to become more productive.
DBAs should standardize problem resolution methods and the process of root cause analysis.
Most large IT organizations have multiple teams with which DBAs must collaborate. So, we need to consider how the extended team works together. If teams are in react mode, they tend to reactively approach problems; they concentrate on eliciting symptoms and applying quick fixes rather than searching for underlying causes. This leads to failure; or, at best, inefficient and overworked teams.
The most common reasons DBAs fail are the following.
Unclear problem definition: DBAs tend to see the symptoms and consider that the problem is now completely defined. For example, a long-running SQL statement may be diagnosed as "bad" and needing to be "fixed." Work then proceeds on tuning the SQL statement without considering possible causes such as poorly organized data, invalid or unavailable data distribution statistics, data locking delays, incorrect lock granularity (row rather than page), disk synchronous I/O delays, or overall system load. Teams must begin by recognizing the difference between symptoms and their possible underlying causes. One way to accomplish this is to ask why a symptom or problem appears.
Making unfounded assumptions: Many experienced DBAs rely on their instincts or gut feelings only to discover that issues surface because their assumptions were false. Consider a distributed Java application that seems to be "locking" the mainframe DB2 data that it accesses, preventing other applications from reading the data. Without knowing the specific connection method and package bind parameters, the DBA may assume the fix will involve appending "WITH UR" (uncommitted read) to the SQL statements from the application. In some cases, non-standard parameters such a s ACQUIRE (ALLOCATE), ISOLATION(RR) or CURRENTDATA(YES) may be the real culprit.
No structured problem-solving process: Using a standard approach can help technical teams.
Stopping with the first good idea: When some teams encounter a problem, one technician will choose a solution and stop. It’s as if the purpose of the process was to generate a single answer. Rarely does the team consider multiple good ideas, which may then be combined or executed in parallel. Teams also need to consider and implement ideas for detecting the symptom or problem if it recurs, preventing the problem, or processes that will automatically detect and correct the problem.
Document, centralize, standardize. Assign quality measures to documents and processes. Productivity for the IT professional means doing the right work while minimizing wasted effort and redundancy. One of the original sources of continuous improvement comes from the Software Engineering Institute at Carnegie Mellon University. Their Capability Maturity Model (CMM) imposes an organizational structure on software development processes and, by extension, infrastructure support processes such as database administration. The model describes processes and practices in terms of a maturity level that can be used as a guide for gauging current maturity and for planning improvements. Continuous improvement is where you work on tasks that increase process and practice maturity.
Consider a process for database change control. Assume the process is poorly documented, uses non-standard scripts, and has no quality measures. Continuous improvement would involve raising the maturity level from repeatable to defined, which might involve improving documentation, standardizing processes, and adding process quality measures.
When implementing a continuous improvement process, follow these guidelines:
• Make the processes repeatable so earlier successes aren’t wasted. This means standardized JCL and scripts that can be executed by anyone without modification, and instructions for execution and for follow-up on failure. Ensure the entire team is aware that processes exist and you have procedures for controlling changes to documentation and processes.
• Standardize. Processes and documentation are all well-written in a standard format. Complete information is available in a centralized area, indexed for ease-of-use. The entire team should be familiar with approved ways to access and update information.
• Manage. Implement initial quality measures. Processes and documentation should be regularly reviewed for possible updates.