We are doing a 5.5 to 6.2 migration now by exporting all our nodes to
new servers. Some of our oracle nodes are very large, but exporting
works fine, it just takes a while. We had one node that took over a week
to complete. Here's an outline of our process:

TSM-A is the 5.5 server. TSM-B is the 6.2 server. NODE1 is currently
backing up to TSM-A using  the TDP client.

0. Instruct DBAs to halt clean ups of old data (TDPOsycn or whatever
scripts they run).
1. Export NODE1 from TSM-A to TSM-B.
    a. If there are mulitple file spaces export a few at a time to make
it more manageable and to not fill BACKUPPOOL on TSM-B if possible.
2. NODE1 continues to backup to TSM-A.
3. Catchup export. You're now missing a day to a week of data, so after
the initial export is done, do another export specifying the date using
fromdate set to the date of the start of the orginal export and
merge=yes. If there's a lot of data it could take a day to catch up.
4. Stop backups on NODE1.
5. Do a final catchup export using fromdate set to date of catchup
export. Don't forget merge=yes.
6. Switch NODE1 over to TSM-B.
7. Make sure backups are working and all backup data is on the new server.
8. Delete NODE1 from TSM-A when you're comfortable.


On 5/13/2012 23:42, Xav Paice wrote:

----- 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.