Re: Best practices for Oracle and DB2 Moves
On 14.05.2012 00:42, Xav Paice wrote: - Original Message - From: "Steve Harris" 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. Xav, maybe I have the wrong end of the stick, but bear with me. Suppose I have an oracle node on OLDSERVER that runs a 12 month retention backup on the first of every month At the moment it has daily backups going back 35 days and 12 months work of monthlies. So, I move the node over to NEWSERVER, and start taking backups there. On 1 June, it takes a new monthly to NEWSERVER. That is as expected. It also attempts to delete the 1 June 2011 backup which is now due to expire. The delete will fail as that backup exists on OLDSERVER not on NEWSERVER. RMAN catalog gets cleaned up and there is now no knowledge of the 1 June 2011 backup in RMAN. Move ahead three months. I run an export/import with merge from OLDSERVER to NEWSERVER. The 1/6/2011, 1/7/2011 and 1/8/2011 backups all get copied across because they have never been deleted, as do the 35 days worth of daily backups that were valid when the node was cut across. There are no RMAN entries for these now, so they will never be deleted. Looks to me that my only option is to run TDPOSYNC. The same applies to DB2, although I should be able to delete what I no longer want using adb2util. Am I confused somewhere? Regards Steve.
Re: Best practices for Oracle and DB2 Moves
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" 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.
Re: Best practices for Oracle and DB2 Moves
- Original Message - > From: "Steve Harris" > > 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.
Best practices for Oracle and DB2 Moves
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