Tom,
It does depend on a number of factors. If you have a number of redo logs,
like 10 or more, you can allow a smaller size file as this prevents the database
from running out of on-line redo before arch gets one cleaned out. Sizing the
redo logs is more a matter of how granular do you want things in the event the
server melts down. A smaller file means that there is less unachieved data to
be lost. Larger files cause the opposite. The down side of a small file is the
overhead on the database to 1) archive the log and 2) to perform a checkpoint.
Therefore I recommend a larger file. My smallest redo log is 10M and I do have
one database that runs with 100M redo files. I've even been to a site where 1GB
redo was a requirement to have a minimum of 5 minutes between log switches. A
lot of folks will get wrapped around the flag post on keeping log switches to a
certain minimum time limit. Well, I'll not bash anyone over the head on that
because having a switch too often is not good. But on the other hand telling
finance that we can only recover to last night may not land very well either.
So you really need a working knowledge on the database's purpose. Three of my
DB's have 10 M logs which gives them a 30 minute average switch, but then I use
multiplexed redo with the second set on a separate server just so that in the
event of a meltdown, all of the on-line and off-line logs will be around.
I would seriously recommend you attend the backup and recovery class as they
get into this subject in some detail, where the rubber and the road meet.
Dick Goulet
____________________Reply Separator____________________
Author: "Tom Schruefer" <[EMAIL PROTECTED]>
Date: 12/31/2001 7:20 AM
Here is the background of the stiuation I am facing.
We are piloting a application that uses a hybred store and forward system to
aggregate all of our disparate student data into one central database.
Currently there are 20 schools integrated into the system with another 48 to
go, those 20 schools hold about half of our 46k student population.
The system allows (requires) student demographics to be entered through a
web client, while grades, attendance, health, conduct, etc. are uploaded
over night.
The system comes with the redo log file size set to 5k, which when the users
in the 20 pilot schools get going causes a log switch about every 90
seconds. In my limited, steep learning curve expereince, this does not seem
like a good thing. Add to that, they cancelled the Oracle Tuning class,
which I have to wait until the system is in to take now.
So my questions (that the books don't really seem to want to answer):
How frequently should redo log file switches occur?
How large should my redo logs be?
I am guessing the answer to both of these questions is, It Depends. So my
question really is, how do I determine what the correct settings for my
installation are?
Tom
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Tom Schruefer
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
