Rollback Segments : How many and of what size?

Administration Tips

How many Rollback Segments do I need? And of what size?

Rollback segments are used to store the before-image of every transaction, so the number of segments depends on the number of concurrent transactions, and the size of them depends on the aggregate size of concurrent transactions. As a general rule of thumb, in an OLTP environment, Oracle suggests 1 rollback segment per 4 concurrent transactions (perhaps degrading that ratio gradually down to 1 per 10). Each segment would be created at a size that can comfortably fit those 4 concurrent transactions. All well and good, but how do you determine the number of concurrent transactions at any one time? The simplest approach is to query V$TRANSACTION: SQL>
SELECT COUNT(*), SUM(USED_UBLK) FROM V$TRANSACTION;

COUNT(*) SUM(USED_UBLK) ---------- -------------30 1016 This shows that thirty transactions are currently pending, and in total, they are using 1016 blocks from the existing rollback segments (that's 8.3Mb of rolback). Using the "1 per 4" rule, we ought to create at least 8 rollback segments to accomodate these thirty transactions -and given that they generate 8Mb of rollback in total, each one should be around 1Mb in size. Of course, this sort of thing only works if you query V$TRANSACTION during peak periods, and when the figures you obtain are likely to be the maximum possible values. That means you need to keep re-testing throughout the day, and pick the worst-case scenario as your sizing guide. An alternative way to get the number of concurrent transactions is to issue this query:
SELECT

FROM V$RESOURCE_LIMIT WHERE RESOURCE_NAME='TRANSACTIONS';

...and you'll get a report like this: RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION ------------------------------ ------------------- --------------TRANSACTIONS 2 5
Copyright Howard Rogers 2001 10/18/2001 Page 1 of 4

Rollback Segments : How many and of what size?

Administration Tips

...which shows the maximum number of concurrent transactions ever encountered during the lifetime of the Instance (the view is re-set when the Instance is bounced). It of course missing the information about the maximum amount of rollback generated in that period, which is unfortunate -and means you will have to resort to the V$TRANSACTION method at some point. Incidentally, when you create multiple rollback segments, it is pointless creating them with different sizes: the mechanism Oracle uses to assign new transactions to a particular rollback segment means that, over time, they will all tend to become the same size anyway. They might as well start off that way, therefore. Once you've created your rollback segments, you can use another view to determine whether you managed to get the sizings about right: V$ROLLSTAT: SQL>
SELECT USN, EXTENTS, RSSIZE,HWMSIZE,SHRINKS,WRITES,WRAPS,EXTENDS FROM

V$ROLLSTAT;

USN EXTENTS RSSIZE HWMSIZE SHRINKS WRITES WRAPS EXTENDS ----- ---------- ---------- ---------- ---------- ---------- ---------- ---------0 7 425984 425984 0 7140 0 0 1 2 126976 126976 0 11472 0 0 2 2 126976 126976 0 12762 0 0 3 2 126976 126976 0 28406 1 0 4 2 126976 126976 0 15726 1 0 5 2 126976 126976 0 10324 0 0 6 8 520192 520192 0 429612 7 6 7 2 126976 126976 0 17288 1 0 8 2 126976 126976 0 21782 0 0 9 2 126976 126976 0 16482 1 0 10 2 126976 126976 0 7584 0 0

This shows us each rollback segment (rather confusingly listed as an 'undo segment', hence the 'undo segment number', or USN, column), it's current size in extents and bytes ('rssize'), and the maximum size it has ever grown to in the past ('hwmsize'). Ideally, you wouldn't want to see a HWMSIZE much bigger than its current RSSIZE, because that would indicate that the segment has undergone growth and shrinkage at some time in the past, and both growth and shrinkage affect overall database performance. The number of times a segment has undergone growth is shown in the EXTENDS column. The number of times it's shrunk is shown in the SHRINKS column. You want both of those to be as low as possible (ideally, zero). Incidentally, the above report also shows a column called 'WRAPS'. The myth is that this indicates when a rollback segment has been filled completely, and has 'wrapped around' back into the first extent. It doesn't. It's actually a count of the number of times the rollback moves from any extent to another. (As proof, if you take the total amount of
Copyright Howard Rogers 2001 10/18/2001 Page 2 of 4

Rollback Segments : How many and of what size?

Administration Tips

rollback written -the WRITES column, and divide by the number of WRAPS, you should come out to something very close to the extent size. From the above report, for segment number 6, the value of WRITES/WRAPS is 429,612 7 = 61373ish (ie, around 64K). For the same segment, the actual size (RSSIZE) divided by the number of extents is 520,192 8 = 65024 bytes (ie, around 64K)). When you create your segments, don't bother following Oracle's printed advice that they should have a MINEXTENTS of 20. This is a daft throw-back to the eerie Oracle 6 days when different transactions were not allowed to use the same extents. Naturally, therefore, to support a decent number of concurrent transactions, you had to have a lot of extents. Since the 'no sharing extents' rule was abolished in Oracle 7 (transactions now simply can't share blocks), there's really no point in having more than about half a dozen extents, provided they are of a sufficient size to accomodate all the rollback that your transactions are going to throw at them. Also try and ignore the awful advice about setting OPTIMAL. This is one of those "features" designed to come to the rescue of DBAs who can't be bothered to size their rollback segments properly to begin with. As a transaction wraps into the next extent, the rollback segment can determine whether it has grown bigger than its "optimal" size, and automatically shrink to something closer to that optimal setting if it has. It's a disastrous idea for performance, since shrinks at the best of times are relatively expensive things and doing it whilst a transaction is trying to write its rollback is just about the worst time to pick! Rather than use the automatic shrinkage mechanism, if your rollback segment balloons in size, consider whether that is because you sized it too small in the first place (in which case, drop it and re-create it at a more appropriate size), or whether it was just an abberation caused by an unusual transactional load. If it was a one-off abberation, rather than rely on an expensive automatic shrink, use O/S scheduling tools to fire off the command
ALTER ROLLBACK SEGMENT SEGMENT_NAME SHRINK TO

50M;

(...or whatever you determine is its 'usual' size) to shrink it back down at a time of your own choosing (preferably something like 2 o'clock in the morning). Finally, if your application regularly, but infrequently, runs one or two huge batch transactions (say, at month-end), consider creating one or two specific rollback segments sized specifically to house the entire rollback generated by those large transactions. You'll probably want to keep them OFFLINE until they are specifically needed (otherwise, normally-sized transactions will start to use them, and potentially upset the even, noncontending, distribution of transactions amongst your regular rollback segments). Then (if you can) re-code your application to bring these specific segments online, and direct the ensuing transaction to use the specific segment required with the following command:

Copyright Howard Rogers 2001

10/18/2001

Page 3 of 4

Rollback Segments : How many and of what size?

Administration Tips

SET TRANSACTION USE ROLLBACK SEGMENT

BLAH;

That command must be the first line of a transaction -and a transaction ends with a commit or rollback. That means the following won't work:
SET TRANSACTION USE ROLLBACK SEGMENT UPDATE EMP SET COMMIT; UPDATE ORDERS SET...;

BLAH;

....;

Whilst the update to emp will use the BLAH rollback segment, the update to the orders table will revert to using the default Oracle assignment mechanism ("which of my segments has the fewest number of active transactions"), and which rollback segment it then uses is entirely in the lap of the gods. To get both using the BLAH segment, you'd have to code it as:
SET TRANSACTION USE ROLLBACK SEGMENT UPDATE EMP SET UPDATE ORDERS COMMIT;

BLAH;

....; SET...;

If you can't re-code the application to direct a specific transaction to a specific rollback segment in this way, you'll have to develop some script which is run immediately prior to beginning the transaction. That script needs to offline all "normal" rollback segments, and bring the large ones on-line. When the transaction then starts, it will use the large segment since that's the only one that's online and available for use. As soon as the transaction starts, the normal segments can be put back on line.

Copyright Howard Rogers 2001

10/18/2001

Page 4 of 4