3 Ways You Can Be Appreciated as a DBA

Last week’s blog about making money with DB2 10 got some interesting comments, mostly related to how management only complains and does not really give us anything even after the performance is improved and we save the company a lot of time and CPU resources. One commenter told a story about an application that the DBAs worked on that went from a runtime of two hours down to ten minutes, saving tremendous CPU and elapsed time. No raise, bonus or even a thank you for the DBA team. Being a DBA is sometimes a thankless situation and maybe that is why there are so many college students not choosing IT. So how do we change the corporate thinking, get some respect and appreciation for being great DBAs?

The first and best way I have seen at some of my clients over the years get the recognition they deserve is by the keeping statistics and keeping track of which application development teams produce good performance and maintain the best performance levels. Usually the architects, application designers, and developers throw a design together and sometimes you have a chance to improve or change it. So, whatever design is implemented in your test environment, start tracing the application performance and keep track of the SQL access paths and their elapsed time performance.

Second, note all the bad access paths, document the bad ones and publish the SQL findings. Sometimes documentation is tough to do with dynamic SQL or ORM application layers like Hibernate or iBatis. Learn how to snap the dynamic cache in z/OS or set up a SQL trace in LUW to capture the SQL statements and Explain them all. Using the free OSC (Optimization Service Center) or Data Studio tools are a great way to get the visual explain graphs and extended database access path information. Publish the findings on your new DBA support web site, in emails to application managers or developers, and keep an on-going list of the access paths that can be improved.

Third, note the number of DBA support calls from the various development groups during the work and non-work hours. This will quickly tell you which teams want, need and have the potential to be problems in the future. Get them a DB2 education class on how to design a database, how DB2 programs should work, Java DB2 performance or SQL tuning. Alternatively, do a lunch and learn session for the developers yourself. It is good to provide a little DB2 education; it goes a long way to helping them and will help cut down on the number of phone calls you receive at all hours of the night.

All of these public and communication efforts will get you and your DBA team noticed and appreciated. Documentation of DB2 performance issues, alternatives on how to address them, and actions to eliminate the issues before they become real problems are always appreciated by management. These three tactics will definitely be noticed.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>