Allen,
Are current backups are not bottling up at the Network. You
overlooked the statement about compressing the data before it was sent.
The 9840s are 9840a and 9840b and they are ESCON attached. Which means
they will max out at 14MB at best (on a 9840b). The tape drives are
definitly starving for data. The actual compressed data arriving is
760GB. There is a lot of unallocated and free space on the data
warehouse. The DBA said it is a realistic 2.4TB not 3TB. I had it
spread out on 6 drives to try and configure things to make maximum use
of the 14 engines doing the compression. Yes, I know it sounds like a
goffy way of doing things but that was the hardware that was available
for other reasons.
I do agree with your suggested design. Ideally we switch to a
LAN FREE environment, or put a copy of TSM server on the data warehouse
server. Using the SAN fabric to tape, and using the hardware
compression has more promise, but requires a structural change that
costs $. Till now they were happy with the backup speeds and the usage
of the available hardware.
What is the real throughput on the LAN FREE environments? Will
it really keep 9840C (30MB/sec) busy?
Matt
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
asr AT UFL DOT EDU
Sent: Friday, May 07, 2004 9:39 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: What are people doing to bkup big DB2, data warehouse
==> In article
<A8610866F3F1234EAA9110636641B8161E0FB2 AT USCLES506EX.agna.amgreetings DOT com
>, "MC Matt Cooper (2838)" <Matt.Cooper AT AMGREETINGS DOT COM> writes:
> what kind of success (backup times) they have had doing it. We are
> backup up a 3TB DB2 data warehouse but it is taking almost 11 hours,
end to end.
> The disk is all Shark, the client is on a p690 14cpu lpar, TSM 5.1
> client, GB Ethenet adapter, going to TSM 5.1.8 server on z/OS 1.4..
> We are precompressing the data on the p690 and going direct to 6 9840
tape drives.
> We are using the DB2 backup utility with parallelism set to 4, with
> the 6 concurrent streams.
OK, let's sketch this out from the black-box perspective.
You've got shark disk, 6x30MB/s tapes, and _one_ GB ethernet? The net
is clearly your bottleneck here. Fix that first.
If we're pretending that you can keep all your tapes streaming (and I
think you'd rather let the tape hardware do any compression here) then
you're talking a -minimum- of 180MB/s, a.k.a. 1.5Gb/s. I'd offhand
recommend 3 gigabit adapters, and switch fabric that won't melt when
they open up the firehose.
Once you get that taken care of, you're still talking about a tape data
rate in the neighborhood of 180MB/s; you might get more depending on
where your tape reps decide to measure bandwidth (I get 110MB/s to a
single 3592 sometimes, but that's an artifact of happy compressable
data)
If we start from 180 MB/s, you're still talking more than 6 hours,
closer to 7. If you're getting 11, while periodically starving your
tapes, you're not really doing that badly.
You might find you do better by -decreasing- the number of streams. If
you are, in fact, starving your tapes occasionally, you could possibly
do better by scaling the number of drives to the rate that fills your
gigabit ethernet.
> Ideally we would like to back it up hot, seems to big and active.
I thing you want this too, and LOGRETAIN set on.
Take some measurements of how long it takes you to roll forward through
a day's transactions. You may be surprised at how little you actually
save by (for example) running daily fulls instead of weekly.
Make sure, whatever schedule you choose, that it's supported by evidence
related to your recovery plan. If you do daily fulls, and they only
result in a 4% improvement in recovery speed compared to weeklies...
you're wasting a LOT of effort.
> There is too much data for mirroring or FLASHCOPY. Has anyone tried
> just backing upthe RAWS seperatly? Matt
Aiee! No, no! don't do this unless you intend to quiesce the whole
thing for the whole time. (shudder)
- Allen S. Rout
|
