Usually I always use big database logs (200M - 50000 pages) . This time, increasing log size from 17M to 200M caused database to slow down significantly.

vmstat was showing lots of "b" processes

After log size was reduced, database went back to normal.

Can someone please comment why increasing log size cause Log I/O to conflict with the other database I/O?

Notice - database located on local storage array, RAID-5, same volume used for datafiles and logs.

I don't know what the performance problem is, but think you should try to move the logs to another array. You don't ever want to loose the logs and the data. I realize that it is Raid-5, but strange things can happen.

I assume that you can satisfy the same objective by using the smaller log file size, but define more log files.

Hello Marcus,

The question is why reducing log size reduced Log I/O contention with other database I/O.

Having logs and datafiles in different palces is not a question for me, however at this point is not an option.

Also, preference is to have big logs - 17 M logs are switching almost every minute

I'd say, it's the log buffer size that's affecting performance in your case, not the log file size.

Can you please explain why and how it can be confirmed from the database statistics?

Have a look at the thread
db2 -log pages read

for information on how to identify log buffering using snapshot ...

Cheers
Sathyaram

Thanks for referring.

Still, since this parameter was not changed, it does not explain, why I/O contention happened