Encryption Conversions for Tablespaces and Databases

You can perform encryption operations on both offline and online tablespaces and databases.

About Encryption Conversion for Tablespaces and Databases

The CREATE TABLESPACE SQL statement can be used to create a new, encrypted tablespace. ALTER TABLESPACE can encrypt existing tablespaces.

In addition to encrypting new and existing tablespaces, you can encrypt full databases, which entails the encryption of the Oracle-managed tablespaces (in this release, the SYSTEM, SYSAUX, TEMP, and UNDO tablespaces). An Oracle-supplied tablespace contains information necessary for the correct functioning (confidentiality, integrity, and availability) of the database system. This information includes the system’s data dictionary, the system’s temporary sort area, the system’s undo segment, and the system’s auxiliary data. This information is only expected to be updated internally by the Oracle database server itself, and does not normally be updated directly by users.

To encrypt a full database, you use the ALTER TABLESPACE statement, not ALTER DATABASE, to encrypt the Oracle-managed tablespaces.

The following table compares the differences between an offline and an online encryption conversion of tablespaces and databases.

Functionality Offline Conversion Online Conversion
Release with minimum conversion capability Oracle Database 11g release 2 (11.2) Oracle Database 12c release 2 (12.2) and later
What can be backported? The ability to encrypt or decrypt a data file with the AES128 algorithm (using ALTER DATABASE DATAFILE data_file ENCRYPT or DECRYPT) can be used in Oracle Database releases 12.1.0.2 and 11.2.0.4. No
Algorithms supported All symmetric encryption algorithms that TDE supports. All symmetric encryption algorithm that TDE supports.
When can the conversion be run? When the tablespace is offline or the database is in the mount stage. When the tablespace is online and database is open in read/write mode.
Is auxiliary space required for the conversion? No Yes.
Oracle Data Guard conversion guidelines Convert both the primary and standby manually. Convert the standby first and then switch over to minimum downtime After you convert the primary, the standby conversion takes place automatically. You cannot perform an online conversion directly on the standby.
Encrypt the SYSTEM, SYSAUX, and UNDO tablespaces (database conversion) Oracle Database 12c release 2 (12.2) and later only. You must set COMPATIBILITY to 12.2.0.0. Only auto-login keystores are supported. Oracle Database 12c release 2 (12.2) and later only. You must set COMPATIBILITY to 12.2.0.0.
Can an existing TEMP tablespace be converted? No, but you can create an encrypted TEMP tablespace in Oracle Database 12c release 2 (12.2) and later, make it the default temporary tablespace, and then drop the original TEMP tablespace. No, but you can create an encrypted TEMP tablespace in Oracle Database 12c release 2 (12.2) and later, make it the default temporary tablespace, and then drop the original TEMP tablespace.
Can an existing tablespace be decrypted? You only can decrypt a tablespace or data file that was previously encrypted by an offline encrypt operation. Oracle does not recommend that you decrypt the UNDO tablespace once it is encrypted. Yes, but Oracle does not recommend that you decrypt the UNDO tablespace once it is encrypted.
Can encryption keys be rekeyed? No, but after the tablespace is encrypted, you can then use online conversion to rekey in Oracle Database 12c release 2 (12.2) compatibility. Yes
Can encryption operations be run in parallel? You can run parallel encryption conversions at the data file level with multiple user sessions running. You can run parallel encryption conversions at the tablespace level with multiple user sessions running.
What to do if an encryption conversion SQL statement fails to complete? Re-issue the encryption or decryption SQL statement to ensure that all the data files within the tablespace are consistently either encrypted or decrypted. Rerun the SQL statement but use the FINISH clause.

Related Topics

Impact of a Closed TDE Keystore on Encrypted Tablespaces

A TDE keystore can be closed or migrated when an Oracle-managed tablespace is encrypted, and the database system itself must be shut down to disallow operations on an Oracle-managed tablespace.

A closed TDE keystore has no impact on operations that involve an encrypted Oracle-managed tablespace (in this release, the SYSTEM, SYSAUX, TEMP, and UNDO tablespaces). This enables operations that are performed by background processes (for example, the log writer) to continue to work on these tablespaces while the TDE keystore is closed. If you want to disallow operations on an encrypted Oracle-managed tablespace, then you must shut down the database.

With regard to user-created tablespaces, a closed TDE keystore causes operations such as rotating a key or decrypting the tablespace to fail with an ORA-28365 wallet is not open error, just as it did in earlier releases. If you want to disallow operations on the user-created tablespace, then close the TDE keystore (or shut down the database).

User-created data can be copied into an encrypted Oracle-managed tablespace (for example, by an internal process such as DBMS_STATS statistics gathering) from a user-created tablespace while the TDE keystore is open. Closing the keystore does not prevent a user from viewing this data afterward, when the TDE keystore is in the CLOSED state at the time that you query the V$ENCRYPTION_WALLET view. Access to the original data by attempting to query an encrypted user-created tablespace will fail, resulting in an ORA-28365 wallet is not open error. The commands depend on whether the encrypted data is in a user-created or Oracle-managed tablespace. If data in one of these categories is not encrypted, commands for that category are not applicable (N/A). You can operate on non-encrypted data unless the instance is shut down.

When you open a database with an encrypted Oracle-managed tablespace, start the database in mount mode, open the TDE keystore, and then open the database. The system may need the TDE master encryption key to decrypt the bootstrap dictionary tables in the encrypted Oracle-managed tablespace.

In the commands below, replace password with the TDE keystore password.

Encrypted user-created tablespace data

Use these commands whether or not an Oracle-managed tablespace is encrypted.

To disallow operations on encrypted user-created tablespace data, run:

  1. ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY password;
  2. SHUTDOWN

To allow operations on encrypted user-created tablespace data, run:

  1. STARTUP MOUNT;
  2. ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY password;
  3. ALTER DATABASE OPEN

If no user-created tablespace is encrypted, commands for user-created tablespace data are not applicable.

Encrypted Oracle-managed tablespace data

Use these commands whether or not a user-created tablespace is encrypted.

To disallow operations on encrypted Oracle-managed tablespace data, run:

  1. SHUTDOWN

To allow operations on encrypted Oracle-managed tablespace data, run:

  1. STARTUP MOUNT;
  2. ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY password;
  3. ALTER DATABASE OPEN

If no Oracle-managed tablespace is encrypted, commands for Oracle-managed tablespace data are not applicable.

Restrictions on Using Transparent Data Encryption Tablespace Encryption

You should be aware of restrictions on using Transparent Data Encryption when you encrypt a tablespace.

Note the following restrictions:

Related Topics

Creating an Encrypted New Tablespace

When you create a new tablespace, you can configure its encryption settings during the creation process.

Step 1: Set the COMPATIBLE Initialization Parameter for Tablespace Encryption

You must set the COMPATIBLE initialization parameter before creating an encrypted tablespace.

About Setting the COMPATIBLE Initialization Parameter for Tablespace Encryption

A minimum COMPATIBLE initialization parameter setting of 11.2.0.0 enables the full set of tablespace encryption features.

Setting the compatibility to 11.2.0.0 enables the following functionality:

Related Topics

Setting the COMPATIBLE Initialization Parameter for Tablespace Encryption

To set the COMPATIBLE initialization parameter, you must edit the initialization parameter file for the database instance.

  1. Connect to the united mode CDB root or isolated mode PDB as a user who has been granted administrative privileges.

  2. Check the current setting of the COMPATIBLE parameter.

    For example:

    SHOW PARAMETER COMPATIBLE

NAME                                 TYPE        VALUE

------------------------------------ ----------- ------------------------------
compatible                           string      12.2.0.0
noncdbcompatible                     BOOLEAN     FALSE

  3. If you must change the COMPATIBLE parameter, then complete the remaining steps in this procedure.

    The value should be 11.2.0.0 or later.

  4. From the command line, locate the initialization parameter file for the database instance.

    • UNIX systems: This file is in the ORACLE_HOME/dbs directory and is named initORACLE_SID.ora (for example, initmydb.ora).

    • Windows systems: This file is in the ORACLE_HOME\database directory and is named initORACLE_SID.ora (for example, initmydb.ora).

  5. Edit the initialization parameter file to use the new COMPATIBLE setting.

    For example:

    COMPATIBLE=20.1.0.0

  6. Connect as a user who has the SYSDBA administrative privilege, and then restart the database.

    • From the CDB root:

      SHUTDOWN IMMEDIATE
STARTUP

    • From a PDB:

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

  7. If tablespace encryption is in use, then open the keystore at the database mount. The keystore must be open before you can access data in an encrypted tablespace.

    For example:

    STARTUP MOUNT;
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY keystore_password|EXTERNAL STORE;
ALTER DATABASE OPEN;

Step 2: Set the TDE Master Encryption Key

You must ensure that you have configured TDE by setting the WALLET_ROOT and TDE_CONFIGURATION parameters.

Set the TDE master encryption key either in the Oracle wallet, or in Oracle Key Vault. The commands for united and isolated PDBs are the same.

Step 3: Create the Encrypted Tablespace

After you have set the COMPATIBLE initialization parameter, you are ready to create the encrypted tablespace.

About Creating Encrypted Tablespaces

To create an encrypted tablespace, you can use the CREATE TABLESPACE SQL statement.

You must have the CREATE TABLESPACE system privilege to create an encrypted tablespace.

You can query the ENCRYPTED column of the DBA_TABLESPACES and USER_TABLESPACES data dictionary views to verify if a tablespace was encrypted.

Creating an Encrypted Tablespace

To create an encrypted tablespace, you must use the CREATE TABLESPACE statement with the ENCRYPTION USING clause.

Run the CREATE TABLESPACE statement, using its encryption clauses.

For example:

CREATE TABLESPACE encrypt_ts
  DATAFILE '$ORACLE_HOME/dbs/encrypt_df.dbf' SIZE 1M
  'ENCRYPTION ENCRYPT';

In this specification:

Related Topics

Example: Creating an Encrypted Tablespace That Uses AES192

You can use the CREATE TABLESPACE SQL statement to create an encrypted tablespace. Creating an Encrypted Tablespace That Uses AES192 creates a tablespace called securespace_1 that is encrypted using the AES192 algorithm.

CREATE TABLESPACE securespace_1
DATAFILE '/home/user/oradata/secure01.dbf'
SIZE 150M
ENCRYPTION USING 'AES192' ENCRYPT;

Example: Creating an Encrypted Tablespace That Uses the Default Algorithm

You can use the CREATE TABLESPACE SQL statement to create an encrypted tablespace that uses the default algorithm. Creating an Encrypted Tablespace That Uses the Default Algorithm creates a tablespace called securespace_2. Because no encryption algorithm is specified, the default encryption algorithm (AES256) is used.

CREATE TABLESPACE securespace_2
DATAFILE '/home/user/oradata/secure01.dbf'
SIZE 150M
ENCRYPTION ENCRYPT;

Setting the Tablespace Encryption Default Algorithm

The TABLESPACE_ENCRYPTION_DEFAULT_ALGORITHM applies to specific encryption scenarios.

These scenarios are as follows:

Enter the following ALTER SYSTEM statement:

ALTER SYSTEM SET TABLESPACE_ENCRYPTION_DEFAULT_ALGORITHM = value SCOPE=BOTH;

In this specification, value can be one of the following encryption algorithms: AES128, AES192, AES256, 3DES168, ARIA128, ARIA192, or ARIA256. The default encryption algorithm is AES256. In FIPS mode, this parameter can take only AES128, AES192, and AES256.

Oracle will offer support for FIPS 140-3 in 2026 for both Oracle AI Database 26ai and Oracle Database 19c. You may need to alter your encryption algorithm following the steps in Ensuring Encryption Algorithms are FIPS 140-3 Compliant.

Note: Starting with Oracle AI Database 26ai, the Transparent Data Encryption (TDE) encryption libraries for the GOST and SEED algorithms are desupported and removed. The GOST and SEED decryption libraries are deprecated. Both are removed on HP Itanium platforms.GOST 28147-89 has been deprecated by the Russian government, and SEED has been deprecated by the South Korean government. If you need South Korean government-approved TDE cryptography, then use ARIA instead. If you are using GOST 28147-89, then you must decrypt and encrypt with another supported TDE algorithm. The decryption algorithms for GOST 28147-89 and SEED are included with Oracle AI Database 26ai, but are deprecated, and the GOST encryption algorithm is desupported with Oracle AI Database 26ai. If you are using GOST or SEED for TDE encryption, then Oracle recommends that you perform an online rekey operation before upgrading to Oracle AI Database 26ai. However, with the exception of the HP Itanium platform, the GOST and SEED decryption libraries are available with Oracle AI Database 26ai, so you can also decrypt after upgrading.

Related Topics

Encrypting Future Tablespaces

You can configure Oracle Database to automatically encrypt future tablespaces that you will create.

About Encrypting Future Tablespaces

The ENCRYPT_NEW_TABLESPACES dynamic database initialization parameter controls if future tablespaces are encrypted.

By default, all Oracle Cloud databases are encrypted. If you install an off-the-shelf application into such a database, its installation scripts most likely do not have the encryption syntax. In this case, because ENCRYPT_NEW_TABLESPACES is set to CLOUD_ONLY, those tablespaces would be created encrypted regardless.

Note: Starting with Oracle AI Database 26ai, the ENCRYPT_NEW_TABLESPACES initialization parameter is deprecated. Oracle recommends that you use the initialization parameter TABLESPACE_ENCRYPTION.

In an Oracle Cloud environment, the following scenarios may occur when you create encrypted tablespaces in Oracle Cloud and on-premises environments:

Related Topics

Setting Future Tablespaces to be Encrypted

You can set the TABLESPACE_ENCRYPTION database initialization parameter to automatically encrypt new tablespaces.

Starting with Oracle Database 19.17, the ENCRYPT_NEW_TABLESPACES has been deprecated.

Oracle recommends that you use the initialization parameter TABLESPACE_ENCRYPTION, which is new for Oracle AI Database 26ai.

If you upgraded from an older database release to 26ai, unset the ENCRYPT_NEW_TABLESPACES parameter before setting TABLESPACE_ENCRYPTION:

alter system RESET "encrypt_new_tablespaces" scope = both SID = '*';

Enter the following ALTER SYSTEM statement:

ALTER SYSTEM SET TABLESPACE_ENCRYPTION = value SCOPE = SPFILE SID = '*';

In this specification, value can be:

Related Topics

Encrypted Sensitive Credential Data in the Data Dictionary

You can encrypt sensitive credential data in the SYS.LINK$ and SYS.SCHEDULER$_CREDENTIAL system tables.

By default, the credential data in the SYS.LINK$ and SYS.SCHEDULER$_CREDENTIAL system tables is obfuscated. However, because of the availability of many types of de-obfuscation algorithms, Oracle recommends that you encrypt this sensitive credential data. To check the status the data dictionary credentials, you can query the DICTIONARY_CREDENTIALS_ENCRYPT data dictionary view.

The encryption of sensitive credential data in these two system tables uses Transparent Data Encryption. To encrypt credential data, you do not need an Oracle Advanced Security Option license, but you must be granted the SYSKM administrative privilege and the database must have a fully functional Transparent Data Encryption setup. Encryption of credential data uses the AES256 algorithm.

Related Topics

Offline Encryption of Existing Tablespaces

You can perform offline encryption by using the ALTER TABLESPACE or ALTER DATABASE DATAFILE SQL statements with the ENCRYPT or DECRYPT clauses.

About Offline Encryption of Existing Tablespaces

You can encrypt or decrypt an existing data file of a user tablespace when the tablespace is offline or when the database is not open.

There are two options for performing the encryption or decryption:

Related Topics

Encrypting an Existing User-Defined Tablespace with Offline Conversion

To encrypt an existing tablespace with offline conversion, you can use the ALTER TABLESPACE SQL statement with the OFFLINE and ENCRYPT clauses.

The procedure that is described in this section applies to the case where you want to encrypt individual user-created tablespaces within a database. These tablespaces can be encrypted offline. However, the Oracle Database-supplied SYSTEM and UNDO tablespaces cannot be brought offline. If you want to encrypt the tablespaces offline, then you must use the method that is described in Encrypting an Existing Database with Offline Conversion.

  1. Connect to the united mode CDB root or isolated mode PDB as a user who has been granted administrative privileges.

    You must have the SYSDBA administrative privilege to work with the SYSTEM and SYSAUX tablespaces. Otherwise, connect with the SYSKM administrative privilege.

  2. Bring the tablespace offline.

    ALTER TABLESPACE users OFFLINE NORMAL;

  3. Back up the tablespace.

    The offline conversion method does not use auxiliary disk space or files, and it operates directly in-place to the data files. Therefore, you should perform a full backup of the user tablespace before converting it offline.

  4. As a user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege, open the TDE wallet.

    For example:

    ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY TDEk_wallet_password;

  5. Encrypt the tablespace.

    For example, to encrypt an entire tablespace, include its data files:

    ALTER TABLESPACE users1 ENCRYPTION OFFLINE ENCRYPT;

    This example encrypts the tablespace with the default encryption algorithm, AES256. To use a different encryption algorithm, enter a statement similar to the following:

    ALTER TABLESPACE users2 ENCRYPTION OFFLINE USING 'AES128' ENCRYPT;

    To encrypt individual data files within a tablespace, use the ALTER DATABASE DATAFILE SQL statement. For example, to encrypt the data files user_01.dbf and user_02.dbf:

    ALTER DATABASE DATAFILE 'user_01.dbf' ENCRYPT;
ALTER DATABASE DATAFILE 'user_02.dbf' ENCRYPT;

    In the same database session, these statements encrypt each of the data files in sequence, one after another. If you run each statement in its own database session, then they will be run in parallel.

    If the encryption process is interrupted, then rerun the ALTER TABLESPACE statement. The kinds of errors that you can expect in an interruption are general errors, such as file system or storage file system errors. The data files within the tablespace should be consistently encrypted. For example, suppose you offline a tablespace that has 10 files but for some reason, the encryption only completes for nine of the files, leaving one decrypted. Although it is possible to bring the tablespace back online with such inconsistent encryption if the COMPATIBLE parameter is set to 12.2.0.0 or later, then it is not recommended to leave the tablespace in this state. If COMPATIBLE is less than 12.2.0.0, then it is not possible to bring the tablespace online if the encryption property is inconsistent across the data files.

  6. Bring the tablespace back online or open the database.

    • To bring the tablespace back online:

      ALTER TABLESPACE users ONLINE;

    • To open a database in a non-multitenant environment:

      ALTER DATABASE OPEN

    • In a multitenant environment, you can encrypt a data file or tablespace with the offline method if the root is open and the PDB is not open. For example, for a PDB named hr_pdb:

      ALTER PLUGGABLE DATABASE hr_pdb OPEN

  7. Perform a full backup of the converted tablespace.

Related Topics

Decrypting an Existing Tablespace with Offline Conversion

To decrypt an existing tablespace with offline conversion, you can use the ALTER TABLESPACE SQL statement with the OFFLINE and DECRYPT clauses.

  1. Connect to the united mode CDB root or isolated mode PDB as a user who has been granted the SYSDBA administrative privilege.

    You must have the SYSDBA administrative privilege to work with the SYSTEM and SYSAUX tablespaces. Otherwise, connect with the SYSKM administrative privilege.

  2. Bring the tablespace offline.

    ALTER TABLESPACE users OFFLINE NORMAL;

  3. As a user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege, open the keystore.

    For example:

    ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY TDE_wallet_password;

  4. Run the ALTER TABLESPACE SQL statement to perform the decryption.

    For example, for a tablespace called users:

    ALTER TABLESPACE users ENCRYPTION OFFLINE DECRYPT;

    If the decryption process is interrupted, then rerun the ALTER TABLESPACE statement. The kinds of errors that you can expect in an interruption are general errors, such as file system or storage file system errors. The data files within the tablespace should be consistently decrypted. For example, suppose you offline a tablespace that has 10 files but for some reason, the decryption only completes for nine of the files, leaving one encrypted. Although it is possible to bring the tablespace back online with such inconsistent decryption if the COMPATIBLE parameter is set to 12.2.0.0 or later, then it is not recommended to leave the tablespace in this state. If COMPATIBLE is less than 12.2.0.0, then it is not possible to bring the tablespace online if the encryption property is inconsistent across the data files.

  5. Bring the tablespace online.

    ALTER TABLESPACE users ONLINE;

Encryption Conversions for Existing Online Tablespaces

You can encrypt and decrypt an online existing tablespace by using the ALTER TABLESPACE SQL statement with the ONLINE and ENCRYPT or DECRYPT clauses.

About Encryption Conversions for Existing Online Tablespaces

You can encrypt, decrypt, or rekey existing user tablespaces, and the SYSTEM, SYSAUX, and UNDO tablespace when they are online.

However, you cannot encrypt, decrypt, or rekey a temporary tablespace online.

An online tablespace can be created by using the ONLINE clause of the CREATE TABLESPACE SQL statement. When you encrypt or rekey a tablespace online, the tablespace will have its own independent encryption keys and algorithms.

Note the following:

Related Topics

Encrypting an Existing Tablespace with Online Conversion

To encrypt an existing tablespace with online conversion, use ALTER TABLESPACE with the ONLINE and ENCRYPT clauses.

  1. Connect to the united mode CDB root or isolated mode PDB as a user who has been granted the SYSDBA administrative privilege.

    You must have the SYSDBA administrative privilege to work with the SYSTEM and SYSAUX tablespaces. Otherwise, connect with the SYSKM administrative privilege.

  2. Ensure that the COMPATIBLE initialization parameter is set to 12.2.0.0 or later.

    You can use the SHOW PARAMETER command to check the current setting of a parameter.

  3. Ensure that the database is open in read-write mode.

    You can query the STATUS column of the V$INSTANCE dynamic view to find if a database is open and the OPEN_MODE column of the V$DATABASE view to find if it in read-write mode.

  4. If necessary, open the database in read-write mode.

    ALTER DATABASE OPEN READ WRITE;

  5. Ensure that the auxiliary space is at least the same size as the largest data file of this tablespace.

    This size requirement is because Oracle Database performs the conversion one file at a time. For example, if the largest data file of the tablespace is 32 GB, then ensure that you have 32 GB of auxiliary space. To find the space used by a data file, query the BYTES or BLOCKS column of the V$DATAFILE dynamic performance view.

  6. As a user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege, create and open a master encryption key.

    For example:

    ADMINISTER KEY MANAGEMENT CREATE KEYSTORE 'TDE_wallet_location' IDENTIFIED BY TDE_wallet_password;
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY TDE_wallet_password;
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY TDE_wallet_password WITH BACKUP;

  7. Run the ALTER TABLESPACE statement using the ENCRYPTION and ENCRYPT clauses to perform the encryption.

    Note: For the SYSTEM tablespace, you can use the ENCRYPT clause to encrypt the tablespace, but you cannot specify an encryption algorithm because it is encrypted with the existing database key the first time. After encrypting the SYSTEM tablespace, use the REKEY clause to specify the algorithm. See Rekeying an Existing Tablespace with Online Conversion for more information.

    For example, for a non-Oracle managed files tablespace named users:

    ALTER TABLESPACE users ENCRYPTION ONLINE USING 'AES256' ENCRYPT FILE_NAME_CONVERT = ('users.dbf', 'users_enc.dbf');

    In this example:

    • ENCRYPTION ONLINE USING 'AES256' ENCRYPT sets the statement to encrypt the tablespace users while it is online and assigns it the AES256 encryption algorithm. If you omit the USING algorithm clause, then the default algorithm, AES256, is used.

    • FILE_NAME_CONVERT specifies one or more pairs of data files that are associated with the tablespace. The first name in the pair is an existing data file, and the second name is for the encrypted version of this data file, which will be created after the ALTER TABLESPACE statement successfully runs. If the tablespace has more than one data file, then you must process them all in this statement. Note the following:

      • Separate each file name with a comma, including multiple pairs of files. For example:

            FILE_NAME_CONVERT = ('users
1.dbf', 'users1_enc.dbf', 'users2.dbf', 'users2_enc.dbf')

      • You can specify directory paths in the FILE_NAME_CONVERT clause. For example, the following clause converts and moves the matching files of the tablespace from the dbs directory to the dbs/enc directory:

        FILE_NAME_CONVERT = ('dbs', 'dbs/enc')

      • The FILE_NAME_CONVERT clause recognizes patterns. The following example converts the data files users_1.dbf and users_2.dbf to users_enc1.dbf and users_enc2.dbf:

        FILE_NAME_CONVERT = ('users', 'users_enc')

      • In an Oracle Data Guard environment, include the name of the standby database data file in the FILE_NAME_CONVERT settings.

      • If you are using Oracle-managed file mode, then the new file name is internally assigned, so this file name should not affect your site’s file-naming standards. If you are using non-Oracle-managed file mode and if you omit the FILE_NAME_CONVERT clause, then Oracle Database internally assigns an auxiliary file name, and then later renames it back to the original name. This enables the encryption process to use the name that you had originally given the file to be encrypted. The renaming operation is effectively creating another copy of the file, hence it is slower than explicitly including the FILE_NAME_CONVERT clause. For better performance, include the FILE_NAME_CONVERT clause.

      • You can find the data files for a tablespace by querying the V$DATAFILE or V$DATAFILE_HEADER dynamic views.

        By default, data files are in the $ORACLE_HOME/dbs directory. If the data files are located there, then you do not have to specify a path.

        After you complete the conversion, you can check the encryption status by querying the STATUS column of the V$ENCRYPTED_TABLESPACES dynamic view. The ENCRYPTIONALG column of this view shows the encryption algorithm that is used. If the conversion process was interrupted, then you can resume it by running ALTER TABLESPACE with the FINISH clause. For example, if the primary data file converts but the standby data file does not, then you can run ALTER TABLESPACE ... FINISH on the standby database for the standby data files.

Related Topics

Rekeying an Existing Tablespace with Online Conversion

To rekey an existing tablespace that is online, you can use the REKEY clause of the ALTER TABLESPACE SQL statement.

Before you perform a rekey operation, be aware of the following:

  1. Connect to the united mode CDB root or isolated mode PDB as a user who has been granted the SYSDBA administrative privilege.

    You must have the SYSDBA administrative privilege to work with the SYSTEM and SYSAUX tablespaces. Otherwise, connect with the SYSKM administrative privilege.

  2. Ensure that the following requirements are met:

    • The COMPATIBLE initialization parameter is set to 12.2.0.0 or later.

    • The database is open and in read-write mode.

    • A master encryption key has been created and is open.

  3. Query the KEY_VERSION and STATUS columns of the V$ENCRYPTED_TABLESPACES dynamic view to find the current status of the encryption algorithm used by the master encryption key.

  4. Perform the rekey operation, based on the status returned by the V$ENCRYPTED_TABLESPACES dynamic view:

    • If the key version status of the tablespace is NORMAL, then specify the new algorithm of the online tablespace rekey.

      For example:

      ALTER TABLESPACE users ENCRYPTION USING 'AES192' REKEY FILE_NAME_CONVERT = ('users.dbf', 'users_enc.dbf');

    • If the key version status is ENCRYPTING, DECRYPTING, or REKEYING, then use the FINISH clause.

      For example:

      ALTER TABLESPACE users ENCRYPTION ONLINE FINISH REKEY FILE_NAME_CONVERT = ('users.dbf', 'users_enc.dbf');

  5. If the ORA-00241 operation disallowed: control file inconsistent with data dictionary error appears, then restart the CDB root and then retry Step 4.

    If the conversion process was interrupted, then you can resume it by running ALTER TABLESPACE with the FINISH clause.

Related Topics

Rekeying the SYSAUX and UNDO Tablespaces with Online Conversion

To rekey the SYSAUX and UNDO onlne tablespaces, you can use the REKEY clause of the ALTER TABLESPACE SQL statement.

  1. Connect to the united mode CDB root or isolated mode PDB as a user who has been granted the SYSDBA administrative privilege.

    You must have the SYSDBA administrative privilege to work with the SYSTEM and SYSAUX tablespaces. Otherwise, connect with the SYSKM administrative privilege.

  2. Ensure that the following requirements are met:

    • The COMPATIBLE initialization parameter is set to 12.2.0.0 or later.

    • The database is open and in read-write mode.

    • A master encryption key has been created and is open.

  3. Depending on how the _TABLESPACE_ENCRYPTION_DEFAULT_ALGORITHM parameter is set, perform the rekey operation as follows:

    • If _TABLESPACE_ENCRYPTION_DEFAULT_ALGORITHM is set to AES256, then you only need the REKEY clause in the ALTER TABLESPACE statement for SYSAUX or UNDO. For example:

      ALTER TABLESPACE SYSAUX ENCRYPTION REKEY;

    • If _TABLESPACE_ENCRYPTION_DEFAULT_ALGORITHM is not set, then you must manually specify the AES256 algorithm. For example:

      ALTER TABLESPACE SYSAUX ENCRYPTION USING 'AES256' REKEY;

Related Topics

Decrypting an Existing Tablespace with Online Conversion

To decrypt an existing tablespace with online conversion, you can use the ALTER TABLESPACE SQL statement with DECRYPT clause.

  1. Connect to the united mode CDB root or isolated mode PDB as a user who has been granted the SYSDBA administrative privilege.

    You must have the SYSDBA administrative privilege to work with the SYSTEM and SYSAUX tablespaces. Otherwise, connect with the SYSKM administrative privilege.

  2. Ensure that the following requirements are met:

    • The COMPATIBLE initialization parameter is set to 12.2.0.0 or later.

    • The database is open and in read-write mode.

    • A master encryption key has been created and is open.

    • There is enough auxiliary space to complete the decryption.

  3. Run the ALTER TABLESPACE SQL statement with the DECRYPT clause.

    For example:

    ALTER TABLESPACE users ENCRYPTION ONLINE DECRYPT FILE_NAME_CONVERT = ('users_enc.dbf', 'users.dbf');

    In this specification:

    • When you specify the files to decrypt, enter them in the reverse order in which they were originally encrypted. That is, first enter the name of the encrypted file (users_enc.dbf), followed by the data file (users.dbf).

    • Do not provide an algorithm key for the decryption.

      If the conversion process was interrupted, then you can resume it by running ALTER TABLESPACE with the FINISH clause.

Related Topics

Finishing an Interrupted Online Encryption Conversion

If an online encryption process is interrupted, then you can complete the conversion by rerunning the ALTER TABLESPACE statement using the FINISH clause.

An interrupted encryption process (encryption, rekey, or decryption) can be, for example, an ORA-28425: missing a valid FILE_NAME_CONVERT clause error in the FILE_NAME_CONVERT clause of the ALTER TABLESPACE SQL statement. Other examples of interrupted processes are if the conversion skips a data file, which can happen if there is an error when an Oracle DataBase WRiter (DBWR) process offlines a data file, or if there is not enough space for the auxiliary file. The tablespace should be operational even if you do not rerun the ALTER TABLESPACE statement with the FINISH clause.

In addition to interrupted encryption processes, the tablespace encryption process can fail during the period when the status is ENCRYPTING. In this case, you can either decrypt the tablespace back to its original state, or you can resume the encryption by using the ENCRYPTION ONLINE FINISH ENCRYPT clause of ALTER TABLEPSPACE.

  1. Connect to the united mode CDB root or isolated mode PDB as a user who has been granted the SYSDBA or SYSKM administrative privilege.

    You must have the SYSDBA administrative privilege to work with the SYSTEM and SYSAUX tablespaces. Otherwise, connect with the SYSKM administrative privilege.

  2. Query the V$ENCRYPTED_TABLESPACES to check the STATUS column for the tablespace.

    If the STATUS column reports ENCRYPTING, DECRYPTING, or REKEYING, then re-run the ALTER TABLESPACE statement with the FINISH clause, as described in this procedure. If the STATUS reports NORMAL, then you can rerun ALTER TABLESPACE without the FINISH clause.

    You can find the tablespace name that matches the TS# and TABLESPACE_NAME columns by querying the V$DATAFILE_HEADER view.

  3. If necessary query the following additional views to find information about the tablespace whose online conversion was interrupted:

    • DBA_TABLESPACES to find if the STATUS of the tablespace indicates if it is online or offline.

    • V$ENCRYPTED_TABLESPACES to find if the STATUS of the tablespace indicates if it is encrypted, and what the KEY_VERSION of the encryption key is.

    • V$DATAFILE and V$DATAFILE_HEADER to find the data files that are associated with a tablespace.

  4. Run the ALTER TABLESPACE statement using the FINISH clause.

    Examples are as follows:

    • For an encryption operation:

      ALTER TABLESPACE users ENCRYPTION ONLINE FINISH ENCRYPT FILE_NAME_CONVERT = ('users.dbf', 'users_enc.dbf');

    • For a decryption operation:

      ALTER TABLESPACE users ENCRYPTION ONLINE FINISH DECRYPT FILE_NAME_CONVERT = ('users_enc.dbf', 'users.dbf');

      Note the order in which the files are specified: first, the name of the encrypted file, and then the name of the data file. (In the encryption operation, the name of the data file is specified first, followed by the name of the encrypted file.)

    • For a rekey operation:

      ALTER TABLESPACE users ENCRYPTION ONLINE FINISH REKEY FILE_NAME_CONVERT = ('users.dbf', 'users_enc.dbf');

      You cannot specify an algorithm when you use the FINISH clause in an ALTER TABLESPACE statement.

  5. To check the conversion, query the STATUS column of the V$ENCRYPTED_TABLESPACES view.

    The status should be NORMAL. In an Oracle Data Guard environment, if the database does not have NORMAL as the STATUS, then run the ALTER TABLESPACE ... FINISH statement on the primary or the standby data file that did not successfully convert.

Rekeying an Encrypted Tablespace

Rekying an already encrypted tablespace enables you to change the data encryption keys from one algorithm to another, for example from AES128 to AES256.

  1. Find the tablespaces that use the earlier algorithm.

    For example, to find tablespaces that use the AES128:

    SELECT TSVIEW.CON_ID, TSVIEW.NAME AS TS_NAME, ETSVIEW.ENCRYPTIONALG
AS ENCRYPTION_ALG FROM V$TABLESPACE TSVIEW , V$ENCRYPTED_TABLESPACES ETSVIEW
WHERE TSVIEW.TS# = ETSVIEW.TS#
AND ETSVIEW.ENCRYPTEDTS = 'YES'
AND ETSVIEW.ENCRYPTIONALG = 'AES128';

    Output similar to the following appears:

    CON_ID  TS_NAME           ENCRYPTION_ALG

------  ----------------  ------------------------
     1  ENCRYPTED_TS_CDB  AES128

  2. Re-encrypt each tablepace that is listed in the output.

    For example, to migrate the ENCRYPTED_TS_CDB tablespace to use the latest supported algorithm, which is AES256:

    ALTER TABLESPACE ENCRYPTED_TS_CDB ENCRYPTION REKEY;

  3. To verify the re-encryption:

    SELECT C.NAME AS PDB_NAME, T.NAME AS TBS_NAME, E.ENCRYPTIONALG AS ALG, E.CIPHERMODE AS "MODE", E.STATUS FROM V$TABLESPACE T,
V$ENCRYPTED_TABLESPACES E, V$CONTAINERS C
WHERE E.TS# = T.TS# AND E.CON_ID = T.CON_ID AND E.CON_ID = C.CON_ID
ORDER BY E.CON_ID, T.NAME;

Related Topics

Creating an Encrypted Database Using DBCA

You can use DBCA to create an encrypted database in both single instance multitenant and Oracle Data Guard environments.

Using DBCA to Create an Encrypted Database

Before you run DBCA to create an encrypted database, you must create the WALLET_ROOT directory.

  1. Log into the host where DBCA will create the database with the united mode PDBs.

    DBCA cannot create PDBs in isolated mode.

  2. Create the WALLET_ROOT directory.

    For example:

    mkdir -pvm700 /etc/ORACLE/KEYSTORES/finance

    When you run DBCA in the next step, DBCA will create the WALLET_ROOT/tde sub-directory.

  3. Run the dbca -createDatabase command to create the encrypted database, and include the appropriate TDE-related parameters.

    For example:

    -configureTDE TRUE

-tdeKeystoreConfigType FILE

-tdeWalletRoot /etc/ORACLE/KEYSTORES/finance

-tdeWalletLoginType LOCAL_AUTO_LOGIN

 -createTDESepsWallet

-TdeWalletPassword ${SYS_PASSWORD}

    If you omit the following values, then DBCA uses their defaults, as follows:

    • tdeAlgorithm: The default is AES256 with XTS cipher mode.

    • encryptTablespaces: SYSTEM, SYSAUX and USERS tablespaces are encrypted. The TEMP and UNDO tablespaces remain unencrypted. The ALL setting encrypts all tablespaces in CDB$ROOT.

    • encryptPDBTablespaces: The SYSTEM, SYSAUX and USERS tablespaces are encrypted. The TEMP and UNDO tablespaces remain unencrypted. The ALL setting encrypts all tablespaces in the PDB.

Related Topics

Using DBCA to Create an Oracle Data Guard Standby Database from an Encrypted Primary Database

Before you run DBCA to create the encrypted database in an Oracle Data Guard environment, you must copy the wallet from the primary to the standby database, and then create the WALLET_ROOT directory.

  1. Log into the server where DBCA will create the standby database from an encrypted primary database.

    DBCA cannot create a standby database from an encrypted primary database if the REDO_TRANSPORT_USER initialization parameter is set to a common user.

  2. Copy the TDE wallet from the primary host to the standby host.

    When you run DBCA, you will specify this wallet location when you set the primaryDBTdeWallet parameter.

  3. Create the WALLET_ROOT directory.

    For example:

    mkdir -pvm700 /etc/ORACLE/KEYSTORES/finance

    When you run DBCA in the next step, DBCA will create the WALLET_ROOT/tde sub-directory.

  4. Run the dbca -createDuplicateDB command to create the encrypted standby database, and include the appropriate TDE-related parameters.

    For example:

    dbca -silent -createDuplicateDB -createAsStandby

  -configureTDE TRUE

    -tdeWalletRoot /etc/ORACLE/KEYSTORES/finance

    -primaryDBTdeWallet /tmp

    -tdeWalletLoginType LOCAL_AUTO_LOGIN

    -sourceTdeWalletPassword tde_password

    -TdeWalletPassword tde_password

Related Topics

Best Practice after DBCA Creates an Encrypted Database

After DBCA has created an encrypted stand-alone or Oracle Data Guard primary and standby database, you can implement Transparent Data Encryption (TDE) best practices.

  1. Add the wallet password to another (local) auto-open wallet so that the wallet password on the SQL*Plus command line can be replaced by EXTERNAL STORE.

    This helps with separation of duties and automation. In Oracle Data Guard, you should run both commands on the primary and standby databases.

    $ mkdir -pvm700 WALLET_ROOT/tde_seps

SQL> ADMINISTER KEY MANAGEMENT ADD SECRET 'wallet_password'
FOR CLIENT 'TDE_WALLET' TO [LOCAL] AUTO-LOGIN KEYSTORE 'wallet_root/tde_seps';

  2. Add a tag to the TDE master key for the PDB.

    When DBCA creates a TDE master key for the PDB, it does not add a tag to this key. The following ADMINISTER KEY MANAGEMENT command adds the tag to the PDB. The tag consists of the string pdb_name date time (IN UTC). The date and time is derived from the time when the key was first activated, not the current time. Run this command in the primary PDB.

    SELECT ' ADMINISTER KEY MANAGEMENT
SET TAG '''||SYS_CONTEXT('USERENV', 'CON_NAME')||' '||TO_CHAR (SYS_EXTRACT_UTC (ACTIVATION_TIME),
'YYYY-MM-DD HH24:MI:SS"Z"')||''' FOR '''||KEY_ID||'''
FORCE KEYSTORE IDENTIFIED BY EXTERNAL STORE WITH BACKUP;'
AS "SET TAG COMMAND" FROM V$ENCRYPTION_KEYS;

    For Oracle Data Guard, copy the primary wallet (with the tagged PDB key) to the standby side. If you are using local auto-login wallets, then delete and recreate the local auto-open wallet on the standby database.

  3. Encrypt the data dictionary.

    This is a Data Guard transaction and as such, it is automatically applied to the standby database. As a user with the SYSKM administrative privilege, perform the following ALTER DATABASE DICTIONARY command:

    ALTER DATABASE DICTIONARY ENCRYPT CREDENTIALS CONTAINER = CURRENT;

  4. Optionally, you can isolate the encrypted PDB with a single command.

    1. From within the primary PDB:

      ADMINISTER KEY MANAGEMENT FORCE ISOLATE KEYSTORE IDENTIFIED BY "new_pdb_wallet_password"
FROM ROOT KEYSTORE FORCE KEYSTORE
IDENTIFIED BY EXTERNAL STORE WITH BACKUP;

      You can run this command without knowing the root wallet password, and the root administrator will not know the new isolated wallet password. This command performs the following actions:

      • Creates the WALLET_ROOT/pdb_guid/tde directrory

      • Creates a wallet in the WALLET_ROOT/pdb_guid/tde directory

      • Moves the PDB keys from the root wallet to the PDB wallet

      • Sets the TDE_CONFIGURATION parameter for the PDB to FILE

        Next, create an isolated (local) auto-open wallet; from within the primary PDB:

        ADMINISTER KEY MANAGEMENT CREATE [LOCAL] AUTO_LOGIN KEYSTORE
FROM KEYSTORE IDENTIFIED BY "new_pdb_wallet_password";

    2. From within the isolated PDB, create a directory and another local auto-open wallet that enables you to hide the isolated wallet password from the SQL*Plus command line.

      SELECT ' HOST MKDIR -PVM700 '||B.VALUE||'/'||A.GUID||'/TDE_SEPS'
AS "CREATE DIRECTORY FOR IDENTIFIED BY EXTERNAL STORE (IBES)"
FROM V$PDBS A, V$PARAMETER B WHERE B.NAME = 'WALLET_ROOT';

SELECT 'ADMINISTER KEY MANAGEMENT ADD SECRET ''NEW-PDB-WALLET-PWD''
FOR CLIENT ''TDE_WALLET'' TO LOCAL AUTO_LOGIN KEYSTORE '''||B.VALUE||'/'||A.GUID||'/TDE_SEPS'''
AS "CREATE ISOLATED WALLET FOR IBES"
FROM V$PDBS A, V$PARAMETER B WHERE B.NAME = 'WALLET_ROOT';

Encryption Conversions for Existing Databases

You can encrypt both offline and online databases.

About Encryption Conversions for Existing Databases

The encryption conversion of an entire database encrypts all tablespaces, including the Oracle-supplied SYSTEM, SYSAUX, UNDO, and TEMP tablespaces.

Note the following:

Encrypting an Existing Database with Offline Conversion

When you encrypt an existing database with offline conversion, for the Oracle-managed tablespaces, you do not specify an encryption algorithm.

  1. Connect to the united mode CDB root or isolated mode PDB as a user who has been granted the SYSDBA administrative privilege.

    You must have the SYSDBA administrative privilege to work with the SYSTEM and SYSAUX tablespaces. Otherwise, connect with the SYSKM administrative privilege.

  2. Mount the database.

    STARTUP MOUNT

  3. As a user who has been granted the ADMINISTER KEY MANAGEMENT or SYSKM privilege, open the keystore.

    ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY keystore_password;

  4. Run the ALTER TABLESPACE SQL statement to encrypt the SYSTEM, SYSAUX, and UNDO tablespaces. Do not encrypt the SYSTEM tablespace concurrently with the encryption of other tablespaces.

    For example, to encrypt the SYSTEM tablespace:

    ALTER TABLESPACE SYSTEM ENCRYPTION OFFLINE ENCRYPT;

  5. Open the CDB root or the PDB.

    • For a CDB, to open in read/write mode, for example:

      ALTER DATABASE OPEN READ WRITE;

    • For a PDB:

      ALTER PLUGGABLE DATABASE pdb_name OPEN READ WRITE;

  6. Run the ALTER TABLESPACE SQL statement to encrypt other user tablespaces.

    Alternatively, you can proceed to the next step and open the database first, and then perform the steps to encrypt an existing user-defined tablespace with offline conversion.

  7. Open the CDB root or the PDB.

    • For a CDB:

      ALTER DATABASE OPEN;

    • For a PDB:

      ALTER PLUGGABLE DATABASE pdb_name OPEN;

      After you have encrypted the tablespace, if you want to use a different encryption algorithm (change the TDE master encryption key) for the SYSTEM, SYSAUX, and UNDO tablespaces, then you must use online conversion. In addition to AES128, supported encryption algorithms are AES192 and AES256, in addition to other algorithms such as ARIA and GOST.

      Note: Starting with Oracle AI Database 26ai, the Transparent Data Encryption (TDE) decryption libraries for the GOST and SEED algorithms are deprecated, and encryption to GOST and SEED are desupported. Starting with Oracle AI Database 26ai, the Transparent Data Encryption (TDE) encryption libraries for the GOST and SEED algorithms are desupported and removed. The GOST and SEED decryption libraries are deprecated. Both are removed on HP Itanium platforms.GOST 28147-89 has been deprecated by the Russian government, and SEED has been deprecated by the South Korean government. If you need South Korean government-approved TDE cryptography, then use ARIA instead. If you are using GOST 28147-89, then you must decrypt and encrypt with another supported TDE algorithm. The decryption algorithms for GOST 28147-89 and SEED are included with Oracle AI Database 26ai, but are deprecated, and the GOST encryption algorithm is desupported with Oracle AI Database 26ai. If you are using GOST or SEED for TDE encryption, then Oracle recommends that you perform an online rekey operation before upgrading to Oracle AI Database 26ai. However, with the exception of the HP Itanium platform, the GOST and SEED decryption libraries are available with Oracle AI Database 26ai, so you can also decrypt after upgrading.

Related Topics

Encrypting an Existing Database with Online Conversion

When you encrypt an existing database with online conversion, you do not specify an encryption algorithm.

The reason that you do not need to specify an encryption algorithm the first time you perform the encryption is that the tablespaces that you must use to encrypt the database are automatically encrypted with the database key. If you want to change the algorithm, then you can issue the ALTER TABLESPACE ENCRYPTION REKEY SQL statement after the initial encryption.

  1. Perform the following tasks, which are performed when encrypting an existing tablespace with online conversion:

    1. Connect as a user who has been granted the SYSDBA administrative privilege.

    2. Ensure that the COMPATIBLE parameter is set to 12.2.0.0 or later.

    3. Ensure that the database is open in read-write mode.

    4. Ensure that you have enough auxiliary space to complete the encryption.

    5. Back up the tablespaces that you must encrypt.

    6. Open the keystore.

  2. Run the ALTER TABLESPACE SQL statement to encrypt the SYSTEM, SYSAUX, and UNDO tablespaces. Do not specify an algorithm, and do not encrypt the SYSTEM tablespace concurrently with the encryption of other tablespaces.

    For example, to encrypt the SYSTEM tablespace:

    ALTER TABLESPACE SYSTEM ENCRYPTION ONLINE ENCRYPT
FILE_NAME_CONVERT=('system01.dbf','system01_enc.dbf');

  3. Create a temporary tablespace.

    1. Create a new (encrypted) TEMP tablespace with the identical characteristics as the original TEMP tablespace, as follows:

      SELECT ' CREATE TEMPORARY TABLESPACE '
||tablespace_name||'_ENC tempfile '''
||substr(file_name,1,length(file_name)-4)
||'_enc.dbf'' size '
||bytes||' ENCRYPTION USING ''AES256'' ENCRYPT;'
AS " Create new encrypted TEMP tablespace"
FROM DBA_TEMP_FILES;

      Alternatively, you could extract the original parameters by running DBMS_METADATA.GET_DDL. If you omit the USING algorithm clause, then Oracle Database applies the default algorithm.

    2. Run the command (that is, the output of the SELECT statement).

    3. Change the database default temporary tablespace to the new encrypted TEMP tablespace.

      ALTER DATABASE DEFAULT TEMPORARY TABLESPACE temp_enc;

    4. Drop the original TEMP tablespace.

      DROP TABLESPACE TEMP INCLUDING CONTENTS AND DATAFILES;

      Optionally, you can rename temp_enc to TEMP.

Related Topics