Daniel,
What hardware/software are you on for that kind of performance?
At 04:16 PM 10/7/2004 +0200, you wrote:
Hi Alexandra
The load process normally takes less time than the unload process. We made a unload on a 165GB large TSM database. It took 24 hours to unload, but only 16 hours to load.
So, it takes about 2/3 of the time todo the reload. This is of course depending on the type of media you're using. We made the unload to disk.
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:15 Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To [EMAIL PROTECTED] cc
Subject Re: DSMSERV UNLOADDB
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.
Fred Johanson
ITSM Administrator
University of Chicago
773-702-8464
