You can configure isolated mode by setting WALLET_ROOT in the initialization parameter file in the CDB root and TDE_CONFIGURATION in the PDB you want to isolate.

1. Connect to the PDB as a user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
2. Run the ALTER SYSTEM statement to configure the WALLET_ROOT and TDE_CONFIGURATION parameters for the CDB environment.
   • If the CDB root and the PDB are open, then set SCOPE to both:

     ALTER SYSTEM SET TDE_CONFIGURATION="KEYSTORE_CONFIGURATION=keystore_type" SCOPE=both;

   • If the CDB root is open and the PDB is in the mount state, then set scope to spfile:

     ALTER SYSTEM SET TDE_CONFIGURATION="KEYSTORE_CONFIGURATION=keystore_type" SCOPE=spfile;

3. Check the configuration.
   • To check the TDE_CONFIGURATION parameter setting:

     SHOW PARAMETER TDE_CONFIGURATION
     

     The output should reflect the keystore configuration that you set for the current PDB. If it shows a different keystore configuration (for example, FILE if you had set it to OKV), then the setting may be showing the keystore configuration that was set for the CDB root, in united mode.

   • To check the keystore mode:

     SELECT KEYSTORE_MODE FROM V$ENCRYPTION_WALLET;

     The output should be ISOLATED.

You can set TDE_CONFIGURATION if you have an older version of a control file that must be restored and only a few PDBs were configured in isolated mode.

When the CDB root and the PDB are both in the mount state, then you can only change the PDB’s keystore configuration from the CDB root.

1. Log in to the CDB root as a user who was granted the SYSDBA administrative privilege.

2. For each PDB that you want to change, use the following syntax:

   ALTER SYSTEM SET TDE_CONFIGURATION="CONTAINER=pdb_name;KEYSTORE_CONFIGURATION=keystore_type" SCOPE=memory;
   

   For example, for the hrpdb and salespdb PDBs using FILE (for software keystores) as the keystore type:

   ALTER SYSTEM SET TDE_CONFIGURATION="CONTAINER=hrpdb;KEYSTORE_CONFIGURATION=FILE" SCOPE=memory;
   ALTER SYSTEM SET TDE_CONFIGURATION="CONTAINER=salespdb;KEYSTORE_CONFIGURATION=FILE" SCOPE=memory;
   

3. After you set the TDE_CONFIGURATION parameter for each PDB, log in to the CDB root and then set TDE_CONFIGURATION for the CDB root itself.

   ALTER SYSTEM SET TDE_CONFIGURATION="KEYSTORE_CONFIGURATION=FILE";

   At this stage, CDB root is in the mounted state. The value of the TDE_CONFIGURATION parameter that was set using ALTER SYSTEM with the CONTAINER attribute is only present in the memory of the CDB root. To ensure that the configuration is properly applied to each PDB, you must close and then reopen the PDB. When an isolated mode PDB is opened, the configuration set by the ALTER SYSTEM statement that was issued in the CDB root is read from the control file and then is automatically applied to the PDB.

4. Connect to each PDB and then close and reopen the PDB.

   ALTER PLUGGABLE DATABASE pdb_name CLOSE IMMEDIATE;
   ALTER PLUGGABLE DATABASE pdb_name OPEN;

You can address the problem of a lost control file by using the ALTER SYSTEM statement.

Running these statements with SCOPE set to memory will store the CONTAINER value in memory. When you open the isolated PDB, this configuration will automatically be updated for the PDB.

If you are using an Oracle Data Guard environment, then to correct the control file, run these statements on both the primary and the standby databases.

1. Log in to the CDB root as a user who was granted the SYSDBA administrative privilege.

2. If you are unsure of the exact state of the system, then you should run ALTER SYSTEM with RESET.

   For example:

   ALTER SYSTEM RESET TDE_CONFIGURATION SCOPE=memory;

3. For each PDB that you want to change, use the following syntax:

   ALTER SYSTEM SET TDE_CONFIGURATION="CONTAINER=pdb_name;KEYSTORE_CONFIGURATION=FILE" SCOPE=memory; 
   

   For example, for the hrpdb and salespdb PDBs with FILE (for software keystores) as the keystore type:

   ALTER SYSTEM SET TDE_CONFIGURATION="CONTAINER=hrpdb;KEYSTORE_CONFIGURATION=FILE" SCOPE=memory; 
   ALTER SYSTEM SET TDE_CONFIGURATION="CONTAINER=salespdb;KEYSTORE_CONFIGURATION=FILE" SCOPE=memory; 
   

4. After you set the TDE_CONFIGURATION parameter for each PDB, log in to the CDB root and then set TDE_CONFIGURATION for the CDB root itself.

   ALTER SYSTEM SET TDE_CONFIGURATION="KEYSTORE_CONFIGURATION=FILE";

   At this stage, CDB root is in the mounted state. The value of the TDE_CONFIGURATION parameter that was set using ALTER SYSTEM with the CONTAINER attribute is only present in the memory of the CDB root. To ensure that the configuration is properly applied to each PDB, you must close and then reopen the PDB. When an isolated mode PDB is opened, the configuration set by the ALTER SYSTEM statement that was issued in the CDB root is read from the control file and then is automatically applied to the PDB.

5. Connect to each PDB and then close and reopen the PDB.

   ALTER PLUGGABLE DATABASE pdb_name CLOSE IMMEDIATE;
   ALTER PLUGGABLE DATABASE pdb_name OPEN;

You can use ALTER SYSTEM to configure isolated mode in an Oracle Real Application Clusters (Oracle RAC) environment.

1. To ensure that the effect of the ALTER SYSTEM statement is applied on each Oracle RAC node, specify the wildcard (*) in the SID clause of the ALTER SYSTEM statement, as follows. You can run this statement from either the CDB root or a PDB.

   ALTER SYSTEM SET TDE_CONFIGURATION="KEYSTORE_CONFIGURATION=keystore_type" SID='*';

2. If you ran this statement in the CDB root, then restart the database. If you executed it from a PDB, then close and open the PDB.

You can create all types of software keystores in isolated mode: password-protected, password protected with the credential provided from an external store, auto-login, local auto-login.

To enable encryption in the PDB after it is configured in isolated mode with the KEYSTORE_CONFIGURATION attribute set to FILE (that is, to use a software keystore), you must create a software keystore, open the software keystore, and then set a TDE master encryption key in the software keystore. Afterward, you can begin to encrypt data for tables and tablespaces that will be accessible in the PDB.

In a multitenant environment, you can create a secure external store to hold the credentials of the software keystore. This feature enables you to hide the keystore password: it removes the need for storing the keystore password in any script or tool that accesses the database without user intervention, such as an overnight batch script. When the WALLET_ROOT parameter is specified, the location of the external store for the CDB root is WALLET_ROOT/tde_seps and for the PDB it is WALLET_ROOT/PDB-GUID/tde_seps. When the WALLET_ROOT parameter is set, there is no longer a single central external store, so when a keystore password is updated, the corresponding external store must be updated as well. When the WALLET_ROOT parameter is not specified, then the location of the external store is the same for both the CDB root and for every PDB. The external store location must then be set by the EXTERNAL_KEYSTORE_CREDENTIAL_LOCATION initialization parameter. When the WALLET_ROOT parameter is not specified, then there is a single central external store, so when you update the keystore password, only the central external store at the EXTERNAL_KEYSTORE_CREDENTIAL_LOCATION must be updated.

In a multitenant environment, different PDBs can access this external store location when you run the ADMINISTER KEY MANAGEMENT statement using the IDENTIFIED BY EXTERNAL STORE clause. This way, you can centrally locate the password and then update it only once in the external store.

A password-protected software keystore requires a password to protect the keystore keys and credentials.

1. Log in to the isolated mode PDB as a user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
   For example:

   sqlplus sec_admin@hrpdb as syskm
   Enter password: password

   Contact your SYSDBA administrator for the correct PDB. To check the current container, run the SHOW CON_NAME command.

2. Run the ADMINISTER KEY MANAGEMENT SQL statement to create the keystore using the following syntax:

   ADMINISTER KEY MANAGEMENT CREATE KEYSTORE 
   ['keystore_location'] 
   IDENTIFIED BY software_keystore_password;
   

   In this specification:

   • keystore_location is the path to the keystore directory location of the password-protected keystore. If the path that is set by the WALLET_ROOT parameter is the path that you want to use, then you can omit the keystore_location setting.

     If you specify the keystore_location, then enclose it in single quotation marks (' '). To find this location, you can query the WRL_PARAMETER column of the V$ENCRYPTION_WALLET view. (If the keystore was not created in the default location, then the STATUS column of the V$ENCRYPTION_WALLET view is NOT_AVAILABLE.)

   • software_keystore_password is the password of the keystore that you, the security administrator, creates.

   For example, to create the keystore in the default location (assuming WALLET_ROOT is set):

   ADMINISTER KEY MANAGEMENT CREATE KEYSTORE 
   IDENTIFIED BY password;
   keystore altered.
   

To open a software keystore in isolated mode, you must use the ADMINISTER KEY MANAGEMENT statement with the SET KEYSTORE OPEN clause.

1. Log in to the isolated mode PDB as a user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.

   Contact your SYSDBA administrator for the correct PDB. To check the current container, run the SHOW CON_NAME command.

2. Run the ADMINISTER KEY MANAGEMENT statement to open the keystore.

   ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN 
   IDENTIFIED BY password;
   keystore altered.

   To switch over to opening the password-protected software keystore when an auto-login keystore is configured and is currently open, specify the FORCE KEYSTORE clause as follows.

   ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN 
   FORCE KEYSTORE 
   IDENTIFIED BY EXTERNAL STORE;
   keystore altered.

   Here, the IDENTIFIED BY EXTERNAL STORE clause is included in the statement because the keystore credentials exist in an external store. This enables the password-protected keystore to be opened without specifying the keystore password within the statement itself.

   If the WALLET_ROOT parameter has been set, then Oracle Database finds the external store by searching in this path: WALLET_ROOT/PDB_GUID/tde_seps.

3. Confirm that the keystore is open.

   SELECT STATUS FROM V$ENCRYPTION_WALLET;

To set the TDE master encryption key in a software keystore in an isolated mode PDB, use the ADMINISTER KEY MANAGEMENT statement with the SET KEY clause.

1. Log in to the isolated mode PDB as a user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
2. Ensure that the database is open in READ WRITE mode.
   To find the status, run the show pdbs command.
3. Run the ADMINISTER KEY MANAGEMENT SQL statement to set the key in the software keystore.
   For example, if the keystore of the PDB is password-protected, the PDB is open, and the keystore of the PDB is open:

   ADMINISTER KEY MANAGEMENT SET KEY 
   IDENTIFIED BY keystore_password 
   WITH BACKUP USING 'emp_key_backup';
   
   keystore altered.

   If the keystore is closed:

   ADMINISTER KEY MANAGEMENT SET KEY 
   FORCE KEYSTORE 
   IDENTIFIED BY keystore_password 
   WITH BACKUP USING 'emp_key_backup';
   
   keystore altered.

   In this specification:

   • FORCE KEYSTORE should be included if the keystore is closed. This automatically opens the keystore before setting the TDE master encryption key. The FORCE KEYSTORE clause also switches over to opening the password-protected software keystore when an auto-login keystore is configured and is currently open.

   • IDENTIFIED BY specifies the keystore password. Alternatively, if the keystore password is in an external store, you can use the IDENTIFIED BY EXTERNAL STORE clause.

4. Confirm that the TDE master encryption key is set.

   SELECT MASTERKEY_ACTIVATED FROM V$DATABASE_KEY_INFO;

   The output should be YES.

Now that you have completed the keystore configuration and the PDB is configured in isolated mode, you can begin to encrypt data in the PDB.

You can configure a hardware keystore for a PDB when the PDB is configured in isolated mode.

To configure a hardware keystore for a PDB in isolated mode, you first must set the WALLET_ROOT parameter. This is necessary for two reasons: first, to have support for migrating to a software keystore in the future, and second, because the configuration file for Oracle Key Vault is retrieved from a location under WALLET_ROOT. Afterwards, you must set the KEYSTORE_CONFIGURATION attribute of the TDE_CONFIGURATION parameter to HSM or OKV, open the configured hardware keystore, and then set the TDE master encryption key for the PDB. After you complete these tasks, you can begin to encrypt data in the PDB.

How you specify the IDENTIFIED BY clause when you run the ADMINISTER KEY MANAGEMENT statement depends on the type of hardware keystore. For a hardware security module (HSM), you use the following syntax:

IDENTIFIED BY "user_name:password"

For an Oracle Key Vault keystore, you can omit the user_name and colon, but you must enclose the password in quotation marks:

IDENTIFIED BY "password"

To configure a third-party hardware security module, you must copy your vendor’s PKCS#11 library to the correct location and follow your vendor's instructions.

To open a hardware keystore in an isolated mode PDB, you must use the ADMINISTER KEY MANAGEMENT statement with the SET KEYSTORE OPEN clause.

1. Log in to the isolated mode PDB as a user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
   For example:

   sqlplus sec_admin@hrpdb as syskm
   Enter password: password

   Contact your SYSDBA administrator for the correct PDB. To check the current container, run the SHOW CON_NAME command.

2. Open the hardware keystore by using the following syntax:

   ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN 
   IDENTIFIED BY "hardware_keystore_credentials";
   

   The type of hardware keystore determines how you specify the hardware keystore password. For hardware security modules, you must use the user_name:password syntax. For example:

   ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN 
   IDENTIFIED BY "psmith:password";
   
   keystore altered.

   For an Oracle Key Vault keystore, you can only provide the password. No user name is allowed in the IDENTIFIED BY clause. Enclose the password in double quotation marks.

   ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN 
   IDENTIFIED BY "password";

3. Repeat this procedure each time you restart the database instance.
   You must open the keystore of the CDB root first.

After you have opened the hardware keystore in an isolated mode PDB, you are ready to set the TDE master encryption key for the PDB.

• Setting a New TDE Master Encryption Key in Isolated Mode
  You should complete this procedure if you have not previously configured a hardware keystore for Transparent Data Encryption.
• Migration of a Previously Configured Encryption Key in Isolated Mode
  You must migrate the previously configured master encryption key if you previously configured a software keystore.

Now that you have completed the keystore configuration and the PDB is configured in isolated mode, you can begin to encrypt data in the PDB.

You can change the password of a software keystore when the PDB is in isolated mode.

To change the password of a hardware keystore, you must use the administrative interface of the hardware keystore. You cannot perform this operation by using the ADMINISTER KEY MANAGEMENT statement.

• Changing the Password-Protected Software Keystore Password in Isolated Mode
  To change the password of a password-protected software keystore in isolated mode, you must use the ADMINISTER KEY MANAGEMENT statement.
• Changing the Password of a Hardware Keystore in Isolated Mode
  To change the password of a hardware keystore, you must close the hardware keystore and then change the password from the hardware keystore’s management interface.

You can close both software and hardware keystores in isolated mode, unless the system tablespace is encrypted.

• Closing a Software Keystore in Isolated Mode
  You can close password-protected keystores, auto-login keystores, and local auto-login software keystores in isolated mode.
• Closing a Hardware Keystore in Isolated Mode
  To close a hardware keystore, you must use the ADMINISTER KEY MANAGEMENT statement with the SET KEYSTORE CLOSE clause.

To create a user-defined TDE master encryption key, use the ADMINISTER KEY MANAGEMENT statement with the SET | CREATE [ENCRYPTION] KEY clause.

1. Log in to the isolated mode PDB as a user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
2. Create the user-defined TDE master encryption key by using the following syntax:

   ADMINISTER KEY MANAGEMENT SET | CREATE [ENCRYPTION] KEY
   'mkid:mk | mk' 
   [USING ALGORITHM 'algorithm'] 
   [FORCE KEYSTORE]
   IDENTIFIED BY [EXTERNAL STORE | keystore_password] 
   [WITH BACKUP [USING 'backup_identifier']];

   In this specification:

   • SET | CREATE : Enter SET if you want to create the master and activate the TDE master encryption key now, or enter CREATE if you want to create the key for later use, without activating it yet.

   • mkid and mk:

     • mkid, the TDE master encryption key ID, is a 16–byte hex-encoded value that you can specify or have Oracle Database generate.

     • mk, the TDE master encryption key, is a hex-encoded value that you can specify or have Oracle Database generate, either 32 bytes (for the for AES256, ARIA256, and GOST256 algorithms) or 16 bytes (for the SEED128 algorithm).

     If you omit the mkid:mk|mkid clause but include the mk value, then Oracle Database generates the mkid for the mk.

     If you omit the entire mkid:mk|mkid clause, then Oracle Database generates these values for you.

   • USING ALGORITHM: Specify one of the following supported algorithms:

     • AES256

     • ARIA256

     • SEED128

     • GOST256

     If you omit the algorithm, then the default, AES256, is used.

   • FORCE KEYSTORE temporarily opens the password-protected keystore for this operation. You must open the keystore for this operation.

   The following example includes a user-created TDE master encryption key but no TDE master encryption key ID, so that the TDE master encryption key ID is generated:

   ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY 
   '3D432109DF88967A541967062A6F4E460E892318E307F017BA048707B402493C' 
   USING ALGORITHM 'GOST256'
   FORCE KEYSTORE
   IDENTIFIED BY keystore_password;

   The next example creates user-defined keys for both the master encryption ID and the TDE master encryption key. It omits the algorithm specification, so the default algorithm AES256 is used.

   ADMINISTER KEY MANAGEMENT CREATE ENCRYPTION KEY 
   '10203040506070801112131415161718:3D432109DF88967A541967062A6F4E460E892318E307F017BA048707B402493C' 
   IDENTIFIED BY keystore_password;

A keystore must be open before you can create a TDE master encryption key for use later on in isolated mode.

1. Log in to the isolated mode PDB as a user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.

   Contact your SYSDBA administrator for the correct PDB. To check the current container, run the SHOW CON_NAME command.

2. Create the TDE master encryption key by using the following syntax:

   ADMINISTER KEY MANAGEMENT CREATE KEY 
   [USING TAG 'tag'] 
   [FORCE KEYSTORE] 
   IDENTIFIED BY [EXTERNAL STORE | keystore_password] 
   [WITH BACKUP [USING 'backup_identifier']];
   

   In this specification:

   • FORCE KEYSTORE temporarily opens the password-protected keystore for this operation. You must open the keystore for this operation.

   • IDENTIFIED BY is required for the BACKUP KEYSTORE operation on a password-protected keystore because although the backup is simply a copy of the existing keystore, the status of the TDE master encryption key in the password-protected keystore must be set to BACKED UP and for this change the keystore password is required.

   • keystore_location is the path at which the backup keystore is stored. This setting is restricted to the PDB when the PDB lockdown profile EXTERNAL_FILE_ACCESS setting is blocked in the PDB or when the PATH_PREFIX variable was not set when the PDB was created. If you do not specify the keystore_location, then the backup is created in the same directory as the original keystore. Enclose this location in single quotation marks (' ').

   For example:

   ADMINISTER KEY MANAGEMENT CREATE KEY 
   FORCE KEYSTORE 
   IDENTIFIED BY keystore_password
   WITH BACKUP;

3. If necessary, activate the TDE master encryption key.
   1. Find the key ID.

      SELECT KEY_ID FROM V$ENCRYPTION_KEYS; 
      
      KEY_ID
      ----------------------------------------------------
      AWsHwVYC2U+Nv3RVphn/yAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

   2. Use this key ID to activate the key.

      ADMINISTER KEY MANAGEMENT USE KEY 
      'AWsHwVYC2U+Nv3RVphn/yAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAA' 
      USING TAG 'quarter:second;description:Activate Key on standby' 
      IDENTIFIED BY password 
      WITH BACKUP;

In isolated mode, you can move an existing TDE master encryption key into a new keystore from an existing software password keystore.

1. Log in to the isolated mode PDB as a user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
2. Query the CREATION_TIME and KEY_ID columns of the V$ENCRYPTION_KEYS view to find the key identifier of the key that you want to move.
   For example:

   SELECT CREATION_TIME, KEY_ID FROM V$ENCRYPTION_KEYS; 
   
   CREATION TIME
   ----------------------------------------------------
   22-SEP-17 08.55.12.956170 PM +00:00
   
   KEY_ID
   ----------------------------------------------------
   ARaHD762tUkkvyLgPzAi6hMAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

3. Move the key into a new keystore by using the following syntax:

   ADMINISTER KEY MANAGEMENT 
   MOVE [ENCRYPTION] KEYS
   TO NEW KEYSTORE 'keystore_location1'
   IDENTIFIED BY keystore1_password
   FROM [FORCE] KEYSTORE
   IDENTIFIED BY keystore_password
   [WITH IDENTIFIER IN
   { 'key_identifier' [, 'key_identifier' ]... | ( subquery ) }]
   [WITH BACKUP [USING 'backup_identifier'] ];

   In this specification:

   • keystore_location1 is the path to the wallet directory that will store the new keystore .p12 file. By default, this directory is $ORACLE_BASE/admin/db_unique_name/wallet.

   • FORCE temporarily opens the keystore for this operation.

   • keystore_password is the password for the keystore from which the key is moving.

   For example:

   ADMINISTER KEY MANAGEMENT MOVE KEYS 
   TO NEW KEYSTORE '$ORACLE_BASE/admin/orcl/wallet' 
   IDENTIFIED BY keystore_password 
   FROM FORCE KEYSTORE 
   IDENTIFIED BY keystore_password 
   WITH IDENTIFIER IN 
   (SELECT KEY_ID FROM V$ENCRYPTION_KEYS WHERE ROWNUM < 2)
   WITH BACKUP;

   After the keys are moved to the new keystore, they no longer exist in the old keystore.
4. To delete the old keystore, go to the wallet directory and do the following:
   1. Back up the .p12 file containing the keystore that you want to delete.
   2. Manually delete the .p12 file containing the keystore.
   To find the location of the keystore, open the keystore, and then query the WRL_PARAMETER column of the V$ENCRYPTION_WALLET view.

You can perform migration and reverse migration operations between software keystores and hardware keystores in isolated mode.

• Migrating from a Password-Protected Software Keystore to a Hardware Keystore in Isolated Mode
  In isolated mode, you can migrate from a password-protected software keystore to a hardware keystore.
• Migrating from a Hardware Keystore to a Password-Protected Software Keystore in Isolated Mode
  In isolated mode, you can migrate from a hardware keystore to a password-protected software keystore.

In isolated mode, the REMOVE_INACTIVE_STANDBY_TDE_MASTER_KEY initialization parameter can configure the automatic removal of inactive master encryption keys.

1. Log in to the server where the isolated mode PDB standby database resides.
2. Locate the init.ora file for the database.
   By default, init.ora file is located in the $ORACLE_HOME/dbs directory.
3. Edit the init.ora file to include the REMOVE_INACTIVE_STANDBY_TDE_MASTER_KEY initialization parameter.
   For example:

   remove_inactive_standby_tde_master_key = true

   Setting this parameter to TRUE enables the automatic removal of inactive master encryption keys; setting it to FALSE disables the automatic removal.

Uniting a PDB keystore moves the TDE master encryption keys from the PDB keystore into the keystore of the CDB root. This enables the administrator of the keystore of the CDB root to manage the keys.

1. Log in to the isolated mode PDB as a user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
2. Unite the PDB keystore, which moves the TDE master encryption keys from the PDB keystore into the keystore of the CDB root, by using the following syntax:

   ADMINISTER KEY MANAGEMENT UNITE KEYSTORE
   IDENTIFIED BY isolated_keystore_password
   WITH ROOT KEYSTORE [FORCE KEYSTORE]
   IDENTIFIED BY 
   [EXTERNAL STORE | keystore_password_of_cdb_root]
   [WITH BACKUP [USING backup_id]];

   In this specification:

   • FORCE KEYSTORE temporarily opens the password-protected keystore for this operation if an auto-login keystore is open (and in use) or if the keystore is closed.

   • united_keystore_password: Knowledge of this password does not enable the user who performs the UNITE KEYSTORE operation privileges to perform ADMINISTER KEY MANAGEMENT UNITE KEYSTORE operations on the PDB.

   When the keystore of a PDB is united with a keystore in the CDB root, all of the previously active (historical) TDE master encryption keys that were associated with the PDB are moved to the keystore of the CDB root.
3. Confirm that the isolated mode PDB is now a united mode PDB.

   SELECT KEYSTORE_MODE FROM V$ENCRYPTION_WALLET;

   The output should be UNITED.

When you create a keystore in a PDB that is closed, the new keystore is empty and the PDB is converted to isolated mode.

• About Creating a Keystore When the PDB Is Closed
  Creating a keystore in a PDB that is closed could inadvertently cause problems in rekey operations, but the keystore creation can be reverted.
• Reverting a Keystore Creation Operation When a PDB Is Closed
  If you have inadvertently created a keystore in a PDB (and thereby caused it to become configured in isolated mode), then you should reverse the keystore creation operation.

In isolated mode, you can automatically move a PDB from one CDB to another (for example, for load balancing or adding new functionality).

1. Before you begin the PDB move operation, log in to the CDB root as a user who has been granted the SYSDBA administrative privilege.
   For example:

   sqlplus c##sec_admin as sysdba
   Enter password: password

2. Set the ONE_STEP_PLUGIN_FOR_PDB_WITH_TDE dynamic initialization parameter TRUE.
   For example:

   ALTER SYSTEM SET ONE_STEP_PLUGIN_FOR_PDB_WITH_TDE = TRUE;

3. Move (relocate) the PDB.

The CREATE PLUGGABLE DATABASE statement with the KEYSTORE IDENTIFIED BY clause can clone a PDB that has encrypted data.

1. Log in to the isolated mode PDB as a user who was granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
2. Ensure that the software keystore of the PDB that you plan to clone is open.

   You can query the STATUS column of the V$ENCRYPTION_WALLET view to find if the software keystore is open.

   For example:

   ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN FORCE KEYSTORE IDENTIFIED BY keystore_password;

3. Clone the PDB.

   For example:

   CREATE PLUGGABLE DATABASE cdb1_pdb3 FROM cdb1_pdb1 
   FILE_NAME_CONVERT=('cdb1_pdb1', 'pdb3/cdb1_pdb3') KEYSTORE 
   IDENTIFIED BY keystore_password;

   Replace keystore_password with the password of the keystore of the CDB where the cdb1_pdb3 clone is created.

   After you create the cloned PDB, encrypted data is still accessible by the clone using the master encryption key of the original PDB. After a PDB is cloned, there may be user data in the encrypted tablespaces. This encrypted data is still accessible because the master encryption key of the source PDB is copied over to the destination PDB. Because the clone is a copy of the source PDB but will eventually follow its own course and have its own data and security policies, you should rekey the master encryption key of the cloned PDB.
4. Rekey the master encryption key of the cloned PDB.

   For example:

   ADMINISTER KEY MANAGEMENT SET KEY 
   IDENTIFIED BY keystore_password 
   WITH BACKUP USING 'emp_key_backup';

   Before you rekey the master encryption key of the cloned PDB, the clone can still use master encryption keys that belong to the original PDB. However, these master encryption keys do not appear in the cloned PDB V$ dynamic views. Rekeying the master encryption key ensures that the cloned PDB uses its own unique keys, which will be viewable in the V$ views.

The CREATE PLUGGABLE DATABASE statement with the KEYSTORE IDENTIFIED BY clause can remotely clone a PDB that has encrypted data.

1. Log in to the isolated mode PDB as a user who was granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
2. Query the STATUS column of the V$ENCRYPTION_WALLET view to ensure that the software keystore of the PDB that you plan to clone is open.
3. Create a database link for the PDB that you want to clone remotely.
   Use the CREATE DATABASE LINK SQL statement to create the database link. You must create the database link by following the database link prerequisites that are required for cloning a remote PDB or a non-CDB.
4. Use the CREATE PLUGGABLE DATABASE statement with the KEYSTORE IDENTIFIED BY clause to perform the clone of the PDB.

   For example:

   CREATE PLUGGABLE DATABASE cdb1_pdb3 
   FROM cdb1_pdb1 
   FILE_NAME_CONVERT=('cdb1_pdb1', 'pdb3/cdb1_pdb3') KEYSTORE 
   IDENTIFIED BY keystore_password;

   Replace keystore_password with the password of the keystore of the CDB where the cdb1_pdb3 clone is created.

   After you create the cloned PDB, encrypted data is still accessible by the clone using the master encryption key of the original PDB. After a PDB is cloned, there may be user data in the encrypted tablespaces. This encrypted data is still accessible because the master encryption key of the source PDB is copied over to the destination PDB. Because the clone is a copy of the source PDB but will eventually follow its own course and have its own data and security policies, you should rekey the master encrytion key of the cloned PDB.
5. Rekey the master encryption key of the remotely cloned PDB.

   For example:

   ADMINISTER KEY MANAGEMENT SET KEY 
   FORCE KEYSTORE
   IDENTIFIED BY keystore_password 
   WITH BACKUP USING 'emp_key_backup';

   In this example, FORCE KEYSTORE is included because the keystore must be open during the rekey operation.

   Before you rekey the master encryption key of the cloned PDB, the clone can still use master encryption keys that belong to the original PDB. However, these master encryption keys do not appear in the cloned PDB V$ dynamic views. Rekeying the master encryption key ensures that the cloned PDB uses its own unique keys, which will be viewable in the V$ views.

The CREATE PLUGGABLE DATABASE statement with the KEYSTORE IDENTIFIED BY clause can relocate across CDBs a cloned PDB that has encrypted data.

1. Log in to the isolated mode PDB as a user who was granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege.
2. Query the STATUS column of the V$ENCRYPTION_WALLET view to ensure that the the software keystore of the PDB that you plan to clone is open.
3. Create a database link for the PDB that you want to clone remotely.
   Use the CREATE DATABASE LINK SQL statement to create the database link. You must create the database link by following the database link prerequisites that are required for cloning a remote PDB or a non-CDB.
4. Use the CREATE PLUGGABLE DATABASE statement with the KEYSTORE IDENTIFIED BY clause to clone the PDB.

   For example:

   CREATE PLUGGABLE DATABASE cdb1_pdb3 
   FROM cdb1_pdb1 
   FILE_NAME_CONVERT=('cdb1_pdb1', 'pdb3/cdb1_pdb3') KEYSTORE 
   IDENTIFIED BY keystore_password;

   Replace keystore_password with the password of the keystore of the CDB where the cdb1_pdb3 clone is created.

   After you create the cloned PDB, encrypted data is still accessible by the clone using the master encryption key of the original PDB. After a PDB is cloned, there may be user data in the encrypted tablespaces. This encrypted data is still accessible because the master encryption key of the source PDB is copied over to the destination PDB. Because the clone is a copy of the source PDB but will eventually follow its own course and have its own data and security policies, you should rekey the master encrytion key of the cloned PDB.
5. Use the ALTER PLUGGABLE DATABASE statement to perform the relocation operation.
   For example:

   ALTER PLUGGABLE DATABASE cdb1_pdb3
   OPEN RELOCATE TO 'need instance name example';

6. Rekey the master encryption key of the remotely cloned PDB.

   For example:

   ADMINISTER KEY MANAGEMENT SET KEY 
   FORCE KEYSTORE
   IDENTIFIED BY keystore_password 
   WITH BACKUP USING 'emp_key_backup';

   In this example, FORCE KEYSTORE is included because the keystore must be open during the rekey operation.

   Before you rekey the master encryption key of the cloned PDB, the clone can still use master encryption keys that belong to the original PDB. However, these master encryption keys do not appear in the cloned PDB V$ dynamic views. Rekeying the master encryption key ensures that the cloned PDB uses its own unique keys, which will be viewable in the V$ views.