Re: Manual mem management in 10g

Powell, Mark D wrote:
> I was unaware that you could not just set the SGA_TARGET down and bounce
> your database but how about:

According to Note:295626.1 I would get ORA-00827.
>
> Create an init.ora from the spfile.
> Remove the underbar values from init.ora
> Stop db.
> Startup nomount and recreate the spfile from the init.ora.
> Open db.

I'm going to try a combination of these first. My issue is I rarely have an opportunity to bounce, but I will on the 4th.

I'm still concerned that there's an inherent mem leak in their automatic implementation so I would just be extending the time between crashes. Here are the current heavy hitters:

SQL> select * from v$sgastat order by 3;

POOL         NAME                            BYTES
------------ -------------------------- ----------
shared pool  kglsim hash table bkts        2097152
shared pool  CCursor                       2718728
shared pool  KQR M PO                      2951912
shared pool  row cache                     3741868
shared pool  KGLS heap                     3951300
shared pool  sql area                      4123572
shared pool  KSFD SGA I/O b                4190228
shared pool  KCB Table Scan Buffer         4194816
shared pool  XDB Schema Cac                4463548
shared pool  db_block_hash_buckets         4464640
shared pool  library cache                 6075032
              log_buffer                    7135232
large pool   free memory                   7314608
shared pool  KGH: NO ACCESS                8364080
shared pool  ASH buffers                   8388608
java pool    free memory                   8388608
shared pool  free memory                  10550608
              buffer_cache               1132462080

> I do no think that fact that MS will not support the /PAE switch would
> stop me from testing it if I was running into outages on a production
> system.

Unfortunately that is my client's call and not mine. I made my recommendation and they chose not to take it. They've been keeping me busy on other projects, too, so I haven't had much time to look at db issues.

-- 

Sincerely,
Michael Ray
Topshot Systems LLC
--
http://www.freelists.org/webpage/oracle-l