The load, in my experience, takes about half the time as the unload. Since all the work is done on the unload, I still don't understand why a load takes so much longer than a restore.
On Fri, 8 Oct 2004, Yuhico, Alexandra wrote: > thank you daniel. > in that case i may as well push through with the loading and hope it takes a > shorter amount of time than the unload which took 8 hours! > > -----Original Message----- > From: Daniel Sparrman [mailto:[EMAIL PROTECTED] > Sent: Friday, 8 October 2004 12:11 AM > To: [EMAIL PROTECTED] > Subject: Re: DSMSERV UNLOADDB > > > Hi Alexandra > > Sorry I misunderstood you. However, as soon as you have initiated the > unload process, the database will be unable to put online. This all have > todo with how the unload process acts. > > I have no answer to why the unload process has this result on the TSM > server database. One possibility is that the unload process doesnt copy > the entries, rather moves them to the unload volumes. > > So the answer is still the same; you will need to restore a database > backup to make your TSM server go online. > > Best Regards > > Daniel Sparrman > ----------------------------------- > Daniel Sparrman > Chef Utveckling & Drift > Exist i Stockholm AB > PropellervÃgen 6B > 183 62 TÃBY > VÃxel: 08 - 754 98 00 > Mobil: 070 - 399 27 51 > > > > "Yuhico, Alexandra" <[EMAIL PROTECTED]> > Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > 2004-10-07 16:03 > Please respond to > "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > > > To > [EMAIL PROTECTED] > cc > > Subject > Re: DSMSERV UNLOADDB > > > > > > > i didn't abort the dsmserv unloaddb. i allowed it to finish. but i want to > stop here before i take more time into my production. > > if i continue doing the dsmserv loadformat, and loaddb command, i will > have > overshot my change window. i want to avoid this and just do the activity > some other time when i can allocate enough time. > > what does unloaddb do that will stop tsm db from restarting? > > -----Original Message----- > From: Daniel Sparrman [mailto:[EMAIL PROTECTED] > Sent: Thursday, 7 October 2004 11:52 PM > To: [EMAIL PROTECTED] > Subject: Re: DSMSERV UNLOADDB > > > Hi Alexandra > > Aborting a dsmserv unloaddb in the middle of a process means you have to > restore the database from your latest database backup. > > There is no other way of getting your TSM server online again. > > Best Regards > > Daniel Sparrman > ----------------------------------- > Daniel Sparrman > Chef Utveckling & Drift > Exist i Stockholm AB > PropellervÃgen 6B > 183 62 TÃBY > VÃxel: 08 - 754 98 00 > Mobil: 070 - 399 27 51 > > > > "Yuhico, Alexandra" <[EMAIL PROTECTED]> > Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > 2004-10-07 15:50 > Please respond to > "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> > > > To > [EMAIL PROTECTED] > cc > > Subject > DSMSERV UNLOADDB > > > > > > > Folks, > ANYONE EVER DONE A TSM reorganization but wanted to stop after performing > DSMSERV UNLOADDB due to time limit? > > I did the DSMSERV UNLOADDB but didn't realize it would take soo long. when > i went and tried to do a restart of the TSM server (after making sure all > my > devconfig.bak files were correct), I got an access denied error. > > Any thoughts? > Ta, > Alexandra > > This e-mail is privileged and may contain confidential information > intended only for the person(s) named above. If you receive this e-mail > in error, please notify the addressee immediately by telephone or return > e-mail. Although the sender endeavours to maintain a computer > virus-free network, the sender does not warrant that this transmission is > virus-free and will not be liable for any damages resulting from > any virus transmitted. > > This e-mail is privileged and may contain confidential information > intended only for the person(s) named above. If you receive this e-mail > in error, please notify the addressee immediately by telephone or return > e-mail. Although the sender endeavours to maintain a computer > virus-free network, the sender does not warrant that this transmission is > virus-free and will not be liable for any damages resulting from > any virus transmitted. > > This e-mail is privileged and may contain confidential information intended only for > the person(s) named above. If you receive this e-mail > in error, please notify the addressee immediately by telephone or return e-mail. > Although the sender endeavours to maintain a computer > virus-free network, the sender does not warrant that this transmission is virus-free > and will not be liable for any damages resulting from > any virus transmitted. > >
