Monday, October 1, 2018

Data Guard Broker to unplug, migrate a single PDB into a new container - Using DGMGRL migrate

Migration of a single PDB or executing of a single PDB into another container database with minimal downtime. This method has zero impact to any remaining primary PDBs.  To use this method  the process takes advantage of a new functionality added to the Data Guard broker command line interface DGMGRL.

Important: The process are steps involve changes being made to 2 independent CDBs and is supported in Oracle RDBMS versions older than

The migration process overview

Monday, September 24, 2018

Point In time Recovery (PITR) issue with PDB When Local Undo Is Enabled

Bug 27693713 - PDB PITR Does Not Apply Incrementals When Local Undo Is Enabled

DB PITR does not apply incremental backup when PDB is configured with local undo
 (select * from database_properties where property_name = 'LOCAL_UNDO_ENABLED' and PROPERTY_VALUE = 'TRUE');

When restore pluggable database noredo is executed, it is supposed to apply incremental backups. Instead, media recovery is being performed when PDB local undo is enabled. this can take a long time.
Bug info 27693713

Maintain Standby Databases when Performing PDB online Clones | standby_pdb_source_file_dblink

In Oracle 12.2 a lot of new features are introduced for Multitenant 12.2 environments One of the possibility is to clone a pluggable databases while they are open for read/write operations. When we want to do this in a MAA environment this will introduce some problems Data Guard Impact on Oracle Multitenant Environments (Doc ID 2049127.1)

For this Oracle has some new parameters which can be used to overcome these problems
the parameter  "standby_pdb_source_file_dblink"

Friday, September 8, 2017

DataGuard FastSync : Define the Redo Transport Mode SYNC NOAFFRIM

FASTSYNC is a new DataGuard capability available with Oracle Database 12c. The FASTSYNC configures redo transport services for this configuration member using the SYNC and NOAFFIRM attributes of the LOG_ARCHIVE_DEST_n initialization parameter. The attribute NOAFFIRM specifies that the standby acknowledge receipt of redo without waiting for the write to the standby redo log file to complete. This mode is only available in maximum availability protection mode.

FASTSYNC transport mode uses the NOAFFIRM attribute of the LOG_ARCHIVE_DEST_n parameter, data loss is possible.

The following attributes of LOG_ARCHIVE_DEST_N initialization parameter define the redo transport mode that is used by primary database to send redo to the standby database:

Thursday, September 7, 2017

Implementation of a GoldenGate Replicate Hub: GoldenGate Remote Capture and Deliver Goldengate processes

Oracle GoldenGate can run on a machine separate from the source and/or target database server. The setup is called GoldenGate remote capturing and delivery. A creation of a GoldenGate Replicate Hub. On Oracle Databases the remote capture can be a remote integrated capture or downstream capture. For remote delivery can be an integrated delivery, a coordinated delivery or classic delivery.

Architect overview

GoldenGate Replicatie Hub - Remote Capture and Delivery

Monday, September 4, 2017

Dataguard: Redoroutes for Alternate Destinations Redo data Transport failover

Using the RedoRoutes Property for Remote Alternate Destinations within a Dataguard environments. The RedoRoutes property can be used to set up a remote alternate destination so that a terminal Standby Database ( Standby DB, Cascade Standby DB, FarSync DB) can still receive redo data even if the Standby Database from which it was receiving the redo data fails.

In this example below we have a primary cdb1 who send his redo data to the farsync instance. The farsync cdb1fs send the redo data to the standby database cdb2. See the instructions for building the dataguard environnment "MaxAvailability DataGuard environment : Adding a far sync instance to the environment". Is it possible to configure a setup, when the primary database, cdb1, send the redo data directly to standby database CDB2 in a case that the farsync csb1fs is not available.  And when the FAR SYNC instance cdb1fs is operational again the configuration is operational again as designed.

Wednesday, August 30, 2017

MaxAvailability DataGuard environment : Adding a far sync instance to the environment

An Oracle Data Guard far sync instance is a remote Oracle Data Guard destination that accepts redo
from the primary database and then ships that redo to other members of the Oracle Data Guard configuration. A far sync instance manages a control file, receives redo into standby redo logs (SRLs), and archives those SRLs to local archived redo logs, but that is where the similarity with  standbys ends. A far sync instance does not have user data files, cannot be opened for access, cannot run redo apply, and can never function in the primary role or be converted to any type of standby database.

Far Sync is a lightweight Oracle instance that has only a control file, spfile, password file
and standby log files, there are no database files or online redo logs

Oracle Far Sync provides the ability to perform a zero data loss failover to a remote standby database without requiring a second standby database or complex operation. Far Sync enables this by deploying a Far Sync instance at a distance that is within an acceptable range of the primary for SYNC transport. The Far Sync instance receives redo from the primary via SYNC transport. and immediately forwards the redo to the standby databases via ASYNC transport.

The Far Sync instance can also forward redo to the new Oracle Database Backup, Logging, and Recovery Appliance

First we create a DataGuard environment in Max Aviability mode.