----- 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
> my
> customers.
>
> 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
> it
> does not work for DB2 and Oracle.
>
> Since DB2 and Oracle keep track of their own named backups, and
> delete
> these when they have expired from the DBMS point of view, and they
> can
> only access one TSM node at a time, there will be orphaned backups
> left
> 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
> for
> oracle by restore/re-backup and fiddle the rman catalog.
>
> What are the rest of you doing to address this issue?
>
> Regards
>
> Steve.
>
> 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 
or not.

I still fail to see why it takes so long to insert the database when doing an 
upgrade.