• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Rollbackblocking
 

Rollbackblocking

on

  • 199 views

oracle foreign key primary key constraints performance tuning MTS IOT 9i block size backup rman corrupted column drop rename recovery controlfile backup clone architecture database archives export ...

oracle foreign key primary key constraints performance tuning MTS IOT 9i block size backup rman corrupted column drop rename recovery controlfile backup clone architecture database archives export dump dmp duplicate rows extents segments fragmentation hot cold blobs migration tablespace locally managed redo undo new features rollback ora-1555 shrink free space user password link TNS tnsnames.ora listener java shutdown sequence

Statistics

Views

Total Views
199
Views on SlideShare
199
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Rollbackblocking Rollbackblocking Document Transcript

    • Blocking Transactions Administration TipsBlocking TransactionsA blocking transaction is any transaction that is left uncommitted or un-rolled back by aUser for a period of time sufficient to prevent the normal re-use of rollback segmentextents.Ordinarily, a rollback segment will place rollback generated by successive transactions inits extents in sequential order. That is, it will fill up the first extent with a variety oftransactions’ rollback, then the second, then the third, and so on. When all extents havebeen filled in this way, it returns to the first one and simply proceeds to overwrite theolder rollback information with new data. However, a rollback segment is never permittedto overwrite the contents of a particular extent if, in any part of that extent, there isrollback belonging to an active transaction (one that is either uncommitted or un-rolledback). This rule is there for what are hopefully obvious reasons!When prevented or blocked from re-using earlier extents in this way, the rollback segmentis forced instead to acquire additional new extents. New transactions may thereforecontinue to house their rollback data in the new extents. But frequent extent acquisitionis 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 toan ever-growing rollback segment just because a User can’t be bothered to finish theirtransaction properly.In fact, rollback segments will continue to acquire extents forever if the blockingtransaction is not committed or rolled back –or at least, they will try to continue acquiringextents until either MAXEXTENTS is reached, or they physically run out of space in thetablespace. 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 ofexisting extents, and thereby induce heavy extent acquisition, is a problem which needs tobe monitored and –where appropriate- dealt with.To detect transactions which have failed to commit or rollback, and which are thus at riskof blocking the normal operation of a rollback segment, issue the following query fromwithin SQL Plus (the first two lines are column formatting options which are not recognisedin other applications, such as Server Manager):COL USERNAME FORMAT A15COL NAME FORMAT A15SELECT S.USERNAME, S.SID, S.SERIAL#, T.START_TIME, N.NAMEFROM V$SESSION S, V$TRANSACTION T, V$ROLLSTAT R, V$ROLLNAME NWHERE S.SADDR=T.SES_ADDRAND R.USN=N.USNAND 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 TipsThat 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. Becauseof 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 lesserdegree of granularity, you could edit the last line.For example, “<(SYSDATE-(0.5/24));” would give you transactions that started overhalf an hour ago. And “<(SYSDATE-(2/24));” would give you those that began more than2 hours ago.Incidentally, note that the START_TIME column from v$transaction, which is being used forthis particular test, is stored as a VARCHAR2 data type, not as a DATE field. That meansthat the formatting string I’ve shown above is fixed. It does not depend on your databaselanguage, 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 aRussian one.Crucially, the report shows you the User involved, and their SID and SERIAL# (the twonumbers which uniquely identify any session in Oracle). The polite approach at this pointis to contact the listed User(s) and ask them to do something with their transactions. Therather more brutal (and some might say “typically DBA”) thing to do would be to issue thefollowing 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 immediatelyterminated, whatever they are doing, and as a result, their transaction gets automaticallyrolled back –thereby ceasing to be a blocking transaction, of course –and permits therollback segment to resume its normal, cyclical re-use of old extents.Be careful though: the report identifies transactions which started a certain period of timeago. A huge batch update that happens to chug along doing its stuff for several hours isjust as likely to appear on the report as a short one that’s been accidentally leftuncommitted for hours. But you really ought to distinguish between big transactions thatjust happen to take a long time to complete, and old transactions which are sitting thereuncommitted 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