Re: undo header congestion? (8.0.5)

From: Joel Garry <joel-garry_at_home.com>
Date: 29 Jan 2004 17:24:58 -0800
Message-ID: <91884734.0401291724.48ebdaa7@posting.google.com>

"Richard Foote" <richard.foote_at_bigpond.com> wrote in message news:<RvORb.32341$Wa.4250_at_news-server.bigpond.net.au>...

> "Bjørn Augestad" <boa_at_metasystems.no.spam.to.me> wrote in message
> news:unJRb.31572$BD3.7011381_at_juliett.dax.net...
> >
> > Statspack indicates that 1 or 2 RBS is fine most of the time, but from
> > time to time we spend a lot of time waiting for "undo header".
> >
> > One of the instances is a backend db server for a web site. The load
> > tends to spike a lot during the day/week/year. I'd therefore rather have
> > too many rollback segments than too few, even if it wastes some disk
> > space. We also have issues with e.g. blocking transactions and clients
> > hanging, and I want to be able to rule out RBS shortage as the cause for
> > those problems.
>
> Hi Bjørn
>
> The little point I would make here is that although too few is certainly not
> recommended (and you appear to have to few at the moment if undo header
> waits are causing you performance issues), note that too many can be a
> problem as well. As well as wasting storage, it hurts performance as it's
> likely to increase the number of physical I/Os which is never a good thing.
>

Maybe it's just too late in the day for me to think clearly, but why would there be too many physical I/O's simply from an excess of rollback segs? Won't they just sit there unwanted and lonely? I've never really tried an excess, since I've always run into disk limitations.

> You need the "right" number (and the right size), enough to not cause
> contention, snapshot problems, etc. during peak loads but no more.

And of course, a peak load from the point of view of RBS isn't necessarily maximum transaction volume, although that is what you use for an initial rule of thumb. Another type of peak (well, really more of a width) comes from lengthy transactions requiring RB info to be kept around for a while. Search for ORA-1555 which has been discussed everywhere ad nauseum, and check out the classic Note:45895.1 on metalink. You probably want to think about this before you run lengthy reports on your backend server.

--
@home.com is bogus.
http://www.miami.com/mld/miamiherald/news/breaking_news/7817919.htm

Received on Thu Jan 29 2004 - 19:24:58 CST