Re: DBMS Failure Issue

"DA Morgan" <damorgan_at_psoug.org> a écrit dans le message de news: 1131832654.679899_at_yasure...
| Michel Cadot wrote:
| > "Leigh Williams" <leighwilliams_at_gmail.com> a écrit dans le message de news:
1131807109.852054.259830_at_g44g2000cwa.googlegroups.com...
| > | The logwriter writes to the logfile on disk, so it must accumulate a
| > | block of log records before flushing to the log file. Suppose a
| > | transaction commits, but the commit record flushing is delayed by the
| > | log writer waiting to fill a block. What would happen to the
| > | transaction if DBMS failure occured while waiting for its commit record
| > | to be flushed? Would it simply be a case of a transaction undo in
| > | recovery?
| > |
| >
| > When a session commits it write a commit marker in the log buffer and
| > signals LGWR to flush the log buffer onto disk *without* waiting the block to be filled.
| > Then the session waits on the "log file sync" event till the block is on the disk.
| > This leads in waste in the log block and you can see the amont of this wastage
| > in the "redo wastage" statistics.
| >
| > Regards
| > Michel Cadot
|
| Given that Oracle has expanded COMMIT with options such as WRITE BATCH,
| NOWAIT, etc. I would like to suggest that we become a bit more careful
| about describing what COMMIT does and does not do. It is now version
| specific and depending upon which form of COMMIT is issued.
| --
| Daniel A. Morgan
| http://www.psoug.org
| damorgan_at_x.washington.edu
| (replace x with u to respond)

Given the question, the OP concern was doubtless (for me) about the good old genuine commit and not extended ones.
But for the general case, Sybrand answer is perfect: no commit marker => rollback.

Regards
Michel Cadot Received on Sun Nov 13 2005 - 00:59:00 CST