1) 100% agreed
2) 100% agreed
3) 90% agreed. I agree with statement paging bandwidth... I disagree
with the second statement more smaller is always better... The
bandwidth must be adjusted to suit the paging rate. If the total page
rate is 1 or 2 per sec, one local could handle the load easily. If it is
100's per sec, a more robust paging subsystem would be needed.
Converting 9 locals to 3 may or may not hurt! (it depends).
4) If I had an unlimited budget....
<snip>
- Individual local page datasets should not exceed 30%
(or
25% if you choose) utilization because the contigious slot allocation
algorithm becomes inefficient/unsuccessful for that dataset. The
utilization% at a total paging subsystem level is irrelevent with
respect to
the algorithms.
- All local page datasets should be the same size (or
close
to it in slots) and device type because of ASMs round robin allocation
algorithm. If one page dataset has 12000 slots and another has 24000
the
utilization% on the second will be about 1/2 of the first.
- Paging bandwidth is as important as paging space.
Converting 9 page datasets to 3 page datasets of triple size will
probably
impact performance. More smaller page datasets is always better over
fewer
large page datasets.
- A volume should only have a single local page dataset
on
it, and no other datasets. Use of WLM managed PAVs by ASM can be used
to
eliminate this restriction. Depending on the actual storage subsystem
backing a page dataset it may or may not be reasonable to have multiple
systems using a volume with a page dataset on it.
</snip>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
