Vous êtes sur la page 1sur 2

The Number of Redo Log Group

Administration Tips

How many Redo Log Groups should I have?


Answer: "As many as are necessary to prevent the loop-back problem". OK -what the hell is the "loop-back problem", then?! There are a finite number of online redo log groups (minimum is 2, maximum is 32). But there is a practically infinite amount of redo generated during the lifetime of a database, because Users just keep on starting new transactions. Oracle solves that mismatch of wants and resources by the simple expedient of re-using online redo log groups. You fill up Group 1, you switch to Group 2. When you've filled up Group 2, you switch back to Group 1, and start over-writing the earlier contents. The trouble starts when you realise what happens to Group 1 when you first switch out of it into Group 2. Oracle uses that log switch as a signal to begin checkpointing the database. All the dirty buffers for which Group 1 contains redo are flushed, by DBWR, out of the Buffer Cache back onto disk. Once that's completed, the CKPT process updates the headers of all data files and control files in the database. Until DBWR and CKPT have finished doing their thing, the redo information in Group 1 is critical for database recovery in the event of Instance failure. That means it cannot be allowed to be over-written. Technically, it means that Group 1 has a status of "ACTIVE" (Group 2 is "Current", of course) ...and the rules state simply that LGWR is not permitted to move into an ACTIVE group, because that would mean over-writing redo information we might still need. And that's the loop-back problem! If LGWR fills up Group 2 really quickly, it stands a good chance of looping back to Group 1 whilst that group is still ACTIVE. Since it's not allowed to do that, it simply hangs, waiting for the status to change to INACTIVE, at which point it will resume its work automatically. If LGWR hangs, so do all your Users. That's not a particularly good look! You can diagnose that it's happened because your Alert Log will contain references to "Thread 1 unable to advance to log sequence 592 - checkpoint incomplete". There are other ways of telling, of course -but the Alert Log is the simplest. The cure? Well, if Group 2 has been filled up, the problem is trying to loop back to Group 1. So why not switch on to Group 3 instead? In fact, why not keep switching on to additional groups until Group 1 has had ample time to become INACTIVE (i.e., there's been ample time for the checkpoint to complete)? And that's exactly the right response. You have as many additional groups as are needed to allow the original checkpoint to complete, so that when the loop back happens, there's no problem. Notice, incidentally, that size has nothing to do with this particular issue. Huge logs might take longer to fill up, and hence to switch. But then the checkpoint for a huge log is itself huge and takes ages to finish, so what you gain on the swings you most definititely lose on the roundabouts.
Page 1 of 2

Copyright Howard Rogers 2001

10/17/2001

The Number of Redo Log Group

Administration Tips

I haven't mentioned one further complication: ARCH. If you are running your database in archivelog mode, then at every log switch not only do we have to checkpoint the log in the way I've described earlier, but ARCH also has to take a copy of the log file being switched away from. Copying takes time -and the log remains ACTIVE until the copy has completed... which means the 'LGWR hang' at a log switch can happen either because the Checkpoint's not complete or because ARCH hasn't finished doing its thing. In either case, the cure as already described -add more log groups so that you aren't trying to switch back to the first group before ARCH or CKPT has finished with it. Incidentally, as a general rule of thumb, ARCH takes three times as long to copy a filled log as LGWR took to fill it in the first place, and that usually means you want to start a database with at least 3 or 4 log groups. Then it's all just a question of monitoring the Alert Log to see whether there's a need to add extra groups, and whether such additions are sufficient in themselves to cure the loop-back problem (youll see messages about being unable to advance to log sequence xxx if you get it wrong).

Copyright Howard Rogers 2001

10/17/2001

Page 2 of 2

Vous aimerez peut-être aussi