[...]... log files For the sake of simplicity, we’ll postpone the issue of infinite changes and simply pretend for the moment that we can record as many undo and redo records as we need ACID Although we’re not going to look at transactions in this chapter, it is, at this point, worth mentioning the ACID requirements of a transactional system and how Oracle s implementation of undo and redo gives Oracle the... blocks only when the transaction commits, the change vector for the start of transaction is an important special case and is applied to the undo segment header block as the transaction starts So Oracle has a mechanism for reducing the number of times a session demands space from, and copies information into, the (public) redo log buffer, and that improves the level of concurrency we can achieve ... but as transactions come and go, the pointers will eventually turn into a fairly random linked list wandering through the slots 29 CHAPTER 3 ■ TRANSACTIONS AND CONSISTENCY Continued Column Description scn The commit SCN for a committed transaction (Since a rollback call ends with a commit, this would also be used for the commit SCN at the end of a rollback) For most versions of Oracle, this column is... first select, select one row on the second select, and insert one row Not only are the mechanisms for undo and redo sufficient to implement the basic requirements of ACID, they also offer advantages in performance and recoverability The performance benefit of redo has already been covered in the comments on durability; if you want an example of the performance benefits of undo, think about isolation—how... take a note of that idea for later examination There are various places we can look in the database to understand what has happened We can examine v$latch_children to understand why the change in latch activity isn’t a new threat We can examine the redo log file to see what the one large redo entry looks like And we can find a couple of dynamic performance objects (x$kcrfstrand and x$ktifp) that will... memory structures One set (called x$kcrfstrand, the private redo) handles “forward” change vectors, and the other set (called x$ktifp, the in-memory undo pool) handles the undo change vectors The private redo structure also happens to hold information about the traditional “public” redo log buffer(s), so don’t be worried if you see two different patterns of information when you query it The number of... When we change a data block, Oracle inserts an undo record into an undo block to tell us how to reverse that change But for every change that happens to a block in the database, Oracle creates a redo change vector describing how to make that change, and it creates the vectors before it makes the changes Historically, it created the undo change vector before it created the “forward” change vector, hence,... point—competition wastes resources 18 CHAPTER 2 ■ REDO AND UNDO I don’t know how many different events there are that could force a session to construct new versions of blocks from private redo and undo, but I do know that there are several events that result in a session abandoning the new strategy before the commit An obvious case where Oracle has to abandon the new mechanism is when either the private... copy of Oracle) When an area is full, Oracle creates a single redo record, copies it to the public redo thread, and then continues using the public redo thread in the old way But there are other events that cause this switch prematurely For example, your SQL might trigger a recursive statement For a quick check on possible causes, and how many times each has occurred, you could connect as SYS and run... changes for a transaction “in private” before creating one large redo record in the redo buffer The new mechanism is strictly limited in the amount of work a session will do before it flushes its change vectors to the redo log buffer and switches to the older mechanism, and there are various events that will make this switch happen prematurely While redo operates as a simple “write it and forget it” . about how Oracle tracks data in memory. Having spent most of our time on data handling, we’ll move on to see how Oracle handles its code (the SQL) and how the memory-handling mechanisms for code. tablespace and the sysaux tablespace, which should not be used for any end-user data. The sysaux tablespace appeared in Oracle 10g as a place for Oracle to keep the more dynamic, and potentially. efficiency and concurrency. We’ll start with simple data changes and the mechanisms that Oracle uses to record and apply changes, and then we’ll examine how changes are combined to form transactions.