There is more to committing a transaction than simply triggering the log writer to write. Commits involve overhead in preparing for the write, updating Oracle internal structures (requiring latches and memory manipulation), and actually issuing the write. Rapid commits also lower the log writer's efficiency, as each write will not be as packed full of redo. So while the IO subsystem may be suffering, the log file sync points more toward an application issue rather than an IO subsystem issue. But this is no excuse for the IO subsystem team to abdicate their responsibility of ensuring the IO subsystem can process Oracle's IO requirements.

Due to all the Oracle SGA and structural change requirements when generating redo and committing, a lack of CPU resources can also be an issue. Investigate the classic "get more CPU" tactics, such as moving workload away from peak processing times, checking for unnecessary or unusual high-CPU consuming processes, and possibly adding more CPU resources.

Another creative "get more CPU" strategy is to bind a CPU exclusively to the log writer background process. While not all operating systems have this capability, if there is a CPU bottleneck or the log writer process spends too much time context switching,7 and log file sync is the top wait event, binding a CPU exclusively to the log writer background process can provide the extra power you need. For details about how to do this, do an Internet search for "binding process to CPU" and consult your operating system's documentation.