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 AT VM.MARIST DOT EDU] On Behalf Of
Steven Harris
Sent: dinsdag 11 maart 2014 11:47
To: ADSM-L AT VM.MARIST DOT 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
********************************************************
|
