log_parallelism & recovery_parallelism
DBAsupport.com Forums - Powered by vBulletin
Results 1 to 10 of 10

Thread: log_parallelism & recovery_parallelism

  1. #1
    Join Date
    Sep 2001
    Location
    Ohio
    Posts
    334

    log_parallelism & recovery_parallelism

    We are getting a new 3rd-party system and the default init parameters specify recovery_parallelism=6 and log_parallelism=6.

    I've never used these parameters, and am not sure if they are necessary. From the docs, it says to increase log_parallelism if you have more than 16 processors. It doesn't really have a recommendation for recovery_parallelism.

    Our system is 9.2.0.5 on AIX 5.2. We only have 4 processors.

    Has anyone used these? Any recommendations?

    Thanks!
    Jodie

  2. #2
    Join Date
    Oct 2002
    Posts
    807
    I typically increase my recovery_parallelism just when setting up a standby, or during major database recovery. Setting it to a higher number (ROT of 2*CPUs) makes a significant difference in the amount of time it takes to recover a database.

  3. #3
    Join Date
    Sep 2001
    Location
    Ohio
    Posts
    334
    Originally posted by Axr2
    I typically increase my recovery_parallelism just when setting up a standby, or during major database recovery. Setting it to a higher number (ROT of 2*CPUs) makes a significant difference in the amount of time it takes to recover a database.
    Is this true with RMAN from tape as well? If I'm restoring with one channel, does it make a difference?

    Thanks for your input.

  4. #4
    Join Date
    Oct 2002
    Posts
    807
    recovery_parallelism has to do with instance recovery. It only comes into play *after* your archivelogs have been transferred to disk. Your TDP settings (or channel) allocation has no bearing on it. You should potentially still be able to leverage the advantages of this parameter.

  5. #5
    Join Date
    Oct 2002
    Posts
    807
    Just curious - but what is this tool that cares about your recovery_parallelism parameter?! I assume it has something to do with recovery.

  6. #6
    Join Date
    Sep 2001
    Location
    Ohio
    Posts
    334
    Originally posted by Axr2
    recovery_parallelism has to do with instance recovery. It only comes into play *after* your archivelogs have been transferred to disk. Your TDP settings (or channel) allocation has no bearing on it. You should potentially still be able to leverage the advantages of this parameter.
    Duh! I'm glad it's Friday. Now that I read the description of the parameter I see that it is for crash/instance recovery. I guess it doesn't hurt to have it set.

    Ever use LOG_PARALLELISM?

  7. #7
    Join Date
    Oct 2002
    Posts
    807
    I've never faced serious redo allocation latching issues. So, I've never had to set log_parallelism higher than the default (1).

  8. #8
    Join Date
    Sep 2001
    Location
    Ohio
    Posts
    334
    Thanks for your insight.

    Have a good weekend.

  9. #9
    Join Date
    May 2000
    Location
    ATLANTA, GA, USA
    Posts
    3,135
    LOG_PARALLELISM aids mostly in a very large OLTP system.
    Orace sets the redo buffers size equivalent to LOG_PARALLELISM times LOG_BUFFERS.

    Tamil

  10. #10
    Join Date
    Oct 2002
    Posts
    807
    Note 147471.1 has some decent info on this.
    Last edited by Axr2; 08-13-2004 at 06:10 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Click Here to Expand Forum to Full Width