Carsten, Paul,
the three biggest contributors to TSM's DB size are tables BACKUPS,
ARCHIVES and CONTENTS. First two show what was backed up/archived and the
third show where the objects are stored. Everything hitting the TSM server
is either a backup or an archive or a space-managed file. Usually
It could be but is a very rare situation. And you do not have the
reusedelay parameter for diskpools, do you.
Zlatko Krastev
IT Consultant
Sam Sheppard <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
22.02.2003 01:03
Please respond to "ADSM: Dist Stor Manager"
My organization recently migrated a 45GB TSM 5.1.5
database from an old AIX platform to a Sun V880
running Solaris 8. The migration of the database was
done by using "dsmserv restore db" as the export
failed on varios errors. A db audit was never
performed because of the downtime involved - days,
w
Lloyd,
Unless proved otherwise I will assume it still applies. Whenever I've
installed TSM in a SAN I've changed this and had not problems. So
practically it is proven. From theoretical side it also makes sense and
with introduction of 2 Gbps (and future faster) SAN it can only become
more importa
