This action might not be possible to undo. Are you sure you want to continue?
When do Rollback Segments shrink?
Rollback segments shrink whenever a transaction crosses an extent boundary, provided that OPTIMAL has been set. Crossing the extent boundary is known as a 'wrap' (erroneously, many think a 'wrap' only occurs when the segment starts re-using its first extent. It doesn't. Any time a new extent starts to be used, that's a wrap). If OPTIMAL has not been set, shrinks will not occur, however many wraps you have. If you think about it, shrinking as a transaction seeks to cross the extent boundary is a ludicrous time to do the deed. There's your transaction, wanting to get on and write its rollback, and suddenly, it has to take time out waiting for the rollback segment to decide which extents are to be de-allocated. Shrinkage also forces DBWR to flush rollback blocks in the Buffer Cache back down to disk -and any time anything induces additional I/O, performance suffers. Therefore, my strong advice has always been: First, size your segments properly in the first place, so that they neither grow nor shrink. Second, if they do inadvertently balloon in size (perhaps because of a blocking transaction, which there's very little you can do to prevent happening), perform a shrink manually, at a time and place of your choosing, instead of relying on the automatic OPTIMAL method firing off in the middle of transactions. To induce a manual shrink, issue the command:
ALTER ROLLBACK SEGMENT BLAH SHRINK TO
(...or whatever size is appropriate for you). The segment might not get all the way down to the specified size (it will never drop extents that contain active rollback -i.e., live transactions- for example), but it will get as close as it can. If that command fires at night when few people are using the system, nobody will notice the performance hit it induces.
Copyright © Howard Rogers 2001
Page 1 of 1