Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.tools -> Re: Size relationship between redo log files, and rollback segments?

Re: Size relationship between redo log files, and rollback segments?

From: Thomas J. Kyte <tkyte_at_us.oracle.com>
Date: 2000/05/17
Message-ID: <8fuo82$ne1$1@nnrp1.deja.com>#1/1

In article <8fujju$hq4$1_at_nnrp1.deja.com>,   argosy22_at_my-deja.com wrote:
> HI again,
>
> I suppose a good supplement to this would be,
> what should the relationship be between the number
> of rollback segments and redo logs?
>

there really isn't one.

rollback contains undo. we must hold all undo online (available) in an RBS for any transaction that has not committed. You therefore need at least enough rollback to hold the undo for all of your concurrent transactions (you need more to avoid ORA-1555 if you have longish running queries as well). You size and segregate your RBS based on how many concurrent transactions you have and how large they are.

redo contains redo or roll forward information. we do not have to hold all REDO online (it does not have to be available) for open transactions (eg: you can have a transaction generate 100meg of redo but have only 5meg of ONLINE redo logs, we just keep wrapping around). therefore, your redo can be significantly smaller then the size of your transactions. You would choose the size and number of redo logs based on many things (but not based on rollback segment allocations). Some of them are:

o how long you want it to take to recover from a system failure. The size of your online redo logs can be used to bound this recovery time as the most we would have to roll forward through is the size of your online redo log

o how frequently you want checkpoints to fire. we initiate a checkpoint on each log switch.

o how frequently you want archive logs sent to a standby instance.

o you are seeing lots of checkpoint not complete or archive not complete messages in your alert (database halts during these) and wish to get rid of them. you would add more log to accomplish this.

o others..

In short -- no real relationship between RBS and redo as far sizing goes. i have 25, 25meg RBS's and 3 25meg online redo logs. The logs are large enough to take me through my busy times with no "checkpoint not complete" messages and the RBS's are sized for the number of concurrent transactions I have and to avoid any ORA-1555's.

> If I have 5 big rollback segments, how many redo logs
> should I have to handle them?
>
> Thanks again,
>
> Argosy
>
> In article <8fuj2i$h31$1_at_nnrp1.deja.com>,
> argosy22_at_my-deja.com wrote:
> > HI all,
> >
> > What should the relationship in size be
> > between redo log files, and rollback segments?
> >
> > About the same size?
> > Or one larger than the other?
> >
> > Much of the reason for my question is that we are now
> > storing objects (files) in LONG RAW fields in one 7.3.4 database.
> > We quickly got LOTS of archived redo logs.
> >
> > So, I am thinking of resizing the redo logs, but I am wondering
> > to what size? I made a number of rollback segments at about 19.5
 megs
> > each. My initial thought is that the redo logs should be
> > larger than the rollback segments. And, certainly larger than the
> > largest files that might be inserted into the LONG RAW fields.
> > Is this correct?
> >
> > What if we did not have Long Raw fields? Would the size
> > relationship change? What would it be?
> >
> > Thanks,
> >
> > Argosy
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
> >
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>

--
Thomas Kyte (tkyte_at_us.oracle.com) Oracle Service Industries
Howtos and such: http://osi.oracle.com/~tkyte/index.html
Oracle Magazine: http://www.oracle.com/oramag
Opinions are mine and do not necessarily reflect those of Oracle Corp


Sent via Deja.com http://www.deja.com/
Before you buy.
Received on Wed May 17 2000 - 00:00:00 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US