-----------------------<snip>-------------------------
I'm curious about this one. A person here has stated that when a VSAM
KSDS file is in multiple extents, it performs more poorly than it would
in a single contigueous extent. He said something to the effect that
when a portion of the index is referenced which is in "another extent"
that the entire in-memory buffer for the file is flushed. I have no idea
where he got this information.
------------------------<unsnip>-----------------------
In my experience, that's completely bogus. Increasing index buffers in
storage is still, IMHO, the best way to improve index performance. The
fewer times you do real I/O to the index, the better.
---------------------------<snip>-------------------------
Also, he wants to use SMS striping for VSAM files which are mainly
accessed sequentially because it would significantly decrease the I/O
time to read. We are using multiple FICON connections to a single 2105
ESS (Shark). We do not have the volumes in any storage group spread
across LCUs. My contention is that it may well decrease I/O, but it
would require that we likewise stripe the volumes across the 2105's LCUs
as well. We don't do this at present.
---------------------------<unsnip>-----------------------
Striping might help "a little bit", but increasing buffers will help
immensely more. You've got loads of storage for buffers; use it! In my
experience, striping on RAID hardware seems to have very little effect,
what with PVA's and all.
Bear in mind: for sequential access, the most important part of the
index is the Sequence Set, the very bottom level of the index tree
structure. Consider using larger Index CI's and more storage for index
buffers. The number of extents has very little, if any, relationship to
overall performance.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
