Comments on: The Pitfalls of Oracle’s Automatic SGA Management

By: Andy

Andy — Mon, 05 May 2008 15:05:48 +0000

We ran into the issue you described too. The trick is to set minimum values for the pools, especially the default buffer cache, that way when your unbound queries dry up the other pools, they can only dry them up to a point, and over time they’ll balance out again.

We’re using 10.2.0.3, and we’ve loaded many terrabytes of *lobs into ASSM, and we haven’t had any problems. In fact, it stores them more efficently than the OS was storing them…we use less space by putting them in the DB then we did when they were out of the DB. I think this is because the full OS block is allocated in the OS, but ASSM is a little more efficient. I wonder in what version you experienced issues, Noons? We have had the shared cursor issue you mentioned, that’s a scary one…and I know of at least 3 different bugs that cause that. Basicly, Oracle matches the sql text in the shared pool for your query, and doesn’t consider the schema that executed that query…so 2 scheams w/the same table name will get the same result, even if they have different data in the tables.

I agree krisgopala, but the problem is the impression from the users…they don’t know about the unbound sql, they only see the db running slowly and they blame Oracle, and of course, the DBA. Still, by setting minimum values, you can compensate for the bad code…a little bit.

By: krisgopala

krisgopala — Thu, 28 Jun 2007 11:56:48 +0000

Just going through this entry, a question comes up on my mind. You have mentioned that the application uses very little binding. Isn’t that a basic design flaw ? Is it fair for us to expect Oracle to automatically fix mistakes in application design?

By: Noons

Noons — Fri, 15 Dec 2006 00:14:11 +0000

Raj, there is much worse to come!

Wait until you have to run multiple schemas in same db, with same table names.
If you’re using ANY of the automatic sga and pga management features since 9ir1, it’s odds on that on a loaded system you’ll see the bugs I alert to in my blog.

They are caused by appaling QA of the pga_aggregate code and other auto memory management parameters.

As well: try to use BLOBs on ASSM tablespaces in any 9i or 10g and aside from the very latest – and unproven – patch releases, I can virtually guarantee you’ll get a corrupt LOB segment as soon as the load goes up!

And Oracle wants us to go through all the trouble of installing regular “patch releases” when they can’t fix the most basic of basics? Helllooooo?

All I can say at this stage is: use “auto-anything” with a grain of salt bigger than Ben-Hur…