On Tuesday, Oct 28, 2003, at 05:17 Australia/Sydney, Hart, Charles
wrote:

We will be upgrading a TSM Server (AIX 4.3.3/ H80) with 100GB TSM DB.
This backup server plays an important role for our Oracle DB's as it
archives the Oracle logs all day long.  (Not using RMAN yet) Our TSM
upgrade from 4.1.6 to 5.7.1 is estimated at 10-12 hours for the
upgrade db process.

If for some reason the upgrade fails we will have to recover ASAP for
the sake of the oracle log file systems will be filling up.  With that
said we are looking at a couple quick recovery options in case we have
to roll back the TSM DB.  Here's a couple options we have though of so
far...

1) Create a Second TSM DB Copy Mirror (TSM Mirroring)  In hopes that
we could break it off prior to the upgrade so it can then run as
primary?
2) Do a backup db to a device type of file.

Any input or other ideas would be greatly appreciated!!!  I will be
calling Tivoli Tech Support as well to see what they suggest.

Our method was - with a smaller DB:

1. Stop client access.
2. Migrate disk pools.
3. Shut down TSM.
4. 'dd' DB and log raw volumes to tape.

This has the advantage of being able to stream to tape (3590 in our
case),
and is a "cold" backup of TSM state. Mind you, we never had to restore
from it, YMMV.

Given your DB size, I'd got with your option 1. Rename whichever sets of
volumes out of the way with TSM shut down, and they shouldn't get
touched.
Your fallback for upgrade will be a TSM shutdown, bunch of renames, TSM
reinstall and TSM startup (and eventual remirror). I wouldn't split off
the mirror inside TSM - leave TSM thinking it has three copies. Just
rename at the OS level to control which sets of volumes TSM uses.

Cheers,
--
Paul Ripke
Unix/OpenVMS/TSM/DBA
I love deadlines. I like the whooshing sound they make as they fly by.
-- Douglas Adams