Who Owns Performance in the Database?

Many moons ago, this was a pretty straightforward question. It also had a very easy answer, the DBA owned performance. By that I mean if the database or it’s applications did not perform as expected, it was the DBA who would step in and fix it.

Several years ago this began to change. More and more shops started to expect the developers to have more than a passing awareness that their applications relied on a database. SQL was more than just a simple call that retrieved your data. If you were going to query the database, you needed to make sure it was efficient. If for some reason a bad plan slipped through to production, the DBA would often flag the offending code for someone in development to address for their next release.

This transference of responsibility did not happen everywhere. I frequently speak to development and business support groups that do not know how to read explain plans, and more importantly, aren’t expected to tune their own queries. There is a ‘smart person’ or DBA (I suspect) that gets stuck figuring out these issues.

Are you a ‘Developer’? Can you read an execution plan?
If your answer is ‘Yes’ and ‘No’|’Mostly’|’a little’ respectively, them I am guessing that someone else in your organization is minding the performance domain. If you spend much time writing SQL, then I can’t help but think you (and your organization, database, application) would benefit immensely. Sometimes the ‘smart person’ isn’t available, or even worse, sometimes your query is never identified as the performance bottleneck. And not to worry you too much, but 80-85% of all database application performance issues can be directly tied to poorly written SQL statements.

Are you the ‘smart person’?
Do you enjoy being the ‘Oracle of Oracle’, the ‘SQL Savant’, or the ‘Master of your Domain’? Do you feel threatened or diminished by the idea of ceding some of this responsibility back to the folks who are writing the queries in the database?

But those people don’t know what they’re doing.
Sure, they understand the business, and know how the application works. But put them in a database, and they are as lost as a sheppard without the North Star. Is it possible they remain in this predicament because you have never challenged or enabled them to grow as database professionals? Perhaps they don’t want to go there. But, maybe, just maybe they do.