----- Original Message ----- > From: "Steve Harris" <[email protected]> > > 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.
