Checkpoint times

Hi, we encounter enhanced checkpoint times on a production instance. I have tried to modify some parameters which results in less checkpoints, but still long (at least for our system). Actual config is Sun 280R, 4GB Ram, 2 Processors, Solaris 9 (Sparc), IDS 10.00FC6. Checkpoint interval was set to 60 sec, but this resulted in a (fuzzy, but blocking!) checkpoint each minute for about 11-21 sec. (which means the server is not reacting for about 25% of the time). I have now set checkpoint interval to 900 sec, set buffers to 200000/2k, lru_max/min is 1.5/1.0. I have increased physical file size to 100000. Physical buffer is 1024, LRUS is 32 Now we get (fuzzy, but still blocking, according to onstat output (BLOCKED: CKPT)) checkpoints for about 20-30 sec, but only at 15 min intervals. Maybe the interval is decreasing over the day because of reaching the dirty percentage, I will check for that tomorrow. This is better of course, but still I want to know what could be the reason, I cannot see we write that many data within a minute. I have read that in 9.40, the recommended action for increased checkpoints (at least for upgraders of 7.x) is to increase the file size for logfiles. Is this still true for 10.0 ? Actual log size is 20000 (one log per hour normally). Other useful values: # Shared Memory Parameters LOCKS 500000 # Maximum number of locks NUMAIOVPS 1 # Number of IO vps PHYSBUFF 1024 # Physical log buffer size (Kbytes) LOGBUFF 128 # Logical log buffer size (Kbytes) CLEANERS 32 # Number of buffer cleaner processes SHMBASE 0x10a000000 # Shared memory base address SHMVIRTSIZE 500000 # initial virtual shared memory segmentsize SHMADD 50000 # Size of new shared memory segments (Kbytes) SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited CKPTINTVL 900 # Check point interval (in sec) TXTIMEOUT 0x12c # Transaction timeout (in sec) STACKSIZE 256 # Stack size (Kbytes) Any recommendations ? Thanks in advance, Marcus

Slow disks? Are you perhaps using RAID5? Singleton disks? Are the logical and physical logs on the same drive structure as each other? As your data? Are you using RAW or COOKED chunks? If COOKED, you do not have nearly enough AIO VPs configured. You should have ~1.0-1.5 times the number of COOKEID chunks plus 3-6 for overhead and text logging. If you are using RAW devices for chunks do you have KAIO enabled in your Solaris kernel? In the IDS instance? Art S. Kagel ----- Original Message ----- From: Marcus Haarmann <ids@iiug.org> At: 5/21 17:10:01 Hi, we encounter enhanced checkpoint times on a production instance. I have tried to modify some parameters which results in less checkpoints, but still long (at least for our system). Actual config is Sun 280R, 4GB Ram, 2 Processors, Solaris 9 (Sparc), IDS 10.00FC6. Checkpoint interval was set to 60 sec, but this resulted in a (fuzzy, but blocking!) checkpoint each minute for about 11-21 sec. (which means the server is not reacting for about 25% of the time). I have now set checkpoint interval to 900 sec, set buffers to 200000/2k, lru_max/min is 1.5/1.0. I have increased physical file size to 100000. Physical buffer is 1024, LRUS is 32 Now we get (fuzzy, but still blocking, according to onstat output (BLOCKED: CKPT)) checkpoints for about 20-30 sec, but only at 15 min intervals. Maybe the interval is decreasing over the day because of reaching the dirty percentage, I will check for that tomorrow. This is better of course, but still I want to know what could be the reason, I cannot see we write that many data within a minute. I have read that in 9.40, the recommended action for increased checkpoints (at least for upgraders of 7.x) is to increase the file size for logfiles. Is this still true for 10.0 ? Actual log size is 20000 (one log per hour normally). Other useful values: # Shared Memory Parameters LOCKS 500000 # Maximum number of locks NUMAIOVPS 1 # Number of IO vps PHYSBUFF 1024 # Physical log buffer size (Kbytes) LOGBUFF 128 # Logical log buffer size (Kbytes) CLEANERS 32 # Number of buffer cleaner processes SHMBASE 0x10a000000 # Shared memory base address SHMVIRTSIZE 500000 # initial virtual shared memory segmentsize SHMADD 50000 # Size of new shared memory segments (Kbytes) SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited CKPTINTVL 900 # Check point interval (in sec) TXTIMEOUT 0x12c # Transaction timeout (in sec) STACKSIZE 256 # Stack size (Kbytes) Any recommendations ? Thanks in advance, Marcus ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

Hi Art, Informix mirroring is active, no RAID. Raw Devices with KAIO are used. But maybe you were right about the slow disks, I have measured datatransfer with dd and the disk with rootdbs seems to be slow. Mirror disk is reacting fast. I will shutdown the primary chunk and work on the mirror for test. Either the disk or the array seems to be damaged. Thanks for the quick answer. I will post if I get new information Marcus -----Original Message----- From: ART KAGEL, BLOOMBERG/ 731 LEXIN [mailto:kagel@bloomberg.net] Sent: Monday, May 21, 2007 11:16 PM To: ids@iiug.org Subject: Re: Checkpoint times [9207] Slow disks? Are you perhaps using RAID5? Singleton disks? Are the logical and physical logs on the same drive structure as each other? As your data? Are you using RAW or COOKED chunks? If COOKED, you do not have nearly enough AIO VPs configured. You should have ~1.0-1.5 times the number of COOKEID chunks plus 3-6 for overhead and text logging. If you are using RAW devices for chunks do you have KAIO enabled in your Solaris kernel? In the IDS instance? Art S. Kagel ----- Original Message ----- From: Marcus Haarmann <ids@iiug.org> At: 5/21 17:10:01 Hi, we encounter enhanced checkpoint times on a production instance. I have tried to modify some parameters which results in less checkpoints, but still long (at least for our system). Actual config is Sun 280R, 4GB Ram, 2 Processors, Solaris 9 (Sparc), IDS 10.00FC6. Checkpoint interval was set to 60 sec, but this resulted in a (fuzzy, but blocking!) checkpoint each minute for about 11-21 sec. (which means the server is not reacting for about 25% of the time). I have now set checkpoint interval to 900 sec, set buffers to 200000/2k, lru_max/min is 1.5/1.0. I have increased physical file size to 100000. Physical buffer is 1024, LRUS is 32 Now we get (fuzzy, but still blocking, according to onstat output (BLOCKED: CKPT)) checkpoints for about 20-30 sec, but only at 15 min intervals. Maybe the interval is decreasing over the day because of reaching the dirty percentage, I will check for that tomorrow. This is better of course, but still I want to know what could be the reason, I cannot see we write that many data within a minute. I have read that in 9.40, the recommended action for increased checkpoints (at least for upgraders of 7.x) is to increase the file size for logfiles. Is this still true for 10.0 ? Actual log size is 20000 (one log per hour normally). Other useful values: # Shared Memory Parameters LOCKS 500000 # Maximum number of locks NUMAIOVPS 1 # Number of IO vps PHYSBUFF 1024 # Physical log buffer size (Kbytes) LOGBUFF 128 # Logicallog buffer size (Kbytes) CLEANERS 32 # Number of buffer cleaner processes SHMBASE 0x10a000000 # Shared memory base address SHMVIRTSIZE 500000 # initial virtual shared memory segment size SHMADD 50000 # Size of new shared memory segments (Kbytes) SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited CKPTINTVL 900 # Check point interval (in sec) TXTIMEOUT 0x12c #Transaction timeout (in sec) STACKSIZE 256 # Stack size (Kbytes) Any recommendations ? Thanks in advance, Marcus ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum. ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum.

On 21/05/07, Marcus Haarmann <marcus.haarmann@midoco.de> wrote: > Hi, > > we encounter enhanced checkpoint times on a production instance. > I have tried to modify some parameters which results in less > checkpoints, but still long (at least for our system). > Actual config is Sun 280R, 4GB Ram, 2 Processors, Solaris 9 (Sparc), IDS > 10.00FC6. > Checkpoint interval was set to 60 sec, but this resulted in a (fuzzy, > but blocking!) checkpoint each minute for about 11-21 sec. (which means > the server is not reacting for about 25% of the time). > I have now set checkpoint interval to 900 sec, set buffers to 200000/2k, > lru_max/min is 1.5/1.0. > I have increased physical file size to 100000. Physical buffer is 1024, > LRUS is 32> > Now we get (fuzzy, but still blocking, according to onstat output > (BLOCKED: CKPT)) checkpoints for about 20-30 sec, but only at 15 min > intervals. > Maybe the interval is decreasing over the day because of reaching the > dirty percentage, I will check for that tomorrow. > This is better of course, but still I want to know what could be the > reason, I cannot see we write that many data within a minute. > I have read that in 9.40, the recommended action for increased > checkpoints (at least for upgraders of 7.x) is to increase the file size > for logfiles. > Is this still true for 10.0 ? Actual log size is 20000 (one log per hour > normally). > > Other useful values: > # Shared Memory Parameters > > LOCKS 500000 # Maximum number of locks > NUMAIOVPS 1 # Number of IO vps > PHYSBUFF 1024 # Physical log buffer size (Kbytes) > LOGBUFF 128 # Logical log buffer size (Kbytes) > CLEANERS 32 # Number of buffer cleaner processes > SHMBASE 0x10a000000 # Shared memory base address > SHMVIRTSIZE 500000 # initial virtual shared memory segment> size > SHMADD 50000 # Size of new shared memory segments > (Kbytes) > SHMTOTAL 0 # Total shared memory (Kbytes). > 0=>unlimited > CKPTINTVL 900 # Check point interval (in sec) > TXTIMEOUT 0x12c # Transaction timeout (in sec) > STACKSIZE 256 # Stack size (Kbytes)> > Any recommendations ? > > Thanks in advance, > > Marcus > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > Marcus Are you using raw disk or file system files. In either case NUMAIOVPS needs to be at least 4 (currently all your updates to filestsem files are going through a single process), and in the latter case it needs to be around the same as the number of dbspaces plus 3. Fuzzy checkpoints should be somewhere in the region of 0 - 1 second !! unless you are performing massive amount of table structure changes. What does disk io and iowait look like during the checkpoint? Traditional wisdom always stated CLEANERS and LRUS should be the same and should be a non-multiple of 2 (31, 63, 127 are good). Keith Keith

Keith, Thanks for your comment. I am using KAIO and I thought that AIO threads could be reduced to a minimum in this case ? I found out that a slow disk array is the problem and brought down the chunks. Now we seem to have better performance, checkpoints are done each 900 sec for 4-5 sec. But I will reduce the checkpoint interval again to 300 sec to have better transactional security. Marcus -----Original Message----- From: Keith Simmons [mailto:smiley73@googlemail.com] Sent: Tuesday, May 22, 2007 9:44 AM To: ids@iiug.org Subject: Re: Checkpoint times [9210] On 21/05/07, Marcus Haarmann <marcus.haarmann@midoco.de> wrote: > Hi, > > we encounter enhanced checkpoint times on a production instance. > I have tried to modify some parameters which results in less > checkpoints, but still long (at least for our system). > Actual config is Sun 280R, 4GB Ram, 2 Processors, Solaris 9 (Sparc), > IDS 10.00FC6. > Checkpoint interval was set to 60 sec, but this resulted in a (fuzzy, > but blocking!) checkpoint each minute for about 11-21 sec. (which > means the server is not reacting for about 25% of the time). > I have now set checkpoint interval to 900 sec, set buffers to > 200000/2k, lru_max/min is 1.5/1.0. > I have increased physical file size to 100000. Physical buffer is > 1024, LRUS is 32 > > Now we get (fuzzy, but still blocking, according to onstat output > (BLOCKED: CKPT)) checkpoints for about 20-30 sec, but only at 15 min > intervals. > Maybe the interval is decreasing over the day because of reaching the > dirty percentage, I will check for that tomorrow. > This is better of course, but still I want to know what could be the > reason, I cannot see we write that many data within a minute. > I have read that in 9.40, the recommended action for increased > checkpoints (at least for upgraders of 7.x) is to increase the file > size for logfiles. > Is this still true for 10.0 ? Actual log size is 20000 (one log per > hour normally). > > Other useful values: > # Shared Memory Parameters > > LOCKS 500000 # Maximum number of locks NUMAIOVPS 1 # Number of IO vps > PHYSBUFF 1024 # Physical log buffer size (Kbytes) LOGBUFF 128 #> Logical log buffer size (Kbytes) CLEANERS 32 # Number of buffer > cleaner processes SHMBASE 0x10a000000 # Shared memory base address > SHMVIRTSIZE 500000 # initial virtual shared memory segment size SHMADD > 50000 # Size of new shared memory segments > (Kbytes) > SHMTOTAL 0 # Total shared memory (Kbytes). > 0=>unlimited > CKPTINTVL 900 # Check point interval (in sec) TXTIMEOUT 0x12c #> Transaction timeout (in sec) STACKSIZE 256 # Stack size (Kbytes) > > Any recommendations ? > > Thanks in advance, > > Marcus > > > ************************************************************************ ******* > Forum Note: Use "Reply" to post a response in the discussion forum. > > Marcus Are you using raw disk or file system files. In either case NUMAIOVPS needs to be at least 4 (currently all your updates to filestsem files are going through a single process), and in the latter case it needs to be around the same as the number of dbspaces plus 3. Fuzzy checkpoints should be somewhere in the region of 0 - 1 second !! unless you are performing massive amount of table structure changes. What does disk io and iowait look like during the checkpoint? Traditional wisdom always stated CLEANERS and LRUS should be the same and should be a non-multiple of 2 (31, 63, 127 are good). Keith Keith ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum.

Marcus AIOs can be reduced, but even so the recommended minimum is 4 to cover online log, console log, logical log to disk (or tape) and archive to disk (or tape). They don't 'eat' anything when not used, but are there when you need them! Keith On 22/05/07, Marcus Haarmann <marcus.haarmann@midoco.de> wrote: > Keith, > > Thanks for your comment. > I am using KAIO and I thought that AIO threads could be reduced to a > minimum in this case ? > I found out that a slow disk array is the problem and brought down the > chunks. > Now we seem to have better performance, checkpoints are done each 900 > sec for 4-5 sec. > But I will reduce the checkpoint interval again to 300 sec to have > better transactional security. > > Marcus > > -----Original Message----- > From: Keith Simmons [mailto:smiley73@googlemail.com] > Sent: Tuesday, May 22, 2007 9:44 AM > To: ids@iiug.org > Subject: Re: Checkpoint times [9210] > > On 21/05/07, Marcus Haarmann <marcus.haarmann@midoco.de> wrote: > > Hi, > > > > we encounter enhanced checkpoint times on a production instance. > > I have tried to modify some parameters which results in less > > checkpoints, but still long (at least for our system). > > Actual config is Sun 280R, 4GB Ram, 2 Processors, Solaris 9 (Sparc), > > IDS 10.00FC6. > > Checkpoint interval was set to 60 sec, but this resulted in a (fuzzy, > > but blocking!) checkpoint each minute for about 11-21 sec. (which > > means the server is not reacting for about 25% of the time). > > I have now set checkpoint interval to 900 sec, set buffers to > > 200000/2k, lru_max/min is 1.5/1.0. > > I have increased physical file size to 100000. Physical buffer is > > 1024, LRUS is 32 > > > > Now we get (fuzzy, but still blocking, according to onstat output > > (BLOCKED: CKPT)) checkpoints for about 20-30 sec, but only at 15 min > > intervals. > > Maybe the interval is decreasing over the day because of reaching the > > dirty percentage, I will check for that tomorrow. > > This is better of course, but still I want to know what could be the > > reason, I cannot see we write that many data within a minute. > > I have read that in 9.40, the recommended action for increased > > checkpoints (at least for upgraders of 7.x) is to increase the file > > size for logfiles. > > Is this still true for 10.0 ? Actual log size is 20000 (one log per > > hour normally). > > > > Other useful values: > > # Shared Memory Parameters > > > > LOCKS 500000 # Maximum number of locks NUMAIOVPS 1 # Number of IO vps > > PHYSBUFF 1024 # Physical log buffer size (Kbytes) LOGBUFF 128 #> > Logical log buffer size (Kbytes) CLEANERS 32 # Number of buffer > > cleaner processes SHMBASE 0x10a000000 # Shared memory base address > > SHMVIRTSIZE 500000 # initial virtual shared memory segment size SHMADD> > > 50000 # Size of new shared memory segments > > (Kbytes) > > SHMTOTAL 0 # Total shared memory (Kbytes). > > 0=>unlimited > > CKPTINTVL 900 # Check point interval (in sec) TXTIMEOUT 0x12c #> > Transaction timeout (in sec) STACKSIZE 256 # Stack size (Kbytes) > > > > Any recommendations ? > > > > Thanks in advance, > > > > Marcus > > > > > > > ************************************************************************ > ******* > > Forum Note: Use "Reply" to post a response in the discussion forum. > > > > > Marcus > > Are you using raw disk or file system files. In either case NUMAIOVPS > needs to be at least 4 (currently all your updates to filestsem files > are going through a single process), and in the latter case it needs to > be around the same as the number of dbspaces plus 3. > Fuzzy checkpoints should be somewhere in the region of 0 - 1 second !! > unless you are performing massive amount of table structure changes. > What does disk io and iowait look like during the checkpoint? > Traditional wisdom always stated CLEANERS and LRUS should be the same > and should be a non-multiple of 2 (31, 63, 127 are good). > > Keith > > Keith > > ************************************************************************ > ******* > Forum Note: Use "Reply" to post a response in the discussion forum. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > >

You still need more than 1 AIO VP. Keith is correct. Configure 4 and tune from there. If onstat -g iov shows all aio vps with io/wup >=1.0 then you need more. If more than one have io/wup <1.0 you can reduce. You should always have aio resources in reserve so nothing has to wait. Art S. Kagel ----- Original Message ----- From: Marcus Haarmann <ids@iiug.org> At: 5/22 3:36:00 Hi Art, Informix mirroring is active, no RAID. Raw Devices with KAIO are used. But maybe you were right about the slow disks, I have measured datatransfer with dd and the disk with rootdbs seems to be slow. Mirror disk is reacting fast. I will shutdown the primary chunk and work on the mirror for test. Either the disk or the array seems to be damaged. Thanks for the quick answer. I will post if I get new information Marcus -----Original Message----- From: ART KAGEL, BLOOMBERG/ 731 LEXIN [mailto:kagel@bloomberg.net] Sent: Monday, May 21, 2007 11:16 PM To: ids@iiug.org Subject: Re: Checkpoint times [9207] Slow disks? Are you perhaps using RAID5? Singleton disks? Are the logical and physical logs on the same drive structure as each other? As your data? Are you using RAW or COOKED chunks? If COOKED, you do not have nearly enough AIO VPs configured. You should have ~1.0-1.5 times the number of COOKEID chunks plus 3-6 for overhead and text logging. If you are using RAW devices for chunks do you have KAIO enabled in your Solaris kernel? In the IDS instance? Art S. Kagel ----- Original Message ----- From: Marcus Haarmann <ids@iiug.org> At: 5/21 17:10:01 Hi, we encounter enhanced checkpoint times on a production instance. I have tried to modify some parameters which results in less checkpoints, but still long (at least for our system). Actual config is Sun 280R, 4GB Ram, 2 Processors, Solaris 9 (Sparc), IDS 10.00FC6. Checkpoint interval was set to 60 sec, but this resulted in a (fuzzy, but blocking!) checkpoint each minute for about 11-21 sec. (which means the server is not reacting for about 25% of the time). I have now set checkpoint interval to 900 sec, set buffers to 200000/2k, lru_max/min is 1.5/1.0. I have increased physical file size to 100000. Physical buffer is 1024, LRUS is 32 Now we get (fuzzy, but still blocking, according to onstat output (BLOCKED: CKPT)) checkpoints for about 20-30 sec, but only at 15 min intervals. Maybe the interval is decreasing over the day because of reaching the dirty percentage, I will check for that tomorrow. This is better of course, but still I want to know what could be the reason, I cannot see we write that many data within a minute. I have read that in 9.40, the recommended action for increased checkpoints (at least for upgraders of 7.x) is to increase the file size for logfiles. Is this still true for 10.0 ? Actual log size is 20000 (one log per hour normally). Other useful values: # Shared Memory Parameters LOCKS 500000 # Maximum number of locks NUMAIOVPS 1 # Number of IO vps PHYSBUFF 1024 # Physical log buffer size (Kbytes) LOGBUFF 128 # Logicallog buffer size (Kbytes) CLEANERS 32 # Number of buffer cleaner processes SHMBASE 0x10a000000 # Shared memory base address SHMVIRTSIZE 500000 # initial virtual shared memory segment size SHMADD 50000 # Size of new shared memory segments (Kbytes) SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited CKPTINTVL 900 # Check point interval (in sec) TXTIMEOUT 0x12c #Transaction timeout (in sec) STACKSIZE 256 # Stack size (Kbytes) Any recommendations ? Thanks in advance, Marcus ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum. ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.

ids-bounces@iiug.org wrote on 05/22/2007 10:09:06 AM: > Keith, > > Thanks for your comment. > I am using KAIO and I thought that AIO threads could be reduced to a > minimum in this case ? > I found out that a slow disk array is the problem and brought down the > chunks. > Now we seem to have better performance, checkpoints are done each 900 > sec for 4-5 sec. > But I will reduce the checkpoint interval again to 300 sec to have > better transactional security. > > Marcus > Marcus, The CKPTINTVL does not affect transactional security. The only affect a longer CKPTINTVL is that fast recovery after a crash will probably take longer. (it effects mainly rollforward phase , it does not have much affect on rollback phase of fast recovery ) SAP standard configuration is 1800 for CKPTINTVL and very low values for LRU_MIN/MAX_DIRTY. The advantage is low checkpoint wait times. The disadvantage is (apart from longer fast recovery) that you might see CPU utilisation increase , as the CLEANERS constantly have to go through the LRUS , write out dirty BUFFERS and rechain cleaned BUFFERS to the clean buffer list . Mit freundlichen Grüssen – With kind regards - Cordialement Tilman Model-Bosch IBM SWG Premium Support Mobile +49 170 7678 593 ---------------------------------------------------------- IBM Deutschland GmbH; Vorsitzender des Aufsichtsrats: Hans Ulrich Maerki ; Geschäftsführung: Martin Jetter (Vorsitzender), Rudolf Bauer, Christian Diedrich, Christoph Grandpierre, Matthias Hartmann, Thomas Fell, Michael Diemer ; Sitz der Gesellschaft: StuttgartRegistergericht: Amtsgericht Stuttgart, HRB 14562 WEEE-Reg.-Nr. DE 99369940

Marcus, The CKPTINTVL does not affect transactional security. The only affect a longer CKPTINTVL is that fast recovery after a crash will probably take longer. (it effects mainly rollforward phase , it does not have much affect on rollback phase of fast recovery ) SAP standard configuration is 1800 for CKPTINTVL and very low values for LRU_MIN/MAX_DIRTY. The advantage is low checkpoint wait times. The disadvantage is (apart from longer fast recovery) that you might see CPU utilisation increase , as the CLEANERS constantly have to go through the LRUS , write out dirty BUFFERS and rechain cleaned BUFFERS to the clean buffer list . Mit freundlichen Grüssen – With kind regards - Cordialement Tilman Model-Bosch

Hmmmmm. Encrypted HDR? MIME? Bob Roussey Unix / Informix Administration Spirit Airlines Robert.Roussey@SpiritAir.com -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of Tilman Model-Bosch Sent: Wednesday, May 23, 2007 4:13 PM To: ids@iiug.org Subject: RE: Re: Checkpoint times [9222] ids-bounces@iiug.org wrote on 05/22/2007 10:09:06 AM: > Keith, > > Thanks for your comment. > I am using KAIO and I thought that AIO threads could be reduced to a > minimum in this case ? > I found out that a slow disk array is the problem and brought down the > chunks. > Now we seem to have better performance, checkpoints are done each 900 > sec for 4-5 sec. > But I will reduce the checkpoint interval again to 300 sec to have > better transactional security. > > Marcus > Marcus, The CKPTINTVL does not affect transactional security. The only affect a longer CKPTINTVL is that fast recovery after a crash will probably take longer. (it effects mainly rollforward phase , it does not have much affect on rollback phase of fast recovery ) SAP standard configuration is 1800 for CKPTINTVL and very low values for LRU_MIN/MAX_DIRTY. The advantage is low checkpoint wait times. The disadvantage is (apart from longer fast recovery) that you might see CPU utilisation increase , as the CLEANERS constantly have to go through the LRUS , write out dirty BUFFERS and rechain cleaned BUFFERS to the clean buffer list . Mit freundlichen Grüssen – With kind regards - Cordialement Tilman Model-Bosch IBM SWG Premium Support Mobile +49 170 7678 593 ---------------------------------------------------------- IBM Deutschland GmbH; Vorsitzender des Aufsichtsrats: Hans Ulrich Maerki ; Geschäftsführung: Martin Jetter (Vorsitzender), Rudolf Bauer, Christian Diedrich, Christoph Grandpierre, Matthias Hartmann, Thomas Fell, Michael Diemer ; Sitz der Gesellschaft: StuttgartRegistergericht: Amtsgericht Stuttgart, HRB 14562 WEEE-Reg.-Nr. DE 99369940 ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum.

That's ALMOST true. IFF you are using BUFFERED logging there is a slight risk that a transaction that's been committed MAY not have had it's COMMIT record flushed to disk during a crash. There will be no server corruption, however, a transaction that the client thought had been committed will be rolled back on restart. This cannot happen if all databases are UNBUFFERED or mode ANSI. Art S. Kagel ----- Original Message ----- From: Tilman Model-Bosch <ids@iiug.org> At: 5/23 16:19:58 Marcus, The CKPTINTVL does not affect transactional security. The only affect a longer CKPTINTVL is that fast recovery after a crash will probably take longer. (it effects mainly rollforward phase , it does not have much affect on rollback phase of fast recovery ) SAP standard configuration is 1800 for CKPTINTVL and very low values for LRU_MIN/MAX_DIRTY. The advantage is low checkpoint wait times. The disadvantage is (apart from longer fast recovery) that you might see CPU utilisation increase , as the CLEANERS constantly have to go through the LRUS , write out dirty BUFFERS and rechain cleaned BUFFERS to the clean buffer list . Mit freundlichen Grüssen - With kind regards - Cordialement Tilman Model-Bosch ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.