ADSM-L

Re: Restore Speeds : Collocated vs Not

2000-08-03 14:35:11
Subject: Re: Restore Speeds : Collocated vs Not
From: "Slaughter, Bill" <BillSlaughter AT TUPPERWARE DOT COM>
Date: Thu, 3 Aug 2000 14:35:11 -0400
Yes (from memory):

Same restored Data, Sort of, each time we improved the process.

The data is from an Oracle database (Not using EBU) and is about 36-39 4GB
mount Points. i.e. 130GB of Oracle Database Data. (Actual ADSM STGP size
50GB)

Same server: each time.

        RS6K R50 AIX 4.3.3 ADSM 3.1.2.40 (Yes I know it's old)

Client: HP T520 (12 CPU)

                Client speed will make a difference.

                I ran the restore on our faster HP V2500 (8 Cpu) it ran in
just over an hour.
                I had to check for errors more because I was looking for why
it completed so quickly.

When using No Collocation it ran for over 24 hours (From DLT7000 in a STK
9710 Library). The data was on just a few DLT 7000 tapes so each restore
request (Mount point) had to locate the data on the tape. I believe it spend
much time waiting for the spinning/rewinding of the tape.

When using collocation at filespace (more tapes) I was able to get it done
in about 8 hours. I could only run 8 at a time since that was the number of
tape drives I had.

When I issued move data commands and brought my tapes back to the disk
storage pool we got it down to 5-6 hours. I did not count the time I spend
doing the move data commands.

We do this restore about twice a quarter. We have learned that when we need
to do this planning in advance by either turning on collocation at the
filespace or turning on the stgpool cache=yes option.

In a disaster scenario, I would issue a "Stgpool restore" to get it back to
the point where all my data (main database data) was on disk. I realize that
I don't have to wait till the "stgpool restore" is done for client restores
but I would anyway.

Bill

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