Judy Warren writes:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Forwarded letter follows =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Are there reasons not to use the "cache" option for disk storage pools?
I understand that one reason might be a lack of database space, as the
ADSM server will keep track of the cached copies of files in addition to
the copies that have been migrated off to the next storage spool.  But =
if
you have plenty of available database space, are there any disadvantages
to using the "cache" option?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Forwarded letter ends =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

My own opinion on this: disk space costs some amount of dollars, and so =
it makes sense to try to utilize it as effectively as possible. =
Especially in the case of disk backup storage pools, you're only putting =
backup versions out there. This means that the odds of you ever reading =
that data back are slim to none. When I was at Connecticut Mutual, I set =
up the disk backup pool so that it would be of sufficient size ot house =
one night's worth of data. During the day, I would migrate most of the =
data to tape. Thus in addition to the slim likelihood of the data ever =
being read back, it doesn't make sense to cache the disk backup pool.

A similar case can be made for archived data. CML uses archive mostly =
for long-term retention of data (i.e. IRS and state regulatory agencies' =
requirements). Again, the data will probably not ever be read again. =
Thus there is little benefit to caching the data.

Generally speaking, I would justify caching only if you have plenty of =
disk space to go around so that you don't migrate much to tape, or on an =
exception basis for a special storage pool where maybe the end users =
have a specific requirement for the fastest possible access and the disk =
residency is lengthy.

Andy Raibeck