Q1) For RAC would weAfter 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.
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?
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?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.
- Why or why not
- Do you see this functionality in version x?
Q3) Given the 'high availability' concept of our new engineered systems: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]
- 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?Not at the moment.