Previous | Table of Contents | Next

Page 500

more concurrent transactions. The larger your transactions (for example, updating a large quantity of rows) the larger your rollback segments need to be. Because rollback segments usually are allowed to grow and then shrink back to the OPTIMUM size value, special care must be taken to make sure that we truly know how much space a rollback segment needs.

Understanding Rollback Segment Operation

As mentioned before, rollback segments are made up of extents. Transactions grab extents to which they exclusively write. More than one transaction can write to the same rollback segment extent, but cannot write to the same block. If the redo information generated by the transaction exceeds the length of its allocated extent, the database attempts to allocate the next extent in the segment to the transaction. Like redo logs, rollback segments operate circularly—if the last extent in the rollback segment is written to, and no other transaction is writing to the first extent, the transaction will start writing to the first extent. Otherwise, the rollback segment will extend, or allocate another extent to itself for the transaction.

You should typically keep user transactions away from the default rollback segment when the database is created. This rollback segment is used by Oracle itself and should be left reserved for that purpose.

See Figure 21.8 for a description of this rollback segment extension.

FIG.21.8
Allocation of extents
inside rollback
segments.

In Figure 21.8, Diagram 1 shows that the rollback segment has two extents, E1 and E2, with active redo data, and two extents free. Diagram 2 shows the amount of redo written increased by another extent, E3, which is right next to E2 and could be allocated as the extent immediately next to E2 was allocated. Subsequently, as time passes, E4 also gets allocated, and shown in Number 3. All four extents in the rollback segment are now allocated. If a transaction needs to extend, a new extent will be added to the rollback segment to fulfill this request.

Page 501

NOTE
Extension can fail if the maxextents for a rollback segment are reached, or there is no more space in the tablespace to allocate to the rollback segment.

Dynamic extension of a rollback segment is a costly operation and causes a performance hit. It can also cause space problems, if the rollback segments are not carefully placed in the overall database configuration. Rollback segments should be allocated to their own tablespace, and no objects other than rollback segments should be stored in this tablespace. All rollback segments should be sized exactly the same—because of the frequent extension and deallocation of extents, fragmentation problems as previously discussed are sure to be a problem if mismatched extent sizes are configured.

Here are some general concepts regarding the extension and allocation of the extents in rollback segments:

Sizing Rollback Segments

When sizing rollback segments, keep the following two basic principles in mind:

Page 502

When transactions modify data in the database, they generate rollback information, which has to be written to the rollback segments. Sufficient space must also exist in your rollback segments to store all this information. The term read consistent must be well understood before we go into any sizing issues. Read consistent merely means that a transaction is guaranteed that the data it queries does not change between the time of the query being issued, and the time when the query ends. This is illustrated in the following example.

Consider a long running report that gives information about the salary details of all the employees in a company. Literally, this report traverses every record of the Employee table and obtains some associated information from other reference tables. Assume that an HR employee issues the report at 3:00 p.m. At 4:00 p.m., another user in payroll decides the salary increments for employees need to be processed for the year (an obvious example of poor communication between departments), and issues the job that performs this maintenance. This process modifies the records of most employees in the company, and commits this information immediately. See Figure 21.9 for a graphical representation.

FIG.21.9
Long-running query and
batch job.

Meanwhile, our original HR report is still chugging along. It comes to a point when an employee record that it needs to retrieve has had the salary changed by the salary increment process. At this point, what should Oracle do? Should the report deliver the salary details that are committed and are current, or should it return the old salary that was recorded before the increment?

If the report gets information that is current, then that would mean some employees in the report have the pre-increment salary and some have the post-increment salary, which would make the report inconsistent and useless. This is where the importance of rollback segments steps in. Through Oracle's transaction processing mechanism, the before update images of all rows changed in the salary increment processing program are written to the rollback segments. When the report program reaches a record that has been changed, it can determine,

Previous | Table of Contents | Next