I would be interested in that, if you'd care to keep posting updates.
Troy Frank
Network Services
University of Wisconsin Medical Foundation
608.829.5384
>>> [EMAIL PROTECTED] 7/4/2005 4:03:41 PM >>>
Hello All,
Just to keep you updated on my quest :)
I began to modify some settings, and have already reduced the number of log
volumes from 10 to 2, and stgpool volumes from 108 to 6. Backups are a little
bit faster now, but I expect the gain to be bigger when I re-create the DB
volumes.
I am very concerned about the expiration process. Analyzing the actlog, I
found out that the expiration process (two daily runs with DURATION=240 each)
is taking nearly a MONTH to process the same filespace again. I am not joking :(
I also found out what might be the cause of the database size and expiration
performance (in addition to the volume allocation). Just look at the output of
a "select type,sum(num_files) as Files from occupancy group by type" command:
TYPE FILES
------------------ -----------
Arch 384354353
Bkup 35759844
It seems that someone likes archiving. I am now in the process of replacing
the majority of these with backup operations.
If there is interest, I can (maybe in private emails) post the results in
terms of changed made vs. performance improvement.
Best regards,
Paul
-----Mensagem original-----
De: Richard Sims [mailto:[EMAIL PROTECTED]
Enviada: sex 7/1/05 8:37
Para: ADSM-L@VM.MARIST.EDU
Cc:
Assunto: Re: Very slow DB backups
Hi, Paul -
You have your work cut out for you with that train-wreck of a system.
I'd begin by questioning the need for all that DB content... There
may be abandoned filespaces which should go, obsolete retention
periods which no one has looked at in years, and perhaps even
Expirations which never run to completion.
As to performance, I'd begin by inspecting SCSI topology, to assure
no dumb stuff, like tape and disk on the same cable. Next I'd review
the LTO microcode levels, as older levels had serious problems (see
"LTO performance" in ADSM QuickFacts). The "sleep" may be the drive
struggling to load and position the tape. You might consider a tape
case study using the tapeutil command, or the like, to get some
baseline numbers on the performance of those drives and tapes for
comparison as improvements are pursued.
The disk layout certainly needs a lot of review, as it doesn't seem
to make sense, even if one is not familiar with EMC boxes.
Only as very last resort would I even consider db unload/reload:
that's ill-advised even in the best of circumstances, as proven
dangerous and often unproductive.
Richard Sims
Confidentiality Notice follows:
The information in this message (and the documents attached to it, if any)
is confidential and may be legally privileged. It is intended solely for
the addressee. Access to this message by anyone else is unauthorized. If
you are not the intended recipient, any disclosure, copying, distribution
or any action taken, or omitted to be taken in reliance on it is
prohibited and may be unlawful. If you have received this message in
error, please delete all electronic copies of this message (and the
documents attached to it, if any), destroy any hard copies you may have
created and notify me immediately by replying to this email. Thank you.
