The primary method of managing the growth of the DB is by running expiration
(Expire Inventory) at a regular interval (once a day is reasonable - more
often really doesn't help).
Among other things, the DB contains a record for every active, and inactive
file that ADSM manages. It also has records for files that are cached and
those in copypools as well. If memory serves, a record can be as large as
600 to 800 bytes, although copypool records are smaller - 200-300 Bytes, I
believe. You can therefore look at some of your policy information and see
some of the trade offs. For example:
1. Are you keeping files "forever" - i.e, - have inactive files set to long
periods of time (Retain extra copies) or are you keeping a large number of
extra copies?
2. Cached files alao have DB entries. If you have a large primary disk
pool, with caching enabled, this might become significant. You can always
turn off caching to regain some DB space. Of course this means that EVERY
restore, will need to go to tape, once the DASD pool has been migrated.
Also, be aware that turning off caching does not cause the cached files to
disappear - they are only deleted when the space is needed and they are
overwritten. Therefore, this will not result in an immediate windfall.
3. Do you have users who are trying to defeat the natural process of ADSM by
trying to do "FULL" backups of their machines every so often? This causes a
lot of files who don't change (such as applications, etc.) to be backed up
needlessly, which then of course causes extra DB entries that will stick
around until they fall off the expiration. I would guess that about 90% of
files on a PC do not change; the nuber probably falls off quickly on a
server, but still stays well above 50%. (That is why I believe that trying
to out fox ADSM and force full backups is never a good idea - end of
soapbox.)
The short version of this is that the DB will grow as you are add clients, or
as your existing clients reach maturity. Part of this is a natural process,
but you have to "mind the store" and not provide unlimited backup capacity -
set your policies at what is reasonable for your customers based on real
needs, not on "I guess I need to be able to go back to any version of any
file for the past 2 years"
Hope this helps. Perhaps others have thought of some different ways to
control the DB.
By the way, my DB, which handles about 650 clients, both servers and desktop
machines, is about at 6GB of live data - actual size is 7.5GB. I know there
are many out there that are a lot larger.
Jerry Lawson
jlawson AT thehartford DOT com
______________________________ Forward Header __________________________________
Subject: Database Size
Author: INTERNET.OWNERAD at SNADGATE
Date: 5/15/97 4:00 PM
Hi! I've been messing around with an NT ADSM Server v2.1.12 for several
months now. I'm watching my database grow, and grow, and grow.....
I've read similar discussion threads here in the past, but I was
wondering if I could get some specific information on how it works. If
I delete some large filespaces, and expire a bunch files, etc., I
thought that the size of the database might decrease accordingly. This
did not occur. Is there a way to reclaim space in the database, or do I
need to do a dumpdb/loaddb or something?
Thanks in advance,
Joelle Booher
AMP Incorporated
jmbooher AT amp DOT com
|
