Re[2]: Checkpoints taking to long!!

Bridgette: Your physical log file may be too small. If it's in it's own dbspace you could check with onstat -d. Otherwise I can't think of another way at the moment (maybe the group has some ideas) Kevin ______________________________ Reply Separator ____________________________ _____ Subject: Re: Checkpoints taking to long!! Author: ntruby@netcomuk.co.uk at TIME_INC Date: 3/24/99 4:08 AM What's triggering your checkpoints? Are they occurring at the interval, i.e. every five minutes, or more frequently? If they're every five minutes, try a more dramatic reduction of max and min dirty, say 10 and 5. Neil bridget wrote in message <36F82B39.C6D6833E@auckland.ac.nz>... >Hi > >I've run into a problem with the checkpoints on my production system - >they used to be all around 0 seconds long with the occasional 3 second >checkpoint - now they have increased to more like 10-15 seconds average >with a top of 20 seconds. We are running 730UC5 on a Sequent Box with 8 > >CPU dedicated to the database and 40 gig of mirrored space. > >Below are the settings in my onconfig file - I have decreased the >max_dirty and min_dirty to see if it makes any difference, it didn't. > >Should I increase the number of LRU's and decrease the size of the >logs?. Any ideas would be more than welcome. > > ># Shared Memory Parameters > >LOCKS 3000000 # Maximum number of locks >BUFFERS 60000 # Maximum number of shared buffers >NUMAIOVPS # Number of IO vps >PHYSBUFF 32 # Physical log buffer size (Kbytes) >LOGBUFF 32 # Logical log buffer size (Kbytes)>LOGSMAX 40 # Maximum number of logical log files >CLEANERS 8 # Number of buffer cleaner processes >SHMBASE 0x10000000 # Shared memory base address >SHMVIRTSIZE 144000 # initial virtual shared memory segment> >size >SHMADD 16000 # Size of new shared memory segments >(Kbytes) >0=>unlimited >CKPTINTVL 300 # Check point interval (in sec) >LRUS 16 # Number of LRU queues >LRU_MAX_DIRTY 40 # LRU percent dirty begin cleaning limit > >LRU_MIN_DIRTY 35 # LRU percent dirty end cleaning limit >LTXHWM 50 # Long transaction high water mark>percentage >LTXEHWM 60 # Long transaction high water mark >(exclusive) >STACKSIZE 32 # Stack size (Kbytes)> > >thanks Bridget > > >