In this Document
  #PURPOSE" style="text-decoration: none; color: rgb(12, 137, 207);">Purpose
  #SCOPE" style="text-decoration: none; color: rgb(12, 137, 207);">Scope and Application
  #BODYTEXT" style="text-decoration: none; color: rgb(12, 137, 207);">Migrating to RAC using Data Guard
     #aref1" style="text-decoration: none; color: rgb(12, 137, 207);">Configure the Primary Database for Data Guard
     #aref2" style="text-decoration: none; color: rgb(12, 137, 207);">Prepare for RAC conversion:
     #aref3" style="text-decoration: none; color: rgb(12, 137, 207);">Create the Standby
     #aref4" style="text-decoration: none; color: rgb(12, 137, 207);">Switchover Production to the new RAC Database
Applies to:

Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 10.2.0.5 - Release: 10.2 to 10.2
Information in this document applies to any platform.
Purpose

The following procedure can be used to quickly and efficiently migrate a non RAC primary database that utilizes a filesystem for datafile storage to a RAC database that utilizes ASM for datafile storage. This procedure creates a RAC standby from a non RAC primary database which can then be used for a role transition. Redo Transport Services are configured to use EZ Connect format for services.
Scope and Application

The example that follows utilizes the following values:

Initial Primary Database:

HOSTNAME
hasunclu1
ORACLE_SID
MTS10
DB_UNIQUE_NAME
MTS10_hasunclu1
SERVICE_NAMES
MTS10

Initial RAC Standby Database:

Node1
HOSTNAME
stella1
ORACLE_SID
MTS101
DB_UNIQUE_NAME
MTS101_stella
SERVICE_NAMES
MTS101, MTS10
INSTANCE_NAME
MTS101
INSTANCE_NUMBER
1
THREAD
1
UNDO_TABLESPACE
UNDOTBS1
Node2
HOSTNAME
stella2
ORACLE_SID
MTS102
DB_UNIQUE_NAME
MTS10_stella
SERVICE_NAMES
MTS102, MTS10
INSTANCE_NAME
MTS102
INSTANCE_NUMBER
2
THREAD
2
UNDO_TABLESPACE
UNDOTBS1





Migrating to RAC using Data Guard

Configure the Primary Database for Data Guard

1. Enable archiving.

If the primary database is not currently in archivelog mode perform the following steps to enable archiving:
SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database archivelog;
SQL> alter database open;

2. Create a password file on the primary database.
To support 10g log transport authentication it is mandatory that every database in a Data Guard configuration utilize a password file. In addition, the sys password must be the same within in the password file for each database. If the primary database does not currently have a password file use the following steps to create one:
$ cd $ORACLE_HOME/dbs
$ orapwd file=orapwOrlando password=oracle

After creating the password file you must take the database to the mount state and set the following parameter:
SQL> alter system set remote_login_passwordfile=exclusive scope=spfile;

3. Enable force logging.
It is a best practice to place the primary database in force logging mode so that all operation are captured in the redo stream. To place the primary database in force logging mode issue the following SQL:
SQL> alter database force logging;

4. Configure the Primary Database Initialization Parameters.

#### Primary Role Parameters ####

db_unique_name=MTS10_hasunclu1
service_names=MTS10
db_file_recovery_dest='/u03/oracle/10/flash_recovery_area'
log_archive_config='dg_config=(MTS10_hasunclu1,MTS10_stella)'
log_archive_dest_2='service=stella1/MTS101 valid_for=(online_logfiles,primary_role) db_unique_name=MTS10_stella'
log_archive_dest_state_2=defer

#### Standby Role Parameters ####

db_file_name_convert=('+DATA/mts10/datafile/','/u03/oracle/10/oradata/MTS10/')
log_file_name_convert=('+DATA/mts10/onlinelog/','/u03/oracle/10/oradata/MTS10/')
standby_file_management=AUTO
fal_server='stella1/MTS101','stella2/MTS102'
fal_client='hasunclu1/MTS10'

Prepare for RAC conversion:

1. Add additional threads of redo and standby redo logs.

Each instance in a RAC database must have it's own thread of redo. Prior to creating the RAC standby and prior to switchover we must create the additional threads of redo.
SQL> alter database
        add logfile thread 2
        group 4 ('/u03/oracle/10/oradata/MTS10/redo2_01.log') size 10M,
        group 5 ('/u03/oracle/10/oradata/MTS10/redo2_02.log') size 10M,
        group 6 ('/u03/oracle/10/oradata/MTS10/redo2_03.log') size 10M;

SQL> alter database enable public thread 2;

2. Add an undo tablespace for each instance.

Each instance in a RAC database must have it's own undo tablespace. Using the following syntax to create a undo tablespace for each instance that you will have:
SQL> create undo tablespace "undotbs2" datafile
         '/u03/oracle/10/oradata/MTS10/undotsb2.dbf' size 200m;

3. Run catclust.sql
To create RAC specific views in preparation for switchover run the catclust.sql script located in $ORACLE_HOME/rdbms/admin on the primary database:
SQL> @?/rdbms/admin/catclust.sql

Create the Standby

1. Create standby initialization parameter files for each instance of the standby RAC database.
On the primary database create a text initialization parameter file from the spfile:
SQL> create pfile from spfile;

Edit the text initialization parameter file to include instance specific parameters as such:
#### Primary Role Parameters ####

*.control_files='+DATA/mts10_stella/controlfile/control01.ctl'
*.db_create_file_dest='+DATA'
*.db_recovery_file_dest='+DATA'
*.cluster_database=true
MTS101.instance_name='MTS101'
MTS102.instance_name='MTS102'
MTS101.instance_number=1
MTS102.instance_number=2
MTS101.thread=1
MTS102.thread=2
MTS101.undo_tablespace='UNDOTBS1'
MTS102.undo_tablespace='UNDOTBS2'
*.db_unique_name=MTS10_stella
*.service_names=MTS101
*.db_recovery_file_dest='+DATA'
*.log_archive_config='dg_config=(MTS10_hasunclu1,MTS10_stella)'
*.log_archive_dest_2='service=hasunclu1/MTS10 valid_for=(online_logfiles,primary_role) db_unique_name=MTS10_hasunclu1'

#### Standby Role Parameters ####

*.db_file_name_convert=('/u03/oracle/10/oradata/mts10/','+data/mts10/datafile/')
*.log_file_name_convert=('/u03/oracle/10/oradata/mts10/','+data/mts10/onlinelog/')
*.standby_file_management=auto
*.fal_server='hasunclu1/MTS10'
MTS101.fal_client='stella1/MTS101'
MTS102.fal_client='stella1/MTS102'
Transfer the modified init.ora to the ORACLE_HOME/dbs directory on each node. Rename the init.ora's to the match the ORACLE_SID.
2. On each standby host, create a password file.
$ orapwd file=orapwMTS101 password=oracle
$ orapwd file=orapwMTS102 password=oracle

3. After setting up the appropriate environment variables, start the standby database instance without mounting the control file.
SQL> startup nomount pfile=?/dbs/initMTS10.ora

4. Perform an RMAN backup of the primary database placing the backup pieces in a location that is accessible from both the primary host as well as the standby hosts.
RMAN> backup device type disk format '/u01/home/mtsmith/%U' database plus archivelog;
RMAN> backup device type disk format '/u01/home/mtsmith/%U'current controlfile for standby;

5. Duplicate the primary database as a standby into the ASM diskgroup. From the standby host on which the standby instance is not mounted:
$ rman target sys/oracle@hasunclu1/MTS10 auxiliary /
RMAN> duplicate target database for standby;

6. Define the new physical RAC standby using srvctl.
As the Oracle user on the standby host:
srvctl add database -d MTS10_stella -o /u03/app/oracle/product/10.1.0/db -r PHYSICAL_STANDBY -s mount
srvctl add instance -d MTS10_stella -i MTS101 -n stella1
srvctl add instance -d MTS10_stella -i MTS102 -n stella2
srvctl add service -d MTS10_stella -s MTS10 -r MTS101,MTS102

As root on the standby host (10.1 only):
srvctl add nodeapps -n stella1 -o /u03/app/oracle/product/10.1.0/db -A x.xx.xxx.xxxx/x.xx.xxx.xxxx # IP/netmask

7. On the primary database enable the previously deferred remote destination.
SQL> alter system set log_archive_dest_state_2=enable scope=both;

8. Place the standby in managed recovery.
SQL> alter database recover managed standby database disconnect;

9. Validate that the standby is correctly applying redo from the primary.
On the standby database, query the V$ARCHIVED_LOG view to identify existing archived redo logs. For example:
SQL> select sequence#, first_time, next_time
        from v$archived_log order by sequence#;

On the primary database, archive the current log using the following SQL statement:
SQL> alter system archive log current;

On the standby database, query the V$ARCHIVED_LOG view again to ensure that the latest log is registered.
SQL> select sequence#, first_time, next_time
          from v$archived_log order by sequence#;

On the standby database find out where the temporary data files should be by querying DBA_TABLESPACES.
SQL> select tablespace_name from dba_tablespaces
           where contents = 'TEMPORARY';

For each tablespace identified above, add a new temporary file to the standby database.
SQL> alter tablespace temp add tempfile size 40m;

Switchover Production to the new RAC Database

When the redo is being shipped from the Primary to your new RAC Standby wait for the standby to be fully synchronized with the Primary database and then perform a switchover to move production to your RAC database. Refer to the MAA paper "Data Guard Switchover and Failover" and the Data Guard Concepts and Administration manual "7.2 Role Transitions Involving Physical Standby Databases" for the details on how to perform the switchover.

In this Document
  #PURPOSE" style="text-decoration: none; color: rgb(12, 137, 207);">Purpose
  #SCOPE" style="text-decoration: none; color: rgb(12, 137, 207);">Scope and Application
  #BODYTEXT" style="text-decoration: none; color: rgb(12, 137, 207);">Migrating to RAC using Data Guard
     #aref1" style="text-decoration: none; color: rgb(12, 137, 207);">Configure the Primary Database for Data Guard
     #aref2" style="text-decoration: none; color: rgb(12, 137, 207);">Prepare for RAC conversion:
     #aref3" style="text-decoration: none; color: rgb(12, 137, 207);">Create the Standby
     #aref4" style="text-decoration: none; color: rgb(12, 137, 207);">Switchover Production to the new RAC Database
Applies to:

Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 10.2.0.5 - Release: 10.2 to 10.2
Information in this document applies to any platform.
Purpose

The following procedure can be used to quickly and efficiently migrate a non RAC primary database that utilizes a filesystem for datafile storage to a RAC database that utilizes ASM for datafile storage. This procedure creates a RAC standby from a non RAC primary database which can then be used for a role transition. Redo Transport Services are configured to use EZ Connect format for services.
Scope and Application

The example that follows utilizes the following values:

Initial Primary Database:

HOSTNAME
hasunclu1
ORACLE_SID
MTS10
DB_UNIQUE_NAME
MTS10_hasunclu1
SERVICE_NAMES
MTS10

Initial RAC Standby Database:

Node1
HOSTNAME
stella1
ORACLE_SID
MTS101
DB_UNIQUE_NAME
MTS101_stella
SERVICE_NAMES
MTS101, MTS10
INSTANCE_NAME
MTS101
INSTANCE_NUMBER
1
THREAD
1
UNDO_TABLESPACE
UNDOTBS1
Node2
HOSTNAME
stella2
ORACLE_SID
MTS102
DB_UNIQUE_NAME
MTS10_stella
SERVICE_NAMES
MTS102, MTS10
INSTANCE_NAME
MTS102
INSTANCE_NUMBER
2
THREAD
2
UNDO_TABLESPACE
UNDOTBS1





Migrating to RAC using Data Guard

Configure the Primary Database for Data Guard

1. Enable archiving.

If the primary database is not currently in archivelog mode perform the following steps to enable archiving:
SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database archivelog;
SQL> alter database open;

2. Create a password file on the primary database.
To support 10g log transport authentication it is mandatory that every database in a Data Guard configuration utilize a password file. In addition, the sys password must be the same within in the password file for each database. If the primary database does not currently have a password file use the following steps to create one:
$ cd $ORACLE_HOME/dbs
$ orapwd file=orapwOrlando password=oracle

After creating the password file you must take the database to the mount state and set the following parameter:
SQL> alter system set remote_login_passwordfile=exclusive scope=spfile;

3. Enable force logging.
It is a best practice to place the primary database in force logging mode so that all operation are captured in the redo stream. To place the primary database in force logging mode issue the following SQL:
SQL> alter database force logging;

4. Configure the Primary Database Initialization Parameters.

#### Primary Role Parameters ####

db_unique_name=MTS10_hasunclu1
service_names=MTS10
db_file_recovery_dest='/u03/oracle/10/flash_recovery_area'
log_archive_config='dg_config=(MTS10_hasunclu1,MTS10_stella)'
log_archive_dest_2='service=stella1/MTS101 valid_for=(online_logfiles,primary_role) db_unique_name=MTS10_stella'
log_archive_dest_state_2=defer

#### Standby Role Parameters ####

db_file_name_convert=('+DATA/mts10/datafile/','/u03/oracle/10/oradata/MTS10/')
log_file_name_convert=('+DATA/mts10/onlinelog/','/u03/oracle/10/oradata/MTS10/')
standby_file_management=AUTO
fal_server='stella1/MTS101','stella2/MTS102'
fal_client='hasunclu1/MTS10'

Prepare for RAC conversion:

1. Add additional threads of redo and standby redo logs.

Each instance in a RAC database must have it's own thread of redo. Prior to creating the RAC standby and prior to switchover we must create the additional threads of redo.
SQL> alter database
        add logfile thread 2
        group 4 ('/u03/oracle/10/oradata/MTS10/redo2_01.log') size 10M,
        group 5 ('/u03/oracle/10/oradata/MTS10/redo2_02.log') size 10M,
        group 6 ('/u03/oracle/10/oradata/MTS10/redo2_03.log') size 10M;

SQL> alter database enable public thread 2;

2. Add an undo tablespace for each instance.

Each instance in a RAC database must have it's own undo tablespace. Using the following syntax to create a undo tablespace for each instance that you will have:
SQL> create undo tablespace "undotbs2" datafile
         '/u03/oracle/10/oradata/MTS10/undotsb2.dbf' size 200m;

3. Run catclust.sql
To create RAC specific views in preparation for switchover run the catclust.sql script located in $ORACLE_HOME/rdbms/admin on the primary database:
SQL> @?/rdbms/admin/catclust.sql

Create the Standby

1. Create standby initialization parameter files for each instance of the standby RAC database.
On the primary database create a text initialization parameter file from the spfile:
SQL> create pfile from spfile;

Edit the text initialization parameter file to include instance specific parameters as such:
#### Primary Role Parameters ####

*.control_files='+DATA/mts10_stella/controlfile/control01.ctl'
*.db_create_file_dest='+DATA'
*.db_recovery_file_dest='+DATA'
*.cluster_database=true
MTS101.instance_name='MTS101'
MTS102.instance_name='MTS102'
MTS101.instance_number=1
MTS102.instance_number=2
MTS101.thread=1
MTS102.thread=2
MTS101.undo_tablespace='UNDOTBS1'
MTS102.undo_tablespace='UNDOTBS2'
*.db_unique_name=MTS10_stella
*.service_names=MTS101
*.db_recovery_file_dest='+DATA'
*.log_archive_config='dg_config=(MTS10_hasunclu1,MTS10_stella)'
*.log_archive_dest_2='service=hasunclu1/MTS10 valid_for=(online_logfiles,primary_role) db_unique_name=MTS10_hasunclu1'

#### Standby Role Parameters ####

*.db_file_name_convert=('/u03/oracle/10/oradata/mts10/','+data/mts10/datafile/')
*.log_file_name_convert=('/u03/oracle/10/oradata/mts10/','+data/mts10/onlinelog/')
*.standby_file_management=auto
*.fal_server='hasunclu1/MTS10'
MTS101.fal_client='stella1/MTS101'
MTS102.fal_client='stella1/MTS102'
Transfer the modified init.ora to the ORACLE_HOME/dbs directory on each node. Rename the init.ora's to the match the ORACLE_SID.
2. On each standby host, create a password file.
$ orapwd file=orapwMTS101 password=oracle
$ orapwd file=orapwMTS102 password=oracle

3. After setting up the appropriate environment variables, start the standby database instance without mounting the control file.
SQL> startup nomount pfile=?/dbs/initMTS10.ora

4. Perform an RMAN backup of the primary database placing the backup pieces in a location that is accessible from both the primary host as well as the standby hosts.
RMAN> backup device type disk format '/u01/home/mtsmith/%U' database plus archivelog;
RMAN> backup device type disk format '/u01/home/mtsmith/%U'current controlfile for standby;

5. Duplicate the primary database as a standby into the ASM diskgroup. From the standby host on which the standby instance is not mounted:
$ rman target sys/oracle@hasunclu1/MTS10 auxiliary /
RMAN> duplicate target database for standby;

6. Define the new physical RAC standby using srvctl.
As the Oracle user on the standby host:
srvctl add database -d MTS10_stella -o /u03/app/oracle/product/10.1.0/db -r PHYSICAL_STANDBY -s mount
srvctl add instance -d MTS10_stella -i MTS101 -n stella1
srvctl add instance -d MTS10_stella -i MTS102 -n stella2
srvctl add service -d MTS10_stella -s MTS10 -r MTS101,MTS102

As root on the standby host (10.1 only):
srvctl add nodeapps -n stella1 -o /u03/app/oracle/product/10.1.0/db -A x.xx.xxx.xxxx/x.xx.xxx.xxxx # IP/netmask

7. On the primary database enable the previously deferred remote destination.
SQL> alter system set log_archive_dest_state_2=enable scope=both;

8. Place the standby in managed recovery.
SQL> alter database recover managed standby database disconnect;

9. Validate that the standby is correctly applying redo from the primary.
On the standby database, query the V$ARCHIVED_LOG view to identify existing archived redo logs. For example:
SQL> select sequence#, first_time, next_time
        from v$archived_log order by sequence#;

On the primary database, archive the current log using the following SQL statement:
SQL> alter system archive log current;

On the standby database, query the V$ARCHIVED_LOG view again to ensure that the latest log is registered.
SQL> select sequence#, first_time, next_time
          from v$archived_log order by sequence#;

On the standby database find out where the temporary data files should be by querying DBA_TABLESPACES.
SQL> select tablespace_name from dba_tablespaces
           where contents = 'TEMPORARY';

For each tablespace identified above, add a new temporary file to the standby database.
SQL> alter tablespace temp add tempfile size 40m;

Switchover Production to the new RAC Database

When the redo is being shipped from the Primary to your new RAC Standby wait for the standby to be fully synchronized with the Primary database and then perform a switchover to move production to your RAC database. Refer to the MAA paper "Data Guard Switchover and Failover" and the Data Guard Concepts and Administration manual "7.2 Role Transitions Involving Physical Standby Databases" for the details on how to perform the switchover.