----- Original Message -----
> From: "Steve Harris" <steve AT STEVENHARRIS DOT INFO>
> Hi All
> Like a lot of us, I'm contemplating a TSM 5.5 to 6.3 move for one of
> Most clients are not a problem, point the client at the new server,
> take the first backup, and then after an appropriate length of time
> either delete the data on the old server or export/import whatever is
> left. This works fine for the BA client, Domino, MSSQL, SAP, however
> does not work for DB2 and Oracle.
> Since DB2 and Oracle keep track of their own named backups, and
> these when they have expired from the DBMS point of view, and they
> only access one TSM node at a time, there will be orphaned backups
> on the old server that will never expire, and as their entries are no
> longer in the DBMS's catalog they will never be deleted if they are
> imported to the new server. This particular customer likes to keep a
> periodic backup for a long time so it is a real issue.
> I just did Butterfly training, and that product solves the problem
> oracle by restore/re-backup and fiddle the rman catalog.
> What are the rest of you doing to address this issue?
> Steven Harris
> TSM Admin, Canberra Australia
You could 'export node' - however if you want to do that across the LAN it does
rely on the new server having a new name so you can do server-server comms, and
a password reset. Or you can rename the old server, and reset the passwords on
all the nodes you've not yet moved. Or just export/import via media. There is
a time issue where you don't want the rman catalog resync'd or it will re-do a
full backup.... depends on the time taken to export/import if that is an issue
I still fail to see why it takes so long to insert the database when doing an