After you switch to customer-managed keys, some database operations might be affected when the key is unreachable.

If the database is unable to access your key for some reason, such as a network outage, then Autonomous Database handles the outage as follows:

• There is a 2-hour grace period where the database remains up and running.

• If the key is not reachable at the end of the 2-hour grace period, the database Lifecycle state is set to Inaccessible. In this state existing connections are dropped and new connections are not allowed.

• If Autonomous Data Guard is enabled when using Oracle Cloud Infrastructure Vault, during or after the 2-hour grace period you can manually try to perform a failover operation. Autonomous Data Guard automatic failover is not triggered when you are using customer-managed encryption keys and the Oracle Cloud Infrastructure Vault is unreachable.

  Note
  
  Only Oracle Cloud Infrastructure Vault is supported with Autonomous Data Guard.

• If Autonomous Database is stopped, then you cannot start the database when the keys are unreachable.

  For this case, the work request shown when you click Work Requests on the Oracle Cloud Infrastructure console under Resources shows:

  The Vault service is not accessible. 
  Your Autonomous Database could not be started. Please contact Oracle Support.

After you switch to customer-managed keys, some database operations might be affected if the master key is disabled or deleted.

• For disable/delete key operations where the Master Encryption Key State is any of the following:

  Key Vault	Key State
  Oracle Cloud Infrastructure (OCI) Vault	DISABLING DISABLED DELETING DELETED SCHEDULING_DELETION PENDING_DELETION
  AWS Key Management System (KMS)	Disabled PendingDeletion
  Azure Key Vault	DISABLED DELETED
  Oracle Key Vault (OKV)	COMPROMISED DEACTIVATED DESTROYED

  The database becomes Inaccessible after the key Lifecycle state goes into one of these states. When the key is in any of these states, Autonomous Database drops existing connections and does not allow new connections.

  The database becoming inaccessible can take up to 15 min after the key operations (Autonomous Database checks the key provider at 15 minute intervals).

• If you disable or delete the Oracle Cloud Infrastructure Vault key used by your Autonomous Database while Autonomous Data Guard is enabled, Autonomous Data Guard will not perform an automatic failover.

  Note
  
  Only Oracle Cloud Infrastructure Vault is supported with Autonomous Data Guard.

• If you enable a disabled key, the database automatically goes into the Available state.

• If you delete the master key you can check the key history in the Oracle Cloud Infrastructure Console to find the keys that were used for the database. The history shows you the key name, along with an activation timestamp. If one of the older keys from the history list is still available, then you can restore the database to the time when the database was using that key, or you can clone from a backup to create a new database with that timestamp.

See View History for Customer-Managed Encryption Keys on Autonomous Database for more information.

After you switch to customer-managed keys, some database operations might be affected if the master key is rotated, disabled, or deleted and you do not have a valid key to restore your data from a previously saved backup or from a clone.

• It is recommended that you create a new key that hasn't been used for rotation in the last 60 days and use that key for rotation. This makes sure that you can go back to a backup if the current key is deleted or disabled.

• When you perform multiple encryption key rotations within 60 days, it is recommended that you either create a new key for each master encryption key rotation operation or specify a key that has not been used in the last 60 days. This helps to save at least one key you can use to recover your data from a backup, in the case where a customer-managed master encryption key is disabled or deleted.

See View History for Customer-Managed Encryption Keys on Autonomous Database for more information.

Autonomous Data Guard is supported when using customer-managed keys with the key provider Oracle Cloud Infrastructure Vault.

Note the following when you are using Autonomous Data Guard with a standby database with customer-managed keys:

• In order for a remote standby to use the same master encryption key as primary, the master encryption key must be replicated to the remote region.

  Customer-Managed Encryption Keys are only supported with a single cross-region Autonomous Data Guard standby. Multiple cross-region standbys are not supported because Oracle Cloud Infrastructure Vault only supports replication to one remote region.

• The primary database and the standby database use the same key. In the event of a switchover or failover to the standby, you can continue to use the same key.

• When you rotate the customer-managed key on the primary database, this is reflected on the standby database.

• When you switch from customer-managed keys to Oracle-managed keys the change is reflected on the standby database.

• When the Oracle Cloud Infrastructure Vault is unreachable, there is a 2-hour grace period before the database goes into the INACCESSIBLE state. You can perform a failover during or after this 2-hour grace period.

• If you disable or delete the Oracle Cloud Infrastructure master encryption key that your Autonomous Database is using with customer-managed keys while Autonomous Data Guard is enabled, Autonomous Data Guard does not perform an automatic failover.

• Customer-Managed Encryption Keys are not supported with Cross Tenancy Autonomous Data Guard.

See the following for more information:

• To Replicate a Vault and Its Keys

• Autonomous Data Guard with Customer Managed Keys
• Overview of Vault

Autonomous Database does not support using customer-managed encryption keys with a refreshable clone.

• You cannot create a refreshable clone from a source database that uses customer-managed encryption keys. Additionally, you cannot switch to a customer-managed encryption key on a source database that has one or more refreshable clones.

To use customer-managed master encryption keys with a Vault in a remote tenancy, note the following:

When you use customer-managed master encryption keys with a Vault in a remote tenancy, the Vault and the Autonomous Database instance must be in the same region. To change the tenancy, on the sign-on page click Change tenancy. After you change the tenancy, make sure to select the same region for both the Vault and the Autonomous Database instance.