Published on

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

  • Be the first to comment

  • Be the first to like this


  1. 1. Size of Redo Logs Administration TipsHow 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 areasonable rate".What a reasonable rate is, of course, will depend from site to site and application toapplication. The key point is that log switching too frequently is something to be avoidedat all costs.Why? Because a log switch induces a full checkpoint on the database. That means it kicksDBWR 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 withthe latest SCN information. Checkpoints thus represent a huge I/O-fest, and if you valueperformance, I/O is something to be avoided at all costs. Accordingly, you dont want tobe 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 principledeterminant of when a log switch takes place is the size of the log. Other things beingequal, big logs take longer to fill up than small ones -which means that big logs are slowerto cause checkpoints than small ones.For this reason, I usually recommend absolutely humungous redo logs (in the order of acouple of gigabytes big), since they will take for ever to fill up, and log switches (andhence checkpoints) are a very rare occurrence. In fact, ideally, I wouldnt want to see alog switch happening during the day at all. Instead, Id have a cron job (or an AT job, ifyoure running NT) which connects to the database at some unearthly hour, like 2 oclock inthe morning, and issues the command ALTER SYSTEM SWITCH LOGFILE;. That means themother-of-all-checkpoints is issued when no-one is around to worry about the performancehit it causes.There is, however, one proviso to all this, and its a serious one. What happens during anInstance Recovery? Well, SMON at startup notices that there are redo log records from atime 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). Nowimagine 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 rollan entire days work forward before the database can be opened. Thats a serious non-availability issue.So, theres 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 forperformance, but Instance Recoveries are done in a matter of moments. Somewhere alongthat spectrum will be a spot where you can be happy, balancing performance with InstanceRecovery time. In search of that balance, many DBAs have, therefore, developed aCopyright © Howard Rogers 2001 10/17/2001 Page 1 of 2
  2. 2. Size of Redo Logs Administration Tipsgeneral rule of thumb that says I will switch logs around once every hour (or perhaps onceevery half hour or so). Thats not bad as a rule of thumb, but thats all it is. You need tofind out whether applying such a “rule” degrades performance unacceptably in yourspecific 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 willbe sitting in wherever the "background_dump_dest" init.ora parameter is pointing (youcould 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 linesusually read something like "Thread 1 advanced to Log Sequence 391". What you arelooking for is an average rate of switching over the course of a typical working day (youwill, of course, tend to switch rather more often during busy periods, and rather slowerduring lunchtimes and at the end of the day).If you find your average switching rate is too high, you cant correct the problem byresizing existing logs. You have, instead, to add new logs of a bigger size, and remove thesmall logs as a separate exercise. ALTER DATABASE ADD LOGFILE /PATH/FILENAME SIZE500M 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