Re: Which RBS is my Update using ?

Richard Foote wrote:

> Hi Brian,
>
> But the use of OPTIMAL is the issue.
>
> Daniel's methodology is such that he prefers *not* to use the SET
> TRANSACTION USE ROLLBACK SEGMENT large (for the reasons he's stated) and
> *not* to use OPTIMAL (for the potential performance issues of extents being
> deallocated during a transaction).
>
> Paul's methodology is such that he also does *not* want to use OPTIMAL
> because of the possible performance issues but *does* prefer to use SET
> TRANSACTION USE ROLLBACK SEGMENT large for his few but pricey large
> transactions such that the majority of his ordinary small transactions can
> use smaller, non optimal constrained rollback segments.
>
> Note there's another current thread 'Optimal size for rollback' where the
> pros and cons of optimal are being debated.
>
> My methodology is that it depends so I can just sit back and watch the
> battle unfold ;)
>
> Cheers
>
> Richard
> "Brian Peasland" <oracle_dba_at_peasland.com> wrote in message
> news:3D9061BE.B41C13FB_at_peasland.com...
> > > Daniel,
> > >
> > > Why should they all be 1 gig on a read-only database?
> > >
> > > Paul
> >
> > You don't define them *all* to be 1-GB. You only define them to be able
> > to *extend* to 1-GB. Then, make sure you set OPTIMAL so that the one
> > rollback segment that does extend will shrink back to a smaller size.
> > This way, you don't have to set your transaction to use one particular
> > rollback segment. No matter which one it grabs, it has the capability to
> > expand any of the rollback segments to a large enough size.
> >
> > HTH,
> > Brian

Actually I have never said anything about OPTIMAL one way or the other. And I haven't said not to use SET TRANSACTION either. What I have said is that as insurance ... all RBS should be sized to handle the largest transaction so that if for any reason BIG_ROLL is not available the system doesn't crash and burn.

Daniel Morgan Received on Tue Sep 24 2002 - 11:04:35 CDT