Comments on: Extremes

By: osborne

osborne — Wed, 16 Sep 2009 01:53:30 +0000

I just saw a report of testing a 540G SGA by the Solaris Internals guys. No real data (they didn’t say how much was buffer cache vs. shared pool) but here’s a link anyway.

http://www.solarisinternals.com/wiki/index.php/Application_Specific_Tuning

Kerry

By: osborne

osborne — Sun, 12 Jul 2009 16:14:06 +0000

Well the 24MB 9.2 database at least stayed up. But still, 16MB is the new record!

By the way, I really don’t like AMM (I think it is an acronym for “Automatic Memory Messer-upper”). Even in 11g, it still seems to way over-allocate the shared pool on top of the occasional flurries of re-allocations. Seems like a feature that has lot’s of problems but doesn’t provide much benefit to most systems.

Kerry

By: Tanel Poder

Tanel Poder — Sun, 12 Jul 2009 13:05:26 +0000

10.1 data warehouse on a 24GB RAM machine - 16 MB of buffer cache.

This was 10.1.0.3 I think with SGA_TARGET set to 8GB. However the shared pool kept growing at the expense of buffer cache due some bug and eventually used almost all of SGA_TARGET, leaving only 1 x 16MB granule for buffer cache - and the instance crashed a while later.

By: osborne

osborne — Tue, 16 Jun 2009 20:46:45 +0000

New record! Last week I just saw a 9.2 database with a 24M buffer cache.

Kerry

By: Kerry Osborne’s Oracle Blog » Blog Archive Building Slow Development Systems (On Purpose) - Kerry Osborne’s Oracle Blog

Tue, 26 May 2009 23:30:13 +0000

[...] actually built some databases with 32M buffer caches (the one I mentioned in this previous post on Buffer Cache Extremes was one of his). He went so far as to say that he thought that developers should be using [...]

By: Mike

Mike — Tue, 19 May 2009 21:59:25 +0000

Dallas,

I’m curious–what statistics did you use to determine that 50G of keep is better than 0?

Mike

By: Yavor

Yavor — Tue, 19 May 2009 12:44:12 +0000

160 MB for Oracle e-business suite database in production :)
The implementer of EBS did not send any dba to that site, so they found a place in the docs that states 160 MB as a minimum and used the number as an recomendation. They called me 1 month after the database went in production, to spped the things up. At that time they had 8 GB of (mainly free) physical memory and have placed an order for 8 more, hoping that adding more memory will help.
Well, it was a problem with too little memory, indeed :)

By: osborne

osborne — Sat, 16 May 2009 02:53:32 +0000

Yeah, I remember the big,mediuum,small settings, back before there was even an spfile. It’s funny how some of those things get carried along, like an 11g database with _spin_count set (carried forward for 10 years and no one knows why anymore).

120G is impressive. Did it work well?

By: Jonathan Lewis

Jonathan Lewis — Fri, 15 May 2009 20:50:51 +0000

In descending order of size:
120GB, 80GB, 64MB.

The 64MB was a few years ago. The machine had 8GB of RAM, but they weren’t an Oracle site and didn’t have a DBA.

Remember how Oracle used to ship an init.ora file with things like:
# db_block_buffers = 8000 # big
# db_block_buffers = 4000 # medium
# db_block_buffers = 2000 # small.

Well they read the file and decided that their database was big, so …

By: Log Buffer #146: a Carnival of the Vanities for DBAs | Pythian Group Blog

Log Buffer #146: a Carnival of the Vanities for DBAs | Pythian Group Blog — Fri, 15 May 2009 17:01:09 +0000

[...] Osborne was playing with numbers too, in his own way—pointing out some extremes in buffer cache sizes, and asking for his readers’ [...]