Availability Manager Log File

[Peter Clarke]

Here is another file that someone may be able to look at and tell me what is wrong.
This is to do with my previous question...

Regards

Peter

[Peter Clarke]

Also typical uaf working set values are:

WSdef - 2000
WSquo - 4000
WSextent - 16384

Any suggestions on what to set the working sets to??

[Jan van den Ende]

Peter,

could it be that your hardware is just a little bit bigger than the system which the AM treshold values are tuned to?

The amount of IO being reported means YOUR system can do, and does do, a lot more work than your reporting tool considers 'normal'.
And I guess you DO have this system to work for you(r company)?

As it is now, just writing this log-file itself is generating significant I/O :-(
Adjust your AM rules so that EXCEPTIONS are reported, but normal-to-your-system conditions are NOT.

_Some_ entries ARE interesting though.

-several signals of 'working set quota is too small'. Seek out those accounts, THOSE are the usernames that would benefit from a WSQUO boost!
You might consider starting with doubling it.
Watch WSEXT as well, you wouldn't want to increase WSQ over WSE!
( and beware, SYSGEN WSMAX sets a hard upper limit, it might need increasing as well, but THEN have AUTOGEN do its recalc on all values).
- several 'SYSTEM high page fault rate'
increase SYSMWCOUNT (start at doubling; we are at 8 * default)
- 'Window turn rate on EURAXP is high'.
Indicative of fragmented files. You CAN however let VMS deal with it (at the cost of memory use) by setting SYSGEN ACP_WINDOW to 255.
This gives cathedral windows to your file headers, ie, irrespective of size the whole header is kept in memory. The parameter IS Dynamic, but changes take only effect for disks mounted AFTER the change!
- several 'paging I/O rate is high'
Seek these out! Those accounts need boosting their PGFLQ (start by doubling)

I DID notice some, but very little, COM state reports. If you did NOT set a treshold to reduce reporting those, than I guess your system can readily handle the load (at least, during this logfile period)

Well, enough work to get started, I think.

Success!


Jan

[Peter Clarke]

Thanks Jan,

I know about the io window turn rate and split transfer rate,coming in this weekend to defrag the disks some are 92% fragmented.
Will try the things you have suggested though.

Regards

Peter

[Peter Clarke]

Just one question all the processes that give the message working set quota too small are subprocesses do i still increase the user wsquo??

[Jan van den Ende]

Peter,

Yes, that's what the process names suggest.
I must admit that I failed to take note though :-(
But it _IS_ all the more reason!
These are pooled quota, if you create a subprocess (spawn, lib$spawn, etc) the quota of the spawning process are split, half given to the child, and half kept.
Next spawn leaves/gives only 1/4th, then 1/8th etc!!!
You CAN tweak this a bit by PQL_Mxxx params, because no process ever gets less, but that IS rather crude. (could be a good safetynet though).

Jan

[Hein van den Heuvel]

Jan is on the rigth track here.

You'll need to tweak tweak the AMDS rules to tell it that higher direct and buffered IO rates are normal for your box. After all, that is just an indication of work being done. Whether thre are more DIO then needed can only be determined from appliaction (Oracle) data.
Even if amds is rigth and those rates are too high, by increasing the threshholds you will be able to focus on the worst offenders which probably give you better insights quickly.
Now you do NOT want to do this just from reports a week late. You want to run this while the system is active such that you can ask Oracle who is responsibel for certain slaves. You have to query V$SESSIONS and V$PROCESS to correlate the backend (for example ORA_EURPC0927 with a frontend (maybe LPIOLI) to get a clue of what work migth be attempted. You probably also want to (have your dba) query v$sql to get an impression which queries are being executed when DECamds is complaining. Maybe you can find Oracle tablescans that can be addressed or maybe you find OCI connections that can benefit from larger array sizes.

Good Luck,

Hein.