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 entries=5 force=y
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
2 add logfile thread 2
3 group 4 ('/u03/oracle/10/oradata/MTS10/redo2_01.log’) size 10M,
4 group 5 ('/u03/oracle/10/oradata/MTS10/redo2_02.log’) size 10M,
5 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
2 '/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, MTS10
*.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)
#### 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_server=’hasunclu1/MTS10’
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 in nomounted:
$ 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
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:
srvctl add nodeapps -n stella1 -o /u03/app/oracle/product/10.1.0/db -A 138.1.138.8/255.255.252.0
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> 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:
Perform the Switchover
1. On the standby RAC cluster shutdown all instance but one. In the one remaining standby instance start managed recovery:
SQL> recover managed standby database disconnect;
2. On the primary database issue the commit switchover to standby command.
SQL> alter database commit to switchover to standby;
Note: If the status returns SESSIONS_ACTIVE then you should issue the switchover command using the WITH SESSION SHUTDOWN
clause.
3. Shutdown and restart the former primary as a standby
SQL> shutdown immediate
SQL> startup mount
4. Verify that the physical standby can be converted to the new primary:
SQL> select switchover_status from v$database;
Note: If the status returns SESSIONS_ACTIVE then you should issue the switchover command using the WITH SESSION SHUTDOWN
clause.
5. Convert the physical standby to the new primary:
SQL> alter database commit to switchover to primary;
6. Shutdown and startup the new primary.
SQL> shutdown immediate
SQL> startup
7. Startup the remaining RAC instances on the new primary.
8. Using srvctl change the database role from PHYSICAL_STANDBY to PRIMARY.
srvctl modify database -d MTS10_stella -r PRIMARY
Bookmarks
SQL> select sequence#, first_time, next_time
2 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 to verify the redY.ass=MsoNormal>
SQL> select tablespace_name 2> 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;
|