Re: Automatic Shared Memory Management
Date: Tue, 12 Feb 2008 11:49:16 +0100 (CET)
Message-ID: <fortjb$gk$1@aioe.org>
On Sun, 10 Feb 2008 06:20:06 -0800, mrowkin_at_gmail.com wrote:
> Hello,
>
> I write an essay about Automatic Shared Memory Management in Oracle 10g
> and I'm looking more information about it. I've found some white papers
> on oracle's site, but I think it's not enough for me. I was wondering
> what is the algorithm that monitors the distribution of memory and
> changes it as needed. Does ASMM takes the advantage of Oracle's
> snapshots and performance views?
>
> A lot of thanks
> Adam
Interesting question. Automatic shared memory manager is extremely poorly
documented because of Oracle's inability to provide really useful
documentation.
<RANT>
Oracle is full of undocumented packages, hints and undocumented features.
All those undocumented beasts indicate that the company itself is unclear
about the documentation concept. They want to make money on education and
they don't really want people to use the documentation.
Oracle documentation is worse then bad, it's Microsoft Contemptible.
That is not surprising as Microsoft has discovered the art of making money
by selling training long before Oracle. That is why every new release has
less and less of useful documentation about the crucial features
available. Writing useful documentation is
a) Expensive as it requires capable and qualified technical writers.
b) Cannot be done by little, bearded Elbonians living in mud huts and
hired cheaply to produce large quantities of unintelligible "manuals". c) Counterproductive as it stimulates people to learn things themselves
and not waste money and time on expensive and often bad quality
training.
d) Indicative of the company attitude toward people who purchased Oracle
RDBMS.
</RANT>
However, there is a way to answer your question. There is table called X $MESSAGES which describes various types of messages exchanged by Oracle components. Here is an excerpt made on version 10.2.0.3:
SQL> column DEST format a30 wrap SQL> column DESCRIPTION format a45 wrap SQL> select description, dest
2 from x$messages where lower(description) like '%mem%';
DESCRIPTION DEST --------------------------------------------- ------------------------------ lock memory at startup MMAN lock memory timeout action MMAN Memory Management MMAN SGA memory tuning parameter update MMON SGA memory tuning parameter update - DBW0 DBW0 SGA memory tuning MMON free PX memory chunks in background CKPT SQL Memory Management Calculation CKPT
8 rows selected.
SQL>
What conclusions can we make?
1) Checkpoint process is responsible for the automatic workarea sizing.
I does accounting of free chunks and SQL memory allocation. 2) Memory management daemon (MMAN) is responsible for carving pieces and
managing memory areas.
3) Tuning and accounting are done by MMON based on the same speculative
prediction methods once used to advise adding more buffers. I believe that MMON can even be using BCHR among other criteria to advise growth of buffer cache or shared pool.
Version 11 remains pretty much the same:
SQL> select description, dest
2 from x$messages where lower(description) like '%mem%';
DESCRIPTION DEST --------------------------------------------- ------------------------------ lock memory at startup MMAN lock memory timeout action MMAN Memory Management MMAN SGA memory tuning parameter update MMON SGA memory tuning parameter update - DBW0 DBW0 Handle mem_target resize MMAN SGA memory tuning MMON free PX memory chunks in background CKPT SQL Memory Management Calculation CKPT
9 rows selected.
SQL> Now there is an explicit "resize" directed to MMAN, probably by MMON who discovers the need for resizing. If you are running Linux, you can run ltrace on MMON and MMAN to confirm that type of communication.
-- Mladen Gogala http://mgogala.freehostia.comReceived on Tue Feb 12 2008 - 04:49:16 CST