Cary Millsap has an excellent (as usual) blog posting today about the software development process employed by so many oranizations.
You can read his full posting here:
This plays into one thing that I see quite a bit as a DBA at client sites. Most developers that I encounter at client sites don’t tend to focus so much on performance (unless it is painful during their testing). This isn’t, specifically, their fault. In many cases, the developers are under significant pressure to “make it work” and move onto the next thing. As a result, they don’t really have the time to worry about performance. Besides, that’s the DBA’s job, isn’t it?
Well, actually, it isn’t. See, here’s the thing, from a DBA perspective, we have a relatively small handful of tools at our disposal. From the bottom-up, here is a basic list of things that a DBA generally does to impact the performance of a system:
Properly configure disk and I/O. This is (or should be) really a collaboration between the DBA, the Systems Administrators, and the Storage Administrators. Done correctly, this shouldn’t really be a problem. However, as with everything, it is still possible to screw it up. Make sure that you have redundant I/O paths that have sufficient bandwidth for your system. Spread your I/O across many physical drives. With RAID technologies (particularly RAID 1/0) this is VERY easy to accomplish. Forget about the old concept of the DBA moving datafiles around to avoid a “hot disk”. The disk array can do this at a much more granular and consistent level than any human possibly can. Your primary goal here should be to have as many spindles involved in every I/O operation as possible.
Properly size your hardware. Another collaboration between the DBA and Systems Administrator. Make sure you have adequate horsepower and RAM. And ALWAYS plan for growth! My general recommendation is always to put more RAM into the box than you think you’ll need. Given that so many systems that I encounter these days are x86-based Linux systems (rather than “big iron” like Solaris or AIX), memory for these systems is a relatively small portion of their cost. Also, RAM doesn’t impact your Oracle licensing!
Properly tune your OS Kernel and Database parameters. I think that this is one area where developers, managers, and users tend to have gross misconceptions. While it’s true that tuning a system to truly “optimal” performance is a dark art, the truth is that, unless you’ve really screwed something up (sized your SGA too small, too few buffers, etc.), odds are you’re not going to see huge performance gains by tweaking these parameters. In most cases, “decent performance” is fairly easy to achieve. Now, squeezing out that extra 20%? That can require in-depth analysis of statistics, utilization, I/O patterns, etc. This is where the “dark art” comes into play. And, honestly, this requires time to observe and adjust.
Unfortunately, too many developers, managers, and even users, seem to wonder why that idiot DBA didn’t just set the magic “MAKE_SQL_RUN_FASTER=TRUE” parameter. (Shh! Don’t tell anyone, that’s OUR little secret!)
The truth is, unless something is wrong at these lower levels, the biggest performance gains are going to come from tuning the code. And, in my opinion, since it’s the developer’s job to produce a quality product, it’s ultimately the developer’s job to do tune their code. Unfortunately, as Cary points out, too many organizations are structured in a manner that breaks the feedback loop required for developers to do this properly.
That MUST be fixed.