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