On 14.05.2012 00: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.
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.
|
