==> 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