Skip navigation.

Michael Dinh

Syndicate content Thinking Out Loud
Michael T. Dinh, Oracle DBA
Updated: 10 hours 9 min ago

RMAN Pet Peeves

Sat, 2014-08-02 12:38

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?


Create Physical Standby Database using RMAN Restore

Mon, 2014-07-14 21:19

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>