Re: optimal size for rollback

Niall Litchfield wrote:
>
> "Richard Foote" <richard.foote_at_bigpond.com> wrote in message
> news:q9jj9.37911$g9.108570_at_newsfeeds.bigpond.com...
> > Hi Howard and Karen,
>
> > One last point. Note that automatic undo management does extra work 'under
> > the covers' which could be viewed as being sub-optimal. I haven't heard
> many
> > that suggest using manual rollback segments is the way to go in 9i ...
>
> Connor certainly suggested that automatic undo management was
>
> 'basically an OPTIMAL clause
> just under the covers...Its like "Oops, I'm an extent thats 3 seconds
> over the retention limit...bang, I'm outta here"'
>
> which isn't exactly a ringing endorsement...
>
> And I must admit I am still sitting on the fence, at least partly because I
> don't really understand what AUM is actually doing, and partly because
> sufficient equisized public rollback segments have never done me any
> significant harm. Sizing them wrong or leaving a big or small rbs segment
> online when I didn't intend to on the other hand.
>
> --
> Niall Litchfield
> Oracle DBA
> Audit Commission UK
> *****************************************
> Please include version and platform
> and SQL where applicable
> It makes life easier and increases the
> likelihood of a good answer
> ******************************************

True, but I was being a little facetious...

There are some other nice things about smu that simply can't be done trivially in old-style rollback. Adding/removing segs on the fly, but more significantly, extent stealing, ie one segment to another 'ah, you've finished with that extent, I'll nab it'.

My only criticism is basically along the lines of optimal - you don't control *when* the shrink occurs. But...this is *not* to say that shrinking rollback segs is bad - I just like to do it manually at quiet times.

The reason I'm a fan of shrinks (ie as small a rollback seg as possible) as the smaller it is, the higher the chance it will be not be responsible for IO. Less IO = more performance. The risk of this is of course ora-1555, but less face it, if you're code catches -1555, all it need do is close/reopen the cursor.

hth
connor

-- 
==============================
Connor McDonald

http://www.oracledba.co.uk

"Some days you're the pigeon, some days you're the statue..."