Your SlideShare is downloading. ×
Rollback1555s
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Rollback1555s

173

Published on

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

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
173
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. ORA-1555s : Causes and Prevention Administration TipsORA-1555s : Causes and PreventionIn order to understand what a "1555 - Snapshot Too Old" error message really means, andwhat you can do to stop them happening, you first have to know about Oracles model forconcurrent access to the same data, and then how rollback segments actually work.ConcurrencyIf I change Bobs salary from, say, $500 to $700, how do I stop you making a simultaneouschange of his salary to $750? Easy: we take exclusive row-level locks on his record, and ifIve got the lock, your update simply cant proceed until I release it (by committing orrolling back my transaction). Thats one writer blocking another writer.What if all you want to do is to see what Bobs salary is? Does my write block your attemptto read the data? In some databases, it does -but not in Oracle. Oracle does not allowwriters to block readers (nor readers to block writers, actually). You will therefore seeBobs salary in your report -but which one? The old $500, or the new $700?The answer is that you are not allowed to see anything which wasnt fully committed at thetime you started to query the data. Since my update has not yet been committed, youmay therefore only see a salary of $500 for Bob. Even if I committed the record at 10:02,and you started your long-running report at 10:00, you wouldnt be allowed to see the newsalary -because it wasnt there at 10:00 when you started your query.This is what is known as read consistency. Oracle will allow you to read data, consistentat the time your query began.But how does Oracle allow you to see Bob at $500 when my update has actually changedthe data in the Buffer Cache (and conceivably on disk as well, if DBWR has decided to flushin the meantime)? The mechanism it uses is the rollback segment. My update caused abefore image of Bobs salary (in this case, $500) to be written into a rollback segmentblock. When your query is told that it cannot read Bobs current salary (i.e., $700) becauseit was changed after the time you started your report, your server process consults myrollback segment block to obtain the version of Bobs data as it was, consistent with thetime of your query.Preparing a read-consistent image of the data in this way allows you to see all the data yourequested, regardless of what I am doing to it at the same time. And preparing yourread-consistent image of the data requires that you should have access to my rollbackblock.Copyright © Howard Rogers 2001 10/18/2001 Page 1 of 5
  • 2. ORA-1555s : Causes and Prevention Administration TipsHow Rollback Segments WorkRollback Segments are comprised of a number of extents, just like any other segmentwould be. But what distinguishes them from other segments is that when all their currentextents have been used up, instead of acquiring more extents as a table would day, theygo back to the first extent and start over-writing the earlier data.Theyll be prevented from re-using this earlier space if, anywhere within the earliestextents, there is rollback generated by a transaction that is still active (i.e., one thathasnt committed or rolled back yet). In that case, they are said to be blocked from re-using their extents in the normal cyclical manner, and instead have to acquire new extentsto allow new transactions to proceed.But unless there is such a blocking transaction present in the original extent, they reallywill just over-write the contents of those first blocks of the segment, obliterating the old,expired rollback as they do so.The cause of 1555 Snapshot Too Old errorsNow put the two preceding sections together. Your select for Bobs salary must be able toread my rollback block. But if I have committed my transaction, and there are no otheractive transactions in the same extent as my block, there is nothing to stop the rollbacksegment over-writing my rollback block with new rollback data generated by freshtransactions. I certainly dont need the data it contains -Ive long-since finished my update.What weve forgotten about, though, is that your report still needs it.When your report comes to generate its required read-consistent image of Bobs salary, itmay well discover that the rollback information it needs (i.e., from my old rollback block)has been over-written by newer transactions as they re-use rollback blocks.At that point, your report -because it simply cannot now work out what Bobs old salaryused to be- will fail with the infamous ORA-1555 Snapshot Too Old error. It means a blockwhich contained useful data for a report has been obliterated by subsequent transactions.Its somewhat unfortunate that Oracle appears to forget that rollback might have otheruses than just allowing me to roll back my update, but thats the way it is (at least, it isuntil you get to Oracle 9i, where you can instruct Oracle to retain a transactions rollbackfor any specified period of time after that transaction has committed, in case its neededby another User for a read-consistent image).To be fair to Oracle, however, this problem is highly unlikely to arise unless you arerunning large and lengthy reports against a database which is also undergoing manyfrequent, small transactions. In plain English, youll encounter the problem when you tryand make an OLTP database run the sort of reports that belong in a Data Warehouse or DSSCopyright © Howard Rogers 2001 10/18/2001 Page 2 of 5
  • 3. ORA-1555s : Causes and Prevention Administration Tipssystem. Unless you must try and make a gazelle-like database perform as though it were aplodding elephant, the standard advice is: run big reports out of hours, when the OLTPstuff has died down a bit. That way you are unlikely to encounter the 1555 error.Preventions and CuresHowever, if you are forced to run big reports in the middle of an OLTP day, there are anumber of things you can do to try and prevent 1555s. Firstly, the problem really arisesbecause the rollback segment has filled up all its extents, and has therefore returned tothe first one and started re-using it. If instead it had lots of other extents to move intobefore needing to return to the first, the over-writing would take place later -andpotentially, youd be able to get your read-consistent image generated before my block gotre-used.So adding more extents to a rollback segment will, at the very least, reduce the frequencywith which youll encounter 1555s.But actually, given that a proliferation of extents for any segment is not a particularlygood idea, you can achieve the same effect with the same number of extents, providedeach existing extent is bigger. In other words, you can prevent 1555s simply by droppingthe rollback segment, and re-creating it with the same number of extents, just bigger ones.Bigger extents contain more blocks, hence it takes longer for the segment to fill them allup -and hence it takes longer before it has to return to the first extent and start re-using it.That extra time is hopefully all youll need to be able to generate your read-consistentimage.In short, size is everything. Make your rollback segments bigger, either with extra extents,or by using the same number of extents, only bigger ones, and 1555s might be a thing ofthe past.I emphasise the words "might be" there. There are no guarantees. However big yourrollback segments are, its possible that a sudden burst of OLTP-like transactional activitycould waltz its way through your entire rollback segment at a rate of knots -and providedthe extent in which my completed transaction has no other active transactions, well beback in the business of over-writing my old rollback block before you need it.But that last qualifier provides a hint as to how we might absolutely, 100% guarantee neverto have another 1555: if we could somehow arrange for the usual "re-use of earlierrollback" to be prevented, then required rollback could not be over-written. Now re-readthe "How Rollback Segments Work" section, and youll see what Im driving at: blockingtransactions prevent the re-use of old rollback blocks.So a permanent cure would be to arrange for your report to first raise a simple transaction(say, insert into dummy values (1), and to leave that transaction uncommitted. YourCopyright © Howard Rogers 2001 10/18/2001 Page 3 of 5
  • 4. ORA-1555s : Causes and Prevention Administration Tipsreport can then chug along doing its stuff, taking all day if it really wants to: because thatfirst dummy transaction remains active, the extent in which it was placed, and all othersafter it, can never be re-used. When your report has finished its thing, it can simply issuethe command rollback -which then frees the extents it was protecting for normal re-use.But that only happens once your report is safely finished.Theres only one slight drawback to this approach. You cant be sure in which rollbacksegment crucial read-consistent data might have been placed by their parent transactions.If your report is to be guaranteed of success, you need to protect all possible rollbacksegments. That means you need to raise the insert into dummy transaction once for eachrollback segment.Thats not necessarily a problem in itself: but what you need is a way of guaranteeing thateach such dummy insert is placed into a separate rollback segment -and the only way toguarantee that a transaction uses a specific rollback segment is to use the set transactionuse rollback segment BLAH; command. And the problem with that is that it must be thevery first line of the transaction.So? Well, this wouldnt work:SET TRANSACTION USE ROLLBACK SEGMENT 1;INSERT INTO DUMMY...;SET TRANSACTION USE ROLLBACK SEGMENT 2;INSERT INTO DUMMY...;...AND SO ONThis is just one transaction (started by the first insert), since transactions dont end until acommit or a rollback. That means the second set transaction statement is blythelyignored.What all this boils down to is that for this trick to work, you need to create as manysessions as you have rollback segments, each of which simply issues the set transactioncommand for a designated rollback segment, followed by an insert into dummy command.Thats not too bad if you have maybe 10 or 20 rollback segments. But if you have dozensand dozens of them, because of the high number of concurrent transactions you normallyexperience, this is going to be quite a painful technique -the idea of 50 or more sessionsbeing created just to do a one-line insert is a bit suspect, frankly.However, if you need to guarantee no more 1555s, and you havent upgraded to 9i, this isabout the only way you can do it.I take no credit for the technique. Steve Adams devised it, and his web site has therequisite scripts needed to make it work (see: http://www.ixora.com.au/tips/admin/ora-1555.htm for a rather more technical explanation of 1555s, and details of, and scripts toimplement, his workaround).Copyright © Howard Rogers 2001 10/18/2001 Page 4 of 5
  • 5. ORA-1555s : Causes and Prevention Administration TipsIf Steves technique sounds too awkward to implement, then the best you can do is try tominimise the chances of 1555s as already described: make your segments larger, and avoidusing OPTIMAL (which is a bad idea anyway), as OPTIMAL is designed to cause rollbacksegments to shrink in size -and as weve already seen, size is the key factor in determininghow often youll encounter 1555s. But best of all, try and do large, long running activitiesduring quiet times wherever possible.---------------------------------------------------Note: 1555s are also very occasionally caused by something called a delayed blockcleanout that can happen even when you are the only person on the database, and theresnot the slightest chance youve overwritten earlier rollback. Its not something youre verylikely to encounter, except if you are performing some very long transactions, and Ivechosen not to discuss it here as a result. Suffice it to say that the size of rollbacksegments is central to this issue, just as it is to the re-use of old rollback described above.If you want more details, see http://home.clara.net/dwotton/dba/snapshot2.htm wherethe issue is explained in some depth.Copyright © Howard Rogers 2001 10/18/2001 Page 5 of 5

×