Checkpoints up to 20 seconds:

I"m hoping someone might be able to give me some pointers why my checkpoints are taking so longer. I'm trying to get my company to pay for the Performance Tuning Class, but unfortunately the higher ups want to start moving to Oracle. I'm running SCO 3.2.5.0.4 and IDS 7.22.UC3. Checkpoints take up to 20+ seconds: Message Log File: /usr/informix/online.log 14:02:40 Checkpoint Completed: duration was 16 seconds. 14:07:59 Checkpoint Completed: duration was 16 seconds. 14:13:17 Checkpoint Completed: duration was 16 seconds. 14:18:38 Checkpoint Completed: duration was 18 seconds. 14:23:59 Checkpoint Completed: duration was 17 seconds. 14:29:19 Checkpoint Completed: duration was 17 seconds. 14:34:39 Checkpoint Completed: duration was 18 seconds. 14:40:00 Checkpoint Completed: duration was 17 seconds. 14:45:20 Checkpoint Completed: duration was 17 seconds. 14:50:40 Checkpoint Completed: duration was 17 seconds. 14:56:00 Checkpoint Completed: duration was 17 seconds. 15:01:21 Checkpoint Completed: duration was 18 seconds. 15:06:39 Checkpoint Completed: duration was 15 seconds. 15:11:59 Checkpoint Completed: duration was 16 seconds. 15:17:17 Checkpoint Completed: duration was 15 seconds. 15:22:35 Checkpoint Completed: duration was 15 seconds. 15:27:54 Checkpoint Completed: duration was 16 seconds. 15:33:12 Checkpoint Completed: duration was 14 seconds. 15:38:28 Checkpoint Completed: duration was 14 seconds. 15:43:45 Checkpoint Completed: duration was 13 seconds. I'm inserting into a single table which has roughtly 300 bytes per row, and 3 composite indexes of 3 columns each. I'm inserting about 1.5-2 million transactions a day average, and can go up to 4 million transactions. Each day is inserted into a new table. onstat -p shows (I zero the statistics out every night): INFORMIX-OnLine Version 7.22.UC3 -- On-Line -- Up 8 days 15:45:13 -- 121240 Kbytes Profile dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached 6307783 6496311 37524242 83.19 1559428 2838075 6189176 74.80 isamtot open start read write rewrite delete commit rollbk 20634020 15633 41183 7955238 2411324 36 98895 14768 0 ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes 0 0 0 6559.14 2465.00 170 340 bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans 200 0 5535304 0 0 310 64106 887 ixda-RA idx-RA da-RA RA-pgsused lchwaits 0 0 0 0 30967 and My onconfig looks like: #************************************************************************** # # INFORMIX SOFTWARE, INC. # # Title: onconfig.std # Description: INFORMIX-OnLine Configuration Parameters # #************************************************************************** # Set NUMAIOVP from 10 to 14 set 1999-05-21 for next restart. # Restarted 1999-06-01 #************************************************************************** # Root Dbspace Configuration ROOTNAME rootdbs # Root dbspace name ROOTPATH /dev/rc04d0 #Path for device containing root dbspace ROOTOFFSET 0 # Offset of root dbspace into device (Kbytes) ROOTSIZE 1800000 # 1.8 gig Size of root dbspace (Kbytes) #************************************************************************** # Disk Mirroring Configuration Parameters MIRROR 0 # Mirroring flag (Yes = 1, No = 0) MIRRORPATH # Path for device containing mirrored root MIRROROFFSET 0 # Offset into mirrored device (Kbytes) #************************************************************************** # Physical Log Configuration PHYSDBS rootdbs # Location (dbspace) of physical log PHYSFILE 300000 # Physical log file size (Kbytes) #************************************************************************** # Logical Log Configuration LOGFILES 6 # Number of logical log files LOGSIZE 50000 # Logical log size (Kbytes) #************************************************************************** # Diagnostics MSGPATH /usr/informix/online.log # System message log file path CONSOLE /dev/console # System console message pathALARMPROGRAM /usr/informix/log_full.sh # Alarm program path #************************************************************************** # System Archive Tape Device TAPEDEV /dev/null # Tape device path TAPEBLK 16 # Tape block size (Kbytes) TAPESIZE 10240 # Maximum amount of data to put on tape (Kbytes) #************************************************************************** # Log Archive Tape Device LTAPEDEV /dev/null # Log tape device path LTAPEBLK 16 # Log tape block size (Kbytes) LTAPESIZE 10240 # Max amount of data to put on log tape (Kbytes) #************************************************************************** # Optical STAGEBLOB # INFORMIX-OnLine/Optical staging area #************************************************************************** # System Configuration SERVERNUM 0 # Unique id corresponding to a OnLine instance DBSERVERNAME onguinness # Name of default database server DBSERVERALIASES tliguinness # List of alternate dbservernames NETTYPE ipcshm,,, # Configure poll thread(s) for nettype#NETTYPE tlitcp # Configure poll thread(s) for nettype DEADLOCK_TIMEOUT 60 # Max time to wait of lock in distributed env. RESIDENT 1 # Forced residency flag (Yes = 1, No = 0) MULTIPROCESSOR 1 # 0 for single-processor, 1 for multi-processor NUMCPUVPS 2 # Number of user (cpu) vps SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vps to one NOAGE 0 # Process aging AFF_SPROC 0 # Affinity start processor AFF_NPROCS 0 # Affinity number of processors #************************************************************************** # Shared Memory Parameters LOCKS 2000 # Maximum number of locks BUFFERS 40000 # Maximum number of shared buffers NUMAIOVPS 36 # Number of IO vps PHYSBUFF 32 # Physical log buffer size (Kbytes) LOGBUFF 32 # Logical log buffer size (Kbytes)LOGSMAX 12 # Maximum number of logical log files CLEANERS 36 # Number of buffer cleaner processes SHMBASE 0x82000000 # Shared memory base address SHMVIRTSIZE 16000 # initial virtual shared memory segment size SHMADD 8192 # Size of new shared memory segments (Kbytes) SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited CKPTINTVL 300 # Check point interval (in sec) LRUS 36 # Number of LRU queuesLRU

Joe, One simple tuning tip would be do reduce your LRU_MAX_DIRTY and LRU_MIN_DIRTY down to 3 and 1 respectively. This usually will reduce your throughput a little but users don't have to sit there for 20 seconds doing nothing. If you run an onstat -F you can see the number of writes between checkpoints (LRU writes) and at checkpoints (Chunk writes). If most of your writes are Chunk writes you're not hitting 30% dirty on your buffer before the checkpoint interval is up. Even if you are hitting 30%, you could use to keep your dirty buffers under 1000 at checkpoint time (depending on the speed of your hardware). With 30,10 you can have as much as 12,000 buffers to write to disk at checkpoint time. I'll leave my Oracle comments out. Hope this helps, Scott Kolaya Lead DBA Fleet Services JLK62 wrote in message <19990609155124.10679.00000822@ng-cg1.aol.com>... >I"m hoping someone might be able to give me some pointers why my checkpoints >are taking so longer. I'm trying to get my company to pay for the Performance >Tuning Class, but unfortunately the higher ups want to start moving to Oracle. >I'm running SCO 3.2.5.0.4 and IDS 7.22.UC3. Checkpoints take up to 20+ >seconds: > >Message Log File: /usr/informix/online.log >14:02:40 Checkpoint Completed: duration was 16 seconds. >14:07:59 Checkpoint Completed: duration was 16 seconds. >14:13:17 Checkpoint Completed: duration was 16 seconds. >14:18:38 Checkpoint Completed: duration was 18 seconds. >14:23:59 Checkpoint Completed: duration was 17 seconds. >14:29:19 Checkpoint Completed: duration was 17 seconds. >14:34:39 Checkpoint Completed: duration was 18 seconds. >14:40:00 Checkpoint Completed: duration was 17 seconds. >14:45:20 Checkpoint Completed: duration was 17 seconds. >14:50:40 Checkpoint Completed: duration was 17 seconds. >14:56:00 Checkpoint Completed: duration was 17 seconds. >15:01:21 Checkpoint Completed: duration was 18 seconds. >15:06:39 Checkpoint Completed: duration was 15 seconds. >15:11:59 Checkpoint Completed: duration was 16 seconds. >15:17:17 Checkpoint Completed: duration was 15 seconds. >15:22:35 Checkpoint Completed: duration was 15 seconds. >15:27:54 Checkpoint Completed: duration was 16 seconds. >15:33:12 Checkpoint Completed: duration was 14 seconds. >15:38:28 Checkpoint Completed: duration was 14 seconds. >15:43:45 Checkpoint Completed: duration was 13 seconds.> >I'm inserting into a single table which has roughtly 300 bytes per row, and 3 >composite indexes of 3 columns each. I'm inserting about 1.5-2 million >transactions a day average, and can go up to 4 million transactions. Each day >is inserted into a new table. > >onstat -p shows (I zero the statistics out every night):> >INFORMIX-OnLine Version 7.22.UC3 -- On-Line -- Up 8 days 15:45:13 -- 121240 >Kbytes > >Profile >dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached >6307783 6496311 37524242 83.19 1559428 2838075 6189176 74.80 > >isamtot open start read write rewrite delete commit rollbk >20634020 15633 41183 7955238 2411324 36 98895 14768 0 > >ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes >0 0 0 6559.14 2465.00 170 340 > >bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans >200 0 5535304 0 0 310 64106 887 > >ixda-RA idx-RA da-RA RA-pgsused lchwaits >0 0 0 0 30967 > > >and My onconfig looks like: > >#************************************************************************** ># ># INFORMIX SOFTWARE, INC. ># ># Title: onconfig.std ># Description: INFORMIX-OnLine Configuration Parameters ># >#************************************************************************** ># Set NUMAIOVP from 10 to 14 set 1999-05-21 for next restart. ># Restarted 1999-06-01 >#************************************************************************** ># Root Dbspace Configuration >ROOTNAME rootdbs # Root dbspace name >ROOTPATH /dev/rc04d0 #Path for device containing root dbspace >ROOTOFFSET 0 # Offset of root dbspace into device (Kbytes) >ROOTSIZE 1800000 # 1.8 gig Size of root dbspace (Kbytes)> >#************************************************************************** ># Disk Mirroring Configuration Parameters >MIRROR 0 # Mirroring flag (Yes = 1, No = 0) >MIRRORPATH # Path for device containing mirrored root >MIRROROFFSET 0 # Offset into mirrored device (Kbytes)> >#************************************************************************** ># Physical Log Configuration >PHYSDBS rootdbs # Location (dbspace) of physical log >PHYSFILE 300000 # Physical log file size (Kbytes)> >#************************************************************************** ># Logical Log Configuration >LOGFILES 6 # Number of logical log files >LOGSIZE 50000 # Logical log size (Kbytes)> >#************************************************************************** ># Diagnostics >MSGPATH /usr/informix/online.log # System message log file path >CONSOLE /dev/console # System console message path>ALARMPROGRAM /usr/informix/log_full.sh # Alarm program path > >#************************************************************************** ># System Archive Tape Device >TAPEDEV /dev/null # Tape device path >TAPEBLK 16 # Tape block size (Kbytes) >TAPESIZE 10240 # Maximum amount of data to put on tape >(Kbytes)> >#************************************************************************** ># Log Archive Tape Device >LTAPEDEV /dev/null # Log tape device path >LTAPEBLK 16 # Log tape block size (Kbytes) >LTAPESIZE 10240 # Max amount of data to put on log tape >(Kbytes)> >#************************************************************************** ># Optical >STAGEBLOB # INFORMIX-OnLine/Optical staging area > >#************************************************************************** ># System Configuration >SERVERNUM 0 # Unique id corresponding to a OnLineinstance >DBSERVERNAME onguinness # Name of default database server >DBSERVERALIASES tliguinness # List of alternate dbservernames >NETTYPE ipcshm,,, # Configure poll thread(s) for nettype>#NETTYPE tlitcp # Configure poll thread(s) for nettype >DEADLOCK_TIMEOUT 60 # Max time to wait of lock in distributed env. >RESIDENT 1 # Forced residency flag (Yes = 1, No = 0) > >MULTIPROCESSOR 1 # 0 for single-processor, 1 formulti-processor >NUMCPUVPS 2 # Number of user (cpu) vps >SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vps toone > >NOAGE 0 # Process aging >AFF_SPR

OK Here goes. First it would be helpful to also post onstat -dRFD and onstat -g iov and onstat -g iof. Now on to what I can see here: JLK62 wrote: > > I"m hoping someone might be able to give me some pointers why my checkpoints > are taking so longer. I'm trying to get my company to pay for the Performance > Tuning Class, but unfortunately the higher ups want to start moving to Oracle. AHHH! Not Oracle! Read Joe Lumbley's book and my article in Tech Note V8 #3 on the subject. > I'm running SCO 3.2.5.0.4 and IDS 7.22.UC3. Checkpoints take up to 20+ > seconds: > > Message Log File: /usr/informix/online.log > 14:02:40 Checkpoint Completed: duration was 16 seconds. > 14:07:59 Checkpoint Completed: duration was 16 seconds. Yup that's a long checkpoint alright. [SNIP] > INFORMIX-OnLine Version 7.22.UC3 -- On-Line -- Up 8 days 15:45:13 -- 121240 > Kbytes > > Profile > dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached > 6307783 6496311 37524242 83.19 1559428 2838075 6189176 74.80 Read cache % is LOW it should be in the high 90% and write cache can be better also though not much with your transaction rate, 75% is borderline. > isamtot open start read write rewrite delete commit rollbk > 20634020 15633 41183 7955238 2411324 36 98895 14768 0 > > ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes > 0 0 0 6559.14 2465.00 170 340 > > bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans > 200 0 5535304 0 0 310 64106 887 > ixda-RA idx-RA da-RA RA-pgsused lchwaits > 0 0 0 0 30967 You have almost 900 sequential scans today but no Read Ahead! Set the RA parameters to 32 & 16 if you have singleton drives 32 & 8 if it is a fast array. > and My onconfig looks like: [SNIP] > # Physical Log Configuration > PHYSDBS rootdbs # Location (dbspace) of physical log > PHYSFILE 300000 # Physical log file size (Kbytes) Physical log in rootdbs that's a no-no! Are the logical logs in rootdbs as well? Much worse! Create a new dbspace for logical logs and one for physical logs on separate drives and controllers from the data drives. [SNIP] #************************************************************************** > # Log Archive Tape Device > LTAPEDEV /dev/null # Log tape device path > LTAPEBLK 16 # Log tape block size (Kbytes) > LTAPESIZE 10240 # Max amount of data to put on log With 4MM transactions a day you are throwing away your logical log backups? (Phew almost flamed on there, sorry.) I hope you have logging turned on in this database and recommend that you backup your logical logs using ontape -c or using the ALARMPROGRAM. I have submitted two ALARMPROGRAMs to do this using ontape -a to the IIUG Software Repositor, as the package utils3_ak, and the engine comes with one using onbar. [SNIP] > SERVERNUM 0 # Unique id corresponding to a OnLine instance > DBSERVERNAME onguinness # Name of default database server > DBSERVERALIASES tliguinness # List of alternate dbservernames > NETTYPE ipcshm,,, # Configure poll thread(s) for nettype> #NETTYPE tlitcp # Configure poll thread(s) for [SNIP] There should be two NETTYPE entries, one for each interface, as follows: NETTYPE ipcshm,2,,CPU # one listener in each CPU VP NETTYPE tlitcp,2,,NET # 2 NET VPs to listen to TCP/IP > MULTIPROCESSOR 1 # 0 for single-processor, 1 for multi-processor > NUMCPUVPS 2 # Number of user (cpu) vps [SNIP] > LOCKS 2000 # Maximum number of locks Not enough locks. What if you need to perform a global update on those 4MM daily records? You should have enough locks for the worst case valid transaction. They only take up about 32 bytes each. > BUFFERS 40000 # Maximum number of shared buffers Not enough buffers. Assuming the 4MM daily rows are actively queries during that day, they take up 666,666 data pages plus index pages. You should decide what % of those active records tend to be accessed concurrently and determine # BUFFERS that way. This will improve your cache %s. I'd take a guess and say you nee about 200000 BUFFERS. > NUMAIOVPS 36 # Number of IO vps Is KAIO active on your release? If so 2-4 AIO VPS is enough unless you are using COOKED files. If not, or if COOKED files, how many chunks do you have? For 7.22 you need about 1.5 AIO VPs per chunk. [SNIP] CKPTINTVL 300 For a heavy transaction server like this one, if you are backing up your logs as they fill (see above) you can afford a much longer check point interval, though you will have to increase the size of the physical log also. I suggest making the interval an hour rather than 5 minutes and increasing the physical log to 1GB to prevent premature checkpointing due to the physical log reaching 75% full. This will improve insert/update throughput by reducing the number of checkpoint halts to the transaction processing. [SNIP] > LRU_MAX_DIRTY 30 # LRU percent dirty begin cleaning limit > LRU_MIN_DIRTY 10 # LRU percent dirty end cleaning limit HERE IS THE MAIN CULPRIT in the long checkpoints. You are saving too much work for checkpoint time. Ignore the manual and set these to: LRU_MAX_DIRTY 2 LRU_MIN_DIRTY 0 And you will be getting checkpoint times between 1 and 8 seconds for 200000 buffers rather than 15-20 seconds for 40000 buffers. [SNIP] > # Read Ahead Variables > RA_PAGES 0 # Number of pages to attempt to read ahead > RA_THRESHOLD 0 # Number of pages left before nextWhy not use RA? You show at least 900 sequential scans a day and they all could benefit from setting these. See above for a recommendation. [SNIP] Well that's what I can do without seeing other onstat output but it should help substantially. Also I suggest you upgrade to 7.30 or 7.31 as there was a substantial speed up going from 7.2x to 7.3x, more in 7.31, 7.22 is fairly buggy, and finally the checkpoint algorithm was rewritten for 7.3x to eliminate a problem that was causing all sessions with threads running in CPU VP #1 to hang until all buffers were flushed. There should be some relief in the 7.3x line that reduces the impact of checkpoints on queries. Art S. Kagel

OK. You have only two CPU vp's configured, so you will have at most, two cleaner threads running at any given time. Having 36 page cleaners is a bit of overkill. Somewhere in the 2 to 4 range would be more realistic. You also have 36 LRU queues configured with only 40000 BUFFERS in the pool. When you do an onstat -F, do you have a large number of Fg writes? This configuration only gives 1111.11 buffers per LRU queue pair, and with a MAX/MIN dirty set to 30/10, I would suspect that Fg writes are incrementing at a steady pace, which can slow you down considerably. I would try settings such as this: BUFFERS 40000LRU 4 CLEANERS 4 If this is a TP system versus an OLAP (data warehouse, heavy reporting, etc), I would also set the following: LRU_MAX_DIRTY 2 LRU_MIN_DIRTY 1 You want to be continuously writing modified buffers out to disk, leaving a minimal number of writes to do at checkpoint time. Having a low MAX/MIN dirty keeps OnLine writing data between checkpoints, which is what you need. JLK62 <jlk62@aol.com32Qfree> wrote in message news:19990609155124.10679.00000822@ng-cg1.aol.com... > I"m hoping someone might be able to give me some pointers why my checkpoints > are taking so longer. I'm trying to get my company to pay for the Performance > Tuning Class, but unfortunately the higher ups want to start moving to Oracle. > I'm running SCO 3.2.5.0.4 and IDS 7.22.UC3. Checkpoints take up to 20+ > seconds: > > Message Log File: /usr/informix/online.log > 14:02:40 Checkpoint Completed: duration was 16 seconds. > 14:07:59 Checkpoint Completed: duration was 16 seconds. > 14:13:17 Checkpoint Completed: duration was 16 seconds. > 14:18:38 Checkpoint Completed: duration was 18 seconds. > 14:23:59 Checkpoint Completed: duration was 17 seconds. > 14:29:19 Checkpoint Completed: duration was 17 seconds. > 14:34:39 Checkpoint Completed: duration was 18 seconds. > 14:40:00 Checkpoint Completed: duration was 17 seconds. > 14:45:20 Checkpoint Completed: duration was 17 seconds. > 14:50:40 Checkpoint Completed: duration was 17 seconds. > 14:56:00 Checkpoint Completed: duration was 17 seconds. > 15:01:21 Checkpoint Completed: duration was 18 seconds. > 15:06:39 Checkpoint Completed: duration was 15 seconds. > 15:11:59 Checkpoint Completed: duration was 16 seconds. > 15:17:17 Checkpoint Completed: duration was 15 seconds. > 15:22:35 Checkpoint Completed: duration was 15 seconds. > 15:27:54 Checkpoint Completed: duration was 16 seconds. > 15:33:12 Checkpoint Completed: duration was 14 seconds. > 15:38:28 Checkpoint Completed: duration was 14 seconds. > 15:43:45 Checkpoint Completed: duration was 13 seconds.> > I'm inserting into a single table which has roughtly 300 bytes per row, and 3 > composite indexes of 3 columns each. I'm inserting about 1.5-2 million > transactions a day average, and can go up to 4 million transactions. Each day > is inserted into a new table. > > onstat -p shows (I zero the statistics out every night):> > INFORMIX-OnLine Version 7.22.UC3 -- On-Line -- Up 8 days 15:45:13 -- 121240 > Kbytes > > Profile > dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached > 6307783 6496311 37524242 83.19 1559428 2838075 6189176 74.80 > > isamtot open start read write rewrite delete commit rollbk > 20634020 15633 41183 7955238 2411324 36 98895 14768 0 > > ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes > 0 0 0 6559.14 2465.00 170 340 > > bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans > 200 0 5535304 0 0 310 64106 887 > > ixda-RA idx-RA da-RA RA-pgsused lchwaits > 0 0 0 0 30967 > > > and My onconfig looks like: > > #************************************************************************** > # > # INFORMIX SOFTWARE, INC. > # > # Title: onconfig.std > # Description: INFORMIX-OnLine Configuration Parameters > # > #************************************************************************** > # Set NUMAIOVP from 10 to 14 set 1999-05-21 for next restart. > # Restarted 1999-06-01 > #************************************************************************** > # Root Dbspace Configuration > ROOTNAME rootdbs # Root dbspace name > ROOTPATH /dev/rc04d0 #Path for device containing root dbspace > ROOTOFFSET 0 # Offset of root dbspace into device (Kbytes) > ROOTSIZE 1800000 # 1.8 gig Size of root dbspace (Kbytes)> > #************************************************************************** > # Disk Mirroring Configuration Parameters > MIRROR 0 # Mirroring flag (Yes = 1, No = 0) > MIRRORPATH # Path for device containing mirrored root > MIRROROFFSET 0 # Offset into mirrored device (Kbytes)> > #************************************************************************** > # Physical Log Configuration > PHYSDBS rootdbs # Location (dbspace) of physical log > PHYSFILE 300000 # Physical log file size (Kbytes)> > #************************************************************************** > # Logical Log Configuration > LOGFILES 6 # Number of logical log files > LOGSIZE 50000 # Logical log size (Kbytes)> > #************************************************************************** > # Diagnostics > MSGPATH /usr/informix/online.log # System message log file path > CONSOLE /dev/console # System console message path> ALARMPROGRAM /usr/informix/log_full.sh # Alarm program path > > #************************************************************************** > # System Archive Tape Device > TAPEDEV /dev/null # Tape device path > TAPEBLK 16 # Tape block size (Kbytes) > TAPESIZE 10240 # Maximum amount of data to put on tape > (Kbytes)> > #************************************************************************** > # Log Archive Tape Device > LTAPEDEV /dev/null # Log tape device path > LTAPEBLK 16 # Log tape block size (Kbytes) > LTAPESIZE 10240 # Max amount of data to put on log tape > (Kbytes)> > #************************************************************************** > # Optical > STAGEBLOB # INFORMIX-OnLine/Optical staging area > > #************************************************************************** > # System Configuration > SERVERNUM 0 # Unique id corresponding to a OnLineinstance > DBSERVERNAME onguinness # Name of default database server > DBSERVERALIASES tliguinness # List of alternate dbservernames > NETTYPE ipcshm,,, # Configure poll thread(s) for nettype> #NETTYPE tlitcp # Configure poll thread(s) for nettype > DEADLOCK_TIMEOUT 6

Thanks to everyone who replied. Increasing the buffers and bringing LRU_MIN/MAX to 2/0 has dramtically reduced the checkpoints to a a maximum time of 5 seconds. Also, tuning the read ahead has reduced the time to run the nightly reports. I'll continue to try and get better performance (my boss has finally agreed with me that the Performance Tuning Class is a good idea, but I still have to keep after him to get the money to take it). Again, Thanks for the help. Joe