Oracle Cloud Infrastructure Documentation

Configure Oracle Database Features for Exadata Cloud Infrastructure

This topic describes how to configure Oracle Multitenant, tablespace encryption, and Huge Pages for use with your Exadata Cloud Infrastructure instance.

Using Oracle Multitenant on an Exadata Cloud Infrastructure Instance

When you create an Exadata Cloud Infrastructure Instance that uses Oracle Database 12c or later, an Oracle Multitenant environment is created.

The multitenant architecture enables an Oracle database to function as a multitenant container database (CDB) that includes zero, one, or many pluggable databases (PDBs). A PDB is a portable collection of schemas, schema objects, and non-schema objects that appears to an Oracle Net Services client as a non-CDB. All Oracle databases using versions earlier than Oracle Database 12c are non-CDBs.

To use Oracle Transparent Data Encryption (TDE) in a pluggable database (PDB), you must create and activate a master encryption key for the PDB.

In a multitenant environment, each PDB has its own master encryption key which is stored in a single keystore used by all containers.

You must export and import the master encryption key for any encrypted PDBs you plug into your Exadata Cloud Infrastructure Instance CDB.

If your source PDB is encrypted, you must export the master encryption key and then import it.

You can export and import all of the TDE master encryption keys that belong to the PDB by exporting and importing the TDE master encryption keys from within a PDB. Export and import of TDE master encryption keys support the PDB unplug and plug operations. During a PDB unplug and plug, all of the TDE master encryption keys that belong to a PDB, as well as the metadata, are involved.

See "Exporting and Importing TDE Master Encryption Keys for a PDB" in Oracle Database Advanced Security Guide for Release 19, 18, 12.2 or 12.1.

See "ADMINISTER KEY MANAGEMENT" in Oracle Database SQL Language Reference for Release 19, 18, 12.2 or 12.1.

To determine if you need to create and activate an encryption key for the PDB

  1. Invoke SQL*Plus and log in to the database as the SYS user with SYSDBA privileges.

  2. Set the container to the PDB:

    SQL> ALTER SESSION SET CONTAINER = pdb;

  3. Query V$ENCRYPTION_WALLET as follows: 

    SQL> SELECT wrl_parameter, status, wallet_type FROM v$encryption_wallet;

    If the STATUS column contains a value of OPEN_NO_MASTER_KEY, you need to create and activate the master encryption key.

To create and activate the master encryption key in a PDB

  1. Set the container to the PDB:

    SQL> ALTER SESSION SET CONTAINER = pdb;

  2. Create and activate a master encryption key in the PDB by executing the following command:

    SQL> ADMINISTER KEY MANAGEMENT SET KEY USING TAG 'tag' FORCE KEYSTORE IDENTIFIED BY keystore-password WITH BACKUP USING 'backup_identifier';

    In the previous command:

    • keystore-password is the keystore password. By default, the keystore password is set to the value of the administration password that is specified when the database is created.
    • The optional USING TAG 'tag' clause can be used to associate a tag with the new master encryption key.
    • The WITH BACKUP clause, and the optional USING 'backup_identifier' clause, can be used to create a backup of the keystore before the new master encryption key is created.

    See also ADMINISTER KEY MANAGEMENT in Oracle Database SQL Language Reference for Release19, 18 or 12.2.

    Note

    To enable key management operations while the keystore is in use, Oracle Database 12c Release 2, and later, includes the FORCE KEYSTORE option to the ADMINISTER KEY MANAGEMENT command. This option is also available for Oracle Database 12c Release 1 with the October 2017, or later, bundle patch.

    If your Oracle Database 12c Release 1 database does not have the October 2017, or later, bundle patch installed, you can perform the following alternative steps:

    1. Close the keystore.
    2. Open the password-based keystore.
    3. Create and activate a master encryption key in the PDB by using ADMINISTER KEY MANAGEMENT without the FORCE KEYSTORE option.
    4. Update the auto-login keystore by using ADMINISTER KEY MANAGEMENT with the CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE option.

  3. Query V$ENCRYPTION_WALLET again to verify that the STATUS column is set to OPEN: 

    SQL> SELECT wrl_parameter, status, wallet_type FROM v$encryption_wallet;

  4. Query V$INSTANCE and take note of the value in the HOST_NAME column, which identifies the database server that contains the newly updated keystore files: 

    SQL> SELECT host_name FROM v$instance;

  5. Copy the updated keystore files to all of the other database servers.

    To distribute the updated keystore, you must perform the following actions on each database server that does not contain the updated keystore files:

    1. Connect to the root container and query V$ENCRYPTION_WALLET. Take note of the keystore location contained in the WRL_PARAMETER column: 

      SQL> SELECT wrl_parameter, status FROM v$encryption_wallet;

    2. Copy the updated keystore files.

      You must copy all of the updated keystore files from a database server that is already updated. Use the keystore location observed in the WRL_PARAMETER column of V$ENCRYPTION_WALLET.

    Open the updated keystore:
    SQL> ADMINISTER KEY MANAGEMENT SET KEYSTORE open FORCE KEYSTORE IDENTIFIED BY keystore-password CONTAINER=all;
    Note

    To enable key management operations while the keystore is in use, Oracle Database 12c Release 2, and later, includes the FORCE KEYSTORE option to the ADMINISTER KEY MANAGEMENT command. This option is also available for Oracle Database 12c Release 1 with the October 2017, or later, bundle patch.

    If your Oracle Database 12c Release 1 database does not have the October 2017, or later, bundle patch installed, you can perform the following alternative steps:

    1. Close the keystore before copying the updated keystore files.
    2. Copy the updated keystore files.
    3. Open the updated keystore by using ADMINISTER KEY MANAGEMENT without the FORCE KEYSTORE option.

  6. Query GV$ENCRYPTION_WALLET to verify that the STATUS column is set to OPEN across all of the database instances: 

    SQL> SELECT wrl_parameter, status, wallet_type FROM gv$encryption_wallet;

To export and import a master encryption key

  1. Export the master encryption key.
    1. Invoke SQL*Plus and log in to the PDB.

    2. Execute the following command:

      SQL> ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS WITH SECRET "secret" TO 'filename' IDENTIFIED BY keystore-password;
  2. Import the master encryption key.
    1. Invoke SQL*Plus and log in to the PDB.

    2. Execute the following command:

      SQL> ADMINISTER KEY MANAGEMENT IMPORT ENCRYPTION KEYS WITH SECRET "secret" FROM 'filename' IDENTIFIED BY keystore-password;

Managing Tablespace Encryption

By default, all new tablespaces that you create in an Exadata database are encrypted.

However, the tablespaces that are initially created when the database is created may not be encrypted by default.

  • For databases that use Oracle Database 12c Release 2 or later, only the USERS tablespaces initially created when the database was created are encrypted. No other tablespaces are encrypted including the non-USERS tablespaces in:
    • The root container (CDB$ROOT).
    • The seed pluggable database (PDB$SEED).
    • The first PDB, which is created when the database is created.
  • For databases that use Oracle Database 12c Release 1 or Oracle Database 11g, none of the tablespaces initially created when the database was created are encrypted.

For further information about the implementation of tablespace encryption in Exadata, along with how it impacts various deployment scenarios, see Oracle Database Tablespace Encryption Behavior in Oracle Cloud.

Creating Encrypted Tablespaces

User-created tablespaces are encrypted by default.

By default, any new tablespaces created by using the SQL CREATE TABLESPACE command are encrypted with the AES128 encryption algorithm. You do not need to include the USING 'encrypt_algorithm' clause to use the default encryption.

You can specify another supported algorithm by including the USING 'encrypt_algorithm' clause in the CREATE TABLESPACE command. Supported algorithms are AES256, AES192, AES128, and 3DES168.

Managing Tablespace Encryption

You can manage the software keystore (known as an Oracle wallet in Oracle Database 11g), the master encryption key, and control whether encryption is enabled by default.

Managing the Master Encryption Key

Tablespace encryption uses a two-tiered, key-based architecture to transparently encrypt (and decrypt) tablespaces. The master encryption key is stored in an external security module (software keystore). This master encryption key is used to encrypt the tablespace encryption key, which in turn is used to encrypt and decrypt data in the tablespace.

When a database is created on an Exadata Cloud Service instance, a local software keystore is created. The keystore is local to the compute nodes and is protected by the administration password specified during the database creation process. The auto-login software keystore is automatically opened when the database is started.

You can change (rotate) the master encryption key by using the ADMINISTER KEY MANAGEMENT SQL statement. For example: 

SQL> ADMINISTER KEY MANAGEMENT SET ENCRYPTION KEY USING TAG 'tag'
IDENTIFIED BY password WITH BACKUP USING 'backup';
keystore altered.

See "Managing the TDE Master Encryption Key" in Oracle Database Advanced Security Guide for Release 19, 18, 12.2 or 12.1 or "Setting and Resetting the Master Encryption Key" in Oracle Database Advanced Security Administrator's Guide for Release 11.2.

Controlling Default Tablespace Encryption

The ENCRYPT_NEW_TABLESPACES initialization parameter controls the default encryption of new tablespaces. In Exadata databases, this parameter is set to CLOUD_ONLY by default.

Values of this parameter are as follows.

Value Description
ALWAYS During creation, tablespaces are transparently encrypted with the AES128 algorithm unless a different algorithm is specified in the ENCRYPTION clause.
CLOUD_ONLY Tablespaces created in an Exadata database are transparently encrypted with the AES128 algorithm unless a different algorithm is specified in the ENCRYPTION clause. For non-cloud databases, tablespaces are only encrypted if the ENCRYPTION clause is specified. ENCRYPTION is the default value.
DDL During creation, tablespaces are not transparently encrypted by default, and are only encrypted if the ENCRYPTION clause is specified.
Note

With Oracle Database 12c Release 2 (12.2), or later, you can no longer create an unencrypted tablespace in an Exadata database. An error message is returned if you set ENCRYPT_NEW_TABLESPACES to DDL and issue a CREATE TABLESPACE command without specifying an ENCRYPTION clause.

Managing Huge Pages

Huge Pages provide considerable performance benefits for Oracle Database on systems with large amounts of memory. Oracle Database on an Exadata Cloud Infrastructure instance provides configuration settings that make use of Huge Pages by default; however, you can make manual adjustments to optimize the configuration of Huge Pages.

Huge Pages is a feature integrated into the Linux kernel 2.6. Enabling Huge Pages makes it possible for the operating system to support large memory pages. Using Huge Pages can improve system performance by reducing the amount of system CPU and memory resources required to manage Linux page tables, which store the mapping between virtual and physical memory addresses. For Oracle Databases, using Huge Pages can drastically reduce the number of page table entries associated with the System Global Area (SGA).

On Exadata Cloud Infrastructure instances, a standard page is 4 KB, while a Huge Page is 2 MB by default. Therefore, an Oracle Database on an Exadata DB system with a 50 GB SGA requires 13,107,200 standard pages to house the SGA, compared with only 25,600 Huge Pages. The result is much smaller page tables, which require less memory to store and fewer CPU resources to access and manage.

Adjusting the Configuration of Huge Pages

The configuration of Huge Pages for Oracle Database is a two-step process:

  • At the operating system level, the overall amount of memory allocated to Huge Pages is controlled by the vm.nr_hugepages entry in the /etc/sysctl.conf file. This setting is made on each compute node in the environment and it is strongly recommended that the setting is consistent across all of the compute nodes. To alter the Huge Page allocation, you can execute the following command on each compute node as the root user: 

    # sysctl -w vm.nr_hugepages=value

    where value is the number of Huge Pages that you want to allocate.

    On Exadata Cloud Infrastructure instances, each Huge Page is 2 MB by default. Therefore, to allocate 50 GB of memory to Huge Pages you can execute the following command: 

    # sysctl -w vm.nr_hugepages=25600
  • At the Oracle Database level, the use of Huge Pages is controlled by the USE_LARGE_PAGES instance parameter setting. This setting applies to each database instance in a clustered database. Oracle strongly recommends a consistent setting across all of the database instances associated with a database. The following options are available:
    • TRUE — specifies that the database instance can use Huge Pages if they are available. For all versions of Oracle Database after 11.2.0.3, Oracle allocates as much of the SGA as it can, using Huge Pages. When the Huge Page allocation is exhausted, standard memory pages are used.
    • FALSE — specifies that the database instance does not use Huge Pages. This setting is generally not recommended if Huge Pages are available.
    • ONLY — specifies that the database instance must use Huge Pages. With this setting, the database instance fails to start if the entire SGA cannot be accommodated in Huge Pages.

If you make any adjustments at either the operating system or Oracle Database level, ensure that the overall configuration works.

For more information, see the Oracle Database Administrator's Reference for Linux and UNIX-Based Operating Systems for Release 19, 18, 12.1, or 11.2 for a general overview of Huge Pages and more information about configuring Huge Pages. Also, see USE_LARGE_PAGES in the Oracle Database Reference for Release 12.2, 12.1, or 11.2.