Size of Redo Logs Administration Tips

Copyright © Howard Rogers 2001 10/17/2001 Page 1 of 2

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

Size of Redo Logs Administration Tips

Copyright © Howard Rogers 2001 10/17/2001 Page 2 of 2

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).