Depends what you mean by "very large" - some people's catalogs are over 100
Gb ;)

I don't think you can selectively delete parts of it (as of 3.4).  You could
expire 
images which would free space, but if you ever needed to use those images,
you would 
need to import the tapes, which takes a looooong time.  If you ship a
database backup 
tape with it, then you're stuck with loading that database tape, and wiping
out your 
live database in the process (i.e., effectively reverting to that point in
time).

You could try playing with the "Delay to compress database" setting.  It's
specified 
in days.  If you set it to, say, 30 days, then the data for images older
than 30 days
would be compressed in the catalog.  The downside is that if you need to
browse those
images for restores, then Netbackup has to uncompress that information,
which can be
slow (depending on your master's disk, cpus, etc.)  I suppose you could set
it very
low (maybe to one day) to compress like a fiend if you rarely restore (or
don't mind
taking 3-4x as long to browse and setup a restore job).

I image that the index level adds space (see the NB Performance Tuning Guide
- it's
/usr/openv/netbackup/db/INDEXLEVEL in Unix).  More indices = more disk space
to hold
them, I would guess.  More indices again equals faster browsing for
restores.

NB 4.5 uses a binary format database which is supposed to be faster and
smaller.

I don't think there's an easy answer...I think just mathematically, your
catalogs are
going to be big.  For every file on every image, you have to store a lot of
metadata
(owner, permissions, last mod time, etc.), plus the overhead of indexing it
all.

--
Drew Fabbro
fabbro.andrew AT cnf DOT com 
Desk: 503-450-3374    Cell: 503-701-0469
"There is no such word as 'maturity'.  There
is only 'maturing' and 'dead'." -- Bruce Lee