Data Guard - Rename ASM DB Directory, Storage, DISK

Objective: To rename Automatic Storage Management (ASM) Database Directory, Storage and DISK when Dataguard is actively used.  The purpose of this is so that after migrating to Exadata servers the new primary will have the original sub directory structure that the old primary had.

Applies to RAC ASM, Engineering Systems (Exadata X2, X3) and other Architectures where ASM is at use.

Solution:

Couple of suggestions.

First approach is takes simple effort when compared to the later.

1. Do the migration to the new Exadata Standby servers first using the standby db_unique_name as you normally would.  Switch over to it as the new primary and when ready break the association to the old primary database which is currently the standby.  Then build a new standby in the Exadata primary servers where db_unique_name = db_name for the new primary in the Exadata standby servers.  Then do a switch over so that the primary database has db_unique_name = db_name and the standby has db_name and db_unique_name with different values.

This approach allows you to use Data Guard Broker and all Data Guard functions as you normally would.

2. Build a standby in the new primary Exadata servers for the migration without setting db_unique_name at all.  Then the original none Exadata primary with have db_unique_name defaulting to db_name and so will the standby.  This means you will not use Data Guard Broker because it requires db_unique_name and must do switch overs manually in Sqlplus.

Therefore your parameters would be set as follows.

Primary:

db_name =   PROD
db_unique_name is not set, so leave it out of the pfile/spfile
log_archive_dest_2 = 'service = standby ASYNC valid_for = (ONLINE_LOGFILES, PRIMARY_ROLE)'  <--  and db_unique_name is not used in this parameter.
fal_server = standby

If you are not using any references to db_unique_name do not set log_archive_config at all.   When you do not set log_archive_config it will not allow you to set db_unique_name in the log_archive_dest_2 parameter.

Standby:

db_name =   PROD
db_unique_name is not set, so leave it out of the pfile/spfile
log_archive_dest_2 = 'primary = standby ASYNC valid_for = (ONLINE_LOGFILES, PRIMARY_ROLE)'  <--  and db_unique_name is not used in this parameter.
fal_server = primary

If you are not using any references to db_unique_name do not set log_archive_config at all.   When you do not set log_archive_config it will not allow you to set db_unique_name in the log_archive_dest_2 parameter.

Log shipping to the standby works fine.  Some times if an archive is not received in the standby the Fetch Archive Log (FAL) GAP processing does not fetch the missing redo log though.  So worst case you have to do some manual GAP resolution by copying a missing archive to the standby and register it.

alter database register logfile ' full path file name ' ;

Option 1: 

For example;

primary db_unique_name PROD

standby db_unique_name PRODDG

1.  Create a standby for the existing primary database (to be migrated) on the standby Exadata servers using db_unique_name PRODDG.  Create the broker configuration. 

The storage for the standby will be in +DISKGROUP/PRODDG   sub directory

2. Switch over to the new Exadata standby as the primary database

3. When ready to disconnect from the old primary (current standby) remove it from the broker configuration and disconnect it.  You now have standalone primary database in Exadata.  

The storage for this new primary will be in +DISKGROUP/PRODDG   sub directory

4. Create a standby database using db_unique_name PROD in the Exadata primary database servers. 

The storage for the standby will be in +DISKGROUP/PROD  sub directory

   

5. Add this new Exadata standby to the broker configuration.

6. Do the swichover to the new Exadata standby as the primary database. 

Now the end result is Primary Database is in the Exadata Primary servers and the storage for Primary 

will be in +DISKGROUP/PROD  sub directory

The standby will be in the Exadata standby servers and the storage for it will be in the 

+DISKGROUP/PRODDG  sub directory

This approach is better because you can use broker to help manage.  And you get the standby built in the process.  Unless there is some reason you cannot run the Primary in the Disaster recovery (DR) site this is the best choice. 

Option 2: 

The second option is considered a workaround and should also work fine.

But may take some manual intervention to keep it in sync until you do the switchover to become the primary.

And then may take some manual intervention to keep the old primary (current standby) in sync.

Or it may not give you any problems at all.  There are lot of Businesses that run Data Guard this way. 

Reference:

URL: http://www.oracle.com/technetwork/database/features/availability/exadata-consolidation-522500.pdf
Title: Best Practices For Database Consolidation On Exadata Database Machine, An Oracle White Paper, May 2013