oracle foreign key primary key constraints performance tuning MTS IOT 9i block size backup rman corrupted column drop rename recovery controlfile backup clone architecture database archives export dump dmp duplicate rows extents segments fragmentation hot cold blobs migration tablespace locally managed redo undo new features rollback ora-1555 shrink free space user password link TNS tnsnames.ora listener java shutdown sequence

1. Size of Redo Logs Administration Tips
How big should Redo Logs be?
This one is easy: "As big as is necessary to get the rate at which you log switch down to a
reasonable rate".
What a 'reasonable rate' is, of course, will depend from site to site and application to
application. The key point is that log switching too frequently is something to be avoided
at all costs.
Why? Because a log switch induces a full checkpoint on the database. That means it kicks
DBWR into action, flushing all dirty buffers related to the just-completed log out to disk,
after which CKPT must update the headers of every single data file and control file with
the latest SCN information. Checkpoints thus represent a huge I/O-fest, and if you value
performance, I/O is something to be avoided at all costs. Accordingly, you don't want to
be checkpointing like crazy -but if you are switching logs ever 4 seconds, you will be.
Since log switches usually only happen when a redo log has been filled, the principle
determinant of when a log switch takes place is the size of the log. Other things being
equal, big logs take longer to fill up than small ones -which means that big logs are slower
to cause checkpoints than small ones.
For this reason, I usually recommend absolutely humungous redo logs (in the order of a
couple of gigabytes big), since they will take for ever to fill up, and log switches (and
hence checkpoints) are a very rare occurrence. In fact, ideally, I wouldn't want to see a
log switch happening during the day at all. Instead, I'd have a cron job (or an AT job, if
you're running NT) which connects to the database at some unearthly hour, like 2 o'clock in
the morning, and issues the command 'ALTER SYSTEM SWITCH LOGFILE;'. That means the
mother-of-all-checkpoints is issued when no-one is around to worry about the performance
hit it causes.
There is, however, one proviso to all this, and it's a serious one. What happens during an
Instance Recovery? Well, SMON at startup notices that there are redo log records from a
time after the time of the last checkpoint, and replays them (i.e., rolls them all forward,
then notices half of them were never committed, and rolls those ones back again). Now
imagine what happens if you are log switching (and hence checkpointing) just once a day,
at 2am, and have an Instance crash the next day, at around 5pm: SMON will have to roll
an entire day's work forward before the database can be opened. That's a serious non-
availability issue.
So, there's a balance to be struck. Huge logs that seldom switch are great for performance,
but mean Instance Recoveries take for ever to complete. Small logs are lousy for
performance, but Instance Recoveries are done in a matter of moments. Somewhere along
that spectrum will be a spot where you can be happy, balancing performance with Instance
Recovery time. In search of that balance, many DBAs have, therefore, developed a
Copyright © Howard Rogers 2001 10/17/2001 Page 1 of 2

2. Size of Redo Logs Administration Tips
general rule of thumb that says 'I will switch logs around once every hour' (or perhaps once
every half hour or so). That's not bad as a rule of thumb, but that's all it is. You need to
find out whether applying such a “rule” degrades performance unacceptably in your
specific environment.
Incidentally: how do you find out how often your log switches are occurring?
Well, there are several ways, but perhaps the easiest is to locate your Alert Log. That will
be sitting in wherever the "background_dump_dest" init.ora parameter is pointing (you
could do a SHOW PARAMETER BACKGROUND to display that). Every log switch is recorded there,
along with the precise time (down to the second) when it happened. The relevant lines
usually read something like "Thread 1 advanced to Log Sequence 391". What you are
looking for is an average rate of switching over the course of a typical working day (you
will, of course, tend to switch rather more often during busy periods, and rather slower
during lunchtimes and at the end of the day).
If you find your average switching rate is too high, you can't correct the problem by
resizing existing logs. You have, instead, to add new logs of a bigger size, and remove the
small logs as a separate exercise. ALTER DATABASE ADD LOGFILE '/PATH/FILENAME' SIZE
500M is the command to add new, single member, groups.
ALTER DATABASE DROP LOGFILE GROUP 1 gets rid of all members of an existing group
(obviously replace the group number there with something appropriate).
Copyright © Howard Rogers 2001 10/17/2001 Page 2 of 2