HomeClever DBAs begin to seek wisdom
Tuesday, 10 February 2009 21:30 | 
Written by Administrator | 
| 
| 
Original blog by James F. Koopmann
http://it.toolbox.com/blogs/database-solutions/clever-dbas-begin-to-seek-wisdom-29901
Albert Einstein stated: "A clever person solves a problem.” but “A wise person avoids it".
DBAs are wired to be clever and solve problems, if DBAs weren’t clever they would soon be unemployed. Give a DBA a problem and they’ll find a way to solve it. The DBA is the gatekeepers to corporate databases—safeguarding, modifying, and keeping systems running at optimal performance. When problems occur the DBA likes to roll up their sleeves, get some grease under the nails, and solve issues. This is when DBAs rise from the dungeon—transforming themselves from gargoyle to demigod and humbly accepting all honor and glory.
Daily, DBAs prove their ability to be clever—constantly inundated with events that trigger investigation and dictate and consume a DBA’s time. As Fernando Andrade commented in an earlier blog posting, “Most of the work falls from the sky.”, DBA tasks are often very specific to an incident, are narrow in scope, and often have pointed solutions that do not fully consider the full health of a database system. Working this way, the DBA ends up reacting and fixing database problems mostly because they are forced by need and everyone is happy when problems are solved. Unfortunately, this type of work focuses only on immediate needs, wastes time, resources, and money, and has little impact on corporate direction and planning.
While being reactive to specific incidents continues to work, it’s beginning to have an affect on business’s bottom line. Databases are at the forefront of critical business and customer facing applications where incidents must be minimized or completely removed. Basing a database support structure solely on a DBAs ability to react can bring an organization to a grinding halt.
DBAs are learning that, while tool vendors have enabled them to react much quicker to incidents, there has to be a better way to stop problems from ever occurring. I have often joked that I’ll not touch a database, trying to solve a performance problem, unless someone complains. This might be extreme but hopefully conveys the point that performance issues are not conjured up and our efforts should be geared towards problem avoidance. As a very simplistic example, and one I wouldn’t recommend, you could add 999TB of disk capacity and never expect to get an out of space error again. Being wise about database administration equates to becoming proactive and anticipating future expectations of a database that you as a DBA will help insure or circumvent.
Both cleverness and wisdom have their rightful place in a DBA’s bag of tricks. But as DBAs, we must understand the difference between being clever (reactive) and using wisdom (proactive) and when to use one over the other. Memory leaks, bugs, instance and system failure are all unforeseen opportunities for DBAs to rush to the aid of a database and prove their cleverness. But when it comes to ensuring service delivery of a database, wisdom must come into play and help predict how databases can remain reliable and highly available.
The current economic downturn coupled with the enormous growth in data make for interesting bedfellows. We will for the unforeseen future continue to increase the amount of data we have to manage and implement innovative solutions as the workforce continues to diminish. It’s time we start using wisdom to avert those incidents that can be forecasted—stepping further and further away from managing the minutia and helping organizations drive business. The good news is that a small handful of vendors are stepping up to the plate to give us the tools we need to be successful. As one of the cool vendors in the predictive performance management (PPM) solutions by Gartner, I’ll be spending some time looking at one of the wise ones, BEZ, and what they have to offer. If you miss a posting just visit the Predictive Performance Management category of this blog for a detail look at BEZ and other ramblings about PPM.
http://it.toolbox.com/blogs/database-solutions/clever-dbas-begin-to-seek-wisdom-29901
Albert Einstein stated: "A clever person solves a problem.” but “A wise person avoids it".
DBAs are wired to be clever and solve problems, if DBAs weren’t clever they would soon be unemployed. Give a DBA a problem and they’ll find a way to solve it. The DBA is the gatekeepers to corporate databases—safeguarding, modifying, and keeping systems running at optimal performance. When problems occur the DBA likes to roll up their sleeves, get some grease under the nails, and solve issues. This is when DBAs rise from the dungeon—transforming themselves from gargoyle to demigod and humbly accepting all honor and glory.
Daily, DBAs prove their ability to be clever—constantly inundated with events that trigger investigation and dictate and consume a DBA’s time. As Fernando Andrade commented in an earlier blog posting, “Most of the work falls from the sky.”, DBA tasks are often very specific to an incident, are narrow in scope, and often have pointed solutions that do not fully consider the full health of a database system. Working this way, the DBA ends up reacting and fixing database problems mostly because they are forced by need and everyone is happy when problems are solved. Unfortunately, this type of work focuses only on immediate needs, wastes time, resources, and money, and has little impact on corporate direction and planning.
While being reactive to specific incidents continues to work, it’s beginning to have an affect on business’s bottom line. Databases are at the forefront of critical business and customer facing applications where incidents must be minimized or completely removed. Basing a database support structure solely on a DBAs ability to react can bring an organization to a grinding halt.
DBAs are learning that, while tool vendors have enabled them to react much quicker to incidents, there has to be a better way to stop problems from ever occurring. I have often joked that I’ll not touch a database, trying to solve a performance problem, unless someone complains. This might be extreme but hopefully conveys the point that performance issues are not conjured up and our efforts should be geared towards problem avoidance. As a very simplistic example, and one I wouldn’t recommend, you could add 999TB of disk capacity and never expect to get an out of space error again. Being wise about database administration equates to becoming proactive and anticipating future expectations of a database that you as a DBA will help insure or circumvent.
Both cleverness and wisdom have their rightful place in a DBA’s bag of tricks. But as DBAs, we must understand the difference between being clever (reactive) and using wisdom (proactive) and when to use one over the other. Memory leaks, bugs, instance and system failure are all unforeseen opportunities for DBAs to rush to the aid of a database and prove their cleverness. But when it comes to ensuring service delivery of a database, wisdom must come into play and help predict how databases can remain reliable and highly available.
The current economic downturn coupled with the enormous growth in data make for interesting bedfellows. We will for the unforeseen future continue to increase the amount of data we have to manage and implement innovative solutions as the workforce continues to diminish. It’s time we start using wisdom to avert those incidents that can be forecasted—stepping further and further away from managing the minutia and helping organizations drive business. The good news is that a small handful of vendors are stepping up to the plate to give us the tools we need to be successful. As one of the cool vendors in the predictive performance management (PPM) solutions by Gartner, I’ll be spending some time looking at one of the wise ones, BEZ, and what they have to offer. If you miss a posting just visit the Predictive Performance Management category of this blog for a detail look at BEZ and other ramblings about PPM.
| < Prev | Next > |
|---|
