I have questions about the adsm db. I do not believe that these are new new
questions. But I do not remember the answers and they might be of the form "it
depends" on your release level....
If the answewr changes based on platform or code level, we have a VM adsm
server ver 1 at maint level .17 that is growing in use. We plan to upgrade to
ver 2 when it is available. Our current DB usage is 33.3% of 1.6Gig
on 2 physical volumes.
Is it best to increase the disk space for the data base all at once? Or add
space as one needs the growth?
If we add db space in small parts on different volumes we can increase the
number of concurrent i/o's but will have an increase in the number of threads
that have to be managed. Are there any quidelines for this. Would it be better
to have a few whole pack db extents or a series of 500, 1000 or 2000 cyls
extents? Should they be keep equal sized as is recommended for the cms sfs?
Some file systems do not perform well if one lets them fill or come close to
same. Does adsm belong in this group? If so, are there any guidelines for
this?
Some files systems (databases) require different amounts of reorganization to
optimize the storage patterns of internal objects that are subject to many
updates over time. For example the old fashion isam file systems were pretty
bad and required offloading and reloading to help performance. Some systems
were designed with almost self optimizing algorithms. Others had utilities
that could dynamically reorganize the systems during idle periods. Where does
adsm fit into the scheme of things?
Is there anything a customer site can do to measure the need to reorganize the
adsm db?
Is there anything a customer site can do to reorganize the adsm db?
If one extends the adsm db with a new extent and then reduces it by removing
an old extent, will this just move the data, reorganize the data, or other?
Is there a practical limit to the size of an adsm db. That is when should
one create a 2nd or n'th adsm server instead of extending an existing one?
Are there any guidelines for this.
Thanks len boyle
-------------------------------------------------------------------------
Leonard Boyle, Mainframe support snolen AT vm.sas DOT com
Leonard Boyle, Mainframe support snolen AT vm.sas DOT com
SAS Institute Inc. ussas4hs@ibmmail
Room E206 (919) 677-8000 ext 6241
203 SAS Campus Drive
Cary NC 27513
|