The New Features of Oracle Active Data Guard 12c

The New Features of Oracle Active Data Guard 12c

Here are the major ones:

1. Far Sync. This feature allows you to failover to a standby database even if it is remotely located in another site thousands of miles away. You do this without any data loss and without negatively affecting the performance of the primary database. Far Sync also keeps things simple and your costs down.

How does Far Sync works ?

The principle is fairly simple, the Far Sync instance receive data synchronously from the primary database and then forward it asynchronously to up de 29 remote destinations.

The far sync database is not a standard database, it only contains a specific controlfile, a spfile and standby redologs. This database must be placed near the primary database to guarantee an optimal network latency during synchronous replication. But be careful, don’t place this database on the same geographical place than the primary, because if your primary database experiences a geographical disaster, your Far Sync will be impacted too, and some data could be lost.

In case of an outage on the primary database, the standard failover procedure applies and the far sync instance guarantee that no data is lost during the failover. “Far Sync Standby” cannot be used as the target. Note that it is possible to create a “Far Sync Standby” on both sides in case the database roles change.

2. Fast Sync. Data Guard Fast Sync (SYNC NOAFFIRM) with Oracle Database 12c provides an easy way of improving performance in synchronous zero data loss configurations. It enables all sessions waiting for a remote RFS write to proceed as soon as the write is submitted, not when the write completes. This offers the best performance since it reduces the overall SYNC remote write wait event

Data Guard maximum availability supports the use of the noaffirm  redo transport parameter. A standby database returns receipt acknowledgment to its primary database as soon as redo is received in memory. The standby database does not wait for the Remote File Server (RFS) to write to a standby redo log file.
 
This noaffirm parameter provides increased primary database performance in Data Guard and SYNC for redo transport. FastSync isolates the primary database in a maximum availability configuration from any performance impact due to slow I/O at the standby database.

This feature gives you the easiest way to improve the database performance when you have synchronous no data loss setups. When a standby database gets a redo in memory, it will check with the primary database, even without getting a disk I/O to a redo log file in the standby. Fast Sync then effectively reduces the total round trip time between the standby and primary, resulting in better primary database performance. It also prevents fluctuations and outliers in standby I/O performance from impacting application response time. Fast Sync can make it practical to increase the distance between the primary and any Data Guard synchronous destination to provide greater geographic protection.

You should know, however, that there is a minute chance that data loss would happen when you use Fast Sync. But Oracle assures you that these instances would be so rare and it has to happen when both databases fail milliseconds within each other.

3. Real-time Cascade. Real-time Cascade allows your standby database to immediately transmit a redo to another standby database even when it has yet to be archived in the redo log file. Before 12c, redo is only cascade after the standby redo log file has finished being archived locally.

4. SYSDG. SYSDG is an administration privilege wherein the user can only perform basic administration actions and tasks. As such, SYSDG privileges are limited to STARTUP, SHUTDOWN, ALTER DATABASE, ALTER SESSION, ALTER SYSTEM, CREATE RESTORE POINT, CREATE SESSION, DROP RESTORE POINT, FLASHBACK DATABASE, SELECT ANY DICTIONARY, DELETE, and EXECUTE.

Other minor features that were introduced in Oracle Active Data Guard 12c:

Data Manipulation Language operations are now permitted on global temporary tables on the standby.
 

You no longer have to add the USING CURRENT LOGFILE clause when you initiate real-time apply. You can now use sequences in a Data Guard environment.

You no longer need to shut down all other primary database instance if you need to switchover from an Oracle Real Application Clusters primary database to a physical standby. Application continuity is now supported as well.

Beside these new features the Data Guard Broker commands have been extended. One of them are in my point of view very useful: The “validate database” command checks if the database is ready for a role transition.

 

PHYSICAL STANDBY DATABASE RELATED PROCESSES

On the Primary Database:

LGWR : The log writer process on the primary database writes entries from the redo log buffer to the online redo log file. When the current online redo log file is full, it triggers the archiver process to start the archiving activity. In some cases, the log writer process writes redo entries to the online redo log file of the primary database and the standby redo log file of the standby database. Usually, in this kind of arrangement the LGWR works as the log transport agent that is setup to achieve high data protection modes.

LNS : The LogWriter Network Service (LNS) reads the redo being flushed from the redo buffers by the LGWR and sends the redo over network to the standby database. The
main purpose of the LNS process is to free up the LGWR process from performing the redo transport role.

ARCH  : The archiver processes archives the ORL files to archive log files. Up to 30 ARCH processes can exist, and these ARCH processes are also used to fulfill gap resolution requests. Note that one ARCH process has a special role in that it is dedicated to local redo log archiving only and never communicates with a standby database.

Fetch Archive Log (FAL) The FAL process has two components: FAL Client and FAL Server. Both processes are used for archive gap resolution. If the Managed Recovery Process (MRP) on the standby database site detects an archive gap sequence, it initiates a fetch request to the FAL client on the standby site. This action, in turn, requests the FAL server process on the primary database to re-transmit the archived log files to resolve the gap sequence.

On the Standby Database:

RFS : The main objective of the Remote File Server process is to perform a network receive of redo transmitted from the primary site and then writes the network buffer (redo data) to the standby redo log (SRL) files.

ARCH : The archive processes on the standby site perform the same functions performed on the primary site, except that on the standby site, an ARCH process generates archived log files from the SRLs.

MRP : The managed recovery process coordinates media recovery management. Remember that a physical standby is in perpetual recovery mode.

Logical Standby Process (LSP) - The LSP applies the redo records from archived redo logs to the logical standby database. The Oracle database log miner engine is used by the logical standby process for the SQL apply operations. Using the log miner engine, the LSP process recreates the SQL statements from redo logs that have been executed on the primary database. These statements are then applied to the standby database to keep it current with the primary database.

---

Basically we can categorize physical standby database  into three major components:

1) Data Guard Redo Transport Services

– To transfer the redo that is generated by the primary database to the standby database.

2) Data Guard Apply Services  

– To receive and apply the redo sent by Redo Transport Services to the standby database.

3) Data Guard Role Management Services

– To assist in the database role changes in switchover and failover scenarios.

This service works in the background and takes care of switchover/failover scenarios