Far Sync Standby 能不能支持 max protection

GOAL

 This Note explains the new Standby Type Far Sync Standby

SOLUTION

Far Sync Standby Database:

A Far Sync Standby Database is a cascading Standby Database which acts as a Redo Log Repository for a Terminal Database. It does not contain any datafiles. Only Log Transport Services are active on a Far Sync Standby Database. The Advantage of a Far Sync Standby Database is that it can be a local ArchiveLog Repository for the Primary Database acting in Maximum Availability Mode where the Physical or Logical Standby Database can be on a far remote Site. 

Creating a Far Sync Standby Instance 

You can prepare your Environment for a Far Sync Instance the same Way like for a Physical Standby Database, see

Note 1475344.1 Creating a Physical Standby Database on Oracle 11.2.0.x

-> Preparing the Environment and Standby Instance

for an Example.

Instead of a Physical Standby Controlfile we are creating a Far Sync Standby Controlfile from the Primary Database and use this Controlfile to mount the Far Sync Instance:

SQL> alter database create far sync instance controlfile as ‘<File Specification>’;

 You can then setup Log Transport Services to the Cascaded Standby just like for normal Cascaded Standby Databases. 

Data Guard Broker and Far Sync Standby Database 

The Data Guard Broker also supports Far Sync Standby Databases and Cascaded Standby Databases. You can add a Far Sync Standby to your Data Guard Broker Configuration using

DGMGRL> add far_sync <Name> as connect identifier is <Connect Identifier>;

 Then set the Data Guard Broker Property ‘RedoRoutes’ for the Databases accordingly. You can find an Explanation about ‘RedoRoutes’ in

Note 1542969.1 Cascaded Standby Databases in Oracle 12c

Technical Briefs:

Oracle Active Data Guard Far Sync Zero Data Loss at Any Distance
https://www.oracle.com/technetwork/database/availability/farsync-2267608.pdf

REFERENCES

NOTE:1475344.1 - Creating a Physical Standby Database
NOTE:1578787.1 - 12c Data guard Switchover Best Practices using SQLPLUS
NOTE:1582837.1 - 12c Dataguard Switchover Best Practices using DGMGRL(Dataguard Broker Command Prompt)
NOTE:1542969.1 - Cascaded Standby Databases in Oracle 12c

PURPOSE

 This Documents explains the Enhancements for Cascaded Standby Databases in Oracle 12c.

DETAILS

There are new Possibilities for cascading Standby Databases in Oracle 12c. The main Differents between Oracle 12c and the previous Releases are:

1. Real-Time Cascading
2. Far Sync Standby Database
3. Data Guard Broker now supports cascaded Standby Database

However, you can still only cascade a Standby Database from a Physical Standby Database. It is not supported to cascade a Standby Database from a Logical Standby Database.

Real-Time Cascading

It is now possible to forward Redo in Real-Time Mode from the first to the cascaded Standby Database. So the Redo Record is forwarded to the cascaded Standby Database once written into a Standby RedoLog of the first Standby Database.

Non Real-Time Cascading means that the whole Log Sequence is transferred to the terminal Standby Database(s) after a Log Switch on the Primary Database.

Prerequisites

• First (Cascading) Standby must be a Physical or Far Sync Standby Database
• Standby RedoLogs must be in Place and used at least on the Cascading Standby Database
• Active Data Guard Option must be licensed
• Primary, Cascading and Cascaded Standby Database db_unique_name must be present in the dg_config of log_archive_config on all the Databases

Setup

First of all setup a Data Guard Environment as usual to the cascading Standby Database. The Log Transport Method should be ‘SYNC’ and Standby RedoLogs must be configured on the cascading Standby Database. Once you created the cascaded Standby Database you can now setup the cascading Log Transport Services. Here are some Hints for correct Setup:

• Primary, Cascading and Cascaded Standby Database db_unique_name must be present in the dg_config of log_archive_config on all the Databases
• Setup log_archive_dest_n on the cascading Standby Database to serve the cascaded (terminal) Standby Databases using the Attribute ‘valid_for=(STANDBY_LOGFILES,STANDBY_ROLE)’
• You can toggle between Real-Time and Non Real-Time Cascading using the Log Transport Method.

ASYNC = Real-Time Cascading

SYNC = Non Real-Time Cascading

• You can only use log_archive_dest_1 until log_archive_dest_10 for Non Real-Time Cascading Destinations where all log_archive_dest_n’s can be used for Real-Time Cascading on the Cascading Standby Database
• The Cascading Standby Standby can be in any Protection Mode
• A Cascading Standby Database can serve one or multiple terminal Standby Databases
• FAL_SERVER on the cascading Standby Database should be set to the Primary or any other Standby Database served by the Primary Database directly
• FAL_SERVER on the terminal Standby Database should be set to the cascading Standby Database or the Primary Database

Far Sync Standby Database

A Far Sync Standby Database is a cascading Standby Database which acts as a Redo Log Repository for a Terminal Database. It does not contain any Datafiles. Only Log Transport Services are active on a Far Sync Standby Database. The Advantage of a Far Sync Standby Database is that it can be a local ArchiveLog Repository for the Primary Database acting in Maximum Protection Mode where the Physical or Logical Standby Database can be on a far remote Site. See

Note 1565071.1: Data Guard 12c New Feature: Far Sync Standby

for further Details and Setup of a Far Sync Standby Database.

Data Guard Broker and Cascaded Standby Database

There is a new Data Guard Broker Property called ‘RedoRoutes’ used to build and implement a cascaded Data Guard Broker Configuration. It has the following Format:

RedoRoutes = ‘(<Redo Source> : <Redo Destination>)’

Redo Source: This is the Source the Redo is coming from. It can be a db_unique_name or the ‘LOCAL’-Keyword which is an Alias for the local Database Name (Cannot be used for a Far Sync Standby Database)

Redo Destination: This is the Destination where the Redo is shipped to from this Database. It can be one or more (comma separated) db_unique_name’s or the ‘ALL’-Keyword which is an Alias for all possible Destinations inside the Data Guard Broker Configuration. Optional you can also specify the Transport Method to be used to the Destination. This can be

• SYNC:                   corresponds to log_archive_dest_n Attributes ‘SYNC AFFIRM’ or Non Real Time Cascade
• ASYNC:                corresponds to log_archive_dest_n Attribute ‘ASYNC’ or Real Time Cascade
• FASTSYNC :        corresponds to log_archive_dest_n Attributes ‘SYNC NOAFFIRM’

Example:

NOTE: In the images and/or the document content below, the user information and environment data used represents fictitious data from the
Oracle sample schema(s), 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:

Primary Database:                               prim
Cascading Standby Database:               local_stdby
Cascaded (terminal) Standby Database: remote_stdby

We want to serve the local Standby Database with ‘SYNC NOAFFIRM’ and the remote Standby Database in Real-Time Cascade Mode. So the setting would be:

Primary Database (prim)

RedoRoutes = ‘(LOCAL : local_stdby FASTSYNC)’

 -> So the Primary Database only ships Redo to the local Standby Database, but has Archive Destination to the remote Standby Database

Local Standby Database (local_stdby)

RedoRoutes = ‘(prim : remote_stdby ASYNC)’

 -> Here we configure that the Redo coming from ‘prim’ is forwarded in Real-Time Cascade (ASYNC) to the remote Standby Database

---------------far sync 配置

PURPOSE

 Use of the terminal standby as an alternate destination in a Far Sync configuration requires accepting that, provided the terminal standby database is not within acceptable sync network range, the configuration will run in asynchronous mode during the entire period required to resolve the Far Sync instance outage.  The advantage of this approach is that it requires no additional hardware or software to deploy or manage.  Applications that can tolerate increased data loss potential during a Far Sync instance outage and where low cost is the main consideration may be best served by configuring the terminal standby as an alternate location using ASYNC redo transport.

SCOPE

APPLIES TO:

Oracle Database versions 12.1.0.1 and 12.1.0.2

Active Data Guard Far Sync 

Data Guard Broker

Data Guard Role Transitions

DETAILS

Using the terminal standby database as an alternate of a far sync instance can result in the following errors when attempting a role transition using Oracle Data Guard Broker.

DGMGRL> switchover to standbyDB;
Performing switchover NOW, please wait...
Error: ORA-16778: redo transport error for one or more databases

Failed.
Unable to switchover, primary database is still "primaryDB"

DGMGRL> failover to standbyDB;
Performing failover NOW, please wait...
Error: ORA-16600: not connected to target standby database for failover

Failed.
Unable to failover

Here is an example of an affected configuration:

DGMGRL> create configuration 'DGconfig' as primary database is 'primaryDB' connect identifier is primaryDB;
Configuration "DGconfig" created with primary database "primaryDB"

DGMGRL> ADD FAR_SYNC farsync1 as connect identifier is farsync1;
far sync instance "farsync1" added

DGMGRL> add database standbyDB as connect identifier is standbyDB;
Database "standbyDB" added

DGMGRL> edit far_sync farsync1 set property redoroutes='(primaryDB:standbyDB ASYNC)';
Property "redoroutes" updated

DGMGRL> edit far_sync farsync1 set property maxfailure=1;
Property "maxfailure" updated

DGMGRL> edit far_sync farsync1 set property nettimeout=8;
Property "nettimeout" updated

DGMGRL> edit far_sync farsync1 set property reopensecs=5;
Property "reopensecs" updated

DGMGRL> edit database primaryDB set property redoroutes='(LOCAL:farsync1 sync alt=(standbyDB async fallback))';
Property "redoroutes" updated

DGMGRL> edit database standbyDB set property redoroutes='(LOCAL:primaryDB async)';
Property "redoroutes" updated

DGMGRL> show configuration

Configuration - DGconfig

Protection Mode: MaxPerformance
Members:
primaryDB - Primary database
 farsync1 - Far sync instance
  standbyDB - Physical standby database
 standbyDB - Physical standby database (alternate of farsync1)

Fast-Start Failover: DISABLED

Configuration Status:
DISABLED

To avoid this error apply the patch for bug 19399918 in all environments(Primary, Far Sync, Standby).

GOAL

From the definition of Application Continuity (AC), the AC replays support Data Guard environments, and it replays the uncommitted transactions in the standby when primary fails.

Scenario:
Application is connected to the Primary Database. Application executes transactions and commits the data. However, the committed data does not reach the standby database due to network latency.
In such scenario, if a failover to the standby database from the primary database is performed, will the replay drivers continue to replay the transaction that was committed but not replicated to the standby site?
What level of protection does Application continuity gives in such scenario?
 

SOLUTION

An Application Continuity-aware configuration uses Transaction Guard to know if the last user submission committed or not. When a failure occurs, the replay driver receives a failure notification and reconnects to the new primary database. Then Application Continuity performs sanity checks to verify that is the correct database and able to safely receive replay requests. Next, Transaction Guard is invoked to determine the state of in-flight transactions. If uncommitted changes exist, they are replayed.
So, if the transaction is already committed, Transaction Guard will avoid already-committed transactions being replayed again,causing potential for logical data corruption.
Data Guard has features such as maximize protection modes to handle committed data changes written to redo logs when there are communication issues with the standby.
To find out the protection mode you use in DataGuard, you could query v$database.
 

SQL>select database_role, open_mode, protection_level, protection_mode from v$database;

For MAXIMUM PROTECTION mode, the lgwr sync affirm log transport mode would be used.
So the transaction won't be committed on the primary database until the standby receives the redo from the primary and send acknowledge back to the primary saying the standby receives the redo. In case there is a communication issue between the primary and the standby, the transaction will not be committed on the primary database which could cause the primary hanging.

Reference: 
Data Guard Concepts and Administration