SHARE

Database Administrators: Boost Your Productivity

With tighter budgets and heavier workloads, the life of a database administrator is full of challenges. Here are some suggestions to do more in less time. DBA Problem Resolution 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, […]

Written By

Lockwood Lyon

Nov 28, 2011

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More

With tighter budgets and heavier workloads, the life of a database administrator is full of challenges. Here are some suggestions to do more in less time.

DBA Problem Resolution

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.

Read the rest about DBA productivity improvement at Database Journal.