Re: Slow Restore: 10 G in 16 hours
2000-07-17 01:42:23
Subject: |
Re: Slow Restore: 10 G in 16 hours |
From: |
Mike Glassman - Admin <admin AT IAA.GOV DOT IL> |
Date: |
Mon, 17 Jul 2000 07:42:23 +0200 |
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
|
|
|