Hybrid Disaster Recovery (DR) configurations in which the primary database runs on-premises (on Exadata or generic hardware) and the standby databases reside in Oracle Cloud on DBCS or ExaCS – or vice versa after a role transition – have become very popular.  These setups allow disaster recovery sites to be configured quickly in Oracle Cloud Infrastructure (OCI) without having to set up and maintain your own data centers in remote regions.  Several customers, such as 7-Eleven, successfully use hybrid DR configurations as a stepping stone to cloud adoption (see case study here: 8 Roads to Cloud Success).

With that in mind, Oracle development is always working on ways to simplify setting up Hybrid DR and moving to the cloud in general.  One obstacle that some customers encountered was Oracle Databases automatically being encrypted via TDE in the cloud where their on-premises databases may not be encrypted.  Previously, if the encryption was mixed (on-premises unencrypted, cloud encrypted), you could easily run into the challenges and problems listed below:

Customer Premises, unencrypted primary, Oracle Cloud Encrypted Standby

Challenge #1 – When the primary is on-premises
– New tablespaces created unencrypted on the primary
– Tablespaces were also created unencrypted on the standby
– The encryption on the standby was a manual task

Encrypted Cloud, shipping encrypted redo logs to customer premises

Challenge #2 – When the primary is on OCI
– New tablespaces created encrypted on OCI
– Tablespaces were also created encrypted on the standby
– This required Advanced Security Option
– Still highly recommended!

customer premises decrypt and apply

Challenge #3 – When the primary is on OCI
– The apply process had to decrypt the redo
– This required Advanced Security Option
– Still highly recommended!

The most effective solution to these challenges is to encrypt both the on-premises database and the OCI-based database.  This also addresses the need for data moving to and from the cloud to be secure and is why the standing Oracle MAA recommendation has always been to encrypt those on-premises databases. 

At the same time, we wanted to be conscious of the need for architectural flexibility to accommodate different customer requirements.  Therefore, we have introduced a new mechanism to accommodate mixed encryption Data Guard configurations with Oracle Database 19c July RU (19.16).
In short, a new init.ora or spfile parameter called TABLESPACE_ENCRYPTION (replacement for ENCRYPT_NEW_TABLESPACES) will provide more flexibility for mixed configurations where the on-premises database may or may not be encrypted in a hybrid DR configuration and the cloud DB (primary or standby) is encrypted. 
The intent is to reduce further friction for those looking to configure a Hybrid DR site (or production site) in OCI with the other site (production or otherwise) remaining on-premises.  In the following, you will find some details about the new property and associated functionality:

TABLESPACE_ENCRYPTION = { AUTO_ENABLE | MANUAL_ENABLE | DECRYPT_ONLY }

AUTO_ENABLEAlways store new data encrypted (mandatory on OCI) recommended for customers with Advanced Security Option (ASO).
DECRYPT_ONLYAlways decrypt and store unencrypted.  For customers without ASO.
MANUAL_ENABLEFallback to the previous behavior.
  • Redo decryption happens at recovery time.
  • Advanced Security Option is not required anymore. However, ASO is still a highly recommended best practice for security reasons. The property TABLESPACE_ENCRYPTION lets you decide whether or not to encrypt new tablespaces.
  • If the behavior specified by the ENCRYPT_NEW_TABLESPACES setting conflicts with the behavior determined by the TABLESPACE_ENCRYPTION setting, then the TABLESPACE_ENCRYPTION behavior takes precedence.
  • The property is set at the CDB level.
  • Cloud databases default (mandatory, changes to the value will be ignored in the cloud): AUTO_ENABLE
  • On-premises databases default: MANUAL_ENABLE

For example,  use the following configuration in a configuration that follows the best practice of having both on-premises and OCI (mandatory) encrypted:

— On-premises init.ora or spfile:
TABLESPACE_ENCRYPTION  = AUTO_ENABLE;
— OCI init.ora or spfile:
TABLESPACE_ENCRYPTION  = AUTO_ENABLE;

Hybrid DR Cloud Configuration Example

Important note regarding TDE prerequisites: You will need to setup your unencrypted primary or standby database as if it were encrypted. Therefore, you need a wallet with a master key set for root and all PDBs on the primary database and will need to copy this wallet over to the standby database after every set key operation, regardless of whether the primary or standby database is encrypted or not.

Stay tuned as we provide more examples and use cases around taking advantage of the TABLESPACE_ENCRYPTION property and other Cloud Maximum Availability Architecture (MAA) features and best practices here in our MAA guidelines.

In the meantime, via the links below, you can find the documentation around the new TABLESPACE_ENCRYPTION initialization parameter and the Oracle Database 19c July RU (19.16).