Re: buffer cache and shared pool size tuning
Date: Wed, 9 Dec 2009 21:04:14 +0100
Message-Id: <10EF7B03-A264-41EB-B908-5BAFD85C0234_at_gmail.com>
IF you have agreed target response times (and maybe additional memory around) you can bring the risk to your application vendor: grab their account manager and argue: "Tell me how much memory I should give the buffer cache /large pool. I will do so. Then we test again. IF the test shows the required target response times, you are right and I will excuse my wrong assessment. But otherwise YOU excuse yours and take over responsibility (and payment) for the additional memory."
I'm aware this will never happen, but I like the face of these account managers (or performance-'pro's) at this particular point. - And it keeps the discussion running. From this point on they have to argue why they suggest something, they are not 100% certain.
just out of curiosity: how much time / percentage could you save if you eliminate all physical IOs?
> Hi,
>
> I have a situation in which the application vendor is asking to
> increase the buffer cache size to resolve a performance issue,
> pointing to the advisories from the dbconsole.
> Although I have already proved via tracing that the problem is
> mainly in the queries and schema design, and that even if we cached
> everything we still would not be able to get the requested response
> times, they are still pointing to the advisory.
> All this asside, it made me wonder what would be a good method to
> verify if the buffer cache is correctly sized?
> Same question for the shared pool.
> --
> http://www.freelists.org/webpage/oracle-l
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Dec 09 2009 - 14:04:14 CST