The largest user of database space is file cataloging. The database mainly
keeps track of where ADSM has stored stuff. If you think about what that
means: a name for the stuff and where the stuff is. So, if the name is
very long or the stuff is stored in many places, say a disk pool, a tape
pool and a copy storage pool (three places) the amount of database space to
keep track of this file might be closer to 700 bytes. However if the
filename is c:\k.txt and only exists on one tape, the database space is
probably closer to 200 bytes.
I like to size the database based on the number of files the server will
hold. Let's say we have 100 objects to backup. 10% of these change on a
daily basis and we keep versions for 30 days. The total number of objects
the server will manage is thus: 100 + (30*10) = 400. Use the 500 byte
average and you'll have 200 Kbytes of database space. Add 10% for server
related stuff: 220 Kbytes. The trickiest part is figuring out how many
files you have in the environment and what percentage changes.
I'll stick with my response from last night: start with a couple of of GB
and be prepared to add more. Don't create on giant mongo database in a
single volume.
The recovery log. Talk about black magic. I'm sure a server design person
in ADSM can tell us more, but the recovery log is tough. First, if you use
the recovery log in normal mode the use of log will become stable over time
as your environment becomes stable, i.e., you aren't adding new clients and
data. The recovery log is "flushed" (in normal mode) once the transaction
is committed to the database. So the overall size is a function of the
amount of simultaneous activity, backups, file expirations, migrations,
etc., that are going on.
In Roll Forward Recovery Log Mode, all transactions are kept in the log
until a database backup is performed. This mode allows for database
recovery to the most recent point in time. For instance, in normal mode,
if you perform a backup of the database at 06:00 and the database fails at
12:00, you will lose all the transactions that occurred between 06:00 and
12:00. If, however, you are in roll forward recovery, the transactions are
still in the log and upon completion of the database restore operation,
these transactions will be applied to the database. Voila, the database is
as it was right before it failed.
Obviously, roll forward recovery log takes more recovery log space. I
recommend roll forward recovery log only for static environments. Again, a
static environment is not the day after you install the ADSM server and are
adding clients at alarming rates. Wait until after you've added your
clients to change to roll forward.
There are good descriptions of all of this in the Admin Guide. I rattle on
since I didn't get to teach a class this month!
Kelly
|
