Start and End of Transaction
When a session starts a transaction, it picks an undo segment, picks an entry from the transaction table,
increments the wrap#, changes the state to “active” (value 10), and modifies a few other columns. Since
this is a change to a database block, it will generate a redo change vector (with an OP code of 5.2) that will
ultimately get into the redo log file; this declares to the world and writes into the database the fact that
the session has an active transaction.
Similarly, when the transaction completes (typically through a commit; call), the session sets the
state back to “free” (value 9) and updates a few other columns in the entry—in particular, by writing the
current SCN into the scn column. Again, this constitutes a change to the database so it generates a redo
change vector (with an OP code of 5.4) that will go into the redo log. This moment is also rather special
because (historically) this is the “moment” when your session protects its committed changes by issuing
a call to the log writer (lgwr) to write the current content of the redo log buffer to disc and then waiting
for the log writer to confirm that it has finished writing. Once the log writer has written, you have a
permanent record of the transaction—in the ACID jargon, the transaction is now durable.
When a session starts a transaction, it picks an undo segment, picks an entry from the transaction table,
increments the wrap#, changes the state to “active” (value 10), and modifies a few other columns. Since
this is a change to a database block, it will generate a redo change vector (with an OP code of 5.2) that will
ultimately get into the redo log file; this declares to the world and writes into the database the fact that
the session has an active transaction.
Similarly, when the transaction completes (typically through a commit; call), the session sets the
state back to “free” (value 9) and updates a few other columns in the entry—in particular, by writing the
current SCN into the scn column. Again, this constitutes a change to the database so it generates a redo
change vector (with an OP code of 5.4) that will go into the redo log. This moment is also rather special
because (historically) this is the “moment” when your session protects its committed changes by issuing
a call to the log writer (lgwr) to write the current content of the redo log buffer to disc and then waiting
for the log writer to confirm that it has finished writing. Once the log writer has written, you have a
permanent record of the transaction—in the ACID jargon, the transaction is now durable.
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/263455/viewspace-751265/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/263455/viewspace-751265/