ADSM-L

DEFINE DBCOPY - why would this operation took >20hours to sync two 8gb volumes

2001-06-29 18:19:42
Subject: DEFINE DBCOPY - why would this operation took >20hours to sync two 8gb volumes
From: "Kent J. Monthei" <Kent_J_Monthei AT SBPHRD DOT COM>
Date: Fri, 29 Jun 2001 18:20:09 -0400
We have a very large application server (Sun E10K, 12 processors, 8GB
physical memory) which runs a 24x7 Oracle data warehouse application.  The
server also runs TSM 3.7.3 Server for backups to a local/private tape
library.

A 'DEFINE DBCOPY' operation for an 8GB database volume mirror on this
server saturated an entire processor - hovered at 8% CPU according to 'top'
for over 20 hours straight!  The really odd thing is that the same
operation was performed last week on the same volume-pair, and was 95%
complete after nearly 8 hours - but had to be terminated because it was
interfering with production.  Another oddity - that same day last week, two
other 4GB volume mirrors were also created (all 3 ran concurrently, in
fact) and those two finished in under 2 hours.  I already confirmed that
all 3 volume-pairs are on the same two controllers and that each of the
three 2-volume mirrors uses 1 volume from each controller.

Our internal debate is whether this is a volume configuration problem, a
TSM defect, or just resource contention between TSM and other applications.
And I'm still wondering why the same TSM operation that took 8 hours the
other day (and seemed excessive then), took over 20 hours overnight last
night.  Again, the TSM server was otherwise idle - no backups were run
during that 20-hour period.

Has anyone had similar experience using 'DEFINE DBCOPY' on a large volume ?
Anyone have any insights?

-rsvp, thanks
Kent Monthei
Kent Monthei
GlaxoSmithKline
<Prev in Thread] Current Thread [Next in Thread>
  • DEFINE DBCOPY - why would this operation took >20hours to sync two 8gb volumes, Kent J. Monthei <=