Data Guard New Features in Oracle 18c and 19c

Data Guard New Features in Oracle 18c and 19c

Data Guard

Oracle Data Guard ensures high availability disaster recovery and data protection for enterprise data
Data Guard maintains these standby databases as copies of the production database.
Then, if the production database becomes unavailable because of a planned or an unplanned outage, Data Guard can switch any standby database to the production role, minimizing the downtime associated with the outage.
It provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases to enable production Oracle databases to survive disasters and data corruptions.
Data Guard can be used with traditional backup, restoration, and cluster techniques to provide a high level of data protection and data availability.

Benefits of Data Guard

Flexibility in data protection to balance availability against performance requirements
Disaster recovery, high availability and data protection
Efficient use of system resources
Automatic gap detection and resolution
Automatic role transitions
Centralized and simple management
Integration with Oracle Database
Complete data protection

Standby Database types

A standby database is a transactionally consistent copy of an Oracle production database that is initially created from a backup copy of the primary database.
Once the standby database is created and configured, Data Guard automatically maintains the standby database by transmitting primary database redo log data to the standby system, where the redo log data is applied to the standby database.

Three Types of Standby Databases

Physical Standby Databases
Logical Standby Databases
Snapshot Standby Databases

Physical Standby Databases

A physical standby database is an exact, block-for-block copy of a primary database.
It maintains an exact copy through redo apply process.
The redo log data received from primary database is continuously applied to physical standby using recovery mechanism.

Benefits;

Performance
Reduction in primary database workload
Disaster recovery and high availability
Data protection

Logical Standby Databases

A logical standby database is initially created as an identical copy of the primary database, but it can be altered to have a different structure.
The logical standby database can be updated by using SQL statements.
Logical Standby will allow users to access the standby database for queries and reporting purpose.

Benefits;

Workload distribution
Minimizing downtime on software upgrades
Optimized for reporting and decision support requirements
Protection against additional kinds of failure
Efficient use of resources

Snapshot Standby Databases

A snapshot standby database is a fully updatable database that is created by converting a physical standby database into a snapshot standby database
A snapshot standby database receives and archives, but it will not apply redo data from its primary database.
Redo data received will be applied when a snapshot standby database is converted back into a physical standby database.
To convert snapshot standby database all the local changes needs to discard.

Benefits

It can be easily refreshed to contain current production data by converting to a physical standby and resynchronizing.
It provides an exact replica of a production database for development and testing purposes

New in Oracle 18C

Data Guard Broker Support for DBMS_ROLLING Upgrades
The broker will notifies Global Data Services and Oracle Clusterware as appropriate during the rolling upgrade.
If the upgrade target is an Oracle RAC database, then the broker automatically reduces the target standby to one instance during the start of the upgrade process and allows the upgrade to proceed. Without the broker, the start of the upgrade is rejected if target has multiple instances running.
The status of a rolling upgrade being done using the PL/SQL package DBMS_ROLLING and the information is displayed in the broker commands SHOW CONFIGURATION and SHOW DATABASE output.
The switchover step during a rolling upgrade should be performed using the DBMS_ROLLING.SWITCHOVER procedure.
Temporary tables – We can create temporary tables on Active Data Guard instance even though they are read-only. These are helpful in applications where a result set is to be buffered for reporting purpose.
Database Buffer Cache State- The buffer cache state is maintained on a active DataGuard standby during a role transition so that application performance is not effected by physical reads from disk.
Global Temporary tables– These tables are permanent database objects and stored on disk.
DML and DDL operations are allowed on Global temporary tables and visible to all sessions connected to the database.
Private temporary tables – These tables metadata stored in memory rather than disk and the lifetime of the private temporary tables is only during the session which created it.
Rolling Forward a Standby – Using RMAN a standby database can be refreshed using RECOVER STANDBY DATABASE over the network. This command restarts the standby instance and refreshes from primary database.
Standby Nologging for Load Performance
Standby Nologging for Data Availability.
ADG_ACCOUNT_INFO_TRACKING – This parameter enables maintaining a local copy of users account information in standby’s memory. The login failures are tracked and denied when failure limit reached. The default value is LOCAL and setting to GLOBAL triggers more secure behavior by maintaining a single copy of user account info across all Data Guard primary and standby databases.
$DATAGUARD_PROCESS – This view replaces V$MANAGED_STANDBY and it maintains the information to verify that redo is being transmitted from primary database and applied on standby database.
Block Change Tracking is now supported with multi-instance redo apply

New in Oracle 19c

DML operations on Active Data Guard standby – This helps applications or reporting’s which run occasionally DML and mostly read. The DML operations on standby will be redirected to run on the primary, if they do not contain bind variables and the Active data guard session waits until the changes are applied to the Active data guard standby.
DML operation on Oracle XA transactions are not supported on Active data guard standby
To redirect top-level PL/SQL operations that run on a standby to the primary database you can configure automatic redirection on the standby database. Use the following command ALTER SESSION ENABLE ADG_REDIRECT_PLSQL;
In Active data guard avoid running too many DML which can impact performance on primary
Between Primary and standby read-consistency will be maintained but other standby instances can view only after the transaction is committed.
In case of RAC, you can choose to run MRP on specific.  From Oracle 19c, you can enable Oracle database In-Memory column store and Multi-instance redo apply at the same time on Oracle Active Data Guard standby database.
Multi-instance redo apply introduced in Oracle 12c and which will allow to apply redo logs to multiple instances at same time. But there will have one MRP coordinator processor for all recovery processes on different instances.
In-Memory column and Multi-instance redo Apply
Automatic Flashback of a Mounted Standby – When you perform flashback or point-in-time recovery on primary database then standby that is in mounted mode can follow the same recovery procedure. This happens after a RESETLOGS operation on the primary. If you don’t want standby to flow the primary then stop the MRP process on the standby or keep the standby database in OPEN mode.
Replicating Restore Points from Primary to Standby – Before Oracle 19c Flashback feature is available on Primary only and now we can replicate the restore point of the primary to standby. This helps to flashing back a physical standby to a point in time.

Ragunathan Kannan