With a flock of new database management packages suddenly hitting the market, you'll forgive your database administrator (DBA) if they suddenly seem to be in a spending mood.

New or upcoming products include Oracle's just-released 11g, which, as usual, promises more features than a DBA can wrap his head around; Microsoft's SQL Server 2008, the follow-on to the successful SQL Server 2005, which is due out next February; the new "Cheetah" release of Informix, with which IBM hopes to chase down lost market share; and Version 9 of FileMaker's namesake software, which the vendor says is Web 2.0-ready but remains as easy to use as ever.

Tempting as these new products can be, experienced DBAs know that new versions usually pack in more features, meaning that any performance boost is more likely to come from the expensive hardware upgrade accompanying a database upgrade, not the database upgrade itself.

And those gains can be limited, if underlying design flaws or operational problems remain.

As Amy Stuemky, a DBA at travel tour operator Globus, puts it, "Throwing hardware at a problem is always the wrong solution."

So how do you solve problems like processes that tend to run for days, or database utilization that mysteriously spikes up to 100%, without spending an arm and a leg on consultants or new hardware? Some DBAs say all it takes is a little resourcefulness and sweat, augmented by a well-chosen third-party tool.

Fixing bad SQL code

For DeWayne Treadway, a database and systems administrator at Dallas-based Lone Star Steel Co., the problem was an "overall general slowness" with the steel maker's pair of Oracle databases that Treadway couldn't pinpoint.

A steel manufacturing plant in the northeastern Texas town of Lone Star, was running Oracle 8i on IBM AIX servers, one of them a 16-way System p 570, the other an older RS/6000 M80, when Treadway arrived two years ago.

Treadway had a hunch the problem had something to do with the SQL code. It had been written by contract developers five years earlier, when Lone Star made a big move off mainframe computers to Unix servers. Lone Star's situation is hardly unique. "Database applications are immortal," wrote Josh Berkus, one of the developers behind the open-source PostGreSQL database, in a recent blog post. "The average life span of a 'temporary, one-off' application is four years, and there is code from the 1960s that is still running today."

So figuring out where the code was not easy for Treadway. The Statspack application that came with the Oracle Database didn't store historical performance data, making it "no good" for the task, he said.

And as Treadway put it, "I'm a DBA, not a developer."