Re: Changeing database parameters on the fly

Muz wrote:
> Well, that's the weird part. db_cache_size is just over 3.9 billion
> (about 480,000 pages), and I'm only using about 235,000 of them, but
my
> hit ratio is just over 70 percent.
>
> I know I'm just throwing memory at it, but I don't think there's much
> more that I can do. (Besides, I have LOTS of memory to throw at it.)

How much memory do you have? How much are you using? What platform are you on?

Are you running the advisor in OEM? I've noticed it keeps telling me I could have more buffers, every time _after_ I follow its advice. If I wasn't watching, I'd be out of memory now. It's a form of ratio tuning, and can be useful for some ballpark tuning, but the advisors aren't so smart you'd want to blindly follow them. They don't take into account the dynamic issues you get with an oversized SGA, for example.

You might want to google this group about hit ratio, and even read the stuff of those who advocate hit ratio tuning - some types of data access (like some DSS systems) will just never have a high ratio. Many people in this group feel that hit ratio tuning is worse than useless. Personally, I think it has its place for being watched for sudden changes in a stable system, but trying to reach a target is a waste of time. Usually there are certain sql statements that are worth focusing on, and there are several methodologies for figuring out which those might be.

Also, you might read up on the recycle pool, if you are blowing through gigantic tables you might want to use that feature.

For tuning advice in this group, you might want to state which init parameters you've modified from default. As someone else said, check out statspack too, if you want to see what is really going on.

See also http://www.dbaoracle.net/readme-cdos.htm

jg

--
@home.com is bogus.
"Upgrade your Oracle license to SB, the Silver Bullet option.
Obviously, it is the inverse of the BS option." - Wolfgang Breitling