ADSM-L

Re: DSMSERV UNLOADDB

2004-10-07 10:31:06
Subject: Re: DSMSERV UNLOADDB
From: Daniel Sparrman <Daniel.Sparrman AT EXIST DOT SE>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 7 Oct 2004 16:33:09 +0200
Hi Fred

pSeries 660 * 2 (HACMP)
4GB RAM
HDS 9960 * 2
4 FC adapter to disk(2 adapters to each HDS 9960)

The environment has a total of 300TB of data divided into 2 STK 
PowderHorns.

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



fred johanson <fred AT MIDWAY.UCHICAGO DOT EDU> 
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
2004-10-07 16:30
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
Re: DSMSERV UNLOADDB






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" <alexandra.yuhico AT ATOSORIGIN DOT COM>
>Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>2004-10-07 16:15
>Please respond to
>"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
>
>To
>ADSM-L AT VM.MARIST DOT EDU
>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:Daniel.Sparrman AT EXIST DOT SE]
>Sent: Friday, 8 October 2004 12:11 AM
>To: ADSM-L AT VM.MARIST DOT EDU
>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" <alexandra.yuhico AT ATOSORIGIN DOT COM>
>Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>2004-10-07 16:03
>Please respond to
>"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
>
>To
>ADSM-L AT VM.MARIST DOT EDU
>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:Daniel.Sparrman AT EXIST DOT SE]
>Sent: Thursday, 7 October 2004 11:52 PM
>To: ADSM-L AT VM.MARIST DOT EDU
>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" <alexandra.yuhico AT ATOSORIGIN DOT COM>
>Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>2004-10-07 15:50
>Please respond to
>"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
>
>To
>ADSM-L AT VM.MARIST DOT EDU
>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 

<Prev in Thread] Current Thread [Next in Thread>