ADSM-L

Re: Slow Restore: 10 G in 16 hours

2015-10-04 17:29:34
Subject: Re: Slow Restore: 10 G in 16 hours
From: Mike Glassman - Admin <admin AT IAA.GOV DOT IL>
To: ADSM-L AT VM.MARIST DOT EDU <ADSM-L AT VM.MARIST DOT EDU>
Date: 18 July 2000 15:00
>Leo,
>
>Can you expand on this a bit please.
>
>Mike
>
>> -----Original Message-----
>> From: Leo Humar [SMTP:lhumar AT BIGPOND.NET DOT AU]
>> Sent: a eaie 17 2000 13:47
>> To:   ADSM-L AT VM.MARIST DOT EDU
>> Subject:      Re: Slow Restore: 10 G in 16 hours
>>
>> G'day Mike,
>>
>> Do you have a separate management class for directories and is it on the
>> disk ?
>> Our performance was not good without DIRMC.
>>
>>
>> Leo Humar
>> LCS Pty Ltd
>> lhumar AT bigpond.net DOT au
>>
>> No trees were killed in the sending of this message. However a large
>> number of electrons were terribly inconvenienced.
>>
>> -----Original Message-----
>> From: Mike Glassman - Admin <admin AT IAA.GOV DOT IL>
>> To: ADSM-L AT VM.MARIST DOT EDU <ADSM-L AT VM.MARIST DOT EDU>
>> Date: 17 July 2000 14:40
>> Subject: Re: Slow Restore: 10 G in 16 hours
>>
>>
>> >That's about the average of such a restore here.
>> >
>> >Last large restore we did, also after collation had been fixed and all,
>> took
>> >2 hours for 64MB of files (300 files).
>> >
>> >What I worked out, is that the system was flipping between tapes all the
>> >bloody time.
>> >
>> >I'm not now or have I ever been impressed with ADSM's restore speeds.
>> >
>> >Mike
>> >
>> >> -----Original Message-----
>> >> From: Raymond Chao [SMTP:Raymond.Chao AT IPAUSTRALIA.GOV DOT AU]
>> >> Sent: a eaie 17 2000 6:33
>> >> To:   ADSM-L AT VM.MARIST DOT EDU
>> >> Subject:      Slow Restore: 10 G in 16 hours
>> >>
>> >> To:   ADSM-L AT VM.MARIST DOT EDU
>> >> cc:
>> >>
>> >>
>> >> Dear all,
>> >>
>> >>     We had a restore from *sm (ADSM 3.1.2.55 running on AIX 4.3.2). It
>> >> took 16
>> >> hours for 10 Gig.
>> >>
>> >> It was a SAP(financial db)  restore, it took 1 hour for 4 G for the
db,
>> >> then the
>> >> rest for the other files. We saw message like
>> >>  "mounting offline tape " and then restore files.
>> >>
>> >> We had collocation turned on in Feb 2000 which we thought would help
>> >> restore.
>> >> I believe all of our nodes have been collocated.
>> >> We have 18 primary storage  dltpool tapes storing  580 gig for this
SAP
>> >> node.
>> >> Can anyone explain why the restore is so SLOW. Is  it  *sm or network
?
>> >>
>> >> I think  *sm smart should be enough to minimise tapes mounting when
>> files
>> >> are
>> >> scattered across
>> >> a numbe(in this case 18) of tapes. Does restore have higher  priority
>> than
>> >> other
>> >> processes?
>> >>
>> >>
>> >> Any suggestions are gladly accepted .....
>> >>
>> >> Raymond Chao
>> >> ADSM Administration, Unix Group
>> >>  IPAustralia, Canberra, Austarlia
>> >
>
<Prev in Thread] Current Thread [Next in Thread>