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. -- //www.freelists.org/webpage/oracle-l
-- //www.freelists.org/webpage/oracle-l
