Your SlideShare is downloading. ×
Redonumber
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Redonumber

114
views

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 …

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


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
114
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. The Number of Redo Log Group Administration TipsHow 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). Butthere 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 ofwants and resources by the simple expedient of re-using online redo log groups. You fillup Group 1, you switch to Group 2. When youve filled up Group 2, you switch back toGroup 1, and start over-writing the earlier contents.The trouble starts when you realise what happens to Group 1 when you first switch out ofit 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 theBuffer Cache back onto disk. Once thats completed, the CKPT process updates theheaders of all data files and control files in the database. Until DBWR and CKPT havefinished doing their thing, the redo information in Group 1 is critical for database recoveryin 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", ofcourse) ...and the rules state simply that LGWR is not permitted to move into an ACTIVEgroup, because that would mean over-writing redo information we might still need.And thats the loop-back problem! If LGWR fills up Group 2 really quickly, it stands a goodchance of looping back to Group 1 whilst that group is still ACTIVE. Since its not allowedto do that, it simply hangs, waiting for the status to change to INACTIVE, at which point itwill resume its work automatically. If LGWR hangs, so do all your Users. Thats not aparticularly good look! You can diagnose that its happened because your Alert Log willcontain references to "Thread 1 unable to advance to log sequence 592 - checkpointincomplete". 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 Group1. So why not switch on to Group 3 instead? In fact, why not keep switching on toadditional groups until Group 1 has had ample time to become INACTIVE (i.e., theres beenample time for the checkpoint to complete)? And thats exactly the right response. Youhave as many additional groups as are needed to allow the original checkpoint to complete,so that when the loop back happens, theres no problem.Notice, incidentally, that size has nothing to do with this particular issue. Huge logs mighttake longer to fill up, and hence to switch. But then the checkpoint for a huge log is itselfhuge and takes ages to finish, so what you gain on the swings you most definititely lose onthe roundabouts.Copyright © Howard Rogers 2001 10/17/2001 Page 1 of 2
  • 2. The Number of Redo Log Group Administration TipsI havent mentioned one further complication: ARCH. If you are running your database inarchivelog mode, then at every log switch not only do we have to checkpoint the log in theway Ive described earlier, but ARCH also has to take a copy of the log file being switchedaway from. Copying takes time -and the log remains ACTIVE until the copy hascompleted... which means the LGWR hang at a log switch can happen either because theCheckpoints not complete or because ARCH hasnt finished doing its thing. In either case,the cure as already described -add more log groups so that you arent trying to switch backto 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 logas LGWR took to fill it in the first place, and that usually means you want to start adatabase with at least 3 or 4 log groups. Then its all just a question of monitoring theAlert Log to see whether theres a need to add extra groups, and whether such additionsare sufficient in themselves to cure the loop-back problem (you’ll see messages aboutbeing ‘unable to advance to log sequence xxx’ if you get it wrong).Copyright © Howard Rogers 2001 10/17/2001 Page 2 of 2