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
