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 GlaxoSmithKline
