Oracle - Rollback Sizes

8/6/2019 Oracle - Rollback Sizes

1/4

Rollback Segments : How many and of what size? Administration Tips

Copyright Howard Rogers 2001 10/18/2001 Page 1 of 4

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_UTILIZATIONMAX_UTILIZATION----------------------------------------------------------------

TRANSACTIONS 2 5


2/4



...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 06 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 therollback moves from any extent to another. (As proof, if you take the total amount of


3/4



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 insize, 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 yourown 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, non-

contending, distribution of transactions amongst your regular rollback segments). Then (if

you can) re-code your application to bring these specific segments online, and direct theensuing transaction to use the specific segment required with the following command:


4/4



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 BLAH;UPDATE EMP SET ....;

COMMIT;

UPDATE ORDERS SET...;

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 BLAH;

UPDATE EMP SET ....;

UPDATE ORDERS SET...;

COMMIT;

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 largesegment 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.

Oracle - Rollback Sizes

Documents

Transcript of Oracle - Rollback Sizes