Rollbacksizes

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


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



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, 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 the
ensuing transaction to use the specific segment required with the following command:



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:

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:

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


Rollbacksizes

Recommandé

Recommandé

Contenu connexe

Similaire à Rollbacksizes

Similaire à Rollbacksizes (20)

Plus de oracle documents

Plus de oracle documents (20)

Rollbacksizes