Error: ORA-16825: Fast-Start Failover and other errors or warnings detected for the database

ORA-16795:

database resource guard detects that database re-creation is required

ORA-16825:

Fast-Start Failover and other errors or warnings detected for the database

ORA-16817:

unsynchronized Fast-Start Failover configuration

solution:

DGMGRL> show database rajesh

Database
  Name:            rajesh
  Role:            PRIMARY
  Enabled:         YES
  Intended State:  ONLINE
  Instance(s):
    rajesh

Current status for "rajesh":
Error: ORA-16825: Fast-Start Failover and other errors or warnings detected for the database


DGMGRL> show database jeyanthi

Database
  Name:            jeyanthi
  Role:            PHYSICAL STANDBY
  Enabled:         NO
  Intended State:  ONLINE
  Instance(s):
    jeyanthi

Current status for "jeyanthi":
Error: ORA-16661: the standby database needs to be reinstated



DGMGRL> reinstate database jeyanthi;
Reinstating database "jeyanthi", please wait...
Operation requires shutdown of instance "jeyanthi" on database "jeyanthi"
Shutting down instance "jeyanthi"...
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "jeyanthi" on database "jeyanthi"
Starting instance "jeyanthi"...
ORACLE instance started.
Database mounted.
Continuing to reinstate database "jeyanthi" ...
Reinstatement of database "jeyanthi" succeeded
DGMGRL> show configuration verbose;

Configuration
  Name:                jeyanthi
  Enabled:             YES
  Protection Mode:     MaxAvailability
  Fast-Start Failover: ENABLED
  Databases:
    jeyanthi - Physical standby database
             - Fast-Start Failover target
    rajesh   - Primary database

Fast-Start Failover
  Threshold: 30 seconds
  Observer:  rac3

Current status for "jeyanthi":
Warning: ORA-16607: one or more databases have failed

then,
stop and start the observer.(start from another machine)
DGMGRL> stop observer
Done.
DGMGRL> connect sys/oracle@jeyanthi
Connected.
DGMGRL> start observer
Observer started


DGMGRL> show configuration verbose

Configuration
  Name:                jeyanthi
  Enabled:             YES
  Protection Mode:     MaxAvailability
  Fast-Start Failover: ENABLED
  Databases:
    jeyanthi - Physical standby database
             - Fast-Start Failover target
    rajesh   - Primary database

Fast-Start Failover
  Threshold: 30 seconds
  Observer:  rac2

Current status for "jeyanthi":
SUCCESS

regards,
rajeshkumar g

fast-start failover DATAGUARD BROKER

here is an example to check the fast start failover in dataguard environment
i manually killed the mandatory background process smon of primary database.
then the observer automatically initiate the standby database to primary database, and reinstate the old primary database to standby.


here, primary database name: whiteowl

physical standby database name: blackowl

observer name: observer

from primary database machine rac1:

[oracle@rac1 ~]$ ps -eaf | grep smon
oracle   17328     1  0 12:25 ?        00:00:00 ora_smon_whiteowl
oracle   17886 17865  0 12:34 pts/4    00:00:00 grep smon
[oracle@rac1 ~]$ kill -9 17428

startup the primary database in mount stage.

DGMGRL> show configuration verbose;

Configuration
  Name:                whiteowl
  Enabled:             YES
  Protection Mode:     MaxAvailability
  Fast-Start Failover: ENABLED
  Databases:
    whiteowl - Physical standby database (disabled)
             - Fast-Start Failover target
    blackowl - Primary database

Fast-Start Failover
  Threshold: 30 seconds
  Observer:  rac1

Current status for "whiteowl":
Warning: ORA-16608: one or more databases have warnings


DGMGRL> show site verbose 'blackowl';
Site
  Name:                          'blackowl'
  Hostname:                      'rac2'
  Instance name:                 'blackowl'
  Service Name:                  'blackowl'
  Standby Type:                  'physical'
  Enabled:                       'yes'
  Required:                      'yes'
  Default state:                 'PRIMARY'
  Intended state:                'PRIMARY'
  PFILE:                         ''
  Number of resources:  1
  Resources:
    Name: blackowl (default) (verbose name='blackowl')
Current status for "blackowl":
Warning: ORA-16817: unsynchronized Fast-Start Failover configuration

DGMGRL> show site verbose 'whiteowl';
Site
  Name:                          'whiteowl'
  Hostname:                      'rac1'
  Instance name:                 'whiteowl'
  Service Name:                  'whiteowl'
  Standby Type:                  'physical'
  Enabled:                       'yes'
  Required:                      'yes'
  Default state:                 'STANDBY'
  Intended state:                'STANDBY'
  PFILE:                         ''
  Number of resources:  1
  Resources:
    Name: whiteowl (default) (verbose name='whiteowl')
Current status for "whiteowl":
Warning: ORA-16817: unsynchronized Fast-Start Failover configuration


on observer: machine rac3

12:19:20.23  Monday, January 25, 2010
Initiating fast-start failover to database "blackowl"...
Performing failover NOW, please wait...
Failover succeeded, new primary is "blackowl"
12:19:51.84  Monday, January 25, 2010

12:24:33.93  Monday, January 25, 2010
Initiating reinstatement for database "whiteowl"...
Reinstating database "whiteowl", please wait...
Operation requires shutdown of instance "whiteowl" on database "whiteowl"
Shutting down instance "whiteowl"...
ORA-01109: database not open

Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "whiteowl" on database "whiteowl"
Starting instance "whiteowl"...
ORACLE instance started.
Database mounted.
Continuing to reinstate database "whiteowl" ...
Reinstatement of database "whiteowl" succeeded
12:26:02.89  Monday, January 25, 2010

then check,
DGMGRL> show configuration verbose;

Configuration
  Name:                whiteowl
  Enabled:             YES
  Protection Mode:     MaxAvailability
  Fast-Start Failover: ENABLED
  Databases:
    whiteowl - Physical standby database
             - Fast-Start Failover target
    blackowl - Primary database

Fast-Start Failover
  Threshold: 30 seconds
  Observer:  rac1

Current status for "whiteowl":
SUCCESS

regards,
rajeshkumar

Monitoring the Primary and Standby Databases

Table indicates whether a primary database event is automatically administered by log transport services and log apply services or requires additional intervention by the database administrator (DBA) to be propagated to the standby database. It also describes how to respond to these events.

Troubleshooting Primary Database Events




regards,
rajeshkumar govindarajan.

source and reference:
http://www-css.fnal.gov/dsg/external/oracle_dcm/9iv2/server.920/a96653/sbydb_manage_ps.htm#1005701

related topics
# Dynamic Performance Views (Fixed Views)For Manganing Standby Database
# Determining Which Logs Have Been Applied to the Standby Database
# Determining Which Logs Have Not Been Received by the Standby Site

Determining Which Logs Have Been Applied to the Standby Database

Query the V$LOG_HISTORY view on the standby database, which records the latest log sequence number that has been applied. For example, issue the following query:

SQL> SELECT THREAD#, MAX(SEQUENCE#) AS "LAST_APPLIED_LOG"
2> FROM V$LOG_HISTORY
3> GROUP BY THREAD#;

THREAD# LAST_APPLIED_LOG
------- ----------------
1 967

In this example, the archived redo log with log sequence number 967 is the most recently applied log.

You can also use the APPLIED column in the V$ARCHIVED_LOG fixed view on the standby database to find out which log is applied on the standby database. The column displays YES for the log that has been applied. For example:

SQL> SELECT THREAD#, SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG;

THREAD# SEQUENCE# APP
---------- ---------- ---
1 2 YES
1 3 YES
1 4 YES
1 5 YES
1 6 YES
1 7 YES
1 8 YES
1 9 YES
1 10 YES
1 11 NO

10 rows selected.

regards,
rajeshkumar govindarajan.

source and reference:
http://www-css.fnal.gov/dsg/external/oracle_dcm/9iv2/server.920/a96653/sbydb_manage_ps.htm#1005911

related topics:
Determining Which Logs Have Not Been Received by the Standby Site
Dynamic Performance Views (Fixed Views) for managing standby database

Determining Which Logs Have Not Been Received by the Standby Site

Each archive destination has a destination ID assigned to it. You can query the DEST_ID column in the V$ARCHIVE_DEST fixed view to find out your destination ID. You can then use this destination ID in a query on the primary database to discover logs that have not been sent to a particular standby site.

For example, assume the current local archive destination ID on your primary database is 1, and the destination ID of one of your remote standby databases is 2. To find out which logs have not been received by this standby destination, issue the following query on the primary database:

SQL> SELECT LOCAL.THREAD#, LOCAL.SEQUENCE# FROM
2> (SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=1) LOCAL
3> WHERE
4> LOCAL.SEQUENCE# NOT IN
5> (SELECT SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=2 AND
6> THREAD# = LOCAL.THREAD#);

THREAD# SEQUENCE#
---------- ----------
1 12
1 13
1 14

The preceding example shows the logs that have not yet been received by standby destination 2.

regards,
rajeshkumar govindarajan

source and reference:
http://www-css.fnal.gov/dsg/external/oracle_dcm/9iv2/server.920/a96653/sbydb_manage_ps.htm#1005941

related topics:
Dyanamic performance views for managing standby database
Determine which Log Have Been Applied to the standby database

Monitoring Events That Affect the Standby Database

To prevent possible problems, you should be aware of events that affect a standby database and learn how to monitor them. Most changes to a primary database are automatically propagated to a standby database through archived redo logs and thus require no user intervention. Nevertheless, some changes to a primary database require manual intervention at the standby site.

Dynamic Performance Views (Fixed Views)

The Oracle database server contains a set of underlying views that are maintained by the server. These views are often called dynamic performance views because they are continuously updated while a database is open and in use, and their contents relate primarily to performance. These views are also called fixed views, because they cannot be altered or removed by the database administrator.

These view names are prefixed with either V$ or GV$, for example, V$ARCHIVE_DEST or GV$ARCHIVE_DEST.

Standard dynamic performance views (V$ fixed views) store information on the local instance. In contrast, global dynamic performance views (GV$ fixed views), store information on all open instances. Each V$ fixed view has a corresponding GV$ fixed view.

The following fixed views contain useful information for monitoring the Data Guard environment:

* V$ARCHIVE_DEST

Describes the archived redo log destinations associated with the current instance on the primary site. You can use this view to find out the current settings of your archived redo log destinations.
* V$ARCHIVE_DEST_STATUS

This view, an extension of the V$ARCHIVE_DEST view, displays runtime and configuration information for the archived redo log destinations. You can use this view to determine the progress of archiving to each destination. It also shows the current status of the archive destination.

* V$ARCHIVE_GAP

Provides information about archive gaps on a standby database. You can use this view to find out the current archive gap that is blocking recovery.

* V$ARCHIVED_LOG

Displays archived redo log information from the control file, including archived log names. This view gives you information on which log has been archived to where on your primary database. On the primary database, this view describes the logs archived to both the local and remote destinations. On a standby database, this view provides information about the logs archived to this standby database. You can use this fixed view to help you to track archiving progress to the standby system by viewing the applied field.

* V$DATABASE

Contains database information from the control file. You can use this view to quickly find out if your database is a primary or a standby database, as well as its switchover status and standby database protection mode.

* V$DATAFILE

Contains datafile information from the control file. You can query this fixed view to verify that the standby datafiles are correctly renamed after your standby database is re-created.

* V$DATAGUARD_STATUS

Displays and logs events related to Data Guard since the instance was started.

* V$LOG

Contains log file information from the online redo logs. You can use the information about the current online log on the primary database from this view as a reference point to determine how far behind your standby database is in receiving and applying logs.

* V$LOGFILE

Contains static information about the online redo logs and standby redo logs.

* V$LOG_HISTORY

Contains log history information from the control file, including a record of the latest archived log that was applied.

* V$MANAGED_STANDBY

Displays current and status information for some Oracle database server processes related to Data Guard. This view can show both foreground and background processes. You can use this view to monitor the various Data Guard recovery and archiving processes on the standby system.

* V$STANDBY_LOG

Provides information about the standby redo logs. Standby redo logs are similar to online redo logs, but they are only used on a standby database receiving logs from the primary database using the log writer process.

regards,
rajeshkumar govindarajan

source and reference:
http://www-css.fnal.gov/dsg/external/oracle_dcm/9iv2/server.920/a96653/sbydb_manage_ps.htm

related topics:
Determining Which Logs Have Not Been Received by the Standby Site