Rollbacksizes

283 views

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 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
283
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Rollbacksizes

  1. 1. Rollback Segments : How many and of what size? Administration TipsHow many Rollback Segments do I need?And of what size?Rollback segments are used to store the before-image of every transaction, so the numberof segments depends on the number of concurrent transactions, and the size of themdepends on the aggregate size of concurrent transactions.As a general rule of thumb, in an OLTP environment, Oracle suggests 1 rollback segmentper 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 concurrenttransactions.All well and good, but how do you determine the number of concurrent transactions at anyone time?The simplest approach is to query V$TRANSACTION:SQL> SELECT COUNT(*), SUM(USED_UBLK) FROM V$TRANSACTION; COUNT(*) SUM(USED_UBLK)---------- -------------- 30 1016This shows that thirty transactions are currently pending, and in total, they are using 1016blocks from the existing rollback segments (thats 8.3Mb of rolback).Using the "1 per 4" rule, we ought to create at least 8 rollback segments to accomodatethese thirty transactions -and given that they generate 8Mb of rollback in total, each oneshould 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 meansyou need to keep re-testing throughout the day, and pick the worst-case scenario as yoursizing 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 youll get a report like this:RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION------------------------------ ------------------- ---------------TRANSACTIONS 2 5Copyright © Howard Rogers 2001 10/18/2001 Page 1 of 4
  2. 2. Rollback Segments : How many and of what size? Administration Tips...which shows the maximum number of concurrent transactions ever encountered duringthe lifetime of the Instance (the view is re-set when the Instance is bounced). It of coursemissing 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 atsome point.Incidentally, when you create multiple rollback segments, it is pointless creating themwith different sizes: the mechanism Oracle uses to assign new transactions to a particularrollback segment means that, over time, they will all tend to become the same sizeanyway. They might as well start off that way, therefore.Once youve created your rollback segments, you can use another view to determinewhether you managed to get the sizings about right: V$ROLLSTAT:SQL> SELECT USN, EXTENTS, RSSIZE,HWMSIZE,SHRINKS,WRITES,WRAPS,EXTENDS FROMV$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 0This shows us each rollback segment (rather confusingly listed as an undo segment, hencethe undo segment number, or USN, column), its current size in extents and bytes (rssize),and the maximum size it has ever grown to in the past (hwmsize).Ideally, you wouldnt want to see a HWMSIZE much bigger than its current RSSIZE, becausethat would indicate that the segment has undergone growth and shrinkage at some time inthe past, and both growth and shrinkage affect overall database performance. Thenumber of times a segment has undergone growth is shown in the EXTENDS column. Thenumber of times its shrunk is shown in the SHRINKS column. You want both of those to beas low as possible (ideally, zero).Incidentally, the above report also shows a column called WRAPS. The myth is that thisindicates when a rollback segment has been filled completely, and has wrapped aroundback into the first extent. It doesnt. Its actually a count of the number of times therollback moves from any extent to another. (As proof, if you take the total amount ofCopyright © Howard Rogers 2001 10/18/2001 Page 2 of 4
  3. 3. Rollback Segments : How many and of what size? Administration Tipsrollback written -the WRITES column, and divide by the number of WRAPS, you shouldcome out to something very close to the extent size. From the above report, for segmentnumber 6, the value of WRITES/WRAPS is 429,612 ÷ 7 = 61373ish (ie, around 64K). For thesame 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, dont bother following Oracles printed advice that theyshould have a MINEXTENTS of 20. This is a daft throw-back to the eerie Oracle 6 dayswhen 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 ofextents. Since the no sharing extents rule was abolished in Oracle 7 (transactions nowsimply cant share blocks), theres really no point in having more than about half a dozenextents, provided they are of a sufficient size to accomodate all the rollback that yourtransactions 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 cant be bothered to size their rollbacksegments properly to begin with. As a transaction wraps into the next extent, the rollbacksegment can determine whether it has grown bigger than its "optimal" size, andautomatically shrink to something closer to that optimal setting if it has. Its a disastrousidea 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 timeto pick!Rather than use the automatic shrinkage mechanism, if your rollback segment balloons insize, consider whether that is because you sized it too small in the first place (in whichcase, drop it and re-create it at a more appropriate size), or whether it was just anabberation caused by an unusual transactional load. If it was a one-off abberation, ratherthan rely on an expensive automatic shrink, use O/S scheduling tools to fire off thecommandALTER ROLLBACK SEGMENT SEGMENT_NAME SHRINK TO 50M;(...or whatever you determine is its usual size) to shrink it back down at a time of yourown choosing (preferably something like 2 oclock in the morning).Finally, if your application regularly, but infrequently, runs one or two huge batchtransactions (say, at month-end), consider creating one or two specific rollback segmentssized specifically to house the entire rollback generated by those large transactions. Youllprobably 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 (ifyou can) re-code your application to bring these specific segments online, and direct theensuing transaction to use the specific segment required with the following command:Copyright © Howard Rogers 2001 10/18/2001 Page 3 of 4
  4. 4. Rollback Segments : How many and of what size? Administration TipsSET TRANSACTION USE ROLLBACK SEGMENT BLAH;That command must be the first line of a transaction -and a transaction ends with acommit or rollback. That means the following wont work:SET TRANSACTION USE ROLLBACK SEGMENT BLAH;UPDATE EMP SET ....;COMMIT;UPDATE ORDERS SET...;Whilst the update to emp will use the BLAH rollback segment, the update to the orderstable will revert to using the default Oracle assignment mechanism ("which of my segmentshas the fewest number of active transactions"), and which rollback segment it then uses isentirely in the lap of the gods. To get both using the BLAH segment, youd have to code itas:SET TRANSACTION USE ROLLBACK SEGMENT BLAH;UPDATE EMP SET ....;UPDATE ORDERS SET...;COMMIT;If you cant re-code the application to direct a specific transaction to a specific rollbacksegment in this way, youll have to develop some script which is run immediately prior tobeginning the transaction. That script needs to offline all "normal" rollback segments, andbring the large ones on-line. When the transaction then starts, it will use the largesegment since thats the only one thats online and available for use. As soon as thetransaction starts, the normal segments can be put back on line.Copyright © Howard Rogers 2001 10/18/2001 Page 4 of 4

×