Re: Problem flushing shared pool on 188.8.131.52 HP-UX Itanium
Date: Fri, 24 Apr 2009 17:55:47 +0200
Surely, flushing the shared pool is far from being a best practice. I don't think that is the solution, as it is probably not solving the real problem
Isn't the size of SGA contributing? Would it not be that as you have increased it to be this beg more things are kept there and as a result more CPU can be spent on spinning for a latch?
There seems to have been a few issues with this in 11G, but it also seems that they were *supposed* to have ben fixed in 11g. It may be worthwhile getting Oracle support to tell you if you are running into a bug.
If it's not a bug, then tracking the actual issue may help more than figuring out issues with flushing the shared pool unless that is the actual thing you ned to make work. It sounds as if you are rather trying to fix issues with a workaround you're using.
2009/4/24 Alfonso León <aleon68_at_gmail.com>
> Hi everybody:
> We have a HP-UX Itanium Server with 28Gb of memory, 4 cores, Oracle
> 184.108.40.206. it often hangs waiting for flushing shared pool, manually or
> automatically. Memory Target is 18Gb.
> the ASMM set the following parameters
> __oracle_base='/prod01/app/oracle'#ORACLE_BASE set from environment
> when the shared pool is full, sometimes we get that most processes wait for
> library cache: mutex X. It takes up to 2 hours to flush the shared pool and
> sometimes we have to kill the smon because the instances doesn't accept any
> conection to shutdown the instance.
> Has anybody had issues with flushing the shared pool?
> Alfonso Leon