As always, thanks for the detailed explanation. I clears up a lot of questions on how the whole process works.
I agree the "GUI" is worth the hassle of what I have to do to get it to work (i.e. xauth trickery). I don't have access to root - just sudo (remember - these are Linux servers - not Windows). Yes my V5 server is old/slow - from the time dsmserv starts to when the server is accessible is usually 20+ minutes. I have tested the conversion process with my simply restoring the V5 DB from a backup and then running through the UPGRADEDB (always wondered what that does - never got a good answer the last time I asked - does it make changes to the existing DB? Can I run it multiple times? What does it do that is required for the EXTRACTDB). The V5 DB is currently 170GB assigned with 42% utilized but can only reduce the size by 43GB - yes, lots of gas! The manual EXTRACTDB produces 40GB files. I also remember all the prep - empty and delete all disk storage volumes (yes, still using regular DISK vs FILE - IMHO, it seems to run faster than the overhead of allocate, fill, delete, rinse-lather-repeat) that FILE requires. With RH Linux V6 and ext4, the storage pool volumes are allocated instantly. On Fri, Jun 14, 2013 at 4:40 PM, Prather, Wanda <[email protected]>wrote: > 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:[email protected]] On Behalf Of > Remco Post > Sent: Friday, June 14, 2013 4:09 PM > To: [email protected] > 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 <[email protected]> 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 <[email protected] > >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:[email protected]] On Behalf > >> Of Remco Post > >> Sent: Friday, June 14, 2013 1:59 PM > >> To: [email protected] > >> 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 <[email protected]> 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 [email protected] - > >>> 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 > >> [email protected] > >> +31 6 24821622 > >> > > > > > > > > -- > > *Zoltan Forray* > > TSM Software & Hardware Administrator > > Virginia Commonwealth University > > UCC/Office of Technology Services > > [email protected] - 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 > [email protected] > +31 6 248 21 622 > -- *Zoltan Forray* TSM Software & Hardware Administrator Virginia Commonwealth University UCC/Office of Technology Services [email protected] - 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
