Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: TRANSACTIONS_PER_ROLLBACK_SEGMENT (the real story)
In article <89o37skkj9a3pqs4gu3ujkbeh0i93dqhpv_at_4ax.com>,
john v <johnvue_at_gte.net> wrote:
> On Tue, 4 Jan 2000 08:00:48 +0100, "Sybrand Bakker"
> <postmaster_at_sybrandb.demon.nl> wrote:
>
> >The real story may be higly misleading...
> >
> >If you have public rollback segments this parameter will determine
(based on
> >the number of processes in init<sid>.ora) how many rollback segments
are
> >brought online.
> >This is, AFAIK, a one-time operation, rollback segments are not added
> >dynamically.
> >Hundred segments is outrageous. Oracle has the 'rule of four' which
means
> >one rollback segment for every four users, with a minumum of four
rollback
> >segments.
> >
>
> I have over 600+ users ... which mathematically works out to 150
> rollback segments. I really didn't need that many so I cut it down to
> 100.
>
> I've never been a big fan of the "divide by four" rule -- I'd rather
> go by # of simultaneous transactions at peak times.
>
Having 100 rbs segments is excessive. If I remember correctly the
Oracle ver 7 documentation specifically mentions not exceeding a
certain number which I think is around 44. I do not remember a limit
being listed in the ver 8 manual but I suspect that it would be the
same.
You should determine your number of rbs segments from your number of simultaneous transactions like you mentioned. Select count(*) from v$transaction several times during peak hours. I bet that your counts will be well below 44, much less 100, and since an rbs segment can handle multiple transactions at a time you should probably consider reducing your number of rbs segments and making your remaining segments bigger since I expect that with 100 of them that they are pretty small.
Just my opinion.
--
Mark D. Powell -- The only advice that counts is the advice that
you follow so follow your own advice --
Sent via Deja.com http://www.deja.com/
Before you buy.
Received on Tue Jan 04 2000 - 09:06:55 CST