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

>>> Paul AT VANGUARD-IT.COM DOT BR 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: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
        


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.