Wednesday, May 1, 2013

11GR2: DUPLICATE DATABASE USING RMAN WITHOUT CONNECTING TO TARGET (PRODUCTION)


11GR2: DUPLICATE DATABASE USING RMAN WITHOUT CONNECTING TO TARGET (PRODUCTION)
11gR2 has excellent feature to duplicate production database without connecting to Production database. This reduces risk touching production accidently as well as eliminates impacting production. Prior to 11gR2, we had to take backup of production, mount backups on Auxillary server (where prod will be duplicated) and run duplicate database rman command connecting to target (production) database. 11gR2 makes this task very easy by duplicating database without connecting to production database.
Step 1 – Backup production database.

RMAN> Configure controlfile autobackup on;
RMAN> backup database plus archivelog;

Step 2 – Copy backups to Auxillary server
This step can be done by
(a)    mounting production backup filesystem to Auxillary server OR
(b)   scp backupsets from production to Auxillary instance
We will be using our backup location as /rman_backup

Step 3 – Prepare Auxillary server instance
Create init.ora for Auxillary instance with just 1 parameter db_name as below.
db_name=CLONEDB1

Step 4 – Start Auxillary instance
$ export ORACLE_SID=CLONEDB1
$ sqlplus "/ as sysdba"
SQL> startup nomount;


Step 5 – Using RMAN connect to Auxillary instance and duplicate database
$ export ORACLE_SID=CLONEDB1
RMAN> rman Auxillary /
RMAN>
Duplicate database to CLONEDB1
spfile
set control_files=’+DGCLONEDB’
set db_file_name_convert=’+DGPRODDB’,’+DGCLONEDB′
set LOG_FILE_NAME_CONVERT=’+DGPRODDB’,’+DGCLONEDB′

set db_create_online_log_dest_1=’+DGCLONEDB′
set db_create_online_log_dest_2=’+DGCLONEDB′ 
set db_recovery_file_dest=’+DGCLONEDB_FRA’
set diagnostic_dest=’
/ora/app/oracle’
backup location ’/rman_backup/’
NOFILENAMECHECK;

Friday, April 5, 2013

Grid Control : The database target is currently unavailable. The state of the components are listed below

Problem

Applied patch on 1 instance of 4-node RAC database. Patch was successful.
When logged into grid control, It shows status of database instance up but no details in it. Message "The database target is currently unavailable. The state of the components are listed below" is displayed.
All other 3 instances(where no patch applied) were fine.

Actions


emctl status agent
--It shows "Agent is Running and Ready"

emctl upload agent
--It shows "EMD upload completed successfully" and 0 pending uploads

Solution

emctl clearstate agent
Message "EMD clearstate completed successfully" will be displayed

Verify in Grid Control. Problem resolved!


Thursday, April 4, 2013

DataGuard - Warning: ORA-16714: the value of property ArchiveLagTarget is inconsistent with the database setting

Problem
Warning: ORA-16714 shown in "Show database tprisby" dgmgrl command

Action
Find the reason for warnings

Step 1

DGMGRL> show database verbose tprisby

Database - tprisby

  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag:   0 seconds
  Apply Lag:       0 seconds
  Real Time Query: OFF
  Instance(s):
    tprisby1 (apply instance)
    tprisby2
      Warning: ORA-16714: the value of property ArchiveLagTarget is inconsistent with the database setting
      Warning: ORA-16714: the value of property LogArchiveMaxProcesses is inconsistent with the database setting
      Warning: ORA-16714: the value of property LogArchiveMinSucceedDest is inconsistent with the database setting


  Properties:
    DGConnectIdentifier             = 'tprisby'
    ObserverConnectIdentifier       = ''
    LogXptMode                      = 'ASYNC'
    DelayMins                       = '0'
    Binding                         = 'OPTIONAL'
    MaxFailure                      = '0'
    MaxConnections                  = '1'
    ReopenSecs                      = '300'
    NetTimeout                      = '30'
    RedoCompression                 = 'DISABLE'
    LogShipping                     = 'ON'
    PreferredApplyInstance          = ''
    ApplyInstanceTimeout            = '0'
    ApplyParallel                   = 'AUTO'
    StandbyFileManagement           = 'AUTO'
    ArchiveLagTarget                = '0'
    LogArchiveMaxProcesses          = '4'
    LogArchiveMinSucceedDest        = '1'
    DbFileNameConvert               = '+PSSDEV, +CSPDEVD01, +PSSFLASH, +CSPDEVF1'
    LogFileNameConvert              = '+PSSDEV, +CSPDEVD01, +PSSFLASH, +CSPDEVF1'
    FastStartFailoverTarget         = ''
    InconsistentProperties          = '(monitor)'
    InconsistentLogXptProps         = '(monitor)'
    SendQEntries                    = '(monitor)'
    LogXptStatus                    = '(monitor)'
    RecvQEntries                    = '(monitor)'
    SidName(*)
    StaticConnectIdentifier(*)
    StandbyArchiveLocation(*)
    AlternateLocation(*)
    LogArchiveTrace(*)
    LogArchiveFormat(*)
    TopWaitEvents(*)
    (*) - Please check specific instance for the property value

Database Status:
WARNING


Step 2 : Find which properties are Inconsistent

DGMGRL> show database tpri InconsistentProperties
INCONSISTENT PROPERTIES
   INSTANCE_NAME        PROPERTY_NAME         MEMORY_VALUE         SPFILE_VALUE         BROKER_VALUE 

--> No Inconsistent properties found 

DGMGRL> show database tprisby InconsistentProperties
INCONSISTENT PROPERTIES
   INSTANCE_NAME        PROPERTY_NAME         MEMORY_VALUE         SPFILE_VALUE         BROKER_VALUE
        tprisby2     ArchiveLagTarget                    0                                         0
        tprisby2 LogArchiveMaxProcesses                    4                                         4
        tprisby2 LogArchiveMinSucceedDest                    1                                         1 

--> Here you go. 3 Inconsistent properties found.

Solution :
SQL(tprisby2)>alter system set log_archive_max_processes=4 scope=both sid='*';

System altered.

SQL(tprisby2)>alter system set archive_lag_target=0 scope=both sid='*';

System altered.

SQL(tprisby2)>alter system set log_archive_min_succeed_dest=1 scope=both sid='*';

System altered.





Verify 

DGMGRL> show database tprisby
Database - tprisby

  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag:   0 seconds
  Apply Lag:       6 minutes 39 seconds
  Real Time Query: OFF
  Instance(s):
    tprisby1 (apply instance)
    tprisby2

Database Status:
SUCCESS