Undo segments are different from table segments because they contain information related to transaction rollback and read consistency. One of the Oracle structures central for rollback and read consistency to properly occur is called the transaction table. Simply put, the transaction table is a map to an undo segment's contents. Every undo segment contains a single transaction table, which is located in the undo segment's header block. When intense DML, especially when combined with read consistency activity, occurs, the transaction table can become the point of contention, resulting in buffer busy waits events on an undo segment header block. Before moving into how to solve this issue, an introduction to the transaction table is warranted.

By default, every Oracle transaction generates redo (roll forward) and undo (roll back) information, as well as the actual data change and the possible index changes. The undo information is stored in an undo segment, and the map of each undo segment is stored in its transaction table. Each undo segment's transaction table can hold multiple transaction entries. From a relational database way of thinking, each entry corresponds to a row in the transaction table. Having the word table as part of its name is unfortunate, because the transaction table is not a relational database structure. In fact, the Oracle kernel developers refer to the transaction table entries as slots.

Because the transaction table is stored in an Oracle block, there is a limit to the number of slots it can hold, which depends on the Oracle block size. If the transaction table becomes full and a new entry must be added, the oldest inactive8 transaction entry is overwritten by the new entry. If the transaction is active and there is no more room in the transaction table or multiple sessions need to change the transaction table, a buffer busy waits event is posted. I provide a lot more information about the transaction table and undo entries in the "TX Enqueue Waits" section later in this chapter.