The following is from the bestselling book
Oracle 10g Grid. You can
order it directly and save 30% here:
http://www.rampant-books.com/book_2004_1_10g_grid.htm
The 64-bit Oracle database now allow for
far larger SGA regions. Sadly a 32-bit word
size can only address (2 to the 32nd power),
or about 4 gigabytes of RAM. All 64-bit
servers have a larger word size (2 to the
64th power) that allows for up to 18 billion
gigabytes (18 exabytes).
Many Oracle DBAs are running SGAs larger
than 30 gigabytes, most of it dedicated to
the data buffer caches such as
db_cache_size and use the
v$db_cache_advice view to tune their
db_cache_size to cache the working set
of frequently used objects.
Also note that the Oracle 10g
dba_hist_db_cache_advice tables in AWR
now all Oracle 10g Automatic memory
management to automatically adjust the
db_cache_size.
It is important to remember that there are
downsides to having a super-large
db_cache_size. While direct access to
data is done with hashing, there are times
when the database must examine all of the
blocks in the RAM cache.
- Systems with high Invalidations - Whenever a program issues a
truncate table, uses temporary tables or
runs a large data purge, Oracle must
sweep all of the blocks in the
db_cache_size to remove dirty
blocks. This can cause excessive
overhead for system with a db_cache_size
greater than 10 gigabytes.
- High Update Systems - The
database writer (DBWR) process must
sweep all of the blocks in
db_cache_size when performing an
asynchronous write. Having a huge
db_cache_size can cause excessive
work and most DBA's segregate
high-update and truncate objects into a
separate, smaller data buffer such as
db_2k_cache_size.
- RAC systems - Systems using
Oracle9i RAC may experience high
cross-instance call when using a large
db_cache_size in multiple RAC
instances. This inter-instance ?pinging?
can cause excessive overhead, and that
is why RAC DBA's try to segregate RAC
instances to access specific areas of
the database.
If your system has any of these
characteristics, you will need to perform
special operations to reduce the stress on
the db_cache_size. Click here for
details and scripts for automatically sizing
your db_cache_size:
Advanced Oracle Monitoring and Tuning Script
Collection