For starters, Database 11g adds self-learning capabilities to Oracle's automatic SQL tuning. Now the engine detects high-load SQL statements and saves them for tuning during a maintenance window. It can apply some automatic fixes or suggest structural changes, such as indexes. If you're leery of letting the engine do too much tuning, you can let it simply capture your queries and suggest fixes. Then, if the engine turns out to be right most of the time, you can start trusting it more. One problem is that Oracle can't take your entire workload into account, so it may suggest changes that would damage your normal flow for a query that gets run only every so often.

The Bottom Line Oracle Database 11g Oracle, oracle.com Very Good  8.6 criteria score weight Manageability 9 25% Performance 8 25% Availability 9 20% Scalability 8 20% Value 9 10% Cost: Editions: Standard Edition One, $149 per user license (minimum of five users) and $4,995 per processor (maximum two sockets per server); Standard Edition, $300 per user license (minimum of five users) and $15,000 per CPU (maximum four sockets per server); Enterprise Edition, $800 per user license (minimum of 25 users) and $40,000 per CPU. Enterprise Edition options: Oracle Real Application Testing, $10,000 per processor or $200 per named user; Oracle Advanced Compression, $10,000 per processor or $200 per named user; Oracle Total Recall, $5,000 per processor or $100 per named user; Oracle Active Data Guard, $5,000 per processor or $100 per named user. Platforms: Linux x86, Linux Itanium, Sun Solaris, IBM AIX5L, HP-UX, Windows NT 4 or later Bottom Line: Oracle Database 11g will be welcome relief to DBAs responsible for testing changes against a production workload. The way that Data Guard and Real Application Testing work together is sheer poetry, and no doubt most shops will quickly come to rely on the combination. The automatic health checks will help DBAs sleep better, though they may initially be leery of the SQL tuning feature. Result Cache will be a big hit with advanced users, and Advanced Compression (data de-duplication) will reward the smart DBA who manages it carefully. About our Reviews and Scoring Methodology

There's more than one way to quantify a runaway workload, and Oracle has risen to the occasion here as well. When workloads go awry, it's typically in one of the three main areas of server performance: CPU, memory, or disk I/O. Usually resource governors quantify a runaway workload by measuring CPU or memory, but Oracle Database 11g has also instituted per-session I/O limits.

These I/O limits allow you to specify a maximum value (either in I/O requests or in megabytes) of work that connections are allowed to perform on the server. I/O limits are a very important addition (especially in the case of large warehouses) because these systems can become disk-bound very easily, and CPU or memory resource capping doesn't adequately address disk contention.

I/O caps can also help DBAs put the kibosh on long-running queries. Because there's no way to natively define a policy that checks whether a query has used 20 percent of the CPU for 20 minutes, for example, DBAs will often write their own checks, and then have the code do something based off of the results. Being able to cap total I/O consumption means no longer having to manage these checks by hand.

And as usual, you can move these long-running queries to a lower-priority resource group as they become a problem. It's like being put in the penalty box at a hockey game. If you're going to write SQL that drags the system down, then you'll be given fewer resources so that you can't affect others. And of course, as a result, your query will take a lot longer.

Result Cache
Result Cache is a feature that can make or break you, depending on who's holding the wheel. Result Cache allows you to effectively pin a query result into a special buffer in memory, therefore bypassing the disk lookup for subsequent calls to the same query. You can cache entire queries, subqueries, or even PL/SQL functions. Of course, the query call has to be the same as the cached version -- and therein lies the rub. Quite often, queries differ only in the parameters being passed (the case with most OLTP queries), so you'll have a lot of individual queries being cached, but very little reuse.