Friday, April 19, 2019

Configuring Read Only OracleHome - 18c

Starting with Oracle Database 18c, you can configure an Oracle home in read-only mode. In a read-only Oracle home, all the configuration data and log files reside outside of the read-only Oracle home. This feature allows you to use the read-only Oracle home as a software image that can be distributed across multiple servers.

The concept of a read-only Oracle home, Oracle has committed to to separate configuration files from binaries. The Configuring Read Only OracleHome 18c have impact on the following methods / DBCA / Patching / Upgrade / Key stores

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.