Ontape to backup Logical logs - Query

Hello, IDS 11.10.FC3 on solaris 10. #Please consider this as a query and not a problem yet. #I know the my logical logs are small in size(500+, 20M each) for taking some hectic transactions BUT not possible to to increase the log size atleast for now. In 11.10.FC2W4 i faced a bug with parallel ontapes running for backing up the logical logs & resulting in Loss of logical logs files. (ontape to directory feature used. Alarmprogram.sh to backup the logs) One of the workaround was to check if ontape is running, some thing like: "ps -aef | grep "ontape -a -d" |grep -v grep |" in the alarmprogram.sh script before a new ontape is invoked. I did all this in order to avoid new ontape when one is already in progress. Now I have 11.10.FC3 with the bug fix, the first thing i checked in my testings was the name for temp file which now i see unique for every temp file generated/used by ontape before writing to permanent file on the disk. I also see that now IDS is not allowing another ontape to run untill one is already running: (May be i am not correct on this). ------ontape's output--------- Performing automatic backup of logical logs. Logbackup failed - A Log backup is already in progress. Program over. Performing automatic backup of logical logs. Logbackup failed - A Log backup is already in progress. ----------------------------- Thanks to detailed explanation by Martin, I understand that the ontape which is already running would backup all the logs that are filled & are available to be backed up, infact it would check if another log is near to complete so that it can also be backed up. So Every logical log file would be backed up. BUT it worries me when i see: 3180dd9e8 342 U-B---- 64216 5:3290053 10000 10000 100.00 3180dda50 343 U-B---- 64217 5:3300053 10000 10000 100.00 3180ddab8 344 U-B---L 64218 5:3310053 10000 10000 100.00 3180ddb20 345 U-B---- 64219 5:3320053 10000 10000 100.00 3180ddb88 346 U------ 64220 5:3330053 10000 10000 100.00 3180ddbf0 347 U------ 64221 5:3340053 10000 10000 100.00 3180ddc58 348 U------ 64222 5:3350053 10000 10000 100.00 3180ddcc0 349 U------ 64223 5:3360053 10000 10000 100.00 3180ddd28 350 U------ 64224 5:3370053 10000 10000 100.00 3180ddd90 351 U------ 64225 5:3380053 10000 10000 100.00 3180dddf8 352 U------ 64226 5:3390053 10000 10000 100.00 3180dde60 353 U------ 64227 5:3400053 10000 10000 100.00 3180ddec8 354 U------ 64228 5:3410053 10000 10000 100.00 3180ddf30 355 U------ 64229 5:3420053 10000 10000 100.00 3180ddf98 356 U------ 64230 5:3430053 10000 10000 100.00 3180de028 357 U------ 64231 5:3440053 10000 10000 100.00 3180de090 358 U------ 64232 5:3450053 10000 10000 100.00 3180de0f8 359 U------ 64233 5:3460053 10000 10000 100.00 3180de160 360 U------ 64234 5:3470053 10000 10000 100.00 3180de1c8 361 U------ 64235 5:3480053 10000 10000 100.00 3180de230 362 U------ 64236 5:3490053 10000 10000 100.00 3180de298 363 U------ 64237 5:3500053 10000 10000 100.00 3180de300 364 U------ 64238 5:3510053 10000 10000 100.00 3180de368 365 U------ 64239 5:3520053 10000 10000 100.00 3180de3d0 366 U------ 64240 5:3530053 10000 10000 100.00 3180de438 367 U------ 64241 5:3540053 10000 10000 100.00 3180de4a0 368 U------ 64242 5:3550053 10000 10000 100.00 3180de508 369 U------ 64243 5:3560053 10000 10000 100.00 3180de570 370 U------ 64244 5:3570053 10000 10000 100.00 3180de5d8 371 U------ 64245 5:3580053 10000 10000 100.00 3180de640 372 U---C-- 64246 5:3590053 10000 4107 41.07 3180de6a8 373 U-B---- 63661 5:3600053 10000 10000 100.00 3180de710 374 U-B---- 63662 5:3610053 10000 10000 100.00 3180de778 375 U-B---- 63663 5:3620053 10000 10000 100.00 3180de7e0 376 U-B---- 63664 5:3630053 10000 10000 100.00 What if now the engine goes down? Sure Ontape is running and would backup all these files. Sure my logical log size needs to be increased atleast to 100M(i had to convience a lot to increase it from 5M to 20 M and still working to get it atleast 100M). Sure IDS is working as it designed to work. With the fix as unique names for temp files i was under wrong impression that, now ontape(s) now can run parallely with out over writing each others temp files and backup the logs, instead of one running and doing all the work. May be i'm totally wrong here hence Any information regarding this is appreciated. Regards, Vikas P.S: Better to read than to fall in guesstimation but i dont know if there are any documents released/written explaining the change made.

Hi, ontape is not parallel in any way, neither for dbspace nor for log backups. (Even ON-Bar, which does parallel dbspace backups, is doing log backups serially.) The problem seems that your system is "producing" log records too fast, i.e. logs fill faster than they can be backed up. You have to find the bottle neck in the log backup. It may be inherent, i.e. it cannot be faster because ontape works serially and simply is too slow. But it may also be due to a slow disk (where the log backups are written to) or something like that. In the latter case you may be able to improve the speed of log backup ... Usually some detailed (performance) analysis of the system is necessary to find out if something can be improved and where this can be done. I think it'll be difficult via e-mail. Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management IBM Deutschland Research & Development GmbH Chairman of the Supervisory Board: Martin Jetter Board of Management: Erich Baier Corporate Seat: Boeblingen, Germany Reg.-Gericht: Amtsgericht Stuttgart, HRB 243294 ids-bounces@iiug.org wrote on 18.02.2009 10:57:54: > Hello, > > IDS 11.10.FC3 on solaris 10. > > #Please consider this as a query and not a problem yet. > #I know the my logical logs are small in size(500+, 20M each) for taking some > hectic transactions BUT not possible to to increase the log size atleast for > now. > > In 11.10.FC2W4 i faced a bug with parallel ontapes running for backing up the > logical logs & resulting in Loss of logical logs files. > (ontape to directory feature used. Alarmprogram.sh to backup the logs) > > One of the workaround was to check if ontape is running, some thing like: > "ps -aef | grep "ontape -a -d" |grep -v grep |" in the alarmprogram.sh script > before a new ontape is invoked. > > I did all this in order to avoid new ontape when one is already in progress. > > Now I have 11.10.FC3 with the bug fix, the first thing i checked in my > testings was the name for temp file which now i see unique for everytemp file > generated/used by ontape before writing to permanent file on the disk. > > I also see that now IDS is not allowing another ontape to run untill one is > already running: (May be i am not correct on this). > ------ontape's output--------- > Performing automatic backup of logical logs. > > Logbackup failed - A Log backup is already in progress. > > Program over. > > Performing automatic backup of logical logs. > > Logbackup failed - A Log backup is already in progress. > ----------------------------- > Thanks to detailed explanation by Martin, I understand that the ontape which > is already running would backup all the logs that are filled & are available > to be backed up, infact it would check if another log is near to complete so > that it can also be backed up. So Every logical log file would be backed up. > > BUT it worries me when i see: > > 3180dd9e8 342 U-B---- 64216 5:3290053 10000 10000 100.00 > 3180dda50 343 U-B---- 64217 5:3300053 10000 10000 100.00 > 3180ddab8 344 U-B---L 64218 5:3310053 10000 10000 100.00 > 3180ddb20 345 U-B---- 64219 5:3320053 10000 10000 100.00 > 3180ddb88 346 U------ 64220 5:3330053 10000 10000 100.00 > 3180ddbf0 347 U------ 64221 5:3340053 10000 10000 100.00 > 3180ddc58 348 U------ 64222 5:3350053 10000 10000 100.00 > 3180ddcc0 349 U------ 64223 5:3360053 10000 10000 100.00 > 3180ddd28 350 U------ 64224 5:3370053 10000 10000 100.00 > 3180ddd90 351 U------ 64225 5:3380053 10000 10000 100.00 > 3180dddf8 352 U------ 64226 5:3390053 10000 10000 100.00 > 3180dde60 353 U------ 64227 5:3400053 10000 10000 100.00 > 3180ddec8 354 U------ 64228 5:3410053 10000 10000 100.00 > 3180ddf30 355 U------ 64229 5:3420053 10000 10000 100.00 > 3180ddf98 356 U------ 64230 5:3430053 10000 10000 100.00 > 3180de028 357 U------ 64231 5:3440053 10000 10000 100.00 > 3180de090 358 U------ 64232 5:3450053 10000 10000 100.00 > 3180de0f8 359 U------ 64233 5:3460053 10000 10000 100.00 > 3180de160 360 U------ 64234 5:3470053 10000 10000 100.00 > 3180de1c8 361 U------ 64235 5:3480053 10000 10000 100.00 > 3180de230 362 U------ 64236 5:3490053 10000 10000 100.00 > 3180de298 363 U------ 64237 5:3500053 10000 10000 100.00 > 3180de300 364 U------ 64238 5:3510053 10000 10000 100.00 > 3180de368 365 U------ 64239 5:3520053 10000 10000 100.00 > 3180de3d0 366 U------ 64240 5:3530053 10000 10000 100.00 > 3180de438 367 U------ 64241 5:3540053 10000 10000 100.00 > 3180de4a0 368 U------ 64242 5:3550053 10000 10000 100.00 > 3180de508 369 U------ 64243 5:3560053 10000 10000 100.00 > 3180de570 370 U------ 64244 5:3570053 10000 10000 100.00 > 3180de5d8 371 U------ 64245 5:3580053 10000 10000 100.00 > 3180de640 372 U---C-- 64246 5:3590053 10000 4107 41.07 > 3180de6a8 373 U-B---- 63661 5:3600053 10000 10000 100.00 > 3180de710 374 U-B---- 63662 5:3610053 10000 10000 100.00 > 3180de778 375 U-B---- 63663 5:3620053 10000 10000 100.00 > 3180de7e0 376 U-B---- 63664 5:3630053 10000 10000 100.00 > > What if now the engine goes down? > > Sure Ontape is running and would backup all these files. > Sure my logical log size needs to be increased atleast to 100M(i had to > convience a lot to increase it from 5M to 20 M and still working to get it > atleast 100M). > Sure IDS is working as it designed to work. > > With the fix as unique names for temp files i was under wrong > impression that, > now ontape(s) now can run parallely with out over writing each others temp > files and backup the logs, instead of one running and doing all the work. > > May be i'm totally wrong here hence Any information regarding this is > appreciated. > > Regards, > Vikas > > P.S: Better to read than to fall in guesstimation but i dont know ifthere are > any documents released/written explaining the change made. > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. >

Thanks Martin, I remembered your explanation about a check in the server that allows only one active log backup operation at a time and is independent of the ALARMPROGRAM mechanism. Yes my logs are filling faster than they can be backed up & the simplest thing i should do is to increase the log file size But :( Possiblility of slow disk, i would check with onstat options for disk I/O and may be i can talk to the admin guys & see if they can help me with any checks on our SAN where the logs are written. As far as the IDS performance is concern, I do check BR and RAU & those are just fine including BTR(Thanks to Art for these formulae). Regards, Vikas ------------------------------------------------------------------- Hi, ontape is not parallel in any way, neither for dbspace nor for log backups. (Even ON-Bar, which does parallel dbspace backups, is doing log backups serially.) The problem seems that your system is "producing" log records too fast, i.e. logs fill faster than they can be backed up. You have to find the bottle neck in the log backup. It may be inherent, i.e. it cannot be faster because ontape works serially and simply is too slow. But it may also be due to a slow disk (where the log backups are written to) or something like that. In the latter case you may be able to improve the speed of log backup ... Usually some detailed (performance) analysis of the system is necessary to find out if something can be improved and where this can be done. I think it'll be difficult via e-mail. Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management IBM Deutschland Research & Development GmbH Chairman of the Supervisory Board: Martin Jetter Board of Management: Erich Baier Corporate Seat: Boeblingen, Germany Reg.-Gericht: Amtsgericht Stuttgart, HRB 243294 ids-bounces@iiug.org wrote on 18.02.2009 10:57:54:

Vikas, May I suggest that you look into the command flock instead of "ps -aef | grep "ontape -a -d" |grep -v grep |". Flock allows you to run just one command at a time. Example: flock -x /var/lock/informix_<instancename> ontape -a -d Thus if the alarmprogram triggers another logbackup it will have to wait for a lock on the file to be released and the lock is released only when ontape exits. I guess this should solve the problem of con-current ontapes. Regards, Kenneth Penza Systems Engineer| SMD MALTA INFORMATION TECHNOLOGY AGENCY * email: kenneth.penza@gov.mt - ( Office: +356 2599 2867 : http://www.mita.gov.mt * Please read our Legal Notice: http://emailpolicy.mita.gov.mt P Please consider your environmental responsibility before printing this e-mail -----Original Message----- From: ids-bounces@iiug.org [mailto:ids-bounces@iiug.org] On Behalf Of VIKAS HIVARKAR Sent: 18 February 2009 10:58 To: ids@iiug.org Subject: Ontape to backup Logical logs - Query [14927] Hello, IDS 11.10.FC3 on solaris 10. #Please consider this as a query and not a problem yet. #I know the my logical logs are small in size(500+, 20M each) for taking some hectic transactions BUT not possible to to increase the log size atleast for now. In 11.10.FC2W4 i faced a bug with parallel ontapes running for backing up the logical logs & resulting in Loss of logical logs files. (ontape to directory feature used. Alarmprogram.sh to backup the logs) One of the workaround was to check if ontape is running, some thing like: "ps -aef | grep "ontape -a -d" |grep -v grep |" in the alarmprogram.sh script before a new ontape is invoked. I did all this in order to avoid new ontape when one is already in progress. Now I have 11.10.FC3 with the bug fix, the first thing i checked in my testings was the name for temp file which now i see unique for every temp file generated/used by ontape before writing to permanent file on the disk. I also see that now IDS is not allowing another ontape to run untill one is already running: (May be i am not correct on this). ------ontape's output--------- Performing automatic backup of logical logs. Logbackup failed - A Log backup is already in progress. Program over. Performing automatic backup of logical logs. Logbackup failed - A Log backup is already in progress. ----------------------------- Thanks to detailed explanation by Martin, I understand that the ontape which is already running would backup all the logs that are filled & are available to be backed up, infact it would check if another log is near to complete so that it can also be backed up. So Every logical log file would be backed up. BUT it worries me when i see: 3180dd9e8 342 U-B---- 64216 5:3290053 10000 10000 100.00 3180dda50 343 U-B---- 64217 5:3300053 10000 10000 100.00 3180ddab8 344 U-B---L 64218 5:3310053 10000 10000 100.00 3180ddb20 345 U-B---- 64219 5:3320053 10000 10000 100.00 3180ddb88 346 U------ 64220 5:3330053 10000 10000 100.00 3180ddbf0 347 U------ 64221 5:3340053 10000 10000 100.00 3180ddc58 348 U------ 64222 5:3350053 10000 10000 100.00 3180ddcc0 349 U------ 64223 5:3360053 10000 10000 100.00 3180ddd28 350 U------ 64224 5:3370053 10000 10000 100.00 3180ddd90 351 U------ 64225 5:3380053 10000 10000 100.00 3180dddf8 352 U------ 64226 5:3390053 10000 10000 100.00 3180dde60 353 U------ 64227 5:3400053 10000 10000 100.00 3180ddec8 354 U------ 64228 5:3410053 10000 10000 100.00 3180ddf30 355 U------ 64229 5:3420053 10000 10000 100.00 3180ddf98 356 U------ 64230 5:3430053 10000 10000 100.00 3180de028 357 U------ 64231 5:3440053 10000 10000 100.00 3180de090 358 U------ 64232 5:3450053 10000 10000 100.00 3180de0f8 359 U------ 64233 5:3460053 10000 10000 100.00 3180de160 360 U------ 64234 5:3470053 10000 10000 100.00 3180de1c8 361 U------ 64235 5:3480053 10000 10000 100.00 3180de230 362 U------ 64236 5:3490053 10000 10000 100.00 3180de298 363 U------ 64237 5:3500053 10000 10000 100.00 3180de300 364 U------ 64238 5:3510053 10000 10000 100.00 3180de368 365 U------ 64239 5:3520053 10000 10000 100.00 3180de3d0 366 U------ 64240 5:3530053 10000 10000 100.00 3180de438 367 U------ 64241 5:3540053 10000 10000 100.00 3180de4a0 368 U------ 64242 5:3550053 10000 10000 100.00 3180de508 369 U------ 64243 5:3560053 10000 10000 100.00 3180de570 370 U------ 64244 5:3570053 10000 10000 100.00 3180de5d8 371 U------ 64245 5:3580053 10000 10000 100.00 3180de640 372 U---C-- 64246 5:3590053 10000 4107 41.07 3180de6a8 373 U-B---- 63661 5:3600053 10000 10000 100.00 3180de710 374 U-B---- 63662 5:3610053 10000 10000 100.00 3180de778 375 U-B---- 63663 5:3620053 10000 10000 100.00 3180de7e0 376 U-B---- 63664 5:3630053 10000 10000 100.00 What if now the engine goes down? Sure Ontape is running and would backup all these files. Sure my logical log size needs to be increased atleast to 100M(i had to convience a lot to increase it from 5M to 20 M and still working to get it atleast 100M). Sure IDS is working as it designed to work. With the fix as unique names for temp files i was under wrong impression that, now ontape(s) now can run parallely with out over writing each others temp files and backup the logs, instead of one running and doing all the work. May be i'm totally wrong here hence Any information regarding this is appreciated. Regards, Vikas P.S: Better to read than to fall in guesstimation but i dont know if there are any documents released/written explaining the change made. ************************************************************************ ******* Forum Note: Use "Reply" to post a response in the discussion forum.

So, to clarify, your question is "Now that ontape instances create a uniquely named temp file, can I run multiple copies of 'ontape -a' to backup the logs in parallel to get them on disk faster?" I would confidently say that the answer is no. Logical log archives are always sequential, one log at a time. A single ontape -a instance will indeed back up all logs that are ready to back up and will indeed also pick up logs that complete while it is running, but it's a single sequential process. Art On Wed, Feb 18, 2009 at 4:57 AM, VIKAS HIVARKAR <vikas.hivarkar@gmail.com>wrote: > Hello, > > IDS 11.10.FC3 on solaris 10. > > #Please consider this as a query and not a problem yet. > #I know the my logical logs are small in size(500+, 20M each) for taking > some > hectic transactions BUT not possible to to increase the log size atleast > for > now. > > In 11.10.FC2W4 i faced a bug with parallel ontapes running for backing up > the > logical logs & resulting in Loss of logical logs files. > (ontape to directory feature used. Alarmprogram.sh to backup the logs) > > One of the workaround was to check if ontape is running, some thing like: > "ps -aef | grep "ontape -a -d" |grep -v grep |" in the alarmprogram.sh > script > before a new ontape is invoked. > > I did all this in order to avoid new ontape when one is already in > progress. > > Now I have 11.10.FC3 with the bug fix, the first thing i checked in my > testings was the name for temp file which now i see unique for every temp > file > generated/used by ontape before writing to permanent file on the disk. > > I also see that now IDS is not allowing another ontape to run untill one is > already running: (May be i am not correct on this). > ------ontape's output--------- > Performing automatic backup of logical logs. > > Logbackup failed - A Log backup is already in progress. > > Program over. > > Performing automatic backup of logical logs. > > Logbackup failed - A Log backup is already in progress. > ----------------------------- > Thanks to detailed explanation by Martin, I understand that the ontape > which > is already running would backup all the logs that are filled & are > available > to be backed up, infact it would check if another log is near to complete > so > that it can also be backed up. So Every logical log file would be backed > up. > > BUT it worries me when i see: > > 3180dd9e8 342 U-B---- 64216 5:3290053 10000 10000 100.00 > 3180dda50 343 U-B---- 64217 5:3300053 10000 10000 100.00 > 3180ddab8 344 U-B---L 64218 5:3310053 10000 10000 100.00 > 3180ddb20 345 U-B---- 64219 5:3320053 10000 10000 100.00 > 3180ddb88 346 U------ 64220 5:3330053 10000 10000 100.00 > 3180ddbf0 347 U------ 64221 5:3340053 10000 10000 100.00 > 3180ddc58 348 U------ 64222 5:3350053 10000 10000 100.00 > 3180ddcc0 349 U------ 64223 5:3360053 10000 10000 100.00 > 3180ddd28 350 U------ 64224 5:3370053 10000 10000 100.00 > 3180ddd90 351 U------ 64225 5:3380053 10000 10000 100.00 > 3180dddf8 352 U------ 64226 5:3390053 10000 10000 100.00 > 3180dde60 353 U------ 64227 5:3400053 10000 10000 100.00 > 3180ddec8 354 U------ 64228 5:3410053 10000 10000 100.00 > 3180ddf30 355 U------ 64229 5:3420053 10000 10000 100.00 > 3180ddf98 356 U------ 64230 5:3430053 10000 10000 100.00 > 3180de028 357 U------ 64231 5:3440053 10000 10000 100.00 > 3180de090 358 U------ 64232 5:3450053 10000 10000 100.00 > 3180de0f8 359 U------ 64233 5:3460053 10000 10000 100.00 > 3180de160 360 U------ 64234 5:3470053 10000 10000 100.00 > 3180de1c8 361 U------ 64235 5:3480053 10000 10000 100.00 > 3180de230 362 U------ 64236 5:3490053 10000 10000 100.00 > 3180de298 363 U------ 64237 5:3500053 10000 10000 100.00 > 3180de300 364 U------ 64238 5:3510053 10000 10000 100.00 > 3180de368 365 U------ 64239 5:3520053 10000 10000 100.00 > 3180de3d0 366 U------ 64240 5:3530053 10000 10000 100.00 > 3180de438 367 U------ 64241 5:3540053 10000 10000 100.00 > 3180de4a0 368 U------ 64242 5:3550053 10000 10000 100.00 > 3180de508 369 U------ 64243 5:3560053 10000 10000 100.00 > 3180de570 370 U------ 64244 5:3570053 10000 10000 100.00 > 3180de5d8 371 U------ 64245 5:3580053 10000 10000 100.00 > 3180de640 372 U---C-- 64246 5:3590053 10000 4107 41.07 > 3180de6a8 373 U-B---- 63661 5:3600053 10000 10000 100.00 > 3180de710 374 U-B---- 63662 5:3610053 10000 10000 100.00 > 3180de778 375 U-B---- 63663 5:3620053 10000 10000 100.00 > 3180de7e0 376 U-B---- 63664 5:3630053 10000 10000 100.00 > > What if now the engine goes down? > > Sure Ontape is running and would backup all these files. > Sure my logical log size needs to be increased atleast to 100M(i had to > convience a lot to increase it from 5M to 20 M and still working to get it > atleast 100M). > Sure IDS is working as it designed to work. > > With the fix as unique names for temp files i was under wrong impression > that, > now ontape(s) now can run parallely with out over writing each others temp > files and backup the logs, instead of one running and doing all the work. > > May be i'm totally wrong here hence Any information regarding this is > appreciated. > > Regards, > Vikas > > P.S: Better to read than to fall in guesstimation but i dont know if there > are > any documents released/written explaining the change made. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. --00163683222a81906a0463340fcb

You might also double-check that LTAPEBLK is tuned to the largest size possible. I found on a RH 32-bit system with attached SCSI-3 tape drive that max throughput topped out at 256 for TAPEBLK and LTAPEBLK. If you could get a maintenance window, you *could* drop about 100 of your 500 logs, and recreate them at 40MB each in that same space. That would take longer for each LLOG to fill giving the tape backup time to keep up. If that works for you, you could do the rest of them too. Just a thought. Bob ----- Original Message ----- From: "VIKAS HIVARKAR" <vikas.hivarkar@gmail.com> To: ids@iiug.org Sent: Wednesday, February 18, 2009 6:30:02 AM GMT -05:00 US/Canada Eastern Subject: Re: Ontape to backup Logical logs - Query [14930] Thanks Martin, I remembered your explanation about a check in the server that allows only one active log backup operation at a time and is independent of the ALARMPROGRAM mechanism. Yes my logs are filling faster than they can be backed up & the simplest thing i should do is to increase the log file size But :( Possiblility of slow disk, i would check with onstat options for disk I/O and may be i can talk to the admin guys & see if they can help me with any checks on our SAN where the logs are written. As far as the IDS performance is concern, I do check BR and RAU & those are just fine including BTR(Thanks to Art for these formulae). Regards, Vikas ------------------------------------------------------------------- Hi, ontape is not parallel in any way, neither for dbspace nor for log backups. (Even ON-Bar, which does parallel dbspace backups, is doing log backups serially.) The problem seems that your system is "producing" log records too fast, i.e. logs fill faster than they can be backed up. You have to find the bottle neck in the log backup. It may be inherent, i.e. it cannot be faster because ontape works serially and simply is too slow. But it may also be due to a slow disk (where the log backups are written to) or something like that. In the latter case you may be able to improve the speed of log backup ... Usually some detailed (performance) analysis of the system is necessary to find out if something can be improved and where this can be done. I think it'll be difficult via e-mail. Regards, Martin -- Martin Fuerderer IBM Informix Development Munich, Germany Information Management IBM Deutschland Research & Development GmbH Chairman of the Supervisory Board: Martin Jetter Board of Management: Erich Baier Corporate Seat: Boeblingen, Germany Reg.-Gericht: Amtsgericht Stuttgart, HRB 243294 ids-bounces@iiug.org wrote on 18.02.2009 10:57:54: ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.