Forum Stats

  • 3,758,216 Users
  • 2,251,355 Discussions
  • 7,870,114 Comments

Discussions

What are the cons to sizing online logs file 10g?

What are the cons to sizing online logs file 10g?

Tagged:

Answers

  • EdStevens
    EdStevens Member Posts: 28,462 Gold Crown

    As opposed to what? Not sizing them?


    The biggest "con" is not the sizeing of the online redo logs, but in this part of your question:

    10g

    Premier support ended Jul 2010

    Extended support ended Jul 2013

    So if you are still running 10g, you've got far bigger problems than the size of your redologs.

  • user12243018
    user12243018 Member Posts: 6 Blue Ribbon

    Thanks for your response and sorry, i meant 10gb size for an online redolog. I was just wondering if that large size is ok from the performance point of view.

    One thing i can think of is instance recovry may take longer. I just wanted to do if there is a solution out there for those who choose size their online redologs to 10gb and beyond.

  • EdStevens
    EdStevens Member Posts: 28,462 Gold Crown

    OK, so what are the 'cons' to sizing them at 10gb ... vs. what? Sizing them smaller? Larger?

    If you are concerned about the time it takes to process the online redo during a recovery, you need to consider the total amount of redo. That is the size of the individual log groups times the number of log groups.

    I would be less concerned about the impact on database/instance recovery as I would having them sized too small, thus creating more waits on log switches. Conventional wisdom says you should aim for one log switch every 20 minutes, during 'typical' transaction load. How often do you expect to be processing them in a recovery situation? What is your service level agreement on down time during database recovery.

    If you really think a 10gb redo log is going to cause a serious impact on recovery, run test. You don't have to do a full database recovery, just a crash recovery to process the redo. Set up your db with the desired redo size and number of log groups. Kick off a job to run transactions until all log groups have been filled - A single UPDATE in a loop will do it. Then do a SHUTDOWN ABORT followed by a STARTUP.