Understanding the Limitations while Implementing Oracle Fail Safe (OFS) & Data Guard (DG)
(Doc ID 2437037.1)
Last updated on APRIL 03, 2020
Applies to:Oracle Fail Safe - Version 3.4.1 and later
Oracle Database - Enterprise Edition - Version 10.2.0.1 to 126.96.36.199.0 [Release 10.2 to 18]
Information in this document applies to any platform.
Public Documentation delivered with an Oracle database product or other training material. Any similarity to actual environments, actual persons, living or dead, is
purely coincidental and not intended in any manner.
For the purposes of this document, the following fictitious environment is used as an example to describe the procedure:
Database Name: ORCL
Node Names: Prim-Node1, Prim-Node2, DR-Node1, DR-Node2
Cluster Names: PRI-Cluster, DR-Cluster
Understanding the known issues while implementing Data Guard (DG) in Oracle Fail Safe (OFS) environment.
Oracle Fail Safe (OFS):
OFS run on windows cluster and takes responsibility to perform cold failover of register resources to another cluster node along with Microsoft cluster. OFS does polling frequently
to check the resource availability and its state to bring the resource to the desired state if necessary.
Fail Safe document:
Oracle Data Guard (DG):
Oracle data guard is used to maintain the copy of oracle database in other site for disaster recovery purpose. If the primary database unavailable due to issues, then standby database
can be brought up for the business.
Both Oracle Data Guard and Oracle Fail Safe have the ability to change the state of the database (start, stop and alter the database).
- During switchover Data Guard can shut down and start the database.
- When Fail Safe moves the database from one node to another available node, Fail Safe shuts down the database and starts the database.
While Fail Safe shuts down the database Data Guard would not know that it is planned shutdown and vice versa (while Data Guard shuts down the database, Fail Safe would not know
that it is planned activity).
When performing the planned activity in Fail Safe it is better to disable the features of Oracle Data Guard and vice versa, this will eliminate many issues will arrive due to product limitations.
- When Data Guard stops the database which is being managed by Oracle Fail Safe, OFS starts the database back to online mode because OFS will not be aware that it
is maintenance activity started from Data Guard.
- When Fail Safe manager moves the resources to next available node of the same cluster Broker will not be intimated by OFS so Broker may take an action to perform
failover if FSFO enabled
So, due to communication limitation, it will lead to an issue.
Below is the sample configuration model.
- Cluster PRI-Cluster has Prim-Node1 & Prim-Node2; Primary database is running in Prim-Node1
- Cluster DR-Cluster has DR-Node1 & DR-Node2; Standby database is running in DR-Node1
The database configured in PRI-Cluster will run in Prim-Node1 OR Prim-Node2 in a given point of time and database can be failed over to next available server(within cluster)
using Fail Safe and same applies for another cluster (DR-Cluster) as well.
Precautions to be taken to minimize the issues during maintenance activity in Fail Safe or Data Guard.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document
|Situation 1: Planned switchover/failover through DGMGRL OR Manual switchover|
|Situation 2: If there is FSFO enabled in DGMGRL & Databases are being managed in OFS|
|Situation 3: If there is FSFO enabled in Data Guard and manually we need to move the resources to next available node in the same cluster|
|Situation 4: Switchover when one or mode nodes are down|