It is important to understand that Oracle trusts the operating system when it indicates that the redo has been written to disk successfully. If the operating system returns a successful write, yet that write did not physically occur, and then a media failure occurs, the database may not be completely recoverable. I have seen failures of lithium backup batteries, disk mirroring software, and physical drives result in the database system becoming unavailable. While optimal performance may not be achieved, it may be in everyone's best interest to ensure when Oracle receives the message, "Sure, the data has been written to disk," it actually has been written to disk. Achieving this performance versus availability balance can be very tricky indeed.

Oracle Database 10g Release 2 introduced the commit write facility, which gives the appearance a commit has completed when it really hasn't. If commit times are taking too long (log file sync will be the top wait event) and the application can survive the possibility of lost data5 in an unfortunate instance failure, then technically, one of the commit write options may provide the extra performance boost you need. But please, ensure your application and the business can tolerate the potential loss of committed data. As I tell people, slower performance is better than no performance.

The trusted standard commit command is the same as commit write immediate, wait, but there are three other alternatives. Each can be put into effect in any of the following ways: