|
This will help end-user performance *only* if a significant proportion of their response time is presently consumed doing “physical” disk I/O (e.g., either ‘db file scattered read’ or ‘db file sequential read’ events).
It’s possible that your strategy might help, but in my estimation, it’s not probable. In over 1,000 trace files that we’ve analyzed in the past couple of years, less than 1% would have benefited from what your development group is suggesting.
The downside of using trial-and-error to find out is the cost (both time and money) of putting that much memory into service. You can find out today whether it will make any difference by tracing (10046 level 8) some of your key user actions. See what percentage of total response time is consumed by OS read calls. If it’s a miniscule percentage to begin with, then making those PIOs into LIOs will gain you at best only a miniscule percentage of positive impact in return for the investment.
Cary Millsap -----Original Message-----
hey folks.. Hoping for a little feedback and opinion please. Having a discussion with the development group ...
The development group is thinking that a VERY LARGE SGA would solve some of their I/O problems. For example, they believe that a SGA consisting of over 8GB of db block buffers would resolve their multitude of issues. I feel that they open another can of worms with something such as this.. And granted-there hasn't really been an infrastructure evaluation-and the SA group is currently performing that review of the environment.
One could suggest that they could "cache" some very large tables in the SGA; but there seems to be some sense of a down side to this.. Could you all provide some input on "Extremely large SGA's"? In the area of 8GB or so.. BUT, most of this would be the database blocks. Would you all be so kinds to provide your thoughts please? TIA
Greg Loughmiller
|
- Big SGA....... Loughmiller, Greg
- RE: Big SGA....... Cary Millsap
- RE: Big SGA....... Stephen Lee
- Re: Big SGA....... Tim Gorman
- RE: Big SGA....... Stephen Lee
- Re: Big SGA....... Jonathan Lewis
- RE: Big SGA....... Loughmiller, Greg
- RE: Big SGA....... Loughmiller, Greg
- Re: Big SGA....... Tim Gorman
- Re: Big SGA....... Connor McDonald
- Re: Big SGA....... Anjo Kolk
- RE: Big SGA....... Loughmiller, Greg
