Skip to Main Content
  • Questions
  • shared_pool_size and other memory questions

Breadcrumb

Question and Answer

Tom Kyte

Thanks for the question, Brian.

Asked: September 29, 2001 - 9:39 pm UTC

Last updated: May 25, 2004 - 2:27 pm UTC

Version: 8.1.6

Viewed 1000+ times

You Asked

----
System: 8.1.6, 1GbRAM, 3 CPUs
----

When I

SELECT * FROM V$PARAMETER

I see (among others)

...
shared_pool_size 12000000
shared_pool_reserved_size 600000
...

When I

select nvl(pool,'buffer cache'),count(*),sum(bytes)
from v$sgastat
group by pool
order by pool

I get

NVL(POOL,'BUFFERCACHE') COUNT(*) SUM(BYTES)
java pool 1 20000768
shared pool 32 13997564
buffer cache 3 20616176

1. Does the fact that 13997564 is greater than 12000000 :

A. Mean that the shared_pool_size parameter is too small?
B. Mean that unnecessary swapping is occuring?

2. Should the reserved size be greater than 5%?

3. The " select sum(bytes) from v$sgastat" is 54614508:

A. Is 54Mb rather small for a 1GbRAM machine?
B. Does this mean that 1Gb minus 54Mb is "unused"?



and Tom said...

1) the correct answer is C -- none of the above. The shared pool is made up of MANY components. When you specify the shared_pool_size in the SGA, you are only setting part of it (the library cache mostly). Other parameters affect the size of the shared pool as well -- we keep many data structures in there.

2) no, in fact, in 8.0 and up with the addition of the large pool, the reserved size can be ZERO if you like. the shared pool reserved size set aside part of the sga for large allocations (those done by MTS for example). In 8.0 and up, they should take place in the large pool and the reserved size isn't as relevant. In fact you might find that in a well tuned system you are setting aside 5% of your shared pool for memory allocations that will NEVER HAPPEN.

3) I would say a 54m SGA is on the small side, yes.

Rating

  (3 ratings)

Is this answer out of date? If it is, please let us know via a Comment

Comments

Shouldn't sum of bytes in v$sga and v$sgastat match though ?

Sameer, October 16, 2001 - 3:25 pm UTC

I can understand why stat in v$sgastat is not exactly equal to shared_pool_size in init.ora but shouldn't sum(value) in v$sga match with sum(bytes) in v$sgastat ? 

I know my SGA is 1.2G (confirmed by v$sga and ipcs). Somehow the value of 5.5G reported by v$sgastat (due to abnormal 4.2G for shared pool miscellaneous) is incorrect. Not sure why though.

This is what I see:

SQL> select * from v$sga;

NAME                      VALUE
-------------------- ----------
Fixed Size                69616
Variable Size         367816704
Database Buffers      838860800
Redo Buffers              90112

SQL> select sum(value) from v$sga;

SUM(VALUE)
----------
1206837232


  1  select nvl(pool,'<unnamed pool>') pool,  name, bytes from v$sgastat
  2* order by 1, 3 desc
SQL> /

POOL           NAME                            BYTES
-------------- -------------------------- ----------
<unnamed pool> db_block_buffers            838860800
<unnamed pool> fixed_sga                       69616
<unnamed pool> log_buffer                      66560
java pool      free memory                  17772544
java pool      memory in use                 2228224
shared pool    miscellaneous              4292546012
shared pool    sql area                    165410724
shared pool    library cache                92752548
shared pool    free memory                  44493116
shared pool    db_block_buffers             27852800
shared pool    dictionary cache              5134736

POOL           NAME                            BYTES
-------------- -------------------------- ----------
shared pool    ktprhtnew3                    4313176
shared pool    db_block_hash_buckets         3539016
shared pool    KQLS heap                     3047488
shared pool    PL/SQL MPCODE                 1709988
shared pool    PL/SQL DIANA                   977796
shared pool    event statistics per sess      390080
shared pool    sessions                       242880
shared pool    KGFF heap                       79244
shared pool    PX msg pool                     64496
shared pool    table columns                   62612
shared pool    joxlod: in ehe                  40636

POOL           NAME                            BYTES
-------------- -------------------------- ----------
shared pool    type object de                  34160
shared pool    table definiti                  17852
shared pool    trigger defini                   9180
shared pool    PX subheap                       7024
shared pool    KGK heap                         6612
shared pool    pl/sql source                    4800
shared pool    view columns d                   2160
shared pool    PLS non-lib hp                   2096
shared pool    trigger inform                   1780
shared pool    temporary tabl                   1692
shared pool    fixed allocation callback         960

POOL           NAME                            BYTES
-------------- -------------------------- ----------
shared pool    errors                            792
shared pool    joxs heap init                    432

35 rows selected.

SQL> select sum(bytes) from v$sgastat;

SUM(BYTES)
----------
5501744632
 

Tom Kyte
October 16, 2001 - 8:15 pm UTC

That number is suspiciously close to 2^32 = 4294967296.

Looks like an issue, yes. Please contact support (i don't see anything filed against it specifically in the probably database)

shared pool

mo, December 20, 2002 - 5:31 pm UTC

Tom:

1. What is the difference between sharred pool and block buffer cache? in your book you say the first one is used for cursors and stored procedures. DOes it mean for QUERY only while the block buffer cache is for insert and update?

2. How do you size these things? How do you determine the right size? In your book you say you do not want it too big or too small? can you figure out from queries how much cache memory they need?

3.  X$bh does not exist in oracle?

SQL> select tch from x$bh;
select tch from x$bh
                *
ERROR at line 1:
ORA-00942: table or view does not exist 

Tom Kyte
December 20, 2002 - 8:18 pm UTC

1) shared pool - code
buffer cache - data

2) 9i will automate this for you to a large degree with the buffer cache advisories. Before then, it was tuning with statspack.

3) v$bh is the one you want to use. x$bh -- is sys.x$bh which you may well not have access to.

Shared SQL and Private SQL Area

Vivek Sharma, May 25, 2004 - 1:31 pm UTC

Dear Tom,

Chapter 7 of Oracle 9i Documentation states about Library Cache that

</code> http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96524/c08memor.htm#10127 <code>

"The library cache includes the shared SQL areas, private SQL areas (in the case of a multiple transaction server), PL/SQL procedures and packages, and control structures such as locks and library cache handles."

I want to know what is a multiple transaction server ? Are they talking about MTS ?

Further they state that the location of the Private SQL Area depends on the type of connection established for the session.

Reading this, I assume that

1. Multiple Transaction Server is actually a Multi Threaded Server
2. In Dedicated Server Connection, the Private Sql Area is in a User Process PGA and is out of SGA whereas in MTS it is in UGA which is in SGA ?

Are my assumption correct ?

Please clarify.

Regards
Vivek





Tom Kyte
May 25, 2004 - 2:27 pm UTC

it is a doc bug times two (and it has been files)

first - 'multiple transaction server' should have read multi-threaded server (shared server actually)

second - library cache should be UGA and the UGA is in the large pool under shared server and in the clients PGA in dedicated server.


your assumptions are correct.