Hi Steve! This is exactly the reason why we decided for the hybrid migration scenario after all. It's a big bang method, but it saved a lot of people an enormous amount of work... The only thing I do not agree with is what your DBA tell you about how RMAN works. RMAN by default knows nothing about what's really stored in TSM. It does not sync with TSM by default, so when you delete obsolete objects through RMAN it just deletes TSM files on your new server which are not there (yet). You need to run tdposync to sync TSM with RMAN afterwards. So, when a node is exported to the new server, you have to remove (through tdposync) the objects which RMAN removed from it's catalog between the time of the node switch and the time of the finish of the export. Or you can decide to hold the RMAN job/task which removes the obsolete backups until all data is exported to the new server. Kind regards, Eric van Loon AF/KLM Storage Engineering
-----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Steven Harris Sent: dinsdag 11 maart 2014 11:47 To: ADSM-L@VM.MARIST.EDU Subject: Moving Oracle and DB2 nodes between servers. Hi All I'm planning a slow, node-by-node migration from V5 to V6 for one of my customers. The database is too big to do anything else. For most types of node, this is not an issue, Move the node to the new server, wait for most of the data to expire and export/import the remainder (there is some 7-year retention on just about every B/A node). Oracle is an issue. As soon as we switch an Oracle node to the new server, the backups on the old server will cease expiring. Further the DBAs tell me that RMAN for Oracle 8i will see that its catalog and TSM don't match and will remove all the rman entries for the old backups. Apparently Oracle 9i just marks them as invalid. I know that there are at least some backups that need to be kept for longer than the standard, so I can't just go and delete everything after 40 days or whatever. The customer is very rigid about keeping data and won't be talked around. This has me at a complete loss. Our biggest node backs up 2.5 TB per day and we usually keep 40 days worth so an export/import of everything is not going to fly and there is the issue of how to sync up on the receiving side anyway. I might be able to use fromdate/time and todate/time to select just the files that I need. I also have a similar issue with DB2, although I've discovered that I can delete a DB2 backup using the BA command line, at least under AIX. There is however no utility similar to tdposync for DB2, so even if I had the data from the V5 server I don't know how to tell DB2 that it is there. Has anyone wrestled these particular demons, and how did it work out? The DBAs are way outside their comfort zone and I'm just as uncomfortable. Thanks Steve Steven Harris TSM Admin Canberra Australia ******************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ********************************************************
