Fixing the business, not the database
Simple adjustments to a company's business process can often pay more dividends than a technical fix. Indeed, fixing a problem -- tuning SQL code, for instance -- can often simply shift a bottleneck from one place to another, according to Craig Shallahamer, an ex-Oracle-turned-independent database consultant with his own firm, Orapub.
By contrast, reducing a database's workload or rebalancing it (moving to a different machine or running a noncritical batch job to a different day or time) can accomplish much more.
So why is this approach so rarely taken? Shallahamer says the problem is the typical personality type of a DBA: introverted and oriented toward problem-solving.
Because of that, says Shallahamer, "they tend to look for any technical problem to solve so when they go home they can feel good, even if that isn't the best solution."
Shallahamer recalls working with a DBA whose Oracle systems were "getting hammered" during the peak month's-end closing period. Just in passing, the DBA mentioned that there were some SQL statements that were part of a message-passing application that were being run every second.
"I asked him if there was any way he could slow that [SQL statement] down to run just once a minute. He said that he would have to check with the users first," he said. "They said, 'Oh yeah, that's not a problem.' So it's really all in how you present it."
DBAs also "often don't feel powerful enough to push for process re-engineering," he said. As the prior example showed, said Shallahamer, that's also a misconception. DBAs can get all of the information they need, such as profiling a workload, to "make a really amazing case."