Allen,
I tend to agree with you, managements tend to get hung up on the full backup
every day concept when the real impact of and incremental or differential
strategy on the occasional outage is quite small. However,...
There is a paper on the IBM site
http://www-106.ibm.com/developerworks/db2/library/techarticle/0204quazi/0204quazi.html
which describes how to use the db2 suspend write command to provide a window
where a split mirror copy can be created. Looking at a description of the TSM
for Hardware product, it seems that this is the way that the SAP/DB2/ESS
version of that product works.
Now I didn't originally suggest this to our original poster because he's on RAW
volumes, and I assume that this is for performance or storage overhead reasons.
ESS flashcopy is out of the question, and split mirror will require the data
to be on cooked volumes. But, if a move to JFS2 filesystems was possible, the
AIX 5.2 snapshot command in conjunction with suspend write might be a good
option.
Regards
Steve Harris
AIX and TSM Admin
Queensland Health, Brisbane Australia
>>> asr AT UFL DOT EDU 08/05/2004 11:39:03 >>>
==> 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
***********************************************************************************
This email, including any attachments sent with it, is confidential and for the
sole use of the intended recipient(s). This confidentiality is not waived or
lost, if you receive it and you are not the intended recipient(s), or if it is
transmitted/received in error.
Any unauthorised use, alteration, disclosure, distribution or review of this
email is prohibited. It may be subject to a statutory duty of confidentiality
if it relates to health service matters.
If you are not the intended recipient(s), or if you have received this email in
error, you are asked to immediately notify the sender by telephone or by return
email. You should also delete this email and destroy any hard copies produced.
***********************************************************************************
|
