Monday, October 31, 2011

RECOVERING A STANDBY DATABASE FROM A MISSING ARCHIVES LOG


Applying an incremental backup for missing archive log in to a physical standby
(OR)
ROLLING FORWARD A STANDBY DATABASE USING RMAN INCREMENTAL BACKUP
My setup

1) 2 node primary RAC database on 11202
2) 2 node physical standby RAC database on 11202
3) Running on ASM


We found that couple of archive log are delete before apply it in the standby database

Primary DB SCN Number

SQL> select current_scn from gv$database;

CURRENT_SCN
-----------
   13395160
   13395160

Standby DB SCN Number

SQL> select current_scn from gv$database;

CURRENT_SCN
-----------
    9642901
    9642901

SQL> select min (checkpoint_change#) from v$datafile_header;


ERROR MESSAGE

In our DG Environment, it has been reported as a error message

wyclorau003[BHU_2]>dgmgrl
DGMGRL for Linux: Version 11.2.0.2.0 - 64bit Production
Copyright (c) 2000, 2009, Oracle. All rights reserved.
Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sys
Password:
Connected.
DGMGRL> show configuration;
Configuration - DG_BHU
  Protection Mode: MaxAvailability
  Databases:
    BHU_B - Primary database
      Error: ORA-16810: multiple errors or warnings detected for the database
    BHU_A - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
ERROR

DGMGRL> show database 'BHU_A';

Database - BHU_A

  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-OFF
  Transport Lag:   13 days 31 minutes 26 seconds
  Apply Lag:       13 days 31 minutes 16 seconds
  Real Time Query: OFF
  Instance(s):
    BHU_1
    BHU_2 (apply instance)
Database Status:
SUCCESS
DGMGRL> show database 'BHU_B';
Database - BHU_B
  Role:            PRIMARY
  Intended State:  TRANSPORT-ON
  Instance(s):
    BHU_1
    BHU_2
  Database Error(s):
    ORA-16783: cannot resolve gap for database BHU_A
  Database Warning(s):
    ORA-16629: database reports a different protection level from the protection mode
Database Status:
ERROR

STEP #1 STOP THE RECOVERY PROCESS (APPLY OFF)

$ dgmgrl     -----à On standby server
DGMGRL for Linux: Version 11.2.0.2.0 - 64bit Production
Copyright (c) 2000, 2009, Oracle. All rights reserved.
Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sys
Password:
Connected.
DGMGRL> edit database 'BHU_A' set state='APPLY-OFF';
Succeeded.
DGMGRL> show database 'BHU_A';
Database - BHU_A
  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-OFF
  Transport Lag:   13 days 31 minutes 26 seconds
  Apply Lag:       13 days 31 minutes 16 seconds
  Real Time Query: OFF
  Instance(s):
    BHU_1
    BHU_2 (apply instance)

Database Status:
SUCCESS

IF NO BROKER

Stop the managed recovery process (MRP)

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

STEP#2 PERFORM A INCREMENTAL BACKUP FROM PRIMARY DB

$ rman target /               -à primary DB

RMAN> run
2> {
3> allocate channel ch1 type disk;
4> allocate channel ch2 type disk;
5> backup incremental from scn 9642000 database format '/oracle/BHU/standby_%d_%t_%c_%p';
6> }

using target database control file instead of recovery catalog
allocated channel: ch1
channel ch1: SID=95 instance=BHU_1 device type=DISK
allocated channel: ch2
channel ch2: SID=120 instance=BHU_1 device type=DISK
Starting backup at 31-OCT-11
backup will be obsolete on date 07-NOV-11
archived logs will not be kept or backed up
channel ch1: starting full datafile backup set
channel ch1: specifying datafile(s) in backup set
input datafile file number=00004 name=+BHU_DATA1/BHU_b/datafile/pindb.257.762433489
input datafile file number=00001 name=+BHU_DATA1/BHU_b/datafile/system.260.762433549
channel ch1: starting piece 1 at 31-OCT-11
channel ch2: starting full datafile backup set
channel ch2: specifying datafile(s) in backup set
input datafile file number=00002 name=+BHU_DATA1/BHU_b/datafile/sysaux.261.762433557
input datafile file number=00005 name=+BHU_DATA1/BHU_b/datafile/undo_2.259.762433541
input datafile file number=00003 name=+BHU_DATA1/BHU_b/datafile/undo.258.762433535
channel ch2: starting piece 1 at 31-OCT-11
channel ch1: finished piece 1 at 31-OCT-11
piece handle=/oracle/BHU/standby_BHU_765989757_1_1 tag=TAG20111031T145557 comment=NONE
channel ch1: backup set complete, elapsed time: 00:00:16
channel ch2: finished piece 1 at 31-OCT-11
piece handle=/oracle/BHU/standby_BHU_765989758_1_1 tag=TAG20111031T145557 comment=NONE
channel ch2: backup set complete, elapsed time: 00:00:25
backup will be obsolete on date 07-NOV-11
archived logs will not be kept or backed up
channel ch1: starting full datafile backup set
channel ch1: specifying datafile(s) in backup set
including current control file in backup set
channel ch1: starting piece 1 at 31-OCT-11
channel ch1: finished piece 1 at 31-OCT-11
piece handle=/oracle/BHU/standby_BHU_765989783_1_1 tag=TAG20111031T145557 comment=NONE
channel ch1: backup set complete, elapsed time: 00:00:01
Finished backup at 31-OCT-11
released channel: ch1
released channel: ch2
RMAN> exit


STEP#3 RECOVER STANDBY DB

A)    Move the rman backup piece to the standby server
B)     Catalog backup piece on the standby server

$ rman target /   -à STANDBY SERVER
Recovery Manager: Release 11.2.0.2.0 - Production on Mon Oct 31 15:05:10 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
connected to target database: BHU (DBID=19835845, not open)

RMAN> catalog start with '/oracle/BHU/saptrace/bkp';

using target database control file instead of recovery catalog
searching for all files that match the pattern /oracle/BHU/bkp
List of Files Unknown to the Database
=====================================
File Name: /oracle/BHU/bkp/standby_BHU_765989757_1_1
File Name: /oracle/BHU/bkp/standby_BHU_765989758_1_1
File Name: /oracle/BHU/bkp/standby_BHU_765989783_1_1
Do you really want to catalog the above files (enter YES or NO)? YES
cataloging files...
cataloging done
List of Cataloged Files
=======================
File Name: /oracle/BHU/bkp/standby_BHU_765989757_1_1
File Name: /oracle/BHU/bkp/standby_BHU_765989758_1_1
File Name: /oracle/BHU/bkp/standby_BHU_765989783_1_1

C)    Recover the standby database using the backup piece which has taken from the PRIMARY DB
-- RUN FROM STANDBY SERVER
RMAN> run
2> {
3> allocate channel ch1 type disk;
4> recover database noredo;
5> }

allocated channel: ch1
channel ch1: SID=2729 instance=BHU_2 device type=DISK
Starting recover at 31-OCT-11
channel ch1: starting incremental datafile backup set restore
channel ch1: specifying datafile(s) to restore from backup set
destination for restore of datafile 00001: +BHU_DATA1/BHU_a/datafile/system.265.762888379
destination for restore of datafile 00004: +BHU_DATA1/BHU_a/datafile/pindb.270.762888453
channel ch1: reading from backup piece /oracle/BHU/bkp/standby_BHU_765989757_1_1
channel ch1: piece handle=/oracle/BHU/saptrace/bkp/standby_BHU_765989757_1_1 tag=TAG20111031T145557
channel ch1: restored backup piece 1
channel ch1: restore complete, elapsed time: 00:00:07
channel ch1: starting incremental datafile backup set restore
channel ch1: specifying datafile(s) to restore from backup set
destination for restore of datafile 00002: +BHU_DATA1/BHU_a/datafile/sysaux.268.762888411
destination for restore of datafile 00003: +BHU_DATA1/BHU_a/datafile/undo.269.762888431
destination for restore of datafile 00005: +BHU_DATA1/BHU_a/datafile/undo_2.264.762888353
channel ch1: reading from backup piece /oracle/BHU/bkp/standby_BHU_765989758_1_1
channel ch1: piece handle=/oracle/BHU/saptrace/bkp/standby_BHU_765989758_1_1 tag=TAG20111031T145557
channel ch1: restored backup piece 1
channel ch1: restore complete, elapsed time: 00:00:15
Finished recover at 31-OCT-11
released channel: ch1

STEP#4 Create standby control from primary DB

SQL> alter database create standby controlfile as '/oracle/BHU/standby.ctl';
Database altered.

STEP#5 Restore the Control file in the STANDBY DB

-- Below steps are in the standby server
A) STOP THE STANDBY DATBASE( Both instances)

$ srvctl stop database -d BHU_a

B) START ONLY ONE INSTANCE OF THE STANDBY DATBASE

$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.2.0 Production on Mon Oct 31 15:10:18 2011
Copyright (c) 1982, 2010, Oracle.  All rights reserved.
Connected to an idle instance.
SQL> startup nomount
ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
ORACLE instance started.
Total System Global Area 1.4431E+10 bytes
Fixed Size                  2240272 bytes
Variable Size            3892314352 bytes
Database Buffers         1.0503E+10 bytes
Redo Buffers               34148352 bytes

C) IDENTIFY THE CONTROL FILE LOCATION

Note: you can remove the existing control file or we can allow the system to over write the control file which is placed in the ASM. I am over writing the controlfiles
SQL> show parameter control_files

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
control_files                        string      +BHU_DATA1/BHU_a/controlfile/current.258.762889151,
+BHU_ARCH/BHU_a/controlfile/current.332.762889151,
+BHU_RECO/BHU_a/controlfile/current.285.762889151

D) I have the copied standby control file from primary DB

$ ls
standby.ctl
$ pwd
/oracle/BHU/bkp

E)     RESTORING CONTROL FILE TO STANDBY DATABASE

RMAN> restore controlfile from '/oracle/BHU/bkp/standby.ctl';

Starting restore at 31-OCT-11
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=660 instance=BHU_2 device type=DISK
channel ORA_DISK_1: copied control file copy
output file name=+BHU_DATA1/BHU_a/controlfile/current.258.762889151
output file name=+BHU_ARCH/BHU_a/controlfile/current.332.762889151
output file name=+BHU_RECO/BHU_a/controlfile/current.285.762889151
Finished restore at 31-OCT-11
RMAN> exit

RMAN> alter database mount;
Database mount

STEP#6 CHANGING CONTROLFILE CONFIGURATION

A) Controlfile is restored from PRIMARY DB the datafile locations in STANDBY controlfile will be same as PRIMARY database, so catalog datafiles in STANDBY will do the necessary rename operations.
B) Perform the below step  in STANDBY for each diskgroup where the datafile directory structure between primary and standby are different.

$ rman target /    à STANDBY DB
Recovery Manager: Release 11.2.0.2.0 -Production on Mon Oct 31 17:27:18 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: BHU (DBID=19835845, not open)

RMAN> CATALOG START WITH '+BHU_DATA1/BHU_A/DATAFILE/';

Starting implicit crosscheck backup at 31-OCT-11
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
Crosschecked 7 objects
Finished implicit crosscheck backup at 31-OCT-11
Starting implicit crosscheck copy at 31-OCT-11
using channel ORA_DISK_1
Finished implicit crosscheck copy at 31-OCT-11
searching for all files in the recovery area
cataloging files...
no files cataloged
searching for all files that match the pattern +BHU_DATA1/BHU_A/DATAFILE/
List of Files Unknown to the Database
=====================================
File Name: +BHU_data1/BHU_A/DATAFILE/UNDO_2.264.762888353
File Name: +BHU_data1/BHU_A/DATAFILE/SYSTEM.265.762888379
File Name: +BHU_data1/BHU_A/DATAFILE/SYSAUX.268.762888411
File Name: +BHU_data1/BHU_A/DATAFILE/UNDO.269.762888431
File Name: +BHU_data1/BHU_A/DATAFILE/INDB.270.762888453
Do you really want to catalog the above files (enter YES or NO)? YES
cataloging files...
cataloging done
List of Cataloged Files
=======================
File Name: +BHU_data1/BHU_A/DATAFILE/UNDO_2.264.762888353
File Name: +BHU_data1/BHU_A/DATAFILE/SYSTEM.265.762888379
File Name: +BHU_data1/BHU_A/DATAFILE/SYSAUX.268.762888411
File Name: +BHU_data1/BHU_A/DATAFILE/UNDO.269.762888431
File Name: +BHU_data1/BHU_A/DATAFILE/INDB.270.762888453

STEP#7 Check for New Datafile added in primary DB

Any datafiles have been added to Primary AFTER SCN 13395160 they will also have to be restored to the standby host and catalog as shown above before doing the switch.
 To determine if any files have been added to Primary since the standby current SCN
-- IN STANBDY DB
SQL> SELECT FILE#, NAME FROM V$DATAFILE WHERE CREATION_CHANGE# > 13395160;

no rows selected

NOTE: if any files available, we have to copy it from primary to the standby database using RMAN

copy the datafile from the primary database.

run
{
allocate channel a1 type disk;
backup datafile 10 format '/oracle/BHU_A/bkp_ctl_file/datafile_%d_%U_%p_%c';
}

Transfer the rman backup datafile to standby database location then catalog the backup piece in the standby database.

run
{
allocate channel a1 type disk;
Restore datafile 10;
}

STEP#8 Switch the datafile USING RMAN
This process will change the datafile details of the standby database in the controlfile

RMAN> SWITCH DATABASE TO COPY;
datafile 1 switched to datafile copy "+BHU_DATA1/BHU_a/datafile/system.265.762888379"
datafile 2 switched to datafile copy "+BHU_DATA1/BHU_a/datafile/sysaux.268.762888411"
datafile 3 switched to datafile copy "+BHU_DATA1/BHU_a/datafile/undo.269.762888431"
datafile 4 switched to datafile copy "+BHU_DATA1/BHU_a/datafile/pindb.270.762888453"
datafile 5 switched to datafile copy "+BHU_DATA1/BHU_a/datafile/undo_2.264.762888353"

STEP#9 Clear the standby log files

On standby database, clear all standby redo log groups:

SQL> ALTER DATABASE CLEAR LOGFILE GROUP 100;
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 110;
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 200;
SQL> ALTER DATABASE CLEAR LOGFILE GROUP 210;
....

STEP#10 START THE RECOVEY PROCESS ON STANDBY

$ dgmgrl     -----à On standby server
DGMGRL for Linux: Version 11.2.0.2.0 - 64bit Production
Copyright (c) 2000, 2009, Oracle. All rights reserved.
Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sys
Password:
Connected.
DGMGRL> edit database 'BHU_A' set state='APPLY-ON';
Succeeded.

IF NO BROKER
 On the STANDBY database, start the MRP on apply instance
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;


FINAL RESULT

DGMGRL> show configuration

Configuration - DG_BHU

  Protection Mode: MaxAvailability
  Databases:
    BHU_B - Primary database
    BHU_A - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

DGMGRL> show database 'BHU_A';

Database - BHU_A

  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag:   0 seconds
  Apply Lag:       0 seconds
  Real Time Query: OFF
  Instance(s):
    BHU_1
    BHU_2 (apply instance)

Database Status:
SUCCESS

DGMGRL>

Saturday, October 29, 2011

Cloning Existing Oracle home (RDBMS) using clone.pl or runInstaller


we have a server which runs two Oracle databases on 10203 release on Linux. We had a plan to upgrade only one database on server to 10205 and keep the other database in the same version (10203) on the server

I have document the process of clone, i hope this will be useful.

STEP#1
Before starting the upgrade, we have to clone the ORACLE_HOME for the existing database to continue running on the same version.
MY EXISTING ORACLE_HOME è /oracle/BHUVAN/10203
MY NEW ORACLE_HOME è /oracle/BHUVAN/10205

STEP#2
Before starting the copy process, we have to stop all databases, listeners(all oracle products) that are running from the source home.

Once all oracle process are stopped, we can perform the copy
$ cd /oracle/BHUVAN/10203
$ tar -cvf /tmp/source_1023.tar .

Since I am restoring in the same server, I didn’t move the tar file. If you are moving to a different server then you have use the binary option for transferring the tar file.
$ cd /oracle/BHUVAN/10205
$ tar -xvf /tmp/source_1023.tar


STEP#3

We are perform the clone using two methods
1) Clone.pl
2) Using runInstaller option.

I have performed through runInstaller, but I am specifying the example of cloning using the clone.pl. When you want use the clone.pl, we should have the Perl installed on our Local server. You can check by issuing
$ perl -v

When you perform the runInstaller method, we don’t require any display or any DB console. In end of the clone setup process, oracle will ask us to run the root.sh from the root user.

Note: we don’t need to do the relink using both options.
EX CLONE.PL METHOD

oracle[BHUVAN]> perl $ORACLE_HOME/clone/bin/clone.pl ORACLE_HOME="/oracle/BHUVAN/10205" ORACLE_HOME_NAME="ORA_1205_HOME"

EX RUNINSTALLER METHOD

oracle[BHUVAN]> ./runInstaller -silent -clone -waitForCompletion  "ORACLE_HOME=/oracle/BHUVAN/10205" "ORACLE_HOME_NAME=ORA_1205_HOME" -noConfig -nowait
Starting Oracle Universal Installer...

No pre-requisite checks found in oraparam.ini, no system pre-requisite checks will be executed.
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2011-10-02_10-11-03AM. Please wait ...Oracle Universal Installer, Version 10.2.0.3.0 Production
Copyright (C) 1999, 2006, Oracle. All rights reserved.

You can find a log of this install session at:
 /oracle/BHUVAN/oraInventory/logs/cloneActions2011-10-02_10-11-03AM.log
.................................................................................................... 100% Done.



Installation in progress (Sun Oct 02 10:11:34 BST 2011)
.................................................................................                                               81% Done.
Install successful

Linking in progress (Sun Oct 02 10:11:50 BST 2011)
Link successful

Setup in progress (Sun Oct 02 10:17:49 BST 2011)
Setup successful

End of install phases.(Sun Oct 02 10:17:57 BST 2011)
WARNING:
The following configuration scripts need to be executed as the "root" user.
#!/bin/sh
#Root script to run
/oracle/BHUVAN/10205/root.sh
To execute the configuration scripts:
    1. Open a terminal window
    2. Log in as "root"
    3. Run the scripts

The cloning of CLONE_HOME was successful.
Please check '/oracle/BHUVAN/oraInventory/logs/cloneActions2011-10-02_10-11-03AM.log' for more details.
STEP#4 (it is optionally only)

Once we complete the process, we can run the ChangePerm.sh to set the proper permission.

$ORACLE_HOME/install/changePerm.sh

STEP#5

Once the Entire clone process completed, we should move the spfile or pfile, tnsnames.ora, listener.ora to the new ORACLE_HOME for the database.

Happy Learning!!!!!!!!!!!!

ORA-01017 SYS Password problem in the Data Guard environment

Problem

While performing the switchover & failover using the DG broker. DG broker reported the below error message in the log file.

Error message

Connection to database BHU_A returns ORA-01017.
NSV0: Failed to connect to remote database BHU_A. Error is ORA-01017
NSV0: Failed to send message to site BHU_A. Error code is ORA-01017.
DMON: failed to forward op EDIT_RES_PROP to site BHU_A with error ORA-01017
DMON: Database BHU_A returned ORA-01017
Connection to database BHU_A returns ORA-01017.
Please check database BHU_A is using a remote password file


When have a two node RAC setup as a primary DB and two node RAC setup as standby database. We have enable data Guard broker configuration for this environment.

PROBLEM CAUSE

When we change the sys password in the primary database using the alter system command, it updates the password file in the ORACLE_HOME of the primary database, it doesn’t update password file in the standby database.

SQL> alter user sys identified by oracle12$;

SOLUTION è Changing SYS Password in the Data Guard environment

While changing the sys password in the Primary database. You have manually copy the password file to the standby database. If it is RAC environment, then make sure that you place the file in both the ORACLE_HOME.


In Oracle 11g, Oracle has come up with case-sensitive option. It means passwords are case-sensitive. It is dynamic parameter and it change modified easily. this function available from oracle 11gR1 onwards.

SQL> show parameter case_sensitive

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
sec_case_sensitive_logon             boolean     TRUE

SQL> alter system set sec_case_sensitive_logon=FALSE scope=both sid='*';

System altered.

Wednesday, October 26, 2011

ORA-16629: database reports a different protection level from the protection mode

Issue:

After completing the reinstate process, I checked my configuration. It throws me a warning message with ORA-16629.

DGMGRL> reinstate  database 'BHU_A';
Reinstating database "BHU_A", please wait...
Reinstatement of database "BHU_A" succeeded

DGMGRL> show configuration;

Configuration - DG_BHU

  Protection Mode: MaxAvailability
  Databases:
    BHU_B - Primary database
      Warning: ORA-16629: database reports a different protection level from the protection mode

    BHU_A - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
WARNING

TO CHECK THE COMPLETE DETAILS OF THE DATABASE

DGMGRL> show database verbose 'BHU_B';


SOLUTION:

Since I am running in the MAX AVAILABILITY, I tried to check the following parameter on the primary site

DGMGRL> show database verbose 'BHU_B';

Database - BHU_B

  Role:            PRIMARY
  Intended State:  TRANSPORT-ON
  Instance(s):
    BHU_1
    BHU_2

  Properties:
    DGConnectIdentifier             = 'BHU_B_DG'
    ObserverConnectIdentifier       = ''
    LogXptMode                      = 'SYNC'
.
.
   (*) - Please check specific instance for the property value

Database Status:
SUCCESS

you can see the difference in the parameter log_archive_dest_2 of each instance.

Node#1
check log_archive_dest_2 or check destination, where archive shipping is enable

Node#2
check log_archive_dest_2 or check destination, where archive shipping is enable

I tried to Re-Apply or change the protection mode to max availability on the primary database.

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
Succeeded.

DGMGRL> show configuration;

Configuration - DG_BHU

  Protection Mode: MaxAvailability
  Databases:
    BHU_B - Primary database
    BHU_A - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS

DGMGRL>

Tuesday, October 25, 2011

ORA-16766: Redo Apply is stopped

When I tried to check the status of my standby database, It has been reported as Redo Apply has been stopped. I tried to start it manually but that doesn’t help me.

Error message in the alert log


Errors in file /oracle/BHU/saptrace/diag/rdbms/BHU_b/BHU_1/trace/BHU_1_pr00_20307.trc:
ORA-01111: name for data file 7 is unknown - rename to correct file
ORA-01110: data file 7: '/oracle/BHU/112_64/dbs/UNNAMED00007'
ORA-01157: cannot identify/lock data file 7 - see DBWR trace file
ORA-01111: name for data file 7 is unknown - rename to correct file
ORA-01110: data file 7: '/oracle/BHU/112_64/dbs/UNNAMED00007'

(or)

you can view the message in the DG broker
bhuora01[BHU_1]>dgmgrl
DGMGRL for Linux: Version 11.2.0.2.0 - 64bit Production
Copyright (c) 2000, 2009, Oracle. All rights reserved.
Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sys
Password:
Connected.

DGMGRL> show configuration;

Configuration - DG_BHU

  Protection Mode: MaxAvailability
  Databases:
    BHU_A - Primary database
    BHU_B - Physical standby database
      Error: ORA-16766: Redo Apply is stopped

Fast-Start Failover: DISABLED
Configuration Status:
ERROR

DGMGRL> show database verbose 'BHU_B';

Database - BHU_B

  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag:   0 seconds
  Apply Lag:       (unknown)
  Real Time Query: OFF
  Instance(s):
    BHU_1
    BHU_2 (apply instance)

  Database Error(s):
    ORA-16766: Redo Apply is stopped

  Properties:
    DGConnectIdentifier             = 'BHU_B_DG'
    ObserverConnectIdentifier       = ''
    LogXptMode                      = 'SYNC'
    DelayMins                       = '0'
    Binding                         = 'OPTIONAL'
    MaxFailure                      = '0'
    MaxConnections                  = '1'
    ReopenSecs                      = '300'
    NetTimeout                      = '30'
    RedoCompression                 = 'DISABLE'
    LogShipping                     = 'ON'
    PreferredApplyInstance          = ''
    ApplyInstanceTimeout            = '0'
    ApplyParallel                   = 'AUTO'
    StandbyFileManagement           = 'MANUAL'
    ArchiveLagTarget                = '0'
    LogArchiveMaxProcesses          = '10'
    LogArchiveMinSucceedDest        = '1'
    DbFileNameConvert               = ''
    LogFileNameConvert              = ''
    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:
ERROR

DGMGRL>

SQL>  SELECT DISTINCT STATUS,count(1) from v$datafile group by status;

STATUS    COUNT(1)
------- ----------
ONLINE           5
RECOVER          1
SYSTEM           1

SQL> select name from v$datafile where status != 'ONLINE';

NAME
--------------------------------------------------------------------------------
+BHU_DATA1/BHU_b/datafile/system.259.764182789
/oracle/BHU/112_64/dbs/UNNAMED00007

SQL> select name,status from v$datafile where status != 'ONLINE';

NAME                                                                                     STATUS
-------
+BHU_DATA1/BHU_b/datafile/system.259.764182789     SYSTEM

/oracle/BHU/112_64/dbs/UNNAMED00007              RECOVER



POSSIBLE CAUSE FOR THIS ISSUE

1)      In my case, STANDBY_FILE_MANAGEMENT has been set as MANUAL. So it was creating the new datafiles in the $ORACLE_HOME/dbs folder. so recover process couldnt apply the logs

To find the files which are created in the UNKNOWN directory
select FNNAM,FNONM from x$kccfn where FNFNO=<Datafile_number>;
Note: you can get this value of datafile from alert_SID.log

A)    first you need to create the datafile in a proper position and start the recover
Ex: For moving file from $ORACLE_HOME to correct ASM DISK GROUP

SQL> alter database create datafile '/oracle/BHU/112_64/dbs/UNNAMED00007' as '+BHU_DATA1';

Database altered.

One more situation


SQL> alter database create datafile '/oracle/BHU/112_74/dbs/UNNAMED00007' as '+BHU_B_SYSTEM';
alter database create datafile '/oracle/BHU/112_74/dbs/UNNAMED00007' as '+BHU_B_SYSTEM'
*
ERROR at line 1:
ORA-01137: specified size of file 7 (12800 blocks) is less than original size
of 4194177 blocks
ORA-01111: name for data file 7 is unknown - rename to correct file
ORA-01110: data file 7: '/oracle/BHU/112_74/dbs/UNNAMED00007'

you might have the UNNAMED file in the $ORACLE_HOME/dbs location itself. so you have to use the size option. you need to identify the datafile size and create like below

SQL> alter database create datafile '/oracle/BHU/112_64/dbs/UNNAMED00007' as '+BHU_B_SYSTEM' size 34358689792;
Database altered.

B)     Try to change the parameter standby_file_management=AUTO

2)      You have to change the standbyfile management across all the instance in the cluster database and you have to change it in the broker configuration also.

3)      standby database recovery process might be stopped or it might killed by some other process, so you need to start it on the apply instance

To find the apply instance on RAC environment

DISPLAY DB CONFIGURATION DETAILS

DGMGRL> show database 'BHU_B';

Database - BHU_B

  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag:   0 seconds
  Apply Lag:       0 seconds
  Real Time Query: OFF
  Instance(s):
    BHU_1 (apply instance)
    BHU_2

Database Status:
SUCCESS
DGMGRL> exit

Login in to the Apply instance, stop and start the recover process.

bhuora01[BHU_1]>sqlplus / as sysdba
SQL*Plus: Release 11.2.0.2.0 Production on Wed Oct 19 13:41:22 2011
Copyright (c) 1982, 2010, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options

-- STOPING RECOVERY PROCESS

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE  CANCEL;

Database altered.

-- STARTING RECOVERY PROCESS

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

Database altered.

Go to the apply instance and check whether the apply process is started or not

SQL> select PROCESS,CLIENT_PROCESS,THREAD#,SEQUENCE#,BLOCK# from v$managed_standby where process = 'MRP0' or client_process='LGWR';

I hope this helps to solve your issue, please provide your feedback. Happy learning!!!!!