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 cant 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 COL NAME FORMAT

A15

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

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 its been active since 10 oclock 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 Ive 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 Users 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 thats 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 Users gone off to do something more exciting instead. Its really only the latter sort of transaction that merits being killed off.
Copyright Howard Rogers 2001 10/17/2001 Page 2 of 2