Do you validate your backup and what command do you use?
Lately, I have been using restore database validate preview summary to kill 2 birds with 1 stone.
The issue is RMAN will skip validation of archived log backupset when archived log exists.
Does this seem wrong to you?
Please take a look at a test case here
What do you think?
Normally, when I create physical standby database, the configuration has the same directory structures and name values as production with the exception of db_unique_name.
But this time was not the case as shown below.
ANGEL:(SYS@xmenstby):PHYSICAL STANDBY> show parameter name NAME TYPE VALUE ------------------------- ----------- ---------------------------------------- cell_offloadgroup_name string db_file_name_convert string /oradata/xmenprod, /oradata/xmenstby db_name string xmenprod db_unique_name string angel_xmenstby global_names boolean FALSE instance_name string xmenstby lock_name_space string log_file_name_convert string /oradata/xmenprod, /oradata/xmenstby processor_group_name string service_names string xmenstby ANGEL:(SYS@xmenstby):PHYSICAL STANDBY>
I have not been accustomed to adding suffixes such as prod, stby, qa, dev, uat, etc… to database name.
Hopefully, when a connection is made to QA server, it’s for a QA database and not PROD.
Enough of the rant, the requirement is to create physical standby with different directory structures and ORACLE_SID at standby site is xmenstby.
The format I have been using is to prefix db_name with closest airport code to the data center to create db_unique_name.
Alternatively is to prefix with hostname.
Active database duplication is not an option because concern it may take a long time.
It was suggested to perform RMAN backup on primary, transfer backup to standby server using multiple scp, and restore database.
Here I go and if you are interested in how this turned out, then please read more about it here
UPDATE: July 18, 2014
If the intention is to know the primary is now a standby and vice versa after a switchover, then naming the db with the environment will achieve this.
DGMGRL> show configuration Configuration - dg_xmen Protection Mode: MaxPerformance Databases: xmenprod - Primary database angel_xmenstby - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS DGMGRL> switchover to angel_xmenstby Performing switchover NOW, please wait... Operation requires a connection to instance "xmenstby" on database "angel_xmenstby" Connecting to instance "xmenstby"... Connected. New primary database "angel_xmenstby" is opening... Operation requires startup of instance "xmenprod" on database "xmenprod" Starting instance "xmenprod"... ORACLE instance started. Database mounted. Switchover succeeded, new primary is "angel_xmenstby" DGMGRL> show configuration verbose Configuration - dg_xmen Protection Mode: MaxPerformance Databases: angel_xmenstby - Primary database xmenprod - Physical standby database Properties: FastStartFailoverThreshold = '30' OperationTimeout = '30' FastStartFailoverLagLimit = '30' CommunicationTimeout = '180' ObserverReconnect = '0' FastStartFailoverAutoReinstate = 'TRUE' FastStartFailoverPmyShutdown = 'TRUE' BystandersFollowRoleChange = 'ALL' ObserverOverride = 'FALSE' ExternalDestination1 = '' ExternalDestination2 = '' PrimaryLostWriteAction = 'CONTINUE' Fast-Start Failover: DISABLED Configuration Status: SUCCESS DGMGRL>