1 Reply Latest reply: Feb 8, 2012 1:37 AM by wzhang-Oracle RSS

    Implications of using DMU with RAC?

    clucas-Oracle
      Neat tool:

      I probably missed this but I did not notice any explicit steps for RAC configurations however:
      - This inquiiry is due to an email post regarding converting an Exadata database from WE8* to AL32UTF8

      Exadata has no impact (it is just an engineered database machine)
      however, most all Exadata machines use RAC (heavily) which are commonly 4 up to 8 nodes.

      Per previous experience we used to perform the migration on a single node with the other
      instances down

      a. shutdown the entire RAC database and work with a single node (e.g. Node #1)
      b. startup restrict for 'Node#1'
      c. perform conversion steps (iDMU objectives: identify, cleanse, convert..etc are much more robust, but still essentially the same outcomes)
      d....

      Questions
      =============

      Q1) For RAC would we

      d. ...shutdown instance #1 while in restrict to restart with new charset / DD (?)

      e. Only then, startup other instances to read the New character set and DD values


      Can you please confirm the above as correct or not?


      MORE
      --------
      Other similar questions on this topic:

      Is there a specific note or documentation reference that I missed that might answer the following also?


      Q2) Can DMU use a Rolling method for RAC?
      - Why or why not
      - Do you see this functionality in version x?


      Q3) Given the 'high availability' concept of our new engineered systems:
      - What is the best practices for maximum availability during charset conversion?
      - What is the fastest / suggested method for converting RAC databases where the shortest conversion time is the major factor?

      Q4) Do we have a note / case study for RAC + DMU?

      Thanks!

      Chuck

      Edited by: clucas on Feb 7, 2012 8:54 AM
        • 1. Re: Implications of using DMU with RAC?
          wzhang-Oracle
          Q1) For RAC would we

          d. ...shutdown instance #1 while in restrict to restart with new charset / DD (?)

          e. Only then, startup other instances to read the New character set and DD values


          Can you please confirm the above as correct or not?


          MORE
          --------
          Other similar questions on this topic:

          Is there a specific note or documentation reference that I missed that might answer the following also?
          After the Unicode conversion of instance #1 is completed successfully, you should be able to start up the other instances which will read the new character set information from the updated control files. Instance #1 must be restarted but it doesn't have to be done first.

          >
          Q2) Can DMU use a Rolling method for RAC?
          - Why or why not
          - Do you see this functionality in version x?
          Can you clarify what you mean by a rolling method for RAC? The Unicode migration process converts the character data in a database to Unicode. RAC has multiple instances running on different nodes but they all access a single database.

          >
          Q3) Given the 'high availability' concept of our new engineered systems:
          - What is the best practices for maximum availability during charset conversion?
          - What is the fastest / suggested method for converting RAC databases where the shortest conversion time is the major factor?
          You may want to take a look at [near-zero-downtime migration with DMU and Streams|http://www.oracle.com/technetwork/database/globalization/dmu/learnmore/nzd-migration-524223.html]
          Q4) Do we have a note / case study for RAC + DMU?
          Not at the moment.