Jeff Mathers asks:

> I am also concerned with how to manage the size of the database.
> It is becoming quite a bit larger than I anticipated. If anyone
> could provide me with information on techniques for
> managing/reducing the size of the database, particularly with
> archived files, I would really appreciate it.
>
> I am using the OS/2 server with TCP/IP and archiving about 60 GB
> per year from Mac, OS/2, and Win 3.x clients.

I'd say that the database size is a direct function of the number of
versions, both backup, archive, and migrated (if you use the HSM feature)
that you have. A couple of things that come to mind:

1) Don't use the cache option for your disk storage pools unless you have
   a lot of disk space to burn (which you probably don't, or else you
   wouldn't be concerned about your database size). Caching defaults to
   'Yes', so you have to explicitly turn it off. Considering that backups
   and archives will probably never be read again, there's no point in
   caching them.

2) Run EXPIRE INVENTORY regularly.

3) Reduce the number of backup versions you retain. This may not be
   desireable in every case, but you can create different management
   classes to help control which files get many versions, and which get
   only a few.

4) If you use the BACKUP STGPOOL command, this will increase the size
   of your database since ADSM now has to keep information for each version
   for two different locations (the primary pool and copy pool).

Other than this, I can't really think of much else. Basically each entry
in the database takes 'x' number of bytes, and I don't think there's any
way to change this outside of changing 'what' and 'how much' you store in
ADSM.

I sent a previous reply to the same question with some stats about my
environment. Overall, considering how much information ADSM retains, the
database size doesn't seem too unreasonable.

Andy Raibeck
Connecticut Mutual
203-987-3521