Blocking transactions inhibit the re-use of rollback segment extents, leading to performance issues and potential failures when additional space is needed. Administrators can identify these transactions using a specific SQL query to monitor active sessions, which should be managed appropriately. Options to handle blocking transactions include contacting users to resolve their transactions or forcefully terminating their sessions with an ALTER SYSTEM command.

1. Blocking Transactions Administration Tips
Blocking Transactions
A blocking transaction is any transaction that is left uncommitted or un-rolled back by a
User for a period of time sufficient to prevent the normal re-use of rollback segment
extents.
Ordinarily, a rollback segment will place rollback generated by successive transactions in
its extents in sequential order. That is, it will fill up the first extent with a variety of
transactions’ rollback, then the second, then the third, and so on. When all extents have
been filled in this way, it returns to the first one and simply proceeds to overwrite the
older rollback information with new data. However, a rollback segment is never permitted
to overwrite the contents of a particular extent if, in any part of that extent, there is
rollback belonging to an active transaction (one that is either uncommitted or un-rolled
back). This rule is there for what are hopefully obvious reasons!
When prevented or blocked from re-using earlier extents in this way, the rollback segment
is forced instead to acquire additional new extents. New transactions may therefore
continue to house their rollback data in the new extents. But frequent extent acquisition
is usually a bad thing for performance (less so in locally managed tablespace, it is true),
and in any case it is not exactly good practice to start losing large chunks of disk space to
an ever-growing rollback segment just because a User can’t be bothered to finish their
transaction properly.
In fact, rollback segments will continue to acquire extents forever if the blocking
transaction is not committed or rolled back –or at least, they will try to continue acquiring
extents until either MAXEXTENTS is reached, or they physically run out of space in the
tablespace. At that point, the transaction needing the extra rollback space will simply fail.
Therefore the existence of long-standing active transactions which prevent the re-use of
existing extents, and thereby induce heavy extent acquisition, is a problem which needs to
be monitored and –where appropriate- dealt with.
To detect transactions which have failed to commit or rollback, and which are thus at risk
of blocking the normal operation of a rollback segment, issue the following query from
within SQL Plus (the first two lines are column formatting options which are not recognised
in other applications, such as Server Manager):
COL USERNAME FORMAT A15
COL NAME FORMAT A15
SELECT S.USERNAME, S.SID, S.SERIAL#, T.START_TIME, N.NAME
FROM V$SESSION S, V$TRANSACTION T, V$ROLLSTAT R, V$ROLLNAME N
WHERE S.SADDR=T.SES_ADDR
AND R.USN=N.USN
AND TO_DATE(T.START_TIME,’MM/DD/YY HH24:MI:SS’)<(SYSDATE-(1/24));
Copyright © Howard Rogers 2001 10/17/2001 Page 1 of 2

2. Blocking Transactions Administration Tips
That produces a report looking something like this:
USERNAME SID SERIAL# START_TIME NAME
------------- ---------- ---------- ----------------- ---------------
SCOTT 8 12 16/10/01 10:00:42 _SYSSMU2$
… and this shows us that Scott has a transaction still active in the rollback segment called
‘_SYSSMU2$’, and that it’s been active since 10 o’clock on the 16th October 2001. Because
of the last line in the query, the report will only show transactions which are still active,
having started more than an hour ago. If you wished to monitor with a finer or lesser
degree of granularity, you could edit the last line.
For example, “<(SYSDATE-(0.5/24));” would give you transactions that started over
half an hour ago. And “<(SYSDATE-(2/24));” would give you those that began more than
2 hours ago.
Incidentally, note that the START_TIME column from v$transaction, which is being used for
this particular test, is stored as a VARCHAR2 data type, not as a DATE field. That means
that the formatting string I’ve shown above is fixed. It does not depend on your database
language, nor on whatever NLS parameters and variables may be set in your environment.
The above query should work, unchanged, just as well as on a Japanese database as on a
Russian one.
Crucially, the report shows you the User involved, and their SID and SERIAL# (the two
numbers which uniquely identify any session in Oracle). The polite approach at this point
is to contact the listed User(s) and ask them to do something with their transactions. The
rather more brutal (and some might say “typically DBA”) thing to do would be to issue the
following command:
ALTER SYSTEM KILL SESSION ‘8,12’;
… you supply whatever the earlier report identifies as the relevant SID and SERIAL#
numbers in the closing quotes there. This causes that User’s session to be immediately
terminated, whatever they are doing, and as a result, their transaction gets automatically
rolled back –thereby ceasing to be a blocking transaction, of course –and permits the
rollback segment to resume its normal, cyclical re-use of old extents.
Be careful though: the report identifies transactions which started a certain period of time
ago. A huge batch update that happens to chug along doing its stuff for several hours is
just as likely to appear on the report as a short one that’s been accidentally left
uncommitted for hours. But you really ought to distinguish between big transactions that
just happen to take a long time to complete, and old transactions which are sitting there
uncommitted simply because the User’s gone off to do something more exciting instead.
It’s really only the latter sort of transaction that merits being killed off.
Copyright © Howard Rogers 2001 10/17/2001 Page 2 of 2