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:rbs AT BU DOT EDU]
Enviada: sex 7/1/05 8:37
Para: ADSM-L AT VM.MARIST DOT 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
|