Oracle Cloud Infrastructure Documentation
Try Free Tier

Updated 2025-03-29

Manage Databases on Oracle Exadata Database Service on Cloud@Customer

Parent topic: How-to Guides

Prerequisites and Limitations for Creating and Managing Oracle Databases on Oracle Exadata Database Service on Cloud@Customer

Review the prerequisites for creating and managing Oracle Databases on Oracle Exadata Database Service on Cloud@Customer.

Before you can create and use an Oracle Database on Exadata Database Service on Cloud@Customer, you must:

  • Provision Exadata Database Service on Cloud@Customer infrastructure
  • Configure a VM cluster
  • Create any required backup destinations

You can create one or more databases on each Oracle Exadata Database Service on Cloud@Customer system. Other than the storage and processing limits of your Oracle Exadata system, there is no maximum for the number of databases that you can create. By default, databases on Exadata Database Service on Cloud@Customer use Oracle Database Enterprise Edition - Extreme Performance. This edition provides all the features of Oracle Database Enterprise Edition, plus all of the database enterprise management packs, and all of the Enterprise Edition options, such as Oracle Database In-Memory, and Oracle Real Application Clusters (Oracle RAC). If you use your own Oracle Database licenses, then your ability to use various features is limited by your license holdings. TDE Encryption is required for all cloud databases. All new tablespaces will automatically be enabled for encryption.

Note

Custom locale objects (such as language, territory, character set, and collation) require deploying custom locale data files to both the database and storage servers, which is not supported in Exadata Database Service on Cloud@Customer.

Oracle Database Releases Supported by Oracle Exadata Database Service on Cloud@Customer

Learn about the versions of Oracle Database that Oracle Exadata Database Service on Cloud@Customer supports.

Exadata Database Service on Cloud@Customer supports the following Oracle Database software releases:

  • Oracle Database 23ai
  • Oracle Database 19c (19.x)
  • Oracle Database 12c Release 2 (12.2.0.1) (requires a valid Upgrade Support contract)
  • Oracle Database 12c Release 1 (12.1.0.2) (requires a valid Upgrade Support contract)
  • Oracle Database 11g Release 2 (11.2.0.4) (requires a valid Upgrade Support contract)

For Oracle Database release and software support timelines, see Release Schedule of Current Database Releases (Doc ID 742060.1) in the My Oracle Support portal.

About Provisioning and Configuring Oracle Databases on Oracle Exadata Database Service on Cloud@Customer

Learn about provisioning and configuring Oracle Database on Oracle Exadata Database Service on Cloud@Customer

Each Oracle Database is configured as follows:
  • When you provision a database, you can associate it with a backup destination, and enable automatic backups.
  • When a database is provisioned an archivelog maintenance job is added to the crontab for the database.
    • If the database is not enabled for backups, then the archivelog job will maintain FRA space by deleting Archive Redo Logs older than 24 hours.
    • If the database is enabled for backups, then the archivelog job will backup archivelogs that have not been backed up. Once an archived log is backed up, it will be purged when older than 24 hours.
  • Each database is configured with Oracle Real Application Clusters (Oracle RAC) database instances running on every node in the virtual machine (VM) cluster.
  • Each database is created in an Oracle home, which uses a separate set of Oracle binaries in a separate Oracle home location.
  • Each database is configured with default instance parameter settings. While the defaults are reasonable for many cases, you should review the instance parameter settings to ensure that they meet your specific application needs.

    In particular, review the Oracle Database system global area (SGA) and program global area (PGA) instance parameter settings, especially if your VM cluster supports multiple databases. Also, ensure that the sum of all Oracle Database memory allocations never exceeds the available physical memory on each virtual machine.

    • When creating a container database, the initialization parameter, SGA_TARGET is set by the automation. This will automatically size the SGA memory pools. The setting will vary depending on the size of the database VM total memory. If the VM has less than or equal to 60 GB of system memory, SGA_TARGET is set to 3800 MB. If the VM has 60 GB or more system memory, SGA_TARGET is set to 7600 MB.
    • The database initialization parameter USE_LARGE_PAGES is set to ONLY upon database creation, which will require the use of large pages for SGA memory. If the VM is configured with insufficient large pages, the instance will fail to start.
    • The database initialization parameter INMEMORY_FORCE is set to CELLMEMORY_LEVEL for all 19.8 and later databases created via the cloud automation. This setting will enable the Exadata Columnar Cache feature, which dramatically speeds up analytic queries. It is available for 19.8 and later databases and no In Memory license is required when running in Exadata Cloud. For more information, see INMEMORY_FORCE
  • Exadata Database Service will only create databases with 8K block size. This parameter cannot be changed.
  • Each database using Oracle Database 12c Release 1 or a later release is configured as a container database (CDB). One pluggable database (PDB) is created inside the CDB. By default:
    • The first PDB is configured with a local PDB administration user account, named PDBADMIN.
    • The PDBADMIN user account is initially configured with the same administration password as the CDB SYS and SYSTEM users.
    • The PDBADMIN user account is initially configured with basic privileges assigned through two roles; CONNECT and PDB_DBA. However, for most practical administrative purposes you must assign extra privileges to the PDBADMIN user account, or to the PDB_DBA role.

    You can use native Oracle Database facilities to create extra PDBs, and to manage all of your PDBs. The dbaascli utility also provides a range of convenient PDB management functions.

Note

Avoid entering confidential information when assigning descriptions, tags, or friendly names to your cloud resources through the Oracle Cloud Infrastructure Console, API, or CLI.

Using the Console to Manage Databases on Oracle Exadata Database Service on Cloud@Customer

To create or terminate a database, complete procedures using the Oracle Exadata console.

Parent topic: Manage Databases on Oracle Exadata Database Service on Cloud@Customer

Using the Console to Create a Database

To create an Oracle Database with the console, use this procedure.

  1. Open the navigation menu Under Oracle Database, and click Exadata Database Service on Cloud@Customer.

    VM Clusters is selected by default.

  2. Choose your Compartment.

    A list of VM Clusters is displayed for the chosen Compartment.

  3. Click the name of a VM cluster where you want to create the database.

    In the VM Cluster Details page, under Resources, Databases is selected by default.

  4. Click Create Database.

    (or)

    1. Click Database Homes.
    2. Click the name of the Database Home where you want to create the database.
    3. Click Create Database.
  5. Provide the requested information in the Create Database page:
    Note

    You cannot modify the db_name, db_unique_name, and SID prefix after creating the database.
    • Provide the database name: Specify a user-friendly name that you can use to identify the database. The database name must contain only the permitted characters.
      Review the following guidelines when selecting a database name.
      • maximum of 8 characters
      • contain only alphanumeric characters
      • begin with an alphabetic character
      • cannot be part of first 8 characters of a db_unique_name on the VM cluster
      • unique within a VM cluster
      • DO NOT use grid because grid is a reserved name
      • DO NOT use ASM because ASM is a reserved name

    • Provide a unique name for the database: Optionally, specify a unique name for the database. This attribute defines the value of the db_unique_name database parameter. The value is case insensitive.

      The db_unique_name must contain only the permitted characters. Review the following guidelines when selecting a database name.
      • maximum of 30 characters
      • can contain alphanumeric and underscore (_) characters
      • begin with an alphabetic character
      • unique across the fleet/tenancy

      If a unique name is not provided, then the db_unique_name defaults to the following format <db_name>_<3 char unique string>_<region-name>.

      If you plan to configure the database for backup to a Recovery Appliance backup destination, then the unique database name must match the name that is configured in the Recovery Appliance.

    • Select a database version: From the list, choose the Oracle Database software release that you want to deploy.
    • Database Home: Select an existing Database Home or create one as applicable. Note that this field is not available when you create a Database from the Database Home details page.
      • Select an existing Database Home: If one or more Database Homes already exist for the database version you have selected, then this option is selected by default. And, you will be presented with a list of Database Homes. Select a Database Home from the list.
      • Create a new Database Home: If no Database Homes exist for the database version you have selected, then this option is selected by default.
        1. Enter Database Home display name.
        2. Click Change Database Image to select your software version.

          Select a Database Software Image window is displayed.

        3. Select an Image Type, Oracle Provided Database Software Images, or Custom Database Software Images.

          If you choose Oracle Provided Database Software Images, then you can use the Display all available version switch to choose from all available PSUs and RUs. The most recent release for each major version is indicated with a latest label.

          Note

          For the Oracle Database major version releases available in Oracle Cloud Infrastructure, images are provided for the current version plus the three most recent older versions (N through N - 3). For example, if an instance is using Oracle Database 19c, and the latest version of 19c offered is 19.8.0.0.0, images available for provisioning are for versions 19.8.0.0.0, 19.7.0.0, 19.6.0.0 and 19.5.0.0.
    • Provide the name of the first PDB: (Optional) Specify the name for the first PDB. A PDB is created with the database.

      To avoid potential service name collisions when using Oracle Net Services to connect to the PDB, ensure that the PDB name is unique across the entire VM cluster. If you do not provide the name of the first PDB, then a system-generated name is used.

    • Provide the administration password: Provide and confirm the Oracle Database administration password. This password is used for administration accounts and functions in the database, including:
      • The password for the Oracle Database SYS and SYSTEM users.
      • The Transparent Data Encryption (TDE) Keystore password.

      For Oracle Database 12c Release 1 or later releases, the password for the PDB administration user in the first PDB (PDBADMIN) must be nine to 30 characters and contain at least two uppercase, two lowercase, two numeric, and two special characters. The special characters must be _, #, or -. In addition, the password must not contain the name of the tenancy or any reserved words, such as Oracle or Table, regardless of casing.

      • Use the administrator password for the TDE wallet: When this option is checked, the password entered for the SYS user is also used for the TDE wallet. To set the TDE wallet password manually, uncheck this option and enter the TDE wallet password.

    • Backup Destination Type: Select a backup destination for the database. From the list, choose an option:

      • None: Select to not define a backup configuration for the database.
      • Local: Select to store backups locally in the Oracle Exadata Storage Servers on your Oracle Exadata Cloud at Customer system.

        This option is available only if you enabled backups on local Oracle Exadata storage in the VM cluster that you want to host the database.

      • Object Storage: Select to store backups in an Oracle-managed object storage container on Oracle Cloud Infrastructure.

        To use this option, your Oracle Exadata Cloud@Customer system must have egress connectivity to Oracle Cloud Infrastructure Object Storage.

      • NFS: Select to store backups in one of your previously defined backup destinations that use Network File System (NFS) storage. For more information, refer to the information about backup destinations in this publication.

        If you select this option, then you must also choose from the list of NFS Backup Destinations.

      • Recovery Appliance: Select to store backups in one of your previously defined backup destinations that use Oracle Zero Data Loss Recovery Appliance. Refer to the information about backup destination options in this document.

        If you select Oracle Zero Data Loss Recovery Appliance as your backup option, then you must also:

        • Choose from the list of appliance Backup Destinations.
        • Choose from the VPC User list, which contains the list of virtual private catalog (VPC) user names that are defined in the Oracle Zero Data Loss Recovery Appliance backup destination.
        • Provide the Password for the VPC user.
        Note

        If you select a backup destination, then you cannot change a backup location after the database is created. However, if you select None now, then you can select a backup destination after the database is created.

      • Enable automatic backups: Select this option to enable daily backups using the policy for automatic backups.

        This option is only enabled when you select a Backup Destination Type other than None. You can change this setting after database creation.

    • Key Management: Choose an encryption option, Oracle Wallet, Oracle Key Vault, or External HSM. The default option is Oracle Wallet.
      • Oracle Wallet:

        Use the administrator password for the TDE wallet: When this option is checked, the password entered for the SYS user is also used for the TDE wallet. To set the TDE wallet password manually, uncheck this option and enter the TDE wallet password and confirm it.

      • Oracle Key Vault: Select the compartment where you have created the Key Store, and then select the Key Store. As part of the CDB creation, a new wallet is created for the CDB in Oracle Key Vault (OKV). Also, a TDE Master Key is generated for the CDB and added to the wallet in OKV.
        Note

        • Container Databases (CDB) and pluggable databases (PDB) only support 256-bit Hardware Security Module (HSM) Vault keys.
        • Validate OKV Key encryption post restart: OKV TDE Maser Key is validated every time you start or restart your CBD.
        • Start or restart fails if the key is not validated. Work requests and life cycle states indicate the reason for failure.
        • View OKV keys post database restore: When you restore a CDB, the master key associated with that backup is restored as well.
        • Enable CDB backups to capture wallet name: CDB backups information about the wallet associated with the backup.
        • OKV Wallet or TDE Master Key on CDB deletion: If you delete a CDB, then the wallet and TDE Master Key remain in OKV and will not be deleted.
      • External Keystore:
        • TDE wallet password: Enter the TDE wallet password.
        • External Keystore credential: Enter user credentials in the format your external keystore provider supports.
    • (Optional) Select Show Advanced Options. From this window, you can select the following options:
      • Provide the Oracle SID prefix:
        Note

        Entering a SID prefix is only available for 12.1 databases and above.

        Optionally, specify the Oracle SID prefix for the database. The instance number is automatically appended to the SID prefix to become the instance_name database parameter. If not provided, then the SID prefix defaults to the db_name.

        Review the following guidelines when selecting a database name:
        • maximum of 12 characters
        • contain only alphanumeric characters
        • begin with an alphabetic character
        • unique in the VM cluster
      • Encryption Key: Choose an encryption option, Encrypt using Oracle-managed keys or Encrypt using customer-managed keys. The default option is Oracle-managed keys.

        To use customer-managed keys, select the Encrypt using customer-managed keys option, select the compartment where you have created the Key Store, and then select the Key Store. As part of the CDB creation, a new wallet is created for the CDB in Oracle Key Vault (OKV). Also, a TDE Master Key is generated for the CDB and added to the wallet in OKV.

        Note

        • Container Databases (CDB) and pluggable databases (PDB) only support 256-bit Hardware Security Module (HSM) Vault keys.
        • Validate OKV Key encryption post restart: OKV TDE Maser Key is validated every time you start or restart your CBD.
        • Start or restart fails if the key is not validated. Work requests and life cycle states indicate the reason for failure.
        • View OKV keys post database restore: When you restore a CDB, the master key associated with that backup is restored as well.
        • Enable CDB backups to capture wallet name: CDB backups information about the wallet associated with the backup.
        • OKV Wallet or TDE Master Key on CDB deletion: If you delete a CDB, then the wallet and TDE Master Key remain in OKV and will not be deleted.

      • Backup retention period: From the list, you can choose the length of time that you want automatic backups to be retained.

        For backups to local Exadata storage, you can choose a retention period of 7 days or 14 days. The default retention period is 7 days.

        For backups to Oracle Cloud Infrastructure Object Storage, or to an NFS backup destination, you can choose one of the following preset retention periods: 7 days, 14 days, 30 days, 45 days, or 60 days. The default retention period is 30 days.

        This option does not apply to Oracle Zero Data Loss Recovery Appliance backup destinations. For backups to Oracle Zero Data Loss Recovery Appliance, the retention policy that is implemented in the appliance controls the retention period.

      • Character set: The character set for the database. The default is AL32UTF8.
      • National character set: The national character set for the database. The default is AL16UTF16.
      • Tags: (Optional) You can choose to apply tags. If you have permissions to create a resource, you also have permissions to apply free-form tags to that resource. To apply a defined tag, you must have permissions to use the tag namespace. For more information about tagging, refer to information about resource tags.If you are not sure if you should apply tags, then skip this option (you can apply tags later), or ask your administrator.
  6. Click Create Database.
Note

You can now:

  • Create or delete a CDB while a Data Guard setup is running on another database within the same Oracle home, and vice versa.
  • Create or delete a CDB while concurrently performing Data Guard actions (switchover, failover, and reinstate) within the same Oracle home, and vice versa.
  • Create or delete a CDB while concurrently creating or deleting a PDB within the same Oracle home, and vice versa.
  • Create or delete a CDB concurrently on different databases within the same Oracle home.
  • Create or delete a CDB while simultaneously updating VM Cluster tags.

Using the Console to Manage SYS User and TDE Wallet Passwords

Learn to manage administrator (SYS user) and TDE wallet passwords.

  1. Open the navigation menu. Click Oracle Database, then click Exadata Database Service on Cloud@Customer
  2. Choose your Compartment that contains the VM cluster that hosts the database that you want to change passwords.
  3. Click the name of the VM cluster that contains the database that you want to change passwords.
  4. In the Resources list of the VM Cluster Details page, click Databases.
  5. Click the name of the database that you want to change passwords.

    The Database Details page displays information about the selected database.

  6. On the Database Details page, click More actions, and then click Manage passwords.
  7. In the resulting Manage passwords dialog, click Update Administrator Password or Update TDE Wallet Password.

    Depending on the option you select, the system displays the fields to edit.

    • Update Administrator Password: Enter the new password in both the New administrator password and Confirm administrator password fields.
      Note

      The Update Administrator Password option will change the sys user password only. Passwords for other administrator accounts such as system, pdbadmin, and TDE wallet will not be changed.
    • Update TDE Wallet Password: Enter the current wallet password in the Enter existing TDE wallet password field, and then enter the new password in both the New TDE wallet password and Confirm TDE wallet password fields.
  8. Click Apply to update your chosen password.

Using the Console to Migrate Encryption Keys from Oracle Wallet to Other Encryption Methods (Oracle Key Vault, External Keystore)

Learn to migrate encryption keys between different encryption methods.

Note

  • Migration requires the credentials for the encryption key, which must already be present on the external keystore.
  • Key migration works seamlessly in a Data Guard environment.
  • You cannot migrate keys if other databases in the same VM cluster are already using different encryption methods, such as an external keystore or Oracle Key Vault (OKV).
  • You will encounter an issue during PDB creation or cloning operations on databases migrated to an external keystore. The fix for this issue will be included in the January 2025 Release Update (RU) for database versions 19c and 23ai. Until the RU becomes available, Oracle recommends applying the one-off patch 36930984 to address the issue.
  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
    VM Clusters is selected by default.
  2. Select the compartment containing the VM cluster that hosts the database for which you are migrating encryption keys.
  3. Click the name of the VM cluster that contains the database that you want to migrate encryption keys.
  4. In the Resources list of the VM Cluster Details page, click Databases.
  5. Click the name of the database that you want to migrate encryption keys to a difference encryption method.

    The Database Details page displays information about the selected database.

  6. In the Encryption section, click the Migrate key link.
  7. On the resulting Migrate Key page, change the key encryption method and click Save changes.

Using the Console to Rotate Encryption Keys

Learn how to rotate encryption keys. Note that key rotation is only available for databases that do not use Oracle Wallet as the encryption method.

Note

The "Rotate key" functionality applies only to databases that are not using Oracle Wallet.
  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
    VM Clusters is selected by default.
  2. Select the compartment containing the VM cluster that hosts the database for which you are rotating encryption keys.
  3. Click the name of the VM cluster that contains the database that you want to rotate encryption keys.
  4. In the Resources list of the VM Cluster Details page, click Databases.
  5. Click the name of the database that you want to rotate encryption keys.

    The Database Details page displays information about the selected database.

  6. In the Encryption section, click the Rotate key link.
  7. On the resulting Rotate Key dialog, click Rotate.

Using the Console to Move a Database to Another Database Home

Learn to move a database to another Database Home.

  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
    VM Clusters is selected by default.
  2. Choose your Compartment that contains the VM cluster that hosts the database that you want to move.
  3. Click the name of the VM cluster that contains the database that you want to move.
  4. In the Resources list of the VM Cluster Details page, click Databases.
  5. Click the name of the database that you want to move.
    The Database Details page displays information about the selected database.
  6. Click Move Database.
  7. In the resulting dialog, select the target Database Home.
    Note

    Oracle recommends using Database Homes, which are running the latest (N) to 3 versions from the latest (N-3) RU versions when updating the software version of the database by moving them to a target DB Home. Only DB Homes provisioned with database versions, which meet this best practice criterion are available as target homes to move your database.
  8. Click Move Database.

The database will be stopped in the current home and then restarted in the destination home. While the database is being moved, the Database Home status displays as Moving Database. When the operation completes, Database Home is updated with the current home. If the operation is unsuccessful, the status of the database displays as Failed, and the Database Home field provides information about the reason for the failure.

Using the Console to Terminate a Database

You can terminate a database and thereby remove the terminated database from the Cloud Control Plane.

Terminating a database removes it from the Cloud Control Plane. In the process, all of the associated data files and backups are destroyed.
  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
    VM Clusters is selected by default.
  2. Choose your Compartment that contains the VM cluster that hosts the database that you want to terminate.
  3. Click the name of the VM cluster that contains the database that you want to terminate.
  4. In the Resources list of the VM Cluster Details page, click Databases.
  5. Click the name of the database that you want to terminate.
    The Database Details page displays information about the selected database.
  6. Click Terminate.
  7. In the resulting dialog, enter the name of the database, and then click Terminate Database to confirm the action.
Note

You can now:

  • Terminate a CDB when Data Guard setup is running on another database in the same Oracle home, and vice versa.
  • Create or delete a CDB while concurrently performing Data Guard actions (switchover, failover, and reinstate) within the same Oracle home, and vice versa.

Using the API to Manage Oracle Database Components

Use various API features to help manage your databases on Oracle Exadata Database Service on Cloud@Customer.

For information about using the API and signing requests, see "REST APIs" and "Security Credentials". For information about SDKs, see "Software Development Kits and Command Line Interface".

Use the following API operations to manage various database components.

Database homes:
  • CreateDbHome
  • DeleteDbHome
  • GetDbHome
  • ListDbHomes
Databases:
  • CreateDatabase
  • GetDatabase
  • ListDatabases
  • UpdateDatabase
  • UpdateDatabaseDetails
Nodes:
  • GetDbNode
  • List DbNodes

Use UpdateDatabase to move a database to a different Database Home, thereby updating the database to the same version as the target Database Home.

For the complete list of APIs, see "Database Service API".

Changing the Database Passwords

To change the SYS password, or to change the TDE wallet password, use this procedure.

The password that you specify in the Database Admin Password field when you create a new Exadata Database Service on Cloud@Customer instance or database is set as the password for the SYS, SYSTEM, TDE wallet, and PDB administrator credentials. Use the following procedures if you need to change passwords for an existing database.

Note

if you are enabling Data Guard for a database, then the SYS password and the TDE wallet password of the primary and standby databases must all be the same.
Note

Using the dbaascli to change the SYS password will ensure the backup/restore automation can parallelize channels across all nodes in the cluster.

To Change the SYS Password for an Exadata Database Service on Cloud@Customer Database

  1. Log onto the Exadata Database Service on Cloud@Customer virtual machine as opc.
  2. Run the following command:
    sudo dbaascli database changepassword --dbname database_name --user SYS

To Change Database Passwords in a Data Guard Environment

  1. Run the following command on the primary database:
    dbaascli database changePassword —dbName <dbname> --user SYS --prepareStandbyBlob true --blobLocation <location to create the blob file>
  2. Copy the blob file created to all the standby databases and update the file ownership to oracle user.
  3. Run the following command on all the standby databases:
    dbaascli database changePassword —dbName <dbname> --user SYS --standbyBlobFromPrimary <location of copies the blob file>

To Change the TDE Wallet Password for an Exadata Database Service on Cloud@Customer Database

  1. Log onto the Exadata Database Service on Cloud@Customer virtual machine as opc.
  2. Run the following command:
    sudo dbaascli tde changepassword --dbname database_name

Manage Pluggable Databases on Oracle Exadata Database Service on Cloud@Customer

Learn to manage pluggable databases on Oracle Exadata Database Service on Cloud@Customer.

Parent topic: Manage Databases on Oracle Exadata Database Service on Cloud@Customer

Pluggable Database Operations

You can create and manage pluggable databases (PDBs) in Oracle Exadata Database Service on Cloud@Customer systems using the Console and APIs.

In this documentation, "database" refers to a container database, also called a CDB. For more information on these resource types, see Multitenant Architecture in the Oracle Database documentation.

Oracle 19c or later databases created in a virtual machine include an initial PDB that you can access from the CDB's Database Details page in the Console. Using the Console or APIs, you can start, stop, clone, and delete the PDB. You can also create additional PDBs in the container database. You can monitor all PDB operations performed using the Console or APIs using the work request generated by the operation.

  • Backup

    You can take a backup of the PDB optionally during create, clone, or relocate operations when the CDB is configured with the auto-backup feature. The PDB backup destination will always be the same as CDB, and the backups cannot be accessed directly or created on demand. Oracle recommends immediately backing up the PDB after you create or clone it. This is because the PDB will not be recoverable until the next daily auto-backup completes successfully, leading to a possible data loss.

  • Restore
    • Base Database Service / Oracle Exadata Database Service on Dedicated Infrastructure:
      • In place restore: You can restore a PDB within the same CDB to last known good state or to a specified timestamp.
      • Out of place restore: You can restore a PDB by creating a database (CDB) from the backup, then selecting a PDB or a subset of them you want to restore on the new database.
    • Oracle Exadata Database Service on Cloud@Customer:
      • In place restore: You can restore a PDB within the same CDB to last known good state and specified timestamp.
      • Out of place restore: It's not available.
    You can perform an in-place restore when you want to move a PDB back to a specified state or time. Both the CDB and PDB must be up and running and only one PDB can be restored at a time.
    • If you have multiple PDBs in your CDB and want to restore multiple of them to the same CDB, then you could restore each individual PDB, one PDB at a time, from the CDB backup.
    • When the CDB is down, you could restore the complete CDB and all the PDBs in that CDB will also be restored.
    • You could either restore the database to the specified timestamp or to its last known good state.
  • Relocate
    You can relocate a PDB from one CDB to another CDB within the same availability domain (AD):
    • Across compartments, VM clusters, DB system (for BaseDB only), or VCNs (not applicable to ExaDB-C@C). If two different VCNs are used, then both VCNs must be peered before relocating.
    • To the same or a higher database version.

    During relocate, the PDB will be removed from the source CDB and moved to the destination CDB that is up and running. In a Data Guard association, a PDB relocated to the primary will be synchronized with the standby as well.

  • Clone

    A clone is an independent and complete copy of the given database as it existed at the time of the cloning operation. You can create clones of your PDB within the same CDB or a different CDB and refresh the cloned PDB.

    The following types of clones are supported:
    • Local clone: A copy of the PDB is created within the same CDB.
    • Remote clone: A copy of the PDB is created in a different CDB.
      You can perform a remote clone of a PDB from one CDB to another CDB within the same availability domain (AD):
      • Across compartments, VM clusters, DB system (for BaseDB only), or VCNs (not applicable to ExaDB-C@C). If two different VCNs are used, then both VCNs must be peered before cloning.
      • To the same or a higher database version.

    • Refreshable clone: A copy of the PDB is created in a different CDB, and you will be able to refresh the cloned PDB.

      You can perform a refreshable clone of a PDB from one CDB to another CDB within the same availability domain (AD):
      • Across compartments, VM clusters, DB system (for BaseDB only), or VCNs (not applicable to ExaDB-C@C). If two different VCNs are used, then both VCNs must be peered before cloning.
      • To the same or a higher database version.
  • Refreshable Clone
    A refreshable clone enables you to keep your remote clone updated with the source PDB. You can only refresh while the PDB is in mount mode. The only open mode you can have is read-only and refresh cannot be done while it is in read-only mode.
    • A database link user credential is required for creating a refreshable clone.
    • Clone, relocate, and in-place restore operations are not supported in the refreshable clone. Relocate and in-place restore operations are not supported in the source, and the source can only be deleted after disconnecting or deleting the refreshable clone.
    • In a Data Guard association, a refreshable clone cannot be created on standby, but it can be created on the primary. However, the primary will not be synced to the standby.
      Note

      A PDB in standby cannot be used as the source for a refreshable PDB.

  • Convert Refreshable PDB to Regular PDB

    You can convert a refreshable PDB to a regular PDB by disconnecting the refreshable clone (destination PDB) from the source PDB at any time. If the refresh PDB is in a Data Guard association, when it is converted to a regular PDB the PDB will be synced to the standby as part of the conversion process.

  • Open Modes

    On the Console, you can see the open modes of a PDB, such as read-write, read-only, and mounted. If the PDB status is the same across all nodes, the system displays the same status for all PDBs. If the PDB statuses are different across the nodes, the system displays a message indicating on which nodes the PDBs are opened in read-write mode. You cannot change the open mode of a PDB through the API or Console. However, you can start or stop a PDB. Starting the PDB will start it in read-write mode. Stopping the PDB will close it and it will remain in mount mode.

Related Topics

Parent topic: Manage Pluggable Databases on Oracle Exadata Database Service on Cloud@Customer

Limitations for Pluggable Database Management

Review the list of limitations in managing PDBs.

  • Oracle recommends using the Console or API-based tools (including the OCI CLI, SDKs, and Terraform) to create and manage PDBs. However, there would be periodic sync of the PDBs created through DBAASCLI and SQL*Plus.
  • PDB management using the OCI Console and API is available only for Oracle Database versions 19c and later.
  • PDBs are backed up at the CDB level, and each backup includes all the PDBs in the database. OCI Control Plane does not support the creation of backups for individual PDBs. However, bkup_api supports PDB backup operations. For more information, see Configuring and Customizing Backups with bkup_api.
    Examples:
    • List backups: 
      /var/opt/oracle/bkup_api/bkup_api list --dbname psarch
    • Create initial PDB backup manually: 
      /var/opt/oracle/bkup_api/bkup_api bkup_start --level1 --dbname psarch --pdb NEWPDBA
  • Restore operations are performed at the CDB level. OCI Control Plane does not support restoring individual PDBs. However, bkup_api supports PDB restore operations.
    Examples:
    • Recover a PDB with least or no data loss possible: 
      /var/opt/oracle/bkup_api/bkup_api recover_start --latest --dbname psarch --pdb NEWPDBA
    • Recover a PDB back to a point in time: 
      /var/opt/oracle/bkup_api/bkup_api recover_start -t '17-AUG2021 21:15:00' --dbname psarch --pdb NEWPDBA
    • Recover until SCN: 
      /var/opt/oracle/bkup_api/bkup_api recover_start -scn 138935800 -pdb=NEWPDBA -uuid=fec6579e077211ec8b0a00102ee75632 -bname=psarch
Create a Pluggable Database

You can create a PDB from the OCI Console, or with the pluggable database APIs.

Parent topic: Pluggable Database Operations

Using the Console to Create a Pluggable Database

To create a pluggable database with the console, use this procedure.

Note

If the databases are created directly on Guest VM, the attributed usage data would be delayed.
  1. Open the navigation menu Under Oracle Database, and click Exadata Database Service on Cloud@Customer.

    VM Clusters is selected by default.

  2. Choose your Compartment.

    A list of VM Clusters is displayed for the chosen Compartment.

  3. In the list of cloud VM clusters, click the name of the cluster in which you want to create the PDB, and then click its name to display the database details page.
  4. In the lower-left corner of the database details page, click Pluggable Databases.

    A list of existing PDBs in this database is displayed.

  5. Click Create Pluggable Database.

    The Create Pluggable Database dialog box is displayed.

  6. In the Create Pluggable Database dialog box, enter the following:
    • Enter PDB Name: Enter a name for the PDB. The name must begin with an alphabetic character and can contain a maximum of 30 alphanumeric characters.
    • Unlock my PDB Admin Account:
      • To enter the administrator's password, check this check box.
        • PDB Admin Password: Enter PDB admin password. The password must contain:
          • a minimum of 9 and a maximum of 30 characters
          • at least two uppercase characters
          • at least two lowercase characters
          • at least two special characters. The valid special characters are underscore ( _ ), a pound or hash sign (#), and dash (-). You can use two of the same characters or any combination of two of the same characters.
          • at least two numeric characters (0 - 9)
        • Confirm PDB Admin Password: Enter the same PDB Admin password in the confirmation field.
      • To skip entering the administrator's password, uncheck this check box. If you uncheck this check box, then the PDB is created but you cannot use it. To use the PDB, you must reset the administrator password.
        Note

        When you create a new PDB, a local user in the PDB is created as the administrator and granted the PDB_DBA role locally to the administrator.
        To reset the password:
        1. Connect to the container where your PDB exists using the SQL*Plus CONNECT statement.
          SQL> show con_name;
CON_NAME
------------------------
CDB$ROOT

          For more information, see Administering a CDB and Administering PDBs in the Oracle® Multitenant Administrator’s Guide.

        2. Find the administrator name of your PDB:
          SQL> select grantee from cdb_role_privs where con_id = (select con_id from cdb_pdbs where pdb_name = '<PDB_NAME>') and granted_role = 'PDB_DBA';
        3. Switch into your PDB:
          SQL> alter session set container=<PDB_NAME>;
Session altered.

          SQL> show con_name;
CON_NAME
------------------------
<PDB_NAME>
        4. Reset the PDB administrator password:
          SQL> alter user <PDB_Admin> identified by <PASSWORD>;
User altered.
    • TDE Wallet password of database: Enter a wallet password for the CDB. This password has the same rules as the PDB Admin Password.
    • Take a backup of the PDB immediately after creating it: You must enable auto-backup on the CDB to back up a PDB immediately after creating it. This check box is checked by default if auto-backup was enabled on the CDB.
      Note

      If the checkbox is unchecked, the system displays a warning stating that PDB cannot be recovered until the next daily backup has been successfully completed.

    • Advanced Options:
      • Tags: Optionally, you can apply tags. If you have permission to create a resource, you also have permission to apply free-form tags to that resource. To apply a defined tag, you must have permission to use the tag namespace. For more information about tagging, see Resource Tags. If you are not sure if you should apply tags, skip this option (you can apply tags later) or ask your administrator.
      • Encryption Key Store: This shows if the encryption key for the CDB is managed by Oracle or by the customer. In the case of customer-manager keys, the name of the key store you have configured for CDB is displayed. You cannot edit this field.
  7. Click Create Pluggable Database.

    The system starts the creation process and opens the Work Request page for the new PDB. The Work request page shows the status of the creation process of the new PDB.

    By default, the Work Request details page shows the log messages created by the system. Click Error Messages or Associated Resources to see any error messages or associated resources for the creation process, in the Resources area on the left side of the page.

    Note

    • The numbers at the right side of the Log Messages, Error Messages, and Associated Resources links indicate how many of each item exists.
    • Create or delete a PDB while a Data Guard setup is running on another database within the same Oracle home, and vice versa.
    • Create or delete a PDB while concurrently performing Data Guard actions (switchover, failover, and reinstate) within the same Oracle home, and vice versa.
    • Create or delete a PDB concurrently on different databases within the same Oracle home.
    • Create or delete a PDB while simultaneously updating VM Cluster tags.
Using the Console to Relocate a Pluggable Database

To relocate a pluggable database with the console, use this procedure.

  1. Open the navigation menu Under Oracle Database, and click Exadata Cloud@Customer.

    VM Clusters is selected by default.

  2. Choose your Compartment.

    A list of VM Clusters is displayed for the chosen Compartment.

  3. In the list of VM clusters, click the name of the cluster in which you want to create the PDB, and then click its name to display the database details page.
  4. In the lower-left corner of the database details page, click Pluggable Databases.

    A list of existing PDBs in this database is displayed.

  5. Click the name of the PDB that you want to relocate.

    From the Pluggable Database details page, click More Actions, and then select Relocate.

    (or)

    Click the Actions menu (three dots) and select Relocate.

  6. In the resulting Relocate Pluggable Database window, enter the following:
    • VM Cluster: Use the menu to select the destination VM cluster.
    • Destination database: Use the menu to select an existing database where the PDB will be created. This database can be of the same version as the CDB the source PDB is in or of a higher version.
    • New PDB name for the clone: The name must begin with an alphabetic character and can contain up to 30 characters. To keep the PDB name the same, just re-enter the source PDB name.
    • Database TDE wallet password: Enter the TDE wallet password for the parent CDB of the source PDB.
    • Unlock my PDB Admin Account:
      • To enter the administrator's password, check this check box.
        • PDB Admin Password: Enter PDB admin password. The password must contain:
          • a minimum of 9 and a maximum of 30 characters
          • at least two uppercase characters
          • at least two lowercase characters
          • at least two special characters. The valid special characters are underscore ( _ ), a pound or hash sign (#), and dash (-). You can use two of the same characters or any combination of two of the same characters.
          • at least two numeric characters (0 - 9)
        • Confirm PDB Admin Password: Enter the same PDB Admin password in the confirmation field.
      • To skip entering the administrator's password, uncheck this check box. If you uncheck this check box, then the PDB is created but you cannot use it. To use the PDB, you must reset the administrator password.
        Note

        When you create a new PDB, a local user in the PDB is created as the administrator and granted the PDB_DBA role locally to the administrator.

        To reset the password:
        1. Connect to the container where your PDB exists using the SQL*Plus CONNECT statement.
          SQL> show con_name;
CON_NAME
------------------------
CDB$ROOT

          For more information, see Administering a CDB and Administering PDBs in the Oracle® Multitenant Administrator’s Guide.

        2. Find the administrator name of your PDB:
          SQL> select grantee from cdb_role_privs where con_id = (select con_id from cdb_pdbs where pdb_name = '<PDB_NAME>') and granted_role = 'PDB_DBA';
        3. Switch into your PDB:
          SQL> alter session set container=<PDB_NAME>;
Session altered.

          SQL> show con_name;
CON_NAME
------------------------
<PDB_NAME>
        4. Reset the PDB administrator password:
          SQL> alter user <PDB_Admin> identified by <PASSWORD>;
User altered.
    • TDE Wallet password of database: Enter a wallet password for the CDB. This password has the same rules as the PDB Admin Password.
    • Take a backup of the PDB immediately after creating it: You must enable auto-backup on the CDB to back up a PDB immediately after creating it. This check box is checked by default if auto-backup was enabled on the CDB.
      Note

      If the checkbox is unchecked, the system displays a warning stating that PDB cannot be recovered until the next daily backup has been successfully completed.

    • Advanced Options:
      • Tags: Optionally, you can apply tags. If you have permission to create a resource, you also have permission to apply free-form tags to that resource. To apply a defined tag, you must have permission to use the tag namespace. For more information about tagging, see Resource Tags. If you are not sure if you should apply tags, skip this option (you can apply tags later) or ask your administrator.
  7. Click Relocate pluggable database.
    Note

    Relocate will incur downtime during the process and that the time required is based on the size of the PDB.

Using the API to Create a Pluggable Database

Use various API features to help create your pluggable databases on Oracle Exadata Database Service on Cloud@Customer.

For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Software Development Kits and Command Line Interface.

Use this API operation to create pluggable databases on Oracle Exadata Database Service on Cloud@Customer systems.
  • CreatePluggableDatabase
Manage a Pluggable Database

To start, stop, clone, and delete a PDB, use these procedures.

Parent topic: Pluggable Database Operations

Using the Console to Start a Pluggable Database

The PDB must be available and stopped to use this procedure.

  1. Open the navigation menu Under Oracle Database, and click Exadata Cloud@Customer.

    VM Clusters is selected by default.

  2. Choose your Compartment.

    A list of VM Clusters is displayed for the chosen Compartment.

  3. In the list of VM clusters, click the name of the VM cluster that contains the PDB you want to start, and then click its name to display the details page.
  4. Under Databases, find the database containing the PDB you want to start.
  5. Click the name of the database to view the Database Details page.
  6. Click Pluggable Databases in the Resources section of the page.

    A list of existing PDBs in this database is displayed.

  7. Click the name of the PDB that you want to start.

    The pluggable details page is displayed.

  8. Click Start.

    The Start PDB dialog box is displayed.

  9. Click Start PDB to confirm the start operation.
Using the Console to Stop a Pluggable Database

The PDB must be available and running (started) to use this procedure.

  1. Open the navigation menu Under Oracle Database, and click Exadata Cloud@Customer.

    VM Clusters is selected by default.

  2. Choose your Compartment.

    A list of VM Clusters is displayed for the chosen Compartment.

  3. In the list of VM clusters, click the name of the VM cluster that contains the PDB you want to stop, and then click its name to display the details page.
  4. Under Databases, find the database containing the PDB you want to stop.
  5. Click the name of the database to view the Database Details page.
  6. Click Pluggable Databases in the Resources section of the page.

    A list of existing PDBs in this database is displayed.

  7. Click the name of the PDB that you want to stop.

    The pluggable details page is displayed.

  8. Click Stop.

    The Stop PDB dialog box is displayed.

  9. Click Stop PDB to confirm the stop operation.
Using the Console to Delete a Pluggable Database

The PDB must be available and stopped to use this procedure.

  1. Open the navigation menu Under Oracle Database, and click Exadata Cloud@Customer.

    VM Clusters is selected by default.

  2. Choose your Compartment.

    A list of VM Clusters is displayed for the chosen Compartment.

  3. In the list of VM clusters, click the name of the VM cluster that contains the PDB you want to delete, and then click its name to display the details page.
  4. Under Databases, find the database containing the PDB you want to delete.
  5. Click the name of the database to view the Database Details page.
  6. Click Pluggable Databases in the Resources section of the page.

    A list of existing PDBs in this database is displayed.

  7. Click the name of the PDB that you want to delete.

    The pluggable details page is displayed.

  8. Click More Actions, and then choose Delete.

    The Delete PDB dialog box is displayed.

  9. Click Delete PDB to confirm the delete operation.
Note

You can now delete a PDB when Data Guard setup is running on another database in the same Oracle home, and vice versa.

Using the Console to Get Connection Strings for a Pluggable Database

Learn how to get connection strings for the administrative service of a PDB. Oracle recommends connecting applications to an application service using the strings created for the application service.

  1. Open the navigation menu Under Oracle Database, and click Exadata Cloud@Customer.

    VM Clusters is selected by default.

  2. Choose your Compartment.

    A list of VM Clusters is displayed for the chosen Compartment.

  3. In the list of VM clusters, click the name of the VM cluster that contains the PDB you want to get connections strings for, and then click its name to display the details page.
  4. Under Databases, find the database containing the PDB you want to get connection strings.
  5. Click the name of the database to view the Database Details page.
  6. Click Pluggable Databases in the Resources section of the page.

    A list of existing PDBs in this database is displayed.

  7. Click the name of the PDB that you want to get connection strings.

    The pluggable details page is displayed.

  8. Click PDB Connection.
  9. In the Pluggable Database Connection dialog, use the Show and Copy links to display and copy connection strings, as needed.
  10. Click Close to exit the dialog.
Clone a Pluggable Database (PDB)

A clone is an independent and complete copy of the given database as it existed at the time of the cloning operation. You can create clones of your PDB within the same CDB or a different CDB and also refresh the cloned PDB.

Note

When cloning a PDB from 19c to 23ai, the cloned PDB is automatically upgraded to 23ai. For example, if you use refreshable clones to clone to 23ai and then convert it to regular PDB, all necessary upgrade steps are automatically handled, converting the refreshable clone into a fully upgraded 23ai PDB.

The following types of clones are supported:

  • Local clone: A clone of the PDB is created within the same CDB.
  • Remote clone: A clone of the PDB is created in a different CDB.
  • Refreshable clone: A clone of the PDB is created in a different CDB, and you will be able to refresh the cloned PDB.

    For more information about refreshable clones, see About Refreshable Clone PDBs..

Parent topic: Manage a Pluggable Database

Using the Console to Create a Local Clone of a Pluggable Database (PDB)

To create a local clone of your PDBs, follow this procedure.

  1. Open the navigation menu Under Oracle Database, and click Exadata Cloud@Customer.

    VM Clusters is selected by default.

  2. Choose your Compartment.

    A list of VM Clusters is displayed for the chosen Compartment.

  3. In the list of VM clusters, click the name of the VM cluster that contains the PDB you want to clone, and then click its name to display the details page.
  4. Under Databases, find the database containing the PDB you want to clone.
  5. Click Pluggable Databases in the Resources section of the page.

    A list of existing PDBs in this database is displayed.

  6. Click the name of the PDB that you want to clone.

    The pluggable details page is displayed.

  7. Click Clone.
  8. In the Clone PDB dialog box, enter the following:
    • Select clone type: Select Local clone to create a copy of the source PDB to the same CDB.
    • VM Cluster: Use the menu to select the source VM cluster.
    • Destination database: This field is disabled.
    • New PDB name for the clone: The name must begin with an alphabetic character and can contain up to 30 characters.
    • Database TDE wallet password: Enter the TDE wallet password for the parent CDB of the source PDB.
    • Unlock my PDB Admin Account:
      • To enter the administrator's password, check this check box.
        • PDB Admin Password: Enter PDB admin password. The password must contain:
          • a minimum of 9 and a maximum of 30 characters
          • at least two uppercase characters
          • at least two lowercase characters
          • at least two special characters. The valid special characters are underscore ( _ ), a pound or hash sign (#), and dash (-). You can use two of the same characters or any combination of two of the same characters.
          • at least two numeric characters (0 - 9)
        • Confirm PDB Admin Password: Enter the same PDB Admin password in the confirmation field.
      • To skip entering the administrator's password, uncheck this check box. If you uncheck this check box, then the PDB is created but you cannot use it. To use the PDB, you must reset the administrator password.
        Note

        When you create a new PDB, a local user in the PDB is created as the administrator and granted the PDB_DBA role locally to the administrator.
        To reset the password:
        1. Connect to the container where your PDB exists using the SQL*Plus CONNECT statement.
          SQL> show con_name;
CON_NAME
------------------------
CDB$ROOT

          For more information, see Administering a CDB and Administering PDBs in the Oracle® Multitenant Administrator’s Guide.

        2. Find the administrator name of your PDB:
          SQL> select grantee from cdb_role_privs where con_id = (select con_id from cdb_pdbs where pdb_name = '<PDB_NAME>') and granted_role = 'PDB_DBA';
        3. Switch into your PDB:
          SQL> alter session set container=<PDB_NAME>;
Session altered.

          SQL> show con_name;
CON_NAME
------------------------
<PDB_NAME>
        4. Reset the PDB administrator password:
          SQL> alter user <PDB_Admin> identified by <PASSWORD>;
User altered.
    • Take a backup of the PDB immediately after creating it: You must enable auto-backup on the CDB to back up a PDB immediately after creating it. This check box is checked by default if auto-backup was enabled on the CDB.
      Note

      If the checkbox is unchecked, the system displays a warning stating that PDB cannot be recovered until the next daily backup has been successfully completed.

    • Enable thin clone: All clones are thin clones by default. For more information about thin clone, see Thin Cloning a Pluggable Database in the Oracle® Exadata Exascale User's Guide. If you specifically want a thick clone (full copy), you need to deselect this option.
    • Advanced Options:
      • Tags: Optionally, you can apply tags. If you have permission to create a resource, you also have permission to apply free-form tags to that resource. To apply a defined tag, you must have permission to use the tag namespace. For more information about tagging, see Resource Tags. If you are not sure if you should apply tags, skip this option (you can apply tags later) or ask your administrator.
  9. Click Clone pluggable database.

Related Topics

Parent topic: Clone a Pluggable Database (PDB)

Using the Console to Create a Remote Clone of a Pluggable Database (PDB)

To create a remote clone of your PDBs, follow this procedure.

  1. Open the navigation menu Under Oracle Database, and click Exadata Cloud@Customer.

    VM Clusters is selected by default.

  2. Choose your Compartment.

    A list of VM Clusters is displayed for the chosen Compartment.

  3. In the list of VM clusters, click the name of the VM cluster that contains the PDB you want to clone, and then click its name to display the details page.
  4. Under Databases, find the database containing the PDB you want to clone.
  5. Click Pluggable Databases in the Resources section of the page.

    A list of existing PDBs in this database is displayed.

  6. Click the name of the PDB that you want to clone.

    The pluggable details page is displayed.

  7. Click Clone.
  8. In the Clone PDB dialog box, enter the following:
    • Select clone type: Select Remote clone to create a copy of the source PDB to the same CDB.
    • VM Cluster: Use the menu to select the destination VM cluster.
    • Destination database: Use the menu to select an existing database where the PDB will be created. This database can be of the same version as the CDB the source PDB is in or of a higher version.
    • New PDB name for the clone: The name must begin with an alphabetic character and can contain up to 30 characters.
    • Database TDE wallet password: Enter the TDE wallet password for the parent CDB of the source PDB.
    • Unlock my PDB Admin Account:
      • To enter the administrator's password, check this check box.
        • PDB Admin Password: Enter PDB admin password. The password must contain:
          • a minimum of 9 and a maximum of 30 characters
          • at least two uppercase characters
          • at least two lowercase characters
          • at least two special characters. The valid special characters are underscore ( _ ), a pound or hash sign (#), and dash (-). You can use two of the same characters or any combination of two of the same characters.
          • at least two numeric characters (0 - 9)
        • Confirm PDB Admin Password: Enter the same PDB Admin password in the confirmation field.
      • To skip entering the administrator's password, uncheck this check box. If you uncheck this check box, then the PDB is created but you cannot use it. To use the PDB, you must reset the administrator password.
        Note

        When you create a new PDB, a local user in the PDB is created as the administrator and granted the PDB_DBA role locally to the administrator.
        To reset the password:
        1. Connect to the container where your PDB exists using the SQL*Plus CONNECT statement.
          SQL> show con_name;
CON_NAME
------------------------
CDB$ROOT

          For more information, see Administering a CDB and Administering PDBs in the Oracle® Multitenant Administrator’s Guide.

        2. Find the administrator name of your PDB:
          SQL> select grantee from cdb_role_privs where con_id = (select con_id from cdb_pdbs where pdb_name = '<PDB_NAME>') and granted_role = 'PDB_DBA';
        3. Switch into your PDB:
          SQL> alter session set container=<PDB_NAME>;
Session altered.

          SQL> show con_name;
CON_NAME
------------------------
<PDB_NAME>
        4. Reset the PDB administrator password:
          SQL> alter user <PDB_Admin> identified by <PASSWORD>;
User altered.
    • Source database SYS password: Enter the database admin password.
    • Database link: Enter the user name and password for the database link. Note that the user must be precreated in the source database. The DB link will be created in the destination using that username and password.
      Note

      If you do not provide database link information, cloud automation will create a database link using the common user. However, you can specify the database link information if you want cloud automation to use a specific database link.
    • Take a backup of the PDB immediately after creating it: You must enable auto-backup on the CDB to back up a PDB immediately after creating it. This check box is checked by default if auto-backup was enabled on the CDB.
      Note

      If the checkbox is unchecked, the system displays a warning stating that PDB cannot be recovered until the next daily backup has been successfully completed.

    • Enable thin clone: All clones are thin clones by default. For more information about thin clone, see Thin Cloning a Pluggable Database in the Oracle® Exadata Exascale User's Guide. If you specifically want a thick clone (full copy), you need to deselect this option.
      Note

      The thin clone option will be disabled (greyed out) if the source and target VM clusters do not share the same vault. In such cases, only thick clones are supported.
    • Advanced Options:
      • Tags: Optionally, you can apply tags. If you have permission to create a resource, you also have permission to apply free-form tags to that resource. To apply a defined tag, you must have permission to use the tag namespace. For more information about tagging, see Resource Tags. If you are not sure if you should apply tags, skip this option (you can apply tags later) or ask your administrator.
  9. Click Clone pluggable database.

Related Topics

Parent topic: Clone a Pluggable Database (PDB)

Using the Console to Create a Refreshable Clone of a Pluggable Database (PDB)

To create a refreshable clone of your PDBs, follow this procedure.

  1. Open the navigation menu Under Oracle Database, and click Exadata Cloud@Customer.

    VM Clusters is selected by default.

  2. Choose your Compartment.

    A list of VM Clusters is displayed for the chosen Compartment.

  3. In the list of VM clusters, click the name of the VM cluster that contains the PDB you want to clone, and then click its name to display the details page.
  4. Under Databases, find the database containing the PDB you want to clone.
  5. Click Pluggable Databases in the Resources section of the page.

    A list of existing PDBs in this database is displayed.

  6. Click the name of the PDB that you want to clone.

    The pluggable details page is displayed.

  7. Click Clone.
  8. In the Clone PDB dialog box, enter the following:
    • Select clone type: Select Refreshable clone to create a copy of the source PDB to the same CDB.

      For more information about refreshable clones, see About Refreshable Clone PDBs.

    • VM Cluster: Use the menu to select the destination VM cluster.
    • Destination database: Use the menu to select an existing database where the PDB will be created. This database can be of the same version as the CDB the source PDB is in or of a higher version.
    • New PDB name for the clone: The name must begin with an alphabetic character and can contain up to 30 characters.
    • Database TDE wallet password: Enter the TDE wallet password for the parent CDB of the source PDB.
    • Unlock my PDB Admin Account:
      • To enter the administrator's password, check this check box.
        • PDB Admin Password: Enter PDB admin password. The password must contain:
          • a minimum of 9 and a maximum of 30 characters
          • at least two uppercase characters
          • at least two lowercase characters
          • at least two special characters. The valid special characters are underscore ( _ ), a pound or hash sign (#), and dash (-). You can use two of the same characters or any combination of two of the same characters.
          • at least two numeric characters (0 - 9)
        • Confirm PDB Admin Password: Enter the same PDB Admin password in the confirmation field.
      • To skip entering the administrator's password, uncheck this check box. If you uncheck this check box, then the PDB is created but you cannot use it. To use the PDB, you must reset the administrator password.
        Note

        When you create a new PDB, a local user in the PDB is created as the administrator and granted the PDB_DBA role locally to the administrator.
        To reset the password:
        1. Connect to the container where your PDB exists using the SQL*Plus CONNECT statement.
          SQL> show con_name;
CON_NAME
------------------------
CDB$ROOT

          For more information, see Administering a CDB and Administering PDBs in the Oracle® Multitenant Administrator’s Guide.

        2. Find the administrator name of your PDB:
          SQL> select grantee from cdb_role_privs where con_id = (select con_id from cdb_pdbs where pdb_name = '<PDB_NAME>') and granted_role = 'PDB_DBA';
        3. Switch into your PDB:
          SQL> alter session set container=<PDB_NAME>;
Session altered.

          SQL> show con_name;
CON_NAME
------------------------
<PDB_NAME>
        4. Reset the PDB administrator password:
          SQL> alter user <PDB_Admin> identified by <PASSWORD>;
User altered.
    • Source database SYS password: Enter the database admin password.
    • Database link: Enter the user name and password for the database link. Note that the user must be precreated in the source database. The DB link will be created in the destination using that username and password.
      Note

      For a refreshable clone, the database link parameter is mandatory, and you must provide this information.
    • Enable thin clone: All clones are thin clones by default. For more information about thin clone, see Thin Cloning a Pluggable Database in the Oracle® Exadata Exascale User's Guide. If you specifically want a thick clone (full copy), you need to deselect this option.
      Note

      The thin clone option will be disabled (greyed out) if the source and target VM clusters do not share the same vault. In such cases, only thick clones are supported.
    • Advanced Options:
      • Tags: Optionally, you can apply tags. If you have permission to create a resource, you also have permission to apply free-form tags to that resource. To apply a defined tag, you must have permission to use the tag namespace. For more information about tagging, see Resource Tags. If you are not sure if you should apply tags, skip this option (you can apply tags later) or ask your administrator.
  9. Click Clone pluggable database.

Related Topics

Parent topic: Clone a Pluggable Database (PDB)

Using the Console to Refresh a Cloned Pluggable Database (PDB)

To create a refresh a cloned PDB, follow this procedure.

  1. Open the navigation menu Under Oracle Database, and click Exadata Cloud@Customer.

    VM Clusters is selected by default.

  2. Choose your Compartment.

    A list of VM Clusters is displayed for the chosen Compartment.

  3. In the list of VM clusters, click the name of the VM cluster that contains the PDB you want to refresh, and then click its name to display the details page.
  4. Under Databases, find the database containing the PDB you want to refresh.
  5. Click the name of the database to view the Database Details page.
  6. Click Pluggable Databases in the Resources section of the page.

    A list of existing PDBs in this database is displayed.

  7. Click the name of the PDB that you want to refresh.

    The pluggable details page is displayed.

  8. Click More Actions and select Refresh.
  9. In the resulting Refresh dialog box, click Refresh to confirm.
Using the Console to Convert a Refreshable Clone to a Regular Pluggable Database (PDB)

To create a convert a refreshable clone to a regular PDB, follow this procedure.

  1. Open the navigation menu Under Oracle Database, and click Exadata Cloud@Customer.

    VM Clusters is selected by default.

  2. Choose your Compartment.

    A list of VM Clusters is displayed for the chosen Compartment.

  3. In the list of VM clusters, click the name of the VM cluster that contains the PDB you want to convert to a regular PDB, and then click its name to display the details page.
  4. Under Databases, find the database containing the PDB you want to convert to a regular PDB.
  5. Click the name of the database to view the Database Details page.
  6. Click Pluggable Databases in the Resources section of the page.

    A list of existing PDBs in this database is displayed.

  7. Click the name of the PDB that you want to convert to a regular PDB.

    From the Pluggable Database details page, click More Actions, and then select Convert to regular PDB.

    (or)

    Click the Actions menu (three dots) and select Convert to regular PDB.

  8. In the resulting Convert to regular PDB dialog, enter the following:
    • Database TDE wallet password: Enter the TDE wallet password for the parent CDB of the source PDB.
    • Take a backup of the PDB immediately after creating it: You must enable auto-backup on the CDB to back up a PDB immediately after creating it. This check box is checked by default if auto-backup was enabled on the CDB.
      Note

      If the checkbox is unchecked, the system displays a warning stating that PDB cannot be recovered until the next daily backup has been successfully completed.

  9. Click Convert.
Restore a Pluggable Database (PDB)

You can restore a PDB within the same CDB to last known good state and specified timestamp.

Parent topic: Manage a Pluggable Database

Using the Console to Perform an In-Place Restore of a Pluggable Database (PDB)

To perform an in-place restore, follow this procedure.

  1. Open the navigation menu Under Oracle Database, and click Exadata Cloud@Customer.

    VM Clusters is selected by default.

  2. Choose your Compartment.

    A list of VM Clusters is displayed for the chosen Compartment.

  3. In the list of VM clusters, click the name of the VM cluster that contains the PDB you want to restore, and then click its name to display the details page.
  4. Under Databases, find the database containing the refreshable PDB you want to restore.
  5. Click the name of the database to view the Database Details page.
  6. Click Pluggable Databases in the Resources section of the page.

    A list of existing PDBs in this database is displayed.

  7. Click the name of the PDB that you want to restore.

    From the Pluggable Database details page, click More Actions, and then select Restore.

    (or)

    Click the Actions menu (three dots) and select Restore.

  8. In the resulting Restore PDB dialog, enter the following:
    • Restore to latest: Select this option to restore and recover the database with zero, or least possible, data loss.
    • Restore to a timestamp: Select this option to restore and recover the database to the specified timestamp.
  9. Click Restore.
Using the API to Manage Pluggable Databases

Use various API features to help manage your pluggable databases on Oracle Exadata Database Service on Cloud@Customer.

For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Software Development Kits and Command Line Interface.

Use these APIs to manage pluggable databases on Exadata Cloud@Customer systems.
  • ListPluggableDatabases
  • GetPluggableDatabase
  • StartPluggableDatabase
  • StopPluggableDatabase
  • CreatePluggableDatabase
  • DeletePluggableDatabase
  • LocalclonePluggableDatabase
  • RemoteclonePluggabledatabase

For the complete list of APIs for the Database service, see Database Service API.

Using the API to Clone a Pluggable Database

Clone a pluggable database (PDB) in the same database (CDB) as the source PDB or to a different database from the source PDB.

For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Software Development Kits and Command Line Interface.

Use these APIs to manage pluggable databases on Exadata Cloud@Customer systems.
  • LocalclonePluggableDatabase
  • RemoteclonePluggabledatabase

For the complete list of APIs for the Database service, see Database Service API.

Concurrently Create or Delete Pluggable Databases (PDBs)

You can now create or delete up to 10 PDBs concurrently, even when the container database (CDB) is in an updating state. However, you cannot create or delete PDBs while a CDB is in an updating state if other operations—excluding PDB creation or deletion—are modifying its metadata or structure.

The maximum number of CDBs and PDBs that can be created on a cluster is determined by the available memory on the VMs. By default, for Oracle Exadata Database Service on Cloud@Customer, each CDB is allocated 12.6 GB of memory (7.6 GB for SGA and 5 GB for PGA) if the VM has more than 60 GB of total memory. For VMs with 60 GB or less, 6.3 GB is allocated (3.8 GB for SGA and 2.5 GB for PGA).

In addition, Grid Infrastructure or ASM typically consumes 2 to 4 GB of memory. You can adjust the VM's memory allocation if necessary. It's important to note that the memory allocated to a CDB is shared among its PDBs. If a CDB has insufficient memory, PDB creation will fail.

Additionally, PDBs can now be created or deleted concurrently in a Data Guard environment. There are no restrictions on concurrent PDB creation or deletion in non-Data Guard environments.

Note:

  • Concurrent creation of PDBs in an Oracle Database configured with Data Guard and using a file-based wallet for TDE encryption keys (Oracle-managed keys) is also supported, however Oracle will serially create the PDBs on the standby database server in a serial manner. However, you can delete them concurrently.
  • A PDB cannot be deleted if its creation is still in progress.

Operations you can perform in parallel:

  • Create or delete CDBs in a VM cluster.
  • Create a CDB in a VM cluster while the deletion of another CDB is in progress within the same cluster.
  • Delete a CDB in a VM cluster while the creation of another CDB is in progress within the same cluster.
  • In a CDB, delete a PDB (PDB1) while another PDB (PDB2) is being created.
  • Create or delete additional PDBs if the CDB is in an updating state.
  • Scale OCPU while a PDB is being created or deleted.

Cost and Usage Attribution for Pluggable Databases (PDBs)

Note

It is supported only on Oracle Databases 19c and higher running in a multitenant deployment.

With this enhancement to the Cost Analysis feature of the OCI Cost Management Service, you can view the attributed usage and cost for all the PDBs in a VM Cluster. This data will be available on the cost analysis dashboard and the reports.

Prerequisites:
  • dbaastools: (minimum version) 24.3.2
    • To check the version of the dbaastools rpm on the guest VM, run: 
      rpm -qa | grep dbaastools
    • To update the dbaastools rpm on the guest VM, run: 
      dbaascli admin updateStack

      Confirm you have the minimum version of dbaastools needed after you update the dbaastools rpm by running the rpm -qa | grep dbaastools command.

  • dbcsagent needs to be running on the guest VM. Minimum version of dbcsagent needed is 23.3.2.
    • To check the version of the dbcsagent on the guest VM, run: 
      rpm -qa | grep dbcs-agent-update
    • You will need to open a service request on My Oracle Support to update the dbcsagent on the guest VM.
    • To check the status of the dbcsagent, run: 
      systemctl status dbcsagent

      Run systemctl start dbcsagent if the dbcsagent is not in active (running) state.

      Check the status of the agent again to confirm that it is running.

  • Network setup: The Control Plane Server must be able to establish a connection with the endpoint specified in the Metering and Monitoring section of Table 3-2 in the Network Requirements for Oracle Exadata Database Service on Cloud@Customer.

Parent topic: Manage Pluggable Databases on Oracle Exadata Database Service on Cloud@Customer

Generate Attributed Cost Analysis Report for Pluggable Databases

Follow the steps below to view the attributed costs based on CPU utilization for all pluggable databases within a VM Cluster.

  1. Open the navigation menu and click Billing & Cost Management. Under Cost Management, click Cost Analysis.
  2. From Reports, select one of the predefined reports, or use the default Costs by Service report.
  3. Make your preferred query adjustments.
    1. From Start/End Date (UTC), select a time period.
    2. From Granularity, select Daily or Monthly.
    3. From Show, select Attributed cost.
    4. From Filters, select Tag.

      In the resulting Tag dialog, select orcl-cloud as the tag with the key parent_resource_id_1 equal to the OCID of the VM Cluster.

    5. From Grouping dimensions, select the preferred grouping dimension. For example, Resource OCID.

      The VM Cluster OCID is the parent of the CDBs it contains, and the CDB OCID is the parent OCID of the PDBs it contains.

    6. Click Apply to apply the changes and reload the chart and table with the selected filters.

      The generated report will show the attributed costs for all the PDBs in the VM Cluster.

  4. After you have made changes, the currently selected predefined report name from the Reports menu changes to (edited).
  5. If you're done making changes and want to save a new report, click Save as new report.
  6. In the Save as new report dialog, enter the report name in the Name field. Avoid entering confidential information..
  7. Click Save.

    A notification is displayed that your report has been saved, and the report is also selected in the Reports menu.

  8. If you didn't already apply your custom report settings, click Apply to view your changes.

    The new saved report is now available for future selection from the Reports menu under Saved Reports.

    For more information about generating a PDB attributed cost analysis report, see Cost Analysis.

Connect to an Oracle Database using Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM) Users

You can configure Oracle Exadata Database Service on Cloud@Customer to use Oracle Cloud Infrastructure Identity and Access Management (IAM) authentication and authorization to allow IAM users to access an Oracle Database with IAM credentials.

Parent topic: Manage Databases on Oracle Exadata Database Service on Cloud@Customer

Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM) Authentication with Oracle Database

Learn to enable an Oracle Database instance on Oracle Exadata Database Service on Cloud@Customer to allow user access with an Oracle Cloud Infrastructure IAM database password (using a password verifier), or SSO tokens.

Parent topic: Connect to an Oracle Database using Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM) Users

About Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM) Authentication with Oracle Database

You can enable an Oracle Database instance to use Oracle Cloud Infrastructure (IAM) authentication and authorization for users.

Note

Oracle Database supports the Oracle DBaaS integration for Oracle Cloud Infrastructure (OCI) IAM with identity domains as well as the legacy IAM, which does not include identity domains. Both default and non-default domain users and groups are supported when using IAM with Identity Domains.

Support for IAM integration is only available with Oracle Database Release 19c, Version 19.21 and higher (but not Oracle Database Release 21c).

Oracle Cloud Infrastructure IAM integration with Oracle Exadata Database Service on Cloud@Customer supports the following:

  • IAM Database Password Authentication
  • Identity and Access Management (IAM) SSO Token Based Authentication

For complete details about the architecture for using IAM users on Oracle Exadata Database Service on Cloud@Customer, see Authenticating and Authorizing IAM Users for Oracle DBaaS Databases in the Oracle Database 19c Security Guide and Oracle Database 23ai Security Guide.

Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM) Database Password Authentication

You can enable an Oracle Database instance to allow user access with an Oracle Cloud Infrastructure IAM database password (using a password verifier).

Note

Any supported 12c and above database client can be used for IAM database password access to Oracle Database.

An Oracle Cloud Infrastructure IAM database password allows an IAM user to log in to an Oracle Database instance as Oracle Database users typically log in with a username and password. The user enters their IAM user name and IAM database password. An IAM database password is a different password than the Oracle Cloud Infrastructure Console password. Using an IAM user with the password verifier, you can log in to Oracle Database with any supported database client.

For password verifier database access, you create the mappings for IAM users and OCI applications to the Oracle Database instance. The IAM user accounts themselves are managed in IAM. The user accounts and user groups can be in either the default domain or in a custom, non-default domain.

For more information about managing IAM database password, see Working with IAM Database User Names and Passwords.

Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM) SSO Token Based Authentication

You can enable an Oracle Database instance to use Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM) SSO tokens.

To access the database using IAM tokens, you create the mappings for IAM users and OCI applications to the Oracle Database instance. The IAM user accounts themselves are managed in IAM. The user accounts and user groups can be in either the default domain or a custom, non-default domain.

There are several ways a database client can obtain an IAM database token:

  • A client application or tool can request the database token from IAM for the user and can pass the database token through the client API. Using the API to send the token overrides other settings in the database client. Using IAM tokens requires the latest Oracle Database client 19c (at least 19.16). Some earlier clients (19c and 21c) provide a limited set of capabilities for token access. Oracle Database client 21c does not fully support the IAM token access feature. For more information about the clients supported for this type of IAM database token usage, see Supported Client Drivers for IAM Connections.
  • If the application or tool does not support requesting an IAM database token through the client API, the IAM user can first use the Oracle Cloud Infrastructure command line interface (CLI) to retrieve the IAM database token and save it in a file location. For example, to use SQL*Plus and other applications and tools using this connection method, you first obtain the database token using the Oracle Cloud Infrastructure (OCI) Command Line Interface (CLI). For more information, see db-token get. If the database client is configured for IAM database tokens, when a user logs in with the slash login form, the database driver uses the IAM database token that has been saved in the default or specified file location.
  • A client application or tool can use an Oracle Cloud Infrastructure IAM instance principal or resource principal to get an IAM database token and use the IAM database token to authenticate itself to an Oracle Database instance.
  • Some Oracle Database 23ai clients can also get a token directly from OCI IAM instead of using the OCI command line interface. Please review the client documentation to see which clients support this native IAM integration.
  • IAM users and OCI applications can request a database token from IAM with several methods, including using an API key. See Configuring a Client Connection for SQL*Plus That Uses an IAM Token for an example. See Authenticating and Authorizing IAM Users for Oracle DBaaS Databases for a description of other methods such as using a delegation token within an OCI cloud shell.

In previous releases, you could only use the IAM username and database password to get a password verifier from IAM. Getting a token with these credentials is more secure than getting a password verifier because a password verifier is considered sensitive. Using a token means that you do not need to pass or use the verifier. Applications cannot pass a token that was retrieved by the IAM user name and password through the database client API. Only the database client can retrieve this type of token. A database client can only retrieve a database token using the IAM user name and IAM database password.

Prerequisites for Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM) Authentication on Oracle Database

Review the prerequisites for Identity and Access Management (IAM) authentication on an Oracle Database.

  • Disable External Authentication Scheme
    Review the prerequisites for enabling IAM user access to Oracle Database.
  • Configure a Network Connection to OCI
    Configure a network connection to OCI to be able to make calls to OCI IAM for the database instances on Oracle Exadata Database Service on Cloud@Customer to accept IAM database access tokens (db-tokens), or get IAM database password verifiers.
  • Configure Proxy Settings
    Configure network proxy settings in your environment to allow the database to access OCI IAM. Replace the network proxy URL http://www-proxy.example.com:80/ and the database name given in the example with yours.
  • Configure TLS to Use IAM Tokens
    When sending IAM tokens from the database client to the database server, a TLS connection must be established. The TLS wallet with the database certificate for the ExaDB-C@C service instance must be stored under the WALLET_ROOT location. Create a tls directory so it looks like: WALLET_ROOT/<PDB GUID>/tls.

Parent topic: Connect to an Oracle Database using Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM) Users

Disable External Authentication Scheme

Review the prerequisites for enabling IAM user access to Oracle Database.

If the database is enabled for another external authentication scheme, verify that you want to use IAM on the Oracle Database instance. There can only be one external authentication scheme enabled at any given time.

If you want to use IAM and another external authentication scheme is enabled, you must first disable the other external authentication scheme.

Configure a Network Connection to OCI

Configure a network connection to OCI to be able to make calls to OCI IAM for the database instances on Oracle Exadata Database Service on Cloud@Customer to accept IAM database access tokens (db-tokens), or get IAM database password verifiers.

  1. Consult your ExaDB-C@C administrator to determine the OCI region assigned to your ExaDB-C@C installation.
  2. Determine the OCI IAM endpoint for that OCI region. For more information, see Identity and Access Management Service API.
  3. Find the port number for Identity Service for name resolution of Oracle operators. For more information, see Table 3-2 Ports to Open for Control Plane Connectivity in Network Requirements for Oracle Exadata Database Service on Cloud@Customer.

    For example, if your OCI region is Phoenix, then open port 443 to https://identity.us-phoenix-1.oci.oraclecloud.com.

  4. Configure your network to open this connection.

For more information on troubleshooting login failures, see Troubleshooting IAM Connections.

Configure Proxy Settings

Configure network proxy settings in your environment to allow the database to access OCI IAM. Replace the network proxy URL http://www-proxy.example.com:80/ and the database name given in the example with yours.

  1. Log in to the host operating system.
  2. Set the proxy environment variables.
    srvctl setenv database -db exampledbname -env "https_proxy=http://www-proxy.example.com:80/"
srvctl setenv database -db exampledbname -env "http_proxy=http://www-proxy.example.com:80/"
  3. Stop the database and verify that the variables have been set:
    $ srvctl stop database -db exampledbname
    $ srvctl getenv database -db exampledbname
http_proxy=http://www-proxy.example.com:80/
https_proxy=http://www-proxy.example.com:80/
  4. Restart the database.
    $ srvctl start database -db exampledbname
Configure TLS to Use IAM Tokens

When sending IAM tokens from the database client to the database server, a TLS connection must be established. The TLS wallet with the database certificate for the ExaDB-C@C service instance must be stored under the WALLET_ROOT location. Create a tls directory so it looks like: WALLET_ROOT/<PDB GUID>/tls.

When configuring TLS between the database client and server there are several options to consider.
  • Using a self-signed database server certificate vs a database server certificate signed by a commonly known certificate authority
  • One-way TLS (TLS) vs Mutual or two-way TLS (mTLS)
  • Client with or without a wallet

Self-Signed Certificate

Using a self-signed certificate is a common practice for internally facing IT resources since you can create these yourself and it's free. The resource (in our case, the database server) will have a self-signed certificate to authenticate itself to the database client. The self-signed certificate and root certificate will be stored in the database server wallet. For the database client to be able to recognize the database server certificate, a copy of the root certificate will also be needed on the client. This self-created root certificate can be stored in a client-side wallet or installed in the client system default certificate store (Windows and Linux only). When the session is established, the database client will check to see that the certificate sent over by the database server has been signed by the same root certificate.

A Well-Known Certificate Authority

Using a commonly known root certificate authority has some advantages in that the root certificate is most likely already stored in the client system default certificate store. There is no extra step for the client to store the root certificate if it is a common root certificate. The disadvantage is that this normally has a cost associated with it.

One-Way TLS

In the standard TLS session, only the server provides a certificate to the client to authenticate itself. The client doesn't need to have a separate client certificate to authenticate itself to the server (similar to how HTTPS sessions are established). While the database requires a wallet to store the server certificate, the only thing the client needs to have is the root certificate used to sign the server certificate.

Two-Way TLS (also called Mutual TLS, mTLS)

In mTLS, both the client and server have identity certificates that are presented to each other. In most cases, the same root certificate will have signed both of these certificates so the same root certificate can be used with the database server and client to authenticate the other certificate. mTLS is sometimes used to authenticate the user since the user identity is authenticated by the database server through the certificate. This is not necessary for passing IAM tokens but can be used when passing IAM tokens.

Client with a Wallet

A client wallet is mandatory when using mTLS to store the client certificate. However, the root certificate can be stored either in the same wallet or in the system default certificate store.

A Client without a Wallet

Clients can be configured without a wallet when using TLS under these conditions: 1) One-way TLS is being configured where the client does not have its own certificate and 2) the root certificate that signed the database server certificate is stored in the system default certificate store. The root certificate would most likely already be there if the server certificate is signed by a common certificate authority. If it's a self-signed certificate, then the root certificate would need to be installed in the system default certificate store to avoid using a client wallet.

For details on how to configure TLS between the database client and database server including the options described above, see Configuring Transport Layer Security Encryption in the Oracle Database Security Guide.

If you choose to use self-signed certificates and for additional wallet related tasks, Managing Oracle Database wallets and certificates in the Oracle Database Security Guide.

Enabling the Database and Clients for IAM Integration

Follow the appropriate link below to configure IAM users to access your database.

For complete details about the architecture for using IAM users on Oracle Exadata Database Service on Dedicated Infrastructure, see Authenticating and Authorizing IAM Users for Oracle DBaaS Databases in the Oracle Database 19c Security Guide and Oracle Database 23ai Security Guide.

Authenticating and Authorizing Microsoft Entra ID (MS-EI) Users for Oracle Databases on Oracle Exadata Database Service on Cloud@Customer

An Oracle Database can be configured for Microsoft Azure users of Microsoft Entra ID to connect using single sign-on authentication.

Parent topic: Manage Databases on Oracle Exadata Database Service on Cloud@Customer

About Authorizing Microsoft Entra ID (MS-EI) Users for Oracle Databases on Oracle Exadata Database Service on Cloud@Customer

Users for Oracle Exadata Database Service on Cloud@Customer can be centrally managed in an MS-EI service.

The Oracle Database integration with MS-EI is supported for on-premises databases and most Oracle OCI DBaaS platforms.

The instructions for configuring MS-EI use the term "Oracle Database" to encompass these environments.

This type of integration enables the MS-EI user to access an Oracle Exadata Database Service on Cloud@Customer instance. MS-EI users and applications can log in with MS-EI Single Sign On (SSO) credentials to get an MS-EI OAuth2 access token to send to the database.

The administrator creates and configures the application registration (app registration) of the Oracle Exadata Database Service on Cloud@Customer instance with MS-EI. The administrator also creates application (app) roles for the database app registration in MS-EI, and assigns these roles to MS-EI users, groups, and applications. These app roles will be mapped to the database global schemas and global roles. An MS-EI principal that is assigned to an app role will be mapped to either a database global schema or database global role. An Oracle global schema can also be mapped exclusively to an MS-EI user. When the principal is a guest user or service principal, they can only be mapped to the database schema through an MS-EI app role. An Oracle global role can only be mapped to an MS-EI app role.

Tools and applications that are updated to support MS-EI tokens can authenticate users directly with MS-EI and pass the database access token to the Oracle Exadata Database Service on Cloud@Customer instance. You can configure existing database tools such as SQL*Plus to use an MS-EI token from a file location or get the token directly from MS-EI. When using a utility to get the token to pass to the database client driver through a file location, MS-EI tokens can be retrieved using tools like Microsoft PowerShell or Azure CLI and put into a file location. An MS-EI OAuth2 database access token is a bearer token with an expiration time. The Oracle Database client driver will ensure that the token is in a valid format and that it has not expired before passing it to the database. The token is scoped for the database. Assigned app roles for the Azure AD principal are included as part of the access token. The directory location for the MS-EI token should only have enough permission for the user to write the token file to the location and the database client to retrieve these files (for example, just read and write by the process user). Because the token allows access to the database, it should be protected within the file system.

MS-EI users can request a token as a client registered with MS-EI app registration by using methods such as the following:

  • Entering the MS-EI credentials into an MS-EI authentication screen with or without multi-factor authentication

Oracle Exadata Database Service on Cloud@Customer supports the following MS-EI authentication flows:

  • Interactive flow (authorization code), which is used when a browser can be used to enter credentials for the user
  • Client credentials, which are for applications that connect as themselves (and not the end-user)
  • On-Behalf-Of (OBO), where an application requests an access token on behalf of a logged-in user to send to the database
  • ROPC is also supported for test and development environments

Oracle Exadata Database Service on Cloud@Customer accepts tokens representing the following MS-EI principals:

  • MS-EI user, who is registered user in the MS-EI tenancy
  • Guest user, who is registered as a guest user in the MS-EI tenancy
  • Service, which is the registered application connecting to the database as itself with the client credential flow (connection pool use case)

Configuring the Oracle Database for Microsoft Entra ID (MS-EI) Integration

The MS-EI integration with the Oracle Database instance requires the database to be registered with MS-EI so that the database can request the MS-EI public key.

For information on configuring MS-EI, configuring the database, and configuring the database client, see:

Prerequisites for Microsoft Entra ID (MS-EI) Authentication

The MS-EI integration with the Oracle Database on Oracle Exadata Database Service on Cloud@Customer requires:

  1. The Oracle Database to be version 19.18 or higher.
  2. Connectivity to the database on TLS port 2484. Non TLS connections are not supported.
  3. The Oracle Database to be registered with MS-EI.
  4. Users and applications that need to request an MS-EI token must also be able to have network connectivity to MS-EI. You may need to configure a proxy setting for the connection.
  5. Outbound network connectivity to MS-EI so that the database can request the MS-EI public key.
    1. Ensure that the ORACLE_SID, ORACLE_HOME, and PATH variables of the database are set correctly.
    2. Run the following srvctl commands as oracle user on the operating system: 
      • $ srvctl setenv database -db <exampledbname> -env "https_proxy=http://www-proxy.example.com:80/"
      • $ srvctl setenv database -db <exampledbname> -env "http_proxy=http://www-proxy.example.com:80/"
      • $ srvctl stop database -db <exampledbname>
      • $ srvctl start database -db <exampledbname>
      • $ srvctl getenv database -db <exampledbname>
http_proxy=http://www-proxy.example.com:80/
https_proxy=http://www-proxy.example.com:80/
TNS_ADMIN=<exampledbhomename>/network/admin/<exampledbname>
    3. The HTTP proxy settings must also be set in the ExaDB-C@C networking.

      These settings are defined by your fleet administrator while creating the Exadata infrastructure as described in Using the Console to Provision Oracle Exadata Database Service on Cloud@Customer.

      Note

      • The network configuration including the HTTP Proxy can only be edited until the Exadata infrastructure is in Requires Activation state. Once it is activated, you cannot edit those settings.
      • Setting up an HTTP Proxy for an already provisioned Exadata infrastructure needs a Service Request (SR) in My Oracle Support. See Create a Service Request in My Oracle Support for details.
Configure TLS to Use Microsoft Entra ID (MS-EI) tokens

When sending MS-EI tokens from the database client to the database server, a TLS connection must be established. The TLS wallet with the database certificate for the ExaDB-C@C service instance must be stored under the WALLET_ROOT location. Create a tls directory so it looks like: WALLET_ROOT/<PDB GUID>/tls.

When configuring TLS between the database client and server there are several options to consider.

  • Using a self-signed database server certificate vs a database server certificate signed by a commonly known certificate authority
  • One-way TLS (TLS) vs Mutual or two-way TLS (mTLS)
  • Client with or without a wallet

Self-Signed Certificate

Using a self-signed certificate is a common practice for internally facing IT resources since you can create these yourself and it's free. The resource (in our case, the database server) will have a self-signed certificate to authenticate itself to the database client. The self-signed certificate and root certificate will be stored in the database server wallet. For the database client to be able to recognize the database server certificate, a copy of the root certificate will also be needed on the client. This self-created root certificate can be stored in a client-side wallet or installed in the client system default certificate store (Windows and Linux only). When the session is established, the database client will check to see that the certificate sent over by the database server has been signed by the same root certificate.

A Well-Known Certificate Authority

Using a commonly known root certificate authority has some advantages in that the root certificate is most likely already stored in the client system default certificate store. There is no extra step for the client to store the root certificate if it is a common root certificate. The disadvantage is that this normally has a cost associated with it.

One-Way TLS

In the standard TLS session, only the server provides a certificate to the client to authenticate itself. The client doesn't need to have a separate client certificate to authenticate itself to the server (similar to how HTTPS sessions are established). While the database requires a wallet to store the server certificate, the only thing the client needs to have is the root certificate used to sign the server certificate.

Two-Way TLS (also called Mutual TLS, mTLS)

In mTLS, both the client and server have identity certificates that are presented to each other. In most cases, the same root certificate will have signed both of these certificates so the same root certificate can be used with the database server and client to authenticate the other certificate. mTLS is sometimes used to authenticate the user since the user identity is authenticated by the database server through the certificate. This is not necessary for passing IAM tokens but can be used when passing IAM tokens.

Client with a Wallet

A client wallet is mandatory when using mTLS to store the client certificate. However, the root certificate can be stored either in the same wallet or in the system default certificate store.

A Client without a Wallet

Clients can be configured without a wallet when using TLS under these conditions: 1) One-way TLS is being configured where the client does not have its own certificate and 2) the root certificate that signed the database server certificate is stored in the system default certificate store. The root certificate would most likely already be there if the server certificate is signed by a common certificate authority. If it's a self-signed certificate, then the root certificate would need to be installed in the system default certificate store to avoid using a client wallet.

For details on how to configure TLS between the database client and database server including the options described above, see:

If you choose to use self-signed certificates and for additional wallet related tasks, see:

Was this article helpful?

Updated 2025-03-29