You can't do the upgrade from a DB backup. "Media method" creates a different
type of output file, called an extract. It is neither a DB backup nor the old
TSM DB dump format. If you do point the extract to tape, then yes you can
reload on the V6 side from the tape. But I think it still takes longer than
network method (at least for the 6 conversions I've done), unless your V5 DB
has remarkably bad I/O throughput. Also, unless this is a quite new V5 server,
if it is currently 100 GB, you will have less than 100GB to transmit. The
extract eliminates all the dead, wasted space in the V5 DB that accumulates
over time.
You HALT the source server TSM process. (You want it down no matter how you do
this, because you don't want anybody to make DB changes that will be lost when
you bring up the V6 server.) But the host machine stays booted so it can talk
to the world via IP.
The "wizard" (and I like the GUI, BTW!) uses RSH or SSH running from the V6
side to actually drive both the V6 server and the V5 server at the same time;
it remotely starts and stops the V5 dsmserv process as needed (in a mode where
it does not accept client connections), but you can see what is happening in
the wizard window.
Another thing about the wizard, it does all the annoying ticky steps like
creating the instance and the DB backup settings required for V6 under the
covers before it finishes. Very worth running!
W
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Remco Post
Sent: Friday, June 14, 2013 4:09 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Migrating last 5.5 server to 6.3.3 and new hardware
On 14 jun. 2013, at 22:02, Zoltan Forray <zforray AT VCU DOT EDU> wrote:
> How does that work? Is the "source server" supposed to be running? -
> The "source" is 100GB or so and figured that would take a while ever
> with 1GB networking. Sounds like the "grab it from DB tape backup" might be
> simpler.
>
>
the bottleneck is not usually the network, but the disk at the source server. 5
to a maximum of 10 GB/hour is the best performance to be expected. How, it
works: the dsmicfgx tool will guide you through the steps, and yes, the source
server must be down. That is BTW the reason why at that database size the
downtime is maybe an issue.
> On Fri, Jun 14, 2013 at 3:54 PM, Prather, Wanda <Wanda.Prather AT icfi DOT
> com>wrote:
>
>> I agree.
>> Much simpler to do the across-the-network upgrade.
>> Install V6 on the new server, let the wizard do the work!
>>
>> -----Original Message-----
>> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
>> Of Remco Post
>> Sent: Friday, June 14, 2013 1:59 PM
>> To: ADSM-L AT VM.MARIST DOT EDU
>> Subject: Re: [ADSM-L] Migrating last 5.5 server to 6.3.3 and new
>> hardware
>>
>> I did an 'over the network' upgrade from the 5.5.4 server to the
>> 6.2.5.0 one, no sweat. Of course, being the man that I am, I steered
>> clear of any GUI that IBM has provided. Your plan will most likely
>> work, but why bother with TSM v5 on the new box? Either dump the db
>> to tape on the old one or transfer via IP....
>>
>> On 14 jun. 2013, at 16:17, Zoltan Forray <zforray AT VCU DOT EDU> wrote:
>>
>>> I am scheduling to do the above and want to make sure I am not
>>> missing something, especially since the upgrade guide is a little confusing.
>>>
>>> Current config - RedHat 5.9, TSM 5.5.6.100 New config - RedHat 6.4,
>>> TSM 6.3.3.200
>>>
>>> What I am proposing (all done on the new, virgin server)
>>>
>>> 1. Install 5.5.7 server and server upgrade 2. Backup DB, devconfig
>>> and volhist on 5.5 server and halt/shut down 3. Restore 5.5 server
>>> DB backup using last devconfig and volhist 4. Install 6.3.3 5. Run
>>> dsmupgdx process which does the UPGRADEDB, EXTRACTDB and then
>>> configs and loads the new DB 6. Switch over network
>>> connections/config
>>>
>>> The last version of the upgrade book I have has you going through
>>> the upgradedb and extractdb manually but then when you run the
>>> dsmupgdx is does it all over again......
>>>
>>> Am I missing anything?
>>>
>>> FWIW, next up is replacing my 6.1 server....fun.....
>>>
>>> --
>>> *Zoltan Forray*
>>> TSM Software & Hardware Administrator Virginia Commonwealth
>>> University UCC/Office of Technology Services zforray AT vcu DOT edu -
>>> 804-828-4807 Don't be a phishing victim - VCU and other reputable
>>> organizations will never use email to request that you reply with
>>> your password, social security number or confidential personal
>>> information. For more details visit
>>> http://infosecurity.vcu.edu/phishing.html
>>
>> --
>>
>> Met vriendelijke groeten/Kind regards,
>>
>> Remco Post
>> r.post AT plcs DOT nl
>> +31 6 24821622
>>
>
>
>
> --
> *Zoltan Forray*
> TSM Software & Hardware Administrator
> Virginia Commonwealth University
> UCC/Office of Technology Services
> zforray AT vcu DOT edu - 804-828-4807
> Don't be a phishing victim - VCU and other reputable organizations
> will never use email to request that you reply with your password,
> social security number or confidential personal information. For more
> details visit http://infosecurity.vcu.edu/phishing.html
--
Met vriendelijke groeten/Kind Regards,
Remco Post
r.post AT plcs DOT nl
+31 6 248 21 622
|
