Undo tablespace and rollback segments

Undo tablespace and rollback segments

The Undo/rollback tablespace is the tablespace used to store rollback segments. The rollback segment is the data space of the image before Oracle saves the modified data. Each rollback segment contains some extensions, which are used by a loop machine. When an extension is full, it is automatically switched to another extension to continue using. A transaction will write the rollback record at the current position of the rollback segment, and indicate the location of the record through the record size. The current write pointer is a control structure in the rollback segment header. The tail refers to the start position of the last record in the rollback segment.
The number of rollback segments and the size of each rollback segment are crucial for the configuration of the rollback segment. In the OLTP system, set a sufficient number of rollback segments to avoid rollback segment conflicts. The size of each rollback segment should be large enough to meet the transaction processing needs. Oracle uses rollback segments cyclically. All online rollback segments (except system rollback segments) are used in turn. Oracle has the following features when using rollback segments.
A transaction uses only one rollback segment to record all rollback records.
Multiple transactions can write the same extension.
The extension is recycled, and no extension will be skipped.
If you cannot use the next extension, Oracle will automatically allocate a new extension and insert it into this ring.
Oracle will not use extensions that are tail occupied.
From the above principle, we can see that the transaction duration and the transaction size are also important factors affecting the rollback segment. A transaction that uses only one byte For A Long Time may cause rollback segment expansion. If a system has multiple rollback segments, Oracle selects a rollback segment based on the following principles.
First, Oracle selects the rollback segment with the lowest number of transactions.
If there are more than two rollback segments with the same number of transactions, Oracle will use the rollback segment number for the previous transaction, select the next proper rollback segment that is larger than the rollback segment number. For example, if the current transaction uses rollback segment 2, rollback segment 1 and rollback segment 4 have a minimum number of transactions, then oracle uses rollback segment 4 to store the data of the next transaction.
From the above principle, what do we get when setting our own rollback segments? If your rollback segment is large enough, you must first determine the storage parameters of the rollback segment based on the actual transaction size so that the rollback segment header will not be quickly transferred to the end of the segment. If the rollback segment is quickly rolled back to the end, the rollback segment will be expanded quickly.
The second issue that should be noted is that if a long-running query is executed and the data accessed by this query changes frequently, the rollback segment must be large enough, to ensure that there is no ORA-1555 error (snapshot too old) before your query ends ).
The size of rollback segments depends on the features of transactions in the database. The rollback segment size should be designed to meet the requirements of daily database transactions, rather than for large transactions that are not frequently used. The number of rollback segments must be set to ensure that no rollback segment competition occurs. Whether there is a rollback segment competition can be viewed through the V $ waitstat view, Code As follows:

Select class, count from V $ waitstat where class = '% undo % ';
Any non-zero Count value indicates that there is competition for rollback segments.

| |

 

Undo is also protected by redo:

In Oracle, undo has two main functions: roll back the transaction, and produce consistent read. Some new functions, such as flashback query, are also derived. The traditional undo operations are managed by undo segment. Let's look at the following example:

 

At the beginning of the transaction, you must first allocate ITL to the data block. The ITL records the transaction ID (Xid). The Xid consists of three parts: xidusn (rollback segment number ), xidslot (rollback segment slot number), xidsqn (serial number), there is a transaction table in the Undo segment header, records the transaction information on the rollback segment, each transaction occupies a rollback slot. Xid corresponds to a UBA (UNDO block address), which indicates the start position of the transaction rollback information. In the preceding example, the transaction executes three operations at T1, T2, and T3 respectively, and updates the data in the three blocks. Each data block has an ITL, point to the transaction table in the Undo segment header. The undo information is stored in three undo blocks respectively. The undo information is a linked list structure, and the UBA In the Undo segment header points to the last undo block, which is also the starting position of rollback. If the transaction needs to be rolled back, you only need to find the starting position of the transaction rollback in the transaction table in the Undo segment header, and then roll back the entire transaction in sequence through the Undo linked list.
Careful DBA will surely find that there is also a UBA in the ITL of each data block. In fact, this UBA points to the starting position of the Undo information corresponding to the block, the main function of UBA is to provide consistent read, because the primary read requires the Undo information to construct a Cr block, with this UBA, you can directly locate the starting position of the block rollback information, instead of using the transaction table in the Undo segment header.
In the traditional undo management mode, Oracle treats undo and data block equally. Both of them must first read the data buffer for modification and generate redo information, the modification process is roughly as follows: generate the Undo Redo, change the Undo block, generate the data Redo, and modify the data block. In short, redo must be recorded before data. When the database crashes, you can use the redo log to restore data and undo blocks, and then roll back uncommitted transactions through the Undo information to ensure data consistency, therefore, the process of instance recovery is the process of previous rollback and rollback.
The traditional undo management has drawbacks. First, undo information must be read from external files if it is not in the data buffer. Second, all undo changes must also record the redo, it is written into the redo log when the transaction is committed. Oracle introduces the new in-memory undo feature, which stores the Undo information in the memory structure to ease the overhead of traditional undo management.
IMU allocates a piece of memory space (IMU pool) in the Shared Pool. Each new transaction will allocate an imu buffer, which is equivalent to a private undo buffer for a transaction and is used to record undo information. The starting position of the IMU node is recorded in the data block, and the consistent read can be achieved through the information in the IMU buffer, which greatly improves the efficiency. (Here I want to clarify that I did not find any specific information pointing to the IMU node when I dumped the data block ).

 

In IMU mode, undo information is still written to redo. It is important to understand this! Because instance recovery requires undo information to roll back uncommitted transactions, so that the database is in a consistent state. If there is no undo change information in the Redo, once the instance crash occurs, the database may be in an inconsistent state.
At the beginning of the transaction, the transaction will still allocate ITL in the data block, and it will still point to the transaction table of the Undo segment header, but the information in the Undo block does not need to be written immediately, at this time, the Undo information is recorded in the IMU buffer, and the Undo block redo information is not generated. In the following two cases, the information in the Undo buffer will be written into the Undo block: 1.imu buffer space is insufficient; 2. lgwr writes the redo information to the redo log (such as commit). In V $ sysstat, we can see IMU flush and IMU commit, which indicate the above two situations respectively, if you find that these two values keep increasing, it means that the system has enabled the IMU feature.
Now we know that the Undo information in IMU will still be written to the redo log, but a private undo buffer is allocated in the shared pool, on the one hand, you can perform consistent read operations in the memory. On the other hand, the Undo information is only batch written to the redo log if necessary, to ensure that the database can be restored to the consistent state after crash. In addition, Oracle always tries its best to retain the information in the Undo buffer so that consistent read operations can be performed in the memory. In addition, when undo information is written into the Undo block, Oracle merges the information, this reduces the consumption of the Undo block and the corresponding redo volume.
Since Oracle 10 Gb, the concept of private redo strands is introduced, and a private redo buffer space is allocated in the shared pool, redo generated by each transaction is put here (9i is placed in PGA), and each buffer is allocated a redo allocation latch to solve the contention problem of redo allocation latch in 9i. In fact, IMU and private redo strands are related. IMU is equivalent to private undo buffer. When the space of redo strand or undo buffer is insufficient, an imu flash event will occur, write redo information (including UNDO) to the redo log.

 

IMU implementation is complex. In many cases, Oracle automatically disables IMU features, such as RAC and stream environments.
-EOF-
I have little information about IMU. The information I obtained comes from a patent "method and mechanic for implementing in-memory transaction logging records" applied by Oracle on freepatents, And the IMU content in Oracle performance firefighting, tanel poder's performance and scalability improvements in Oracle 10g and 11g, as well as my own experiments and ideas.
The content is not necessarily correct. You are welcome to criticize and correct it.