log file sync due to batch job has too many COMMITs

9:30am, my exention ring before I drink my coffee, developer reported that his trial run job keeps running since 5:30am.

investigating ...

no long-runing query captured. the developer told maybe because of the update is too fast and can't. However, check wait event. I saw one session started at 05:30am with wait event "log file sync". That it is.

When a user session COMMITs (or rolls back), the sessions redo information needs to be flushed to the redo logfile. The user session will post the LGWR to write all redo required from the log buffer to the redo log file. When the LGWR has finished it will post the user session. The user session waits on this wait event while waiting for LGWR to post it back to confirm all redo changes are safely on disk. [QY: this implies that commit is not immediate done as we can feel it using sql*plus]
("log file sync" applies to ROLLBACK in that once the rollback is complete the end of the rollback operation requires all changes to complete the rollback to be flushed to the redo log)

"If there are lots of short duration transactions see if it is possible to BATCH
transactions together so there are fewer distinct COMMIT operations. Each
commit has to have it confirmed that the relevant REDO is on disk. Although
commits can be "piggybacked" by Oracle reducing the overall number of
commits by batching transactions can have a very beneficial effect."

runt the report and see below
redo blocks written 2,760,350 153.4 2.8
...
redo writes 968,848 53.8 1.0

size/write=(2,760,350/968,848)*1k , consider as small
**1k here is internal redo block,related to mount point mounting option. it is not block size (i just learned that)

Also observed that transaction per second is 55, higher than usual 8.

Solution: advise developer to reduce COMMITs.