After working in over 40 companies now, there is either some amazing coincidence or the discipline of query performance is not truly "owned" by anyone. Yes, every company says they "have it covered" to some extent. Usually, this means the DBA's tune queries. But the reality is that the typical DBA simply does not have the time to tune queries everyday, therefore can't possibly build the skill set desired for such a discipline.
What do they say....repitition breeds proficiency? The point is you can't possibly be as good at something you do 20% of the time that someone else does 100% of the time.
A day in the life of a DBA is immense. First and foremost (way before performance) is the availability and integrity of the database. Oh, and then there is the constant cycle of applying patches, migrating database objects between databases, creating new databases, answering dozens of questions from various sources, etc. etc. etc.
What ends up happening is performance takes a back seat. And when "performance" is looked at, it's usually database performance that is the focus. Not query performance. Too often, a shotgun approach is taken to turn a big knob on the database to make all the queries run faster. Did that fix anything? Of course not, but you can bet the queries will run faster. For now.
Because there is a mentality to want to kill many birds with one stone by tuning the database, we never fix the true problem. The queries. So, the common cycle of making changes at the database level, partitioning, buying hardware, etc. is prescribed instead of doing what's right....tuning the queries.
I propose that we quit thinking of ways to take broad strokes at "fixing" query performance and start making broad strokes at "diagnosing" what queries to fix! Whether it's fixing the anomalies that bubble to the top of the averages or the individual elapse times, the idea is to determine which queries bring the greatest return.
So, let's trade in the habit of taking the shotgun approach of tuning with tactics like partitioning and disk array tactics intended to evenly distribute I/O. Why distribute I/O? Eliminate it. That sounds far more efficient to me. Eliminate the I/O by tuning at the level that's needed, the query level.
Having said all that, it takes a unique process and discipline to help identify what queries will bring the greatest return. This discipline will need two things. The right product and the right skill set.
So, share with me any thoughts and think about the following:
- How is query performance addressed in your shop?
- Is it effective?
- How do you know it's effective?
- Could there be a possibility of a different, maybe even better, methodology that exists to make your query performance discipline a world class service?
I have assumptions about the answers to the first three questions, but I know the answer to the last one for sure. The answer is "Yes" and it's called DPOP. DPOP is the methodology I've created for addressing query performance and you'll quickly see how it applies to any database (DB2, Oracle, SQL Server) and for any application (developed or purchased).
Is anyone out there?