Using the dbaascli Utility with Oracle Exadata Database Service on Cloud@Customer

Learn to use the dbaascli utility on Oracle Exadata Database Service on Cloud@Customer.

About Using the dbaascli Utility on Oracle Exadata Database Service on Cloud@Customer

You can use the dbaascli utility to perform various database lifecycle and administration operations on Oracle Exadata Database Service on Cloud@Customer such as creating an Oracle Database, patching an Oracle Database, managing pluggable databases (PDBs), scaling the CPU core count in disconnected mode, and more.

You must use the DBaaS console or command-line interface to scale resources. The capabilities of the dbaascli utility are in addition to, and separate from, the Oracle Cloud Infrastructure Console, API, or command-line interface (CLI). Unless specified differently, you need root access to dbaascli to run all administration commands.

To use the utility, you must be connected to an Exadata Cloud@Customer virtual machine. See Connecting to a Virtual Machine with SSH.

To get possible commands available with dbaascli, run dbaascli --help.

To get command-specific help, run dbaascli command --help. For example, dbaascli database create --help.

Creating Oracle Database Using dbaascli

Using dbaascli, you can create an Oracle Database by first creating an Oracle Database home of desired version, followed by creating a database in that Oracle Database home.

Listing Available Software Images and Versions for Database

To get a list of available supported versions for creating Oracle Database, use the dbaascli cswlib showImages command.

  1. Connect to the virtual machine as the opc user.

    For detailed instructions, see Connecting to a Virtual Machine with SSH.

  2. Start a root user command shell:
    sudo -s
  3. Run the following command:
    dbaascli cswlib showImages

    The command output lists the available database software images.

  4. Exit the root user command shell:
    exit

    For more details on advanced supported options, see dbaascli cswlib showImages.

Example 7-1 dbaascli cswlib showImages

dbaascli cswlib showImages

DBAAS CLI version MAIN Executing command cswlib showImages 
INFO : Log file => /var/opt/oracle/log/list/list_2021-05-10_10:11:00.56966610630.log 

############ List of Available DB Images #############
1.IMAGE_TAG=19.8.0.0.0
VERSION=19.8.0.0.0
DESCRIPTION=19c JUL 2020 DB Image
IMAGE_ALIASES=19000-19800,19000-JUL2020

2.IMAGE_TAG=19.8.0.0.0-NC
VERSION=19.8.0.0.0
DESCRIPTION=19c JUL 2020 Non CDB Image
IMAGE_ALIASES=19000-NC19800,19000-NCJUL2020

3.IMAGE_TAG=19.9.0.0.0
VERSION=19.9.0.0.0
DESCRIPTION=19c OCT 2020 DB Image
IMAGE_ALIASES=19000-19900,19000-OCT2020

4.IMAGE_TAG=19.9.0.0.0-NC
VERSION=19.9.0.0.0
DESCRIPTION=19c OCT 2020 Non CDB Image
IMAGE_ALIASES=19000-NC19900,19000-NCOCT2020
Note

You can specify the target version in dbaascli dbhome create command as --version value from the dbaascli cswlib showImages command output.

Creating Oracle Database Home

To create an Oracle Database home of desired version, use the dbaascli dbhome create command.

Note

You can create an Oracle Database home with a specified Oracle home name. If you do not specify, then this is computed automatically (recommended).
  1. Connect to the virtual machine as the opc user.

    For detailed instructions, see Connecting to a Virtual Machine with SSH.

  2. Start a root user command shell:
    sudo -s
  3. Run the following command:
    dbaascli dbhome create --version Oracle Home Version --imageTag image Tag Value
    Where:
    • --version specifies the Oracle Database version
    • --imageTag specifies the Image Tag of the image to be used
    For example:
    dbaascli dbhome create --version 19.9.0.0.0
    Note

    Specifying imageTag is optional. To view the Image Tags, refer to command dbaascli cswlib showImages. Image Tags are typically same as the version of the database. However, it is kept as a provision for cases where multiple images may need to be released for the same version - each catering to a specific customer requirement.
  4. Exit the root user command shell:
    exit

    For more details on advanced supported options, see dbaascli dbhome create.

Creating Oracle Database In the Specified Oracle Database Home

To create an Oracle Database in the specified Oracle Database home of desired version, use the dbaascli database create command.

You can use the dbaascli database create command to:
  • Create a Container Database (CDB) or non-Container Database
  • Create a CDB with pluggable databases (PDBs)
  • Create an Oracle Database with the specified Character Set
  • Create Oracle Databases on a subset of cluster nodes
    Note

    Databases created on a subset of nodes will not be displayed in the OCI console.
  • Create Oracle Database version 12.1.0.2 or higher with the release update JAN 2021 or higher. For databases with lower versions, it is recommended to use the OCI Console based API.
  1. Connect to the virtual machine as the opc user.

    For detailed instructions, see Connecting to a Virtual Machine with SSH.

  2. Start a root user command shell:
    sudo -s
  3. Run the following command:
    dbaascli database create --dbName database name --oracleHome Oracle Home Path
    Where:
    • --dbName specifies the name of the database
    • --oracleHome specifies Oracle home location
    To create a CDB, run the following command:
    dbaascli database create --dbName database name --oracleHome Oracle Home Path
    To create a non-CDB, run the following command:
    dbaascli database create --dbName database name --oracleHome Oracle Home Path --createAsCDB false

    When prompted, enter the sys and tde passwords.

  4. Exit the root user command shell:
    exit

    For more details on advanced supported options, see dbaascli database create.

Running Prerequisite Checks Prior to Creating Oracle Database

To run prerequisites checks, use the --executePrereqs command option. This will perform only the prerequisite checks without performing the actual Oracle Database creation.

  1. Connect to the virtual machine as the opc user.

    For detailed instructions, see Connecting to a Virtual Machine with SSH.

  2. Start a root user command shell:
    sudo -s
  3. Run the following command:
    dbaascli database create --dbName database name --oracleHome Oracle Home Path --executePrereqs
    Where:
    • --dbName specifies the name of the database
    • --oracleHome specifies the Oracle home location
  4. Exit the root user command shell:
    exit

    For more details on advanced supported options, see dbaascli database create.

Resuming or Reverting Oracle Database Creation Operation

To resume or revert a failed database creation operation, use the --resume or --revert command option.

For example:
dbaascli database create --dbName database name --oracleHome Oracle Home Path --resume
Note

  • While using the --resume or --revert command options, ensure that you use the same command from the same node that was used for actual create operation flow.
  • You can resume database creation only if there is a failure in the post database creation step.

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

Managing Oracle Exadata Database Service on Cloud@Customer Software Images Using the Dbaascli Utility

You can list and download the Oracle database software images on an Oracle Exadata Database Service on Cloud@Customer instance, which can then be used for provisioning a database home.

Note

You can create custom database software images for your Oracle Exadata Database Service on Cloud@Customer instances using the Console or API. These images are stored in Object Storage, and can be used to provision a Database Home in your Exadata instance. See Oracle Database Software Images more information.

You can control the version of Oracle binaries that is installed when you provision a new database on an Oracle Exadata Database Service on Cloud@Customer instance by maintaining the software images on the system. Oracle provides a library of cloud software images that you can view and download onto your instance by using the dbaascli utility.

Listing Available Software Images and Versions for Database and Grid Infrastructure

To produce a list of available supported versions for patching, use the dbaascli cswlib showImages command.

  1. Connect to the virtual machine as the opc user.

    For detailed instructions, see Connecting to a Virtual Machine with SSH.

  2. Start a root user command shell:
    sudo -s
  3. Run the following command:
    dbaascli cswlib showImages --product database

    The command output lists the available database software images.

    dbaascli cswlib showImages --product grid

    The command output lists the available grid software images.

  4. Exit the root user command shell:
    exit

    For more details on advanced supported options, see dbaascli cswlib showImages.

Example 7-2 dbaascli cswlib showImages

[root@dg11lrg1 dbhome_1]# dbaascli cswlib showImages
DBAAS CLI version <version>
Executing command cswlib
      showImagesJob id: 00e89b1a-1607-422c-a920-22f44bec1953Log file location:
      /var/opt/oracle/log/cswLib/showImages/dbaastools_2022-05-11_08-49-12-AM_46941.log

############
List of Available Database Images
#############

17.IMAGE_TAG=18.17.0.0.0  
   VERSION=18.17.0.0.0  
   DESCRIPTION=18c JAN 2022 DB Image

18.IMAGE_TAG=19.10.0.0.0  
   VERSION=19.10.0.0.0  
   DESCRIPTION=19c JAN 2021 DB Image

19.IMAGE_TAG=19.11.0.0.0  
   VERSION=19.11.0.0.0  
   DESCRIPTION=19c APR 2021 DB Image

20.IMAGE_TAG=19.12.0.0.0
  VERSION=19.12.0.0.0
  DESCRIPTION=19c JUL 2021 DB Image

21.IMAGE_TAG=19.13.0.0.0  
  VERSION=19.13.0.0.0  
  DESCRIPTION=19c OCT 2021 DB Image

Images can be downloaded using their image tags. For details, see help using 'dbaascli cswlib download --help'.
dbaascli execution completed

To download a software image

You can download available software images onto your Oracle Exadata Database Service on Cloud@Customer instance by using the cswlib download subcommand of the dbaascli utility.

  1. Connect to a compute node as the opc user. For detailed instructions, see Connecting to a Virtual Machine with SSH.
  2. Start a root user command shell:
    $ sudo -s
    #
  3. Execute the dbaascli command with the cswlib download subcommand:
    # dbaascli cswlib download [--version <software_version>] [--imageTag <image tag
        value>]
    The command displays the location of software images that are downloaded to your Oracle Exadata Database Service on Cloud@Customer environment.

    The optional parameters are:

    • version: specifies an Oracle Database software version. For example, 19.14.0.0.0.
    • imageTag: specifies the image tag of the image.
  4. Exit the root user command shell:
    # exit
    $

Patching Oracle Grid Infrastructure and Oracle Databases Using dbaascli

Learn to use the dbaascli utility to perform patching operations for Oracle Grid Infrastructure and Oracle Database on an Exadata Cloud@Customer system.

Patching Databases using dbaascli

Using dbaascli, you can choose to patch a database by patching Oracle home, or by moving the database to an Oracle home with the desired patch level.

  • Patching an Oracle home (in-place patching). This updates all databases located in the Oracle home.
  • Moving a database to a different Oracle home that has the desired Oracle Database software version (out-of-place patching).
Patching a Database Home (In-Place Database Patching)

To patch an Oracle home, use the dbaascli dbHome patch command.

This will patch all databases running in the specified home, and the databases will remain in the home after the patching is complete. The following apply to using the dbHome patch command for in-place patching operations:
  • You can patch all of your database nodes or a subset of nodes.
  • Multi-node patching takes place in a rolling fashion.
  • Optionally, you can perform a software-only patch operation. Then, when you are ready, you can run datapatch to perform post-patch SQL actions.
  • You can patch an Oracle home containing one or more databases.

To patch an Oracle Home (dbhome):

  1. Connect to the virtual machine as the opc user.

    For detailed instructions, see Connecting to a Virtual Machine with SSH.

  2. Start a root user command shell:
    sudo -s
  3. Run the following command:
    dbaascli dbhome patch --oracleHome dbhome_path --targetVersion Oracle_Database_version
    Where:
    • --oracleHome identifies the path of the Oracle home to be patched.
    • --targetVersion specifies the target Oracle Database version to use for patching, specified as five numeric segments separated by periods (e.g. 19.12.0.0.0).
    For example:
    dbaascli dbhome patch --oracleHome /u02/app/oracle/product/19.0.0.0/dbhome_2 --targetVersion 19.9.0.0.0
  4. Exit the root user command shell:
    exit

    For more details on advanced supported options, see dbaascli dbHome patch.

Moving a Database to a Different Oracle Home (Out-of-Place Patching)

To patch an Oracle Database by moving it to an Oracle home that is already at the desired patch level, use the dbaascli database move command.

After the database move operation is complete, the database runs using the Oracle Database software version of the target Oracle Home.

To patch a database by moving it to a different Oracle Home:

  1. Connect to the virtual machine as the opc user.

    For detailed instructions, see Connecting to a Virtual Machine with SSH.

  2. Start a root user command shell:
    sudo -s
  3. Run the following command:
    dbaascli database move --oracleHome path_to_target_oracle_home --dbname database_name
    Where:
    • --oracleHome identifies the path of the target Oracle home that uses the desired Oracle Database software version. Note that the target Oracle home must exist in your system prior to using the database move command.
    • --dbname specifies the name of the database that is being moved.
    For example:
    dbaascli database move --oracleHome /u02/app/oracle/product/19.0.0.0/dbhome_2 --dbname xyz
  4. Exit the root user command shell:
    exit

    For more details on advanced supported options, see dbaascli database move.

Patching Oracle Grid Infrastructure

To apply a patch to Oracle Grid Infrastructure, use the grid patch command.

  1. Connect to the virtual machine as the opc user.

    For detailed instructions, see Connecting to a Virtual Machine with SSH.

  2. Start a root user command shell:
    sudo -s
  3. Run the following command:
    dbaascli grid patch --targetVersion target_software_version_number

    Where --targetVersion identifies target software version that the Oracle Grid Infrastructure will be patched to.

    For example:
    dbaascli grid patch --targetVersion 19.11.0.0.0
  4. Exit the root user command shell:
    exit

    For more details on advanced supported options, see dbaascli grid patch.

Patching Oracle Grid Infrastructure (GI) Using GI Software Image

To patch Oracle Grid Infrastructure (GI) using GI software image, use this procedure.

Oracle Grid Infrastructure can also be patched by first creating a patched software image, and then using that image to perform the patching operation. This provides the advantage that an image can be created ahead of time outside of the patching window. It also helps in conflict resolution as any conflicts among the patches are highlighted during the image creation process without impacting the patching window.

  1. Create a patched software image.
    dbaascli grid patch --targetVersion <target_software_version_number> --createImage
    Once the patched software image creation is completed, the image can then be used for performing the patching operation.
  2. Perform the patching operation.
    dbaascli grid patch --targetVersion <target_software_version_number> --imageLocation <location_of_patched_software_image>

Listing Available Software Images and Versions for Database and Grid Infrastructure

To produce a list of available supported versions for patching, use the dbaascli cswlib showImages command.

  1. Connect to the virtual machine as the opc user.

    For detailed instructions, see Connecting to a Virtual Machine with SSH.

  2. Start a root user command shell:
    sudo -s
  3. Run the following command:
    dbaascli cswlib showImages --product database

    The command output lists the available database software images.

    dbaascli cswlib showImages --product grid

    The command output lists the available grid software images.

  4. Exit the root user command shell:
    exit

    For more details on advanced supported options, see dbaascli cswlib showImages.

Example 7-3 dbaascli cswlib showImages

[root@dg11lrg1 dbhome_1]# dbaascli cswlib showImages
DBAAS CLI version <version>
Executing command cswlib
      showImagesJob id: 00e89b1a-1607-422c-a920-22f44bec1953Log file location:
      /var/opt/oracle/log/cswLib/showImages/dbaastools_2022-05-11_08-49-12-AM_46941.log

############
List of Available Database Images
#############

17.IMAGE_TAG=18.17.0.0.0  
   VERSION=18.17.0.0.0  
   DESCRIPTION=18c JAN 2022 DB Image

18.IMAGE_TAG=19.10.0.0.0  
   VERSION=19.10.0.0.0  
   DESCRIPTION=19c JAN 2021 DB Image

19.IMAGE_TAG=19.11.0.0.0  
   VERSION=19.11.0.0.0  
   DESCRIPTION=19c APR 2021 DB Image

20.IMAGE_TAG=19.12.0.0.0
  VERSION=19.12.0.0.0
  DESCRIPTION=19c JUL 2021 DB Image

21.IMAGE_TAG=19.13.0.0.0  
  VERSION=19.13.0.0.0  
  DESCRIPTION=19c OCT 2021 DB Image

Images can be downloaded using their image tags. For details, see help using 'dbaascli cswlib download --help'.
dbaascli execution completed

Performing a Precheck Before Patching Databases and Grid Infrastructure

You can perform a prerequisites-checking operation (also called a "precheck") for the commands in this topic using the applicable precheck flag.

Running prechecks allows you to run only the precheck portion of the patching operation without performing actual patching. Oracle recommends running prechecks to discover software issues that could prevent successful patching.

To perform patching prechecks, first, connect to a virtual machine in your Exadata Cloud@Customer instance as the root user.

Precheck for Oracle Home Patching (In-Place Patching)

Use the --executePrereqs flag with the dbaascli dbhome patch command.

  1. Connect to the virtual machine as the opc user.

    For detailed instructions, see Connecting to a Virtual Machine with SSH.

  2. Start a root user command shell:
    sudo -s
  3. Run the following command:
    dbaascli dbhome patch --oracleHome dbhome_path --targetVersion Oracle_Database_version --executePrereqs
    Where:
    • --oracleHome identifies the path of the Oracle home to be prechecked.
    • --targetVersion specifies the target Oracle Database version to be patched to, specified as five numeric segments separated by periods (e.g. 19.12.0.0.0).
  4. Exit the root user command shell:
    exit
Precheck for Database Move Patching (Out-of-Place Patching)

Use the --executePrereqs flag with the dbaascli database move command.

  1. Connect to the virtual machine as the opc user.

    For detailed instructions, see Connecting to a Virtual Machine with SSH.

  2. Start a root user command shell:
    sudo -s
  3. Run the following command:
    dbaascli database move --oracleHome path_to_target_oracle_home --dbname database_name --executePrereqs
    Where:
    • --oracleHome identifies the path of the target Oracle Home that uses the desired Oracle Database software version. Note that the target Oracle Home must exist in your system prior to using the database move command.
    • --dbname specifies the name of the database that is being moved
  4. Exit the root user command shell:
    exit
Precheck for Oracle Grid Infrastructure Patching

Use the --executePrereqs flag with the dbaascli grid patch command.

  1. Connect to the virtual machine as the opc user.

    For detailed instructions, see Connecting to a Virtual Machine with SSH.

  2. Start a root user command shell:
    sudo -s
  3. Run the following command:
    dbaascli grid patch --targetVersion target_software_version_number --executePrereqs

    Where --targetVersion identifies target software version that the Oracle Grid Infrastructure will be patched to, specified as five numeric segments separated by periods, for example, 19.12.0.0.0

  4. Exit the root user command shell:
    exit

Resuming or Rolling Back a Patching Operation

You can resume or revert a failed patching operation. Reverting a patch is known as a rollback.

Resuming a Patch Operation

To resume a patching operation, use the --resume flag with the original patching command.

  1. Connect to the virtual machine as the opc user.

    For detailed instructions, see Connecting to a Virtual Machine with SSH.

  2. Start a root user command shell:
    sudo -s
  3. Run the original patching command to resume a patching operation:
    For example:
    dbaascli dbhome patch --oracleHome /u02/app/oracle/product/19.0.0.0/dbhome_2 --targetVersion 19.9.0.0.0 --resume
  4. Exit the root user command shell:
    exit
Rolling Back a Patch Operation

Use the --rollback flag with the original patching command to roll back (revert) a patching operation.

  1. Connect to the virtual machine as the opc user.

    For detailed instructions, see Connecting to a Virtual Machine with SSH.

  2. Start a root user command shell:
    sudo -s
  3. Run the original patching command to roll back (revert) a patching operation:
    For example:
    dbaascli grid patch --targetVersion 19.11.0.0.0 --rollback
    Note

    • Resume and Rollback operations are supported for Oracle Home patching, Oracle Grid Infrastructure patching, and database move operations.
    • When resuming or rolling back a patching operation, you must run the resume or rollback command from the same node that was used to run the original patching command, and you must run the original command with the addition of the --resume or --rollback flag.
  4. Exit the root user command shell:
    exit

Updating Cloud Tooling Using dbaascli

To update the cloud tooling release for Oracle Exadata Database Service on Cloud@Customer, complete this procedure.

Cloud-specific tooling is used on the Exadata Cloud@Customer Guest VMs for local operations, including dbaascli commands.

The cloud tooling is automatically updated by Oracle when new releases are made available. If needed, you can follow the steps below to ensure you have the latest version of the cloud-specific tooling on all of the virtual machines in the VM cluster.
Note

You can update the cloud-specific tooling by downloading and applying a software package containing the updated tools.
  1. Connect to a virtual machine as the opc user.

    For detailed instructions, see Connecting to a Virtual Machine with SSH.

  2. Start a root user command shell:
    sudo -s
  3. To update to the latest available cloud tooling release, run the following command:
    dbaascli admin updateStack

    The command takes care of updating the cloud tooling release on all the nodes of the cluster.

    For more details and other available options, refer to dbaascli admin updateStack --help.

Creating a Duplicate Database

Using dbaascli to Duplicate a Cloud Database

You can create a duplicate database using dbaascli. This new database can be in the same cloud region as the source region or across the regions. The following steps describe how to create a duplicate database on cloud.

Note

If a database is configured with OCI Vault for TDE encryption and you want to duplicate a database, then refer to the following sections.

Prepare for duplication

Ensure that the following prerequisites are ment:

  • Make sure that there is a network path setup to access the source database through the EZConnect string.
  • Copy the TDE wallet file (ewallet.p12 ) to the target database node. The node where you decide to run the dbaascli command.
  • Create an Oracle home on the target node if required. Oracle home version must be the same version as the source or of higher RU version.

Run prerequisite checks

To run prerequisites checks, use the --executePrereqs command option. This will perform only the prerequisite checks without performing the actual Oracle Database duplication.

dbaascli database duplicate --dbName <database name> --oracleHome <Oracle Home Path> --sourceDBConnectionString <source database EZConnect string> --sourceDBTDEWalletLocation <location of copied wallet> --sourceDBTdeConfigMethod FILE --tdeConfigMethod FILE --executePrereqs

Duplicate the database

dbaascli database duplicate --dbName <database name> --oracleHome <Oracle Home Path> --sourceDBConnectionString <source database EZConnect string> --sourceDBTDEWalletLocation <location of copied wallet> --sourceDBTdeConfigMethod FILE --tdeConfigMethod FILE
Note

If source database is using OKV for TDE keystore management, current duplicate database operation does not support this configuration.

Duplicate an On-Premises Database

Using dbaascli, you can duplicate an on-prem database onto the cloud. This can be done with the dbaascli database duplicate command. This command creates a new database on the cloud, which is a duplicate of an on-prem database along with its data. While this process is going on, the on-prem database remains still operational. You can migrate your applications to the duplicated database on the cloud after due verification.

Prepare for duplication

The migration process includes the following prerequisites to be met.
  • Make sure that there is a network path setup to access an on-prem database from the OCI node through the EZConnect string.
  • If an on-prem database is configured with TDE, copy the TDE wallet file (ewallet.p12 ) to the OCI node, where you decide to run the dbaascli command.
  • Create an Oracle home on the OCI node if required. The Oracle home version must be the same as the source or of a higher RU version.

Verify the necessary RPMs

This process requires a minimum dbaastools RPM version of 23.3.2.0.0 but updating to the latest dbaastools rpm is always recommended.

  • To check the currently installed version, run:
    dbaascli --version
    DBAAS CLI version 23.3.2.0.0
  • To apply the latest tools RPM, as the root user, run:
    # dbaascli admin updateStack

Run the prerequisite checks

To run the prerequisite checks, use the --executePrereqs command option. This will perform only the prerequisite checks without performing the actual Oracle Database duplication.

dbaascli database duplicate --dbName <database name> --oracleHome <Oracle Home Path> --sourceDBConnectionString <source database EZConnect string> --sourceDBTDEWalletLocation <location of copied wallet> --executePrereqs

Duplicate the database

Duplicate the database using the following command:

dbaascli database duplicate --dbName <database name> --oracleHome <Oracle Home Path> --sourceDBConnectionString <source database EZConnect string> --sourceDBTDEWalletLocation <location of copied wallet>

For example:

dbaascli database duplicate --sourceDBConnectionString xyzhost.oracle.com:1521/dbuniquename.oracle.com --dbName orcl --oracleHome /u02/app/oracle/product/19.0.0.0/dbhome_1 --sourceDBTDEWalletLocation /tmp/wallet_copy/tde --waitForCompletion false

Upon successful completion of this command, the database is duplicated to Cloud and ready for sanity checks for application usage. Once verification is done, application connections can be migrated to the Cloud database.

Refer to dbaascli database duplicate –help for additional configuration options.

Few considerations for migration

  • If you prefer to allocate multiple channels for RMAN duplicate, you could do so by specifying the --rmanParallelism argument.
  • Exadata Cloud Service configures database memory as Automatic Shared Memory Management (ASMM). If your on-prem database is configured with different memory management, make sure to adjust memory parameter values accordingly on the OCI side by providing values for --sgaSizeInMB and --pgaSizeInMB.
  • Verify that the on-prem database does not contain any deprecated or invalid initialization parameters.
  • Database initialization parameters related to database storage (datafile location, redo location, recovery area destination, control file multiplexing) may be changed using the --initParams argument.

    For example, to override db_create_online_log_dest value for the duplicate database: --initParams db_create_online_log_dest_1=+DATAC1,db_create_online_log_dest_2=+RECOC1

Troubleshooting the database duplication

  • dbaascli operation log file can be found under /var/opt/oracle/log/<dbname>/database/duplicate
  • One of the jobs of the duplicate is to run dbca. Its log file can be found under /u02/app/oracle/cfgtoollogs/dbca and /u02/app/oracle/cfgtoollogs/dbca/<dbuniquename>.

If the operation fails, you will have an option to resume the operation by providing the --resume argument to the same command. Alternatively, clean up the database using dbaascli database delete –dbname <dbname> –force, and then rerun the database duplicate command.

Release Notes

Review the changes made in various releases of dbaascli.

Release 24.3.2.0.0 (240912)

  • Includes AHF version 24.7
  • Includes syslens version 24.3.1.0
  • Various bug fixes and stability improvements

Release 24.3.1.0.0 (240730)

  • TDE migration from sqlnet.ora to wallet_root on database upgrade to 19c release
  • Grid patch in-place to use image-based patching as default mode
  • Includes AHF version 24.6.1
  • Includes syslens version 24.1.2.0
  • Various bug fixes and stability improvements

Release 24.2.1.0.0 (240620)

  • Added support for Oracle Database 23ai.
  • Includes AHF version 24.4.3
  • Includes syslens version 24.1.2.0
  • Various bug fixes and stability improvements.

Release 24.1.2.0.0 (240327, 240424, 240502)

  • Includes AHF version 24.1.1.
  • Includes syslens version 2.6.8.0.
  • Various bug fixes and stability improvements

Release 24.1.1.0.0 (240118, 240219)

  • Includes AHF version 23.11.1.
  • Includes syslens version 2.6.4.3.
  • Various bug fixes and stability improvements
  • (240219) Bug 36309260 fix applicable to DBCS agent version 21.2 or earlier: communication between OCI Control Plane and DBCS agent does not work in some VMs.

Release 23.4.1.0.0 (231219)

  • Includes AHF version 23.9.5.
  • Includes syslens version 2.6.4.2.
  • Various bug fixes and stability improvements

Release 23.3.2.0.0 (231115)

  • Pluggable Database Operations
    • Added support to set custom key version OCID (Bring Your Own Key - BYOK) of OCI Vault during create and clone operations. For details, see respective PDB commands help.
  • Grid Infrastructure (GI) Patching
    • Enhanced the patching workflow to improve patching time, especially in environments having high number of databases.
    • A new option --patchInParallel is introduced that can be used to perform patching remote nodes in parallel.
  • Database Patching
    • Provided option to run datapatch on a specific node of cluster.
  • Includes AHF version 23.7.7
  • Includes syslens version 2.3.6.10
  • Various bug fixes and stability improvements

Release 23.3.1.0.0 (230817, 231020)

  • New dbaascli commands
    • dbaascli gridHome create - This command can be used to create a Grid Infrastructure home of a supported version. For details, see dbaascli gridHome create --help.
    • dbaascli system getGridHomes - This command gives details on the available Grid Infrastructure homes on the system. For details, see dbaascli system getGridHomes --help.
  • Pluggable Database Operations
    • Improvements in the area of refreshable pluggagble database lifecycle.
  • Database Backup and Recovery
    • Added support to configure backups on standby sites in case of Data Guard configurations. The backups configuration are Data Guard site-specific, that is, the change of roles (for example, with Data Guard switchover operation) will not impact the backup operations of the database on primary or standby sites. Backups, if configured on primary site or stand-by site, will continue regardless of the role-change.
    • Includes AHF version 23.5.2 - Release 23.3.1.0.0 (230817)
    • Includes AHF version 23.5.4 - Release 23.3.1.0.0 (231020)
  • Includes syslens version 2.3.6.9
  • Various bug fixes and stability improvements
  • Additional critical product fixes (231020)

Release 23.2.1.0.0 (230708, 230724)

  • Database Lifecycle related improvements
    • Introduced dbaascli grid removeTCPSCert to remove expired TCPS certificates. For details, see dbaascli grid removeTCPSCert --help.
    • Added option to exclude specific PDBs during database duplicate. For details, see skipPDBs argument in dbaascli database duplicate --help.
  • Database Backup and Recovery
    • Changed the default for FILES_PER_SET to 64 for OSS backups. This can be changed with dbaascli database backup --configure. For details, see dbaascli database backup --help.
    • Archive log backups continue from the standby site after the role switchover in data guard environments.
    • For backups that are not managed by Oracle, the schedules for L0 and L1 backups are not created by default. They must be be created explicitly by using dbaascli database backup --configure command.
    • Includes AHF version 23.3.4 - Release 23.2.1.0.0 (230708)
    • Includes AHF version 23.3.5 - Release 23.2.1.0.0 (230724)
  • Various bug fixes and stability improvements

Release 23.1.2.0.0 (230411, 230616)

  • Database Lifecycle related improvements
    • Added option to create database templates (DBCA temapltes) to object store. DBCA templates can subsequently be used to create databases. For details, see dbaascli database createTemplate --help.
  • Pluggable Database Operations
    • Introduced dbaascli pdb refresh to refresh a pluggable database that was created using manual refresh option. For details, see dbaascli pdb refresh --help.
    • Added option to convert refreshable pluggable database to a regular pluggable database. For details, see dbaascli pdb open --help.
    • Creation of a refreshable pluggable database now requires existing source database user for creation of database link to the source pluggable database. For details, see dblinkUserName argument in dbaascli pdb remoteClone --help.
  • Includes AHF version 23.2.0
  • Various bug fixes and stability improvements

Release 23.1.1.0.1 (230302)

  • Database Lifecycle related improvements
    • Added support to create a duplicate database from a source database which uses OCI Vault Services for encryption key management.
  • Includes AHF version 22.2.5
  • Various bug fixes and stability improvements

Release 22.4.1.0.1 (221214)

  • Pluggable Database Operations
    • Added option to not open the PDB at the end of relocate. For details, see skipOpenPDB argument in dbaascli pdb relocate --help. After using this option, the pdb relocate can be completed by running the command using completePDBRelocate argument.
    • Added option to clean up the relocated PDB metadata/services at the source location. For details, see cleanupRelocatedPDB argument in dbaascli pdb delete --help
  • New dbaascli commands
    • dbaascli database createTemplate - This command can be used to create database templates (DBCA templates) that can subsequently be used to create databases. DBCA templates are widely used for creating a clone database with DBCA - a tool that is shipped with Oracle Database server software. For details, see dbaascli database createTemplate --help
    • Introduced dbaascli tde rotateMasterKey to rotate the master key for database encryption. For details, see dbaascli tde rotateMasterKey --help. The command dbaascli tde rotate masterkey is now deprecated.
  • Database Lifecycle related improvements
    • Added support to use dbca templates in database creation workflows. For details, see dbcaTemplateFilePath argument in dbaascli database create --help
    • Improved performance for duplicate database creation. For details on how to create duplicate database, see dbaascli database duplicate --help
    • Added support to create a duplicate database from a source database which is not TDE-encrypted.
  • TDE management
    • Introduced dbaascli tde rotateMasterKey to rotate the master key for database encryption. For details, see dbaascli tde rotateMasterKey --help. The command dbaascli tde rotate masterkey is now deprecated.
    • Revamped workflow for all TDE operations. For details, see dbaascli tde --help
  • Grid Infrastructure (GI) Patching
    • Added support to allow parallel execution of patching operation on nodes. This option needs to be carefully exercised as it results into reduced database availability.
  • Database Backup and Recovery
    • Revamped workflow for creating database from standalone backups
  • Includes AHF version 22.2.4
  • Various bug fixes and stability improvements

Release 22.3.1.1.0 (221003)

  • New dbaascli commands
    • dbaascli database getDetails - This command shows the detailed information of a given database, for example, dbname, node information, pluggable databases information, and so on. For details, see dbaascli database getDetails --help.
  • Pluggable Database Operations
    • Added support for creating pluggable databases as refreshable clone using refreshablePDB argument. For details, see dbaascli pdb remoteClone --help
  • Various bug fixes and stability improvements

Release 22.3.1.0.1 (220831)

  • New database lifecycle commands
    • dbaascli database addInstance - This command can be used to add a database instance to one of the nodes of the cluster where database is not already configured. For details, see dbaascli database addInstance --help.
    • dbaascli database deleteInstance - This command can be used to delete a database instance from one of the nodes of the cluster where database is configured. For details, see dbaascli database deleteInstance --help.
    • dbaascli database duplicate - This command can be used to create a new database from an already existing database within a cluster, or across clusters, provided network connection exists between the clusters. For details, see dbaascli database duplicate --help.
  • Cloud Software Library
    • Introduced dbaascli cswlib listLocal command to list images that are downloaded from software library locally on the system. For details, see dbaascli cswlib listLocal --help. The command dbaascli dbimage list is now deprecated.
    • Introduced dbaascli cswlib deleteLocal command to delete images that are downloaded from cloud software library. For details, see dbaascli cswlib deleteLocal --help. The command dbaascli dbImage purge is now deprecated.
  • The log location for the command dbaascli admin updateStack has been changed to follow the convention of other dbaascli commands. The logs can be conveniently found under /var/opt/oracle/log/admin/updateStack directory. The earlier location was /var/opt/oracle/log/tooling/Update.
  • dbaascli help is now cloud platform aware in that it will list help output for commands applicable for the cloud environment it is operating on.
  • Added support for changing TDE password in dataguard environments. For details, see dbaascli tde changePassword --help. This support is currently not available for 11.2.0.4 release.
  • Included AHF version 22.1.5.
  • Revamped workflow for database upgrade operation.
  • Revamped workflow for database home create operation.
  • Various bug fixes and stability improvements

Release 22.2.1.1.0 (220713)

  • New dbaascli commands:
    • dbaascli dbHome getDatabases - This command lists all the databases running from a given database Oracle home. The output is returned in JSON format to facilitate automation. For details, see dbaascli dbHome getDatabases --help.
    • dbaascli database getPDBs - This command lists all the pluggable databases of a given container database. The output is returned in JSON format to facilitate automation. For details, see dbaascli database getPDBs --help.
    • dbaascli dbHome delete - This command deletes a given database Oracle home. For details, see dbaascli dbHome delete --help.
    • dbaascli dataguard prepareStandbyBlob - This command generates a blob file containing various files that are required on the standby site for a Data Guard environment. For details, see dbaascli dataguard prepareStandbyBlob --help.
  • Grid Infrastructure (GI) Patching:
    • New optimized workflow
    • Introduced a way to create the Grid Infrastructure (GI) software image prior to patching. This GI image can be subsequently used for performing the GI patching operation. The advantage of this approach is that it results in reduced patching window as the image is already prepared. The GI stack on the node is not brought down to create the image. For details, see createImage option in dbaascli grid patch --help
    • Introduced a way to perform the Grid Infrastructure patching through the use of user specified GI software image, created using createImage option of the dbaascli grid patch command. For details, see imageLocation option in dbaascli grid patch --help.
  • Change Password support in Data Guard environment:
    • Added support to change password in Data Guard environments. For details, see dbaascli database changePassword --help and dbaascli dataguard prepareStandbyBlob --help
  • Data Guard configuration:
    • Added support to update Data Guard Automation Attributes (in the /var/opt/oracle/dg/dg.conf file). For details, see dbaascli dataguard --help.
  • Various bug fixes and stability improvements

Release 22.2.1.0.1 (220504)

  • New dbaascli commands:
    • Introduced dbaascli admin showLatestStackVersion to show the latest dbaastools version available for customers to download and install. The installation of dbaastools RPM can be performed by using the command dbaascli admin updateStack. For details see the dbaascli Command Reference section.
  • Cloud Software Library:
    • Deprecated the support for BP activation (dbaascli cswlib activateBP) as BPs (Bundle Patches) are now replaced with RUs ("Release Updates"). Cloud deployment consumes RUs in the form of software images, identified with Image Tags. It is therefore recommended to use image tags while interfacing with Cloud Software Library (cswlib) commands. For details, see dbaasscli cswlib download –help.
    • Eliminated the need to download non-CDB images to create non-CDB databases. Now users can create the non-CDB database using regular images. For details, see createAsCDB option in dbaascli database create –help.
  • Non-CDB Database Creation:
    • Enhanced database creation workflow to create a non-CDB database using standard database software image. For details, see createAsCDB option in dbaascli database create –help.
  • Database Home Patching:
    • New optimized workflow
  • Grid Infrastructure Upgrade:
    • New optimized workflow
  • Pluggable Database (PDB) Operations:
    • Deletion of PDB in Data Guard environments requires explicit acknowledgment to indicate that operations necessary on standby site are completed, by passing of additional argument –allStandByPrepared. For details, see dbaascli pdb delete --help.
  • Provided rolling capability for database bounce operation. For details, see dbaascli database bounce –help.
  • Various bug fixes and stability improvements

Release 22.1.1.1.0 (220301)

  • New dbaascli commands:
    • Introduced dbaascli system getDBHomes to get all the database Oracle homes on the cluster. The output is returned in JSON format to facilitate automation.
    • Introduced dbaascli dbhome getDetails to get detailed information on a specific Oracle home. The output is returned in JSON format to facilitate automation.
  • Cloud Software Library (cswlib):
    • Deprecated the support for dbaascli cswlib list command for cloud software library listing operations. The new command is dbaascli cswlib showImages that lists the images along with its of ImageTag. It is recommended to use Image tags to download the images from the cloud software library. For details on downloads using image tags, see dbaascli cswlib download –help.
    • Various bug fixes and stability improvements

Release 22.1.1.0.1 (220223)

  • Grid Infrastructure Upgrade:
    • New optimized workflow
  • Database Backup and Recovery:
    • Internal update to metadata repository for backup metadata
    • Introduced deprecation messages for bkup_api commands as they are now replaced with dbaascli commands. For details, see dbaascli database backup --help and dbaascli database recover –help
  • Pluggable Database (PDB) Operations:
    • Relocate operation of PDB is now supported. For details, see dbaascli pdb relocate –help.
    • Revamped workflow for non-CDB to PDB conversion. For details, see dbaascli database convertToPDB –help.
  • Encryption Key Management:
    • Transparent Data Encryption (TDE) heartbeat-specific initialization parameters are set to the cloud recommended values for databases with 'Customer Managed Keys'.
  • Cloud Software Library Management:
    • Revamped software library download of artifacts through imageTags. It is recommended to use imageTags to download the database and grid software images. For details, see dbaascli cswlib showimages and dbaascli cswlib download –help
  • Included AHF version 21.4.2
  • Various bug fixes and stability improvements

Release 21.4.1.1.0

  • Enabled encryption of the system level tablespaces (SYSTEM, SYSAUX, UNDO, and TEMP) for databases that will get created with this version of dbaastools onwards. This feature is enabled for Oracle Database version 19.6.0.0.0 and above.
  • Grid Patching:
    • Prerequisite condition added to check for following file ownership to be owned by grid user.
      • <gi_home>/suptools/tfa/release/tfa_home/jlib/jdev-rt.jar
      • <gi_home>/suptools/tfa/release/tfa_home/jlib/jewt4.jar
  • Database Patching:
    • Simultaneous database move operation is disallowed by default. A new option –allowParallelDBMove is introduced that can be used to override the default behavior for Oracle Database releases 12.2 and above.
    • Fixed issues related to move of standby databases being in MOUNT mode.
  • Database Backup and Recovery:
    • Added new command-line options for database backup. For more details, refer to dbaascli database backup command reference.
    • Added new command-line options for database recovery. For more details, refer to dbaascli database recover command reference.
    • bkup_api usage for backup and recovery operations will be deprecated in future.
    • To align with the Oracle recommended practice of using SYSBACKUP administrative privilege for Backup and Recovery operations, cloud automation creates a common administrative user C##DBLCMUSER with SYSBACKUP role at the CDB$ROOT container level. Backup and Recovery operations are therefore performed with the user having the least required privileges. Credentials for this user are randomly generated and securely managed by cloud automation. If the user is not found or is LOCKED and EXPIRED, then cloud automation will recreate or unlock this user during the backup or recovery operation. This change in the cloud automation is made starting with dbaastools version 21.4.1.1.0.
  • Enhanced dbaascli resume functionality to resume any previous session by specifying the –sessionID <value> argument to the resume command. The session ID is shared in the dbaascli output as well as in the logs.
  • Enhanced dbaascli help output to show the command usage.
  • Deprecated the usage of dbaascli shell (interactive session). This will be completely unsupported after March 2022. It is recommended to execute complete dbaascli commands on command prompt as suggested in all document examples.
  • Included Autonomous Health Framework (AHF) version 21.2.8.
  • Various bug fixes and stability improvements.

Release 21.3.1.2.0

  • Improved the timing of dbaascli operations with enhanced Control Plane metadata synchronization logic.
  • Enhanced dbaascli logs to have millisecond-level information along with the associated thread.
  • Introduced more prerequisite checks in database home patching and database move operations to catch potential failures scenarios with suggestions to corrective action.
  • Database patching operations now retain the state of the databases to be same as it was prior to patching. For pluggable databases, pdb saved state is honored.
  • Various bug fixes and stability improvements.

Release 21.3.1.1.0

  • Added support to unlock PDB Admin user account as part of PDB creation, localClone, or remoteClone operation. For details, see option --lockPDBAdminAccount in dbaascli pdb create --help.
  • Fixed an issue that updates the database resource registered with Oracle Grid Infrastructure in existing environments with the correct value of database name.
  • Enhanced PDB lifecycle operations.
  • Various bug fixes and stability improvements.

Release 21.3.1.0.1

  • Support for the following dbaascli commands to be run as oracle user.
    • dbaascli pdb bounce
    • dbaascli pdb close
    • dbaascli pdb connectString
    • dbaascli pdb create
    • dbaascli pdb delete
    • dbaascli pdb getDetails
    • dbaascli pdb list
    • dbaascli pdb localClone
    • dbaascli pdb open
    • dbaascli pdb remoteClone
  • Revamped out-of-place patching of database. For details, see dbaascli database move –help.
  • Timing related enhancements in Oracle Grid Infrastructure patching workflow. For details, see dbaascli grid patch –help.
  • Deprecated the support for exadbcpatchmulti / dbaascli patch for patching operations. The dbaascli dbhome patch and dbaascli grid patch commands are provided for patching operation for database homes and Oracle Grid Infrastructure. Refer to the Patching Oracle Grid Infrastructure and Oracle Database Using dbaascli section for details. Also see, dbaascli Command Reference section.
  • Deprecated the support for dbaascli tools patch command to bring consistency in the dbaascli command conventions. The new command is dbaascli admin updateStack. For details, see section Updating Cloud Tooling using dbaascli.
  • Ability to run dbaascli in disconnected mode for long running operations. Executing dbaascli command with --waitForCompletion false gets you a job ID that can be queried later to get the status of the operation, using dbaascli job getStatus –jobid job_id. This is useful for long running operations where users may want to get the control back immediately after command execution. In this release, this option is available only for dbaascli database create command. More commands will be added in subsequent releases to have this support. The help output for those commands will reflect the support of --waitForCompletion option.
  • Deprecated the support for dbaascli shell. It is recommended that users run the complete dbaascli commands on the command prompt as suggested in all the document examples. Execution of just dbaascli will show the output of its usage help instead of entering into a dbaascli shell.
  • Various bug fixes and stability improvements.

Release 21.2.1.x.x

  • Redesigned Oracle Grid Infrastructure patching operation and added ability to resume from failed point, patch on subset of nodes, instance draining, and other enhancements. For details, see dbaascli grid patch --help. Also refer to the Patching Oracle Grid Infrastructure and Oracle Database Using dbaascli section.
  • Deprecated the support for exadbcpatchmulti / dbaascli patch for patching operations. dbaascli dbhome patch and dbaascli grid patch commands are provided for patching operation for database homes and Oracle Grid Infrastructure. Refer to the Patching Oracle Grid Infrastructure and Oracle Database Using dbaascli section for details. Also see, dbaascli Command Reference section.
  • Deprecated the support for dbaascli tools patch command to bring consistency in the command conventions. The new command is dbaascli admin updateStack.
  • Redesigned PDB management APIs for create, local clone, and remote clone operations. For details, see dbaascli pdb --help.
  • Redesigned database delete API. For details, see dbaascli database delete --help.
  • Revamped dbhome creation (support for custom software image, scale-out operation). For details, see dbaascli dbhome create --help.
  • Support for database creation on subset of cluster nodes. For details, see dbaascli database create --help.
  • Ability to run dbaascli in disconnected mode for long running operations. Executing dbaascli command with --waitForCompletion false gets you a job ID that can be queried later to get the status of the operation, using dbaascli job getStatus –jobid job_id. This is useful for long running operations where users may want to get the control back immediately after command execution. In this release, this option is available only for dbaascli database create command. More commands will be added in subsequent releases to have this support. The help output for those commands will reflect the support of --waitForCompletion option.
  • Enhanced dbhome patching experience with introduction of multiple options like skipPDBs, continueWithDowntime, and so on. For details, see dbaascli dbhome patch --help.
  • Support for better diagnostic collection. For details, see dbaascli diag collect --help.
  • Minor improvements in the area of database upgrade automation.
  • Various bug fixes and stability improvements.

dbaascli Command Reference

You must use dbaascli to create databases and integrate them with the cloud automation framework.

dbaascli is a cloud native interface that can take DBCA templates as inputs, calls the functionality of DBCA to create databases, and then calls OCI APIs to integrate the database into the cloud automation framework. Customers using DBCA in scripts today can update their existing scripts to call dbaascli instead of DBCA. If dbaascli cannot be used due to a particular feature of DBCA being unavailable in dbaascl, then customers should open a My Oracle Support (MOS) request to add that functionality to dbaascli.

Administration and Configuration

This section covers essential tasks for managing and configuring Oracle Database environments. It includes commands such as dbaascli admin updateStack for installing or updating the dbaastools RPM, and dbaascli job getStatus for checking the status of specific jobs.

dbaascli admin updateStack

To install or update a dbaastools RPM, use the dbaascli admin updateStack command.

Prerequisites

Run the command as the root user.

To use the utility, you must connect to an Exadata Database Service on Cloud@Customer virtual machine.

See, Connecting to a Virtual Machine with SSH.

Syntax

dbaascli admin updateStack 
[--resume]
[--prechecksOnly]
[--nodes]
Where:
  • --resume resumes the previous execution
  • --prechecksOnly runs only the prechecks for this operation
  • --nodes specifies a comma-delimited list of nodes to install the RPM on. If you do not pass this argument, then the RPM will be installed on all of the cluster nodes

Frequently Asked Questions

Q: What is the dbaascli admin updateStack command used for?

A: The dbaascli admin updateStack command is used to install or update a dbaastools RPM on Exadata Cloud Infrastructure.

Q: What are the prerequisites for using the dbaascli admin updateStack command?

A: You must run the command as the root user and connect to an Exadata Cloud Infrastructure virtual machine.

Q: What does the --resume option do?

A: The --resume option resumes the previous execution of the updateStack command if it was interrupted or incomplete.

Q: What is the purpose of the --prechecksOnly option?

A: The --prechecksOnly option runs only the prechecks for the operation without actually performing the installation or update.

Q: How is the --nodes parameter used?

A: The --nodes parameter specifies a comma-delimited list of nodes on which the RPM should be installed. If not provided, the RPM will be installed on all cluster nodes.

Q: What should I do if I encounter issues with the dbaascli admin updateStack command?

A: Ensure you are running the command as the root user and that you are connected to an Exadata Cloud Infrastructure virtual machine. Check if there are any specific error messages and consult the command documentation or Oracle support if needed.

Q: How do I connect to an Exadata Cloud Infrastructure virtual machine to use the dbaascli admin updateStack command?

A: You need to use SSH to connect to the virtual machine. Refer to the section on "Connecting to a Virtual Machine with SSH" in the documentation for detailed instructions.

Example Use Cases

Example 1: Installing or updating the dbaastools RPM on all nodes

dbaascli admin updateStack

Installs or updates the dbaastools RPM on all nodes of the Exadata Cloud@Customer environment.

Example 2: Running prechecks only before installing or updating the RPM

dbaascli admin updateStack --prechecksOnly

Runs only the prechecks for the dbaastools RPM update, without actually performing the installation. It ensures that all prerequisites are satisfied before proceeding with the update.

Example 3: Resuming a previously interrupted updateStack operation

dbaascli admin updateStack --resume

Resumes a previous dbaastools RPM update operation that was interrupted or did not complete successfully.

Example 4: Installing or updating dbaastools on specific nodes

dbaascli admin updateStack --nodes node1,node2

Installs or updates the dbaastools RPM on the specified nodes node1 and node2 only, without affecting other nodes in the cluster.

Example 5: Resuming the updateStack process on specific nodes

dbaascli admin updateStack --resume --nodes node3,node4

Resumes the update process for dbaastools on the specific nodes node3 and node4 only, if the previous execution was interrupted.

dbaascli job getStatus

To view the status of a specified job, use the dbaascli job getStatus command.

Prerequisite

Run the command as the root user.

To use the utility, you must connect to an Exadata Cloud@Customer virtual machine.

See, Connecting to a Virtual Machine with SSH.

Syntax

dbaascli job getStatus --jobID
Where:
  • --jodID specifies the job ID

Frequently Asked Questions

Q: What is the dbaascli job getStatus command used for?

A: The dbaascli job getStatus command is used to view the status

Example Use Cases

Example 1: Checking the status of a specific job using job ID

dbaascli job getStatus --jobID 12345

Checks the status of the job with the ID 12345. The output will show the current state of the job (e.g., in progress, completed, or failed).

Example 2: Checking the status of a patching job using job ID

dbaascli job getStatus --jobID 98765

Retrieves the status of a patching job with the ID 98765 to see whether the patch has been applied successfully or is still running.

Example 3: Checking the status of a database backup job

dbaascli job getStatus --jobID 45678

Checks the status of a database backup job with the ID 45678. The output will provide details about the progress or completion of the backup.

Example 4: Checking a long-running job’s progress

dbaascli job getStatus --jobID 23456

Check the progress of a long-running job (ID 23456) to see if it’s still executing or has finished.

Example 5: Viewing the status of a database creation job

dbaascli job getStatus --jobID 67890

Checks the status of a database creation job identified by the job ID 67890.

CPU Scaling

This section focuses on adjusting CPU resources in a VM cluster. It includes commands like dbaascli cpuscale get_status to check the status of current or past scaling requests, and dbaascli cpuscale update to increase or decrease the number of CPU cores allocated to a virtual machine, allowing flexible resource management based on workload demands.

dbaascli cpuscale get_status

To check the status of current or last scale request performed when network connectivity between the Control Plane Server and OCI region is disrupted, use the dbaascli cpuscale get_status command.

Prerequisites

Run the command as the root user.

To use the utility, you must connect to an Exadata Cloud@Customer virtual machine.

See, Connecting to a Virtual Machine with SSH.

Syntax

Displays various command execution states as it progresses from scheduled, running, and finally to success or failure.
dbaascli cpuscale get_status

Frequently Asked Questions

Q: What is the dbaascli cpuscale get_status command used for?

A: The dbaascli cpuscale get_status command is used to check the status of the current or last CPU scale request, especially when network connectivity between the Control Plane Server and OCI region is disrupted.

Q: What are the prerequisites for using the dbaascli cpuscale get_status command?

A: You must run the command as the root user and connect to an Exadata Cloud@Customer virtual machine.

Q: What should I do if I encounter issues running the dbaascli cpuscale get_status command?

A: Ensure you are running the command as the root user and that you are connected to an Exadata Cloud@Customer virtual machine. If issues persist, consult the command documentation or seek support from Oracle.

Q: What if the command shows a status of failure?

A: If the command shows a failure status, check the detailed logs for error messages and troubleshoot based on the specific error. You may need to address network issues or review the scale request details.

Example Use Cases

Example 1: Checking the status of the most recent CPU scaling operation

dbaascli cpuscale get_status

Checks the status of the current or last CPU scaling request. It will provide information on whether the scaling is scheduled, running, or has completed with success or failure.

Example 2: Checking the status after a scaling request failed

A scaling operation was requested but encountered network issues between the Control Plane Server and the OCI region.

dbaascli cpuscale get_status

Checks the status of the scaling request. Since the scaling process failed due to network issues, the output will provide details about the failure state.

Example 3: Checking the status when scaling is in progress

A CPU scaling operation is ongoing, and the user wants to monitor its progress.

dbaascli cpuscale get_status

Checks the current status, showing that the scaling request is in the "running" state. It allows the user to track the operation until it completes or fails.

Example 4: Checking the status after successful scaling completion

A scaling operation was performed and completed successfully.

dbaascli cpuscale get_status

Checks the status and confirms that the scaling operation has successfully completed. It reports the final state as "success."

dbaascli cpuscale update

To scale up or down the CPU core count for a virtual machine in a VM cluster when network connectivity between the Control Plane Server and OCI region is disrupted, use the dbaascli cpuscale update command.

Prerequisites

To scale OCPUs up or down in a VM cluster in disconnected mode, run the dbaascli cpuscale update and dbaascli cpuscale get_status commands from any node inside a VM cluster to change the CPU core count for that cluster. If you have more than one VM cluster, then run a separate command from any node inside each VM cluster you want to scale up or down. These commands are designed to not work if issued during the normal connected mode and will time out after 600 seconds (10 minutes).

Run the command as the root user.

To use the utility, you must connect to an Exadata Cloud@Customer virtual machine.

See, Connecting to a Virtual Machine with SSH.

Syntax

Exadata Database Service on Cloud@Customer is considered to be in a Disconnected mode when there is a loss of connectivity with the DBaaS control plane running on Oracle Cloud Infrastructure (OCI).

dbaascli cpuscale update --coreCount coreCount --message message
Where:
  • --coreCount specifies the target number of CPUs you want to scale up or down for each VM in the cluster
  • --message optionally, you can include a message for your reference

Frequently Asked Questions

Q: What is the dbaascli cpuscale update command used for?

A: The dbaascli cpuscale update command is used to scale up or down the CPU core count for a virtual machine in a VM cluster when network connectivity between the Control Plane Server and Oracle Cloud Infrastructure (OCI) is disrupted.

Q: What are the prerequisites for using the dbaascli cpuscale update command?

A: Before using this command, ensure you are running it in disconnected mode, meaning there is a loss of connectivity with the DBaaS control plane on OCI. Run the command from any node inside the VM cluster, and note that it will time out after 600 seconds (10 minutes) if used in connected mode. The command must be executed as the root user.

Q: How do I connect to a virtual machine to use this command?

A: To use the dbaascli cpuscale update command, you need to connect to an Exadata Cloud@Customer virtual machine using SSH. Refer to "Connecting to a Virtual Machine with SSH" for detailed instructions.

Q: What does the --coreCount option specify in the command?

A: The --coreCount option specifies the target number of CPUs you want to scale up or down for each VM in the cluster.

Q: Can I include a message with the dbaascli cpuscale update command?

A: Yes, you can include an optional message using the --message option for your reference.

Q: How do I check the status of a CPU scale operation?

A: To check the status of a CPU scale operation, use the dbaascli cpuscale get_status command. This should be run from any node inside the VM cluster as well.

Q: What happens if I run the dbaascli cpuscale update command in connected mode?

A: The command is designed to not work in connected mode and will time out after 600 seconds (10 minutes). It should only be used in disconnected mode.

Q: How do I scale CPU cores for multiple VM clusters?

A: If you have more than one VM cluster, you need to run the dbaascli cpuscale update command separately from any node inside each VM cluster that you want to scale up or down.

Example Use Cases

Example 1: Scaling up CPU cores to 20

The VM cluster is running with 16 cores, and you want to increase it to 20.

dbaascli cpuscale update --coreCount 20 --message "Scaling up for increased demand"

Scales the CPU core count up to 20, and includes a message "Scaling up for increased demand" for reference.

Example 2: Scaling down CPU cores to 8

The VM cluster is currently using 12 cores, but you want to reduce the count to 8 to save resources.

dbaascli cpuscale update --coreCount 8 --message "Reducing CPU for maintenance period"

Reduces the number of CPU cores to 8 and provides a message for future reference about why the scaling operation was performed.

Example 3: Scaling CPU without a message

You need to scale the CPU cores from 32 to 24, but no additional message is necessary.

dbaascli cpuscale update --coreCount 24

This command scales the core count down to 24 without any message. The operation will be carried out with the default logging of actions.

Example 4: Verifying the status after scaling CPU

After running the scaling command, you want to check if the update was successful.

dbaascli cpuscale get_status

Checks the status of the current or last scaling request, allowing you to confirm whether the scale-up or scale-down operation was successful.

Example 5: Attempting to scale when VM is already at maximum cores

The VM cluster already has the maximum allowed CPU cores (48), but an attempt is made to scale up.

dbaascli cpuscale update --coreCount 50 --message "Attempt to scale beyond limit"

Fail since the VM cluster cannot exceed its maximum allowed cores. The status will reflect the failure after attempting to scale to 50 cores.

Cloud Software Library (CSWLIB) Management

This section provides tools for managing software images in Exadata Database Service on Cloud@Customer environments. Commands like dbaascli cswlib deleteLocal allow for the removal of local images, while dbaascli cswlib download enables the download of new software images. You can also view available images locally with dbaascli cswlib listLocal or check all available Database and Grid Infrastructure images using dbaascli cswlib showImages. These commands help manage and maintain software libraries efficiently.

dbaascli cswlib deleteLocal

To delete the local image, use the dbaascli cswlib deleteLocal command.

Run the command as the root user.

Syntax

dbaascli cswLib deleteLocal --imageTag <value>

Where:

  • --imageTag specifies Oracle home image tag

Frequently Asked Questions

Q: What is the purpose of the dbaascli cswlib deleteLocal command?

A: The dbaascli cswlib deleteLocal command is used to delete a local Oracle home image from the system.

Q: What are the prerequisites for running the dbaascli cswlib deleteLocal command?

A: The command must be run as the root user to ensure the necessary permissions are available to delete the local image.

Q: How do I specify which local image to delete?

A: Use the --imageTag option to specify the Oracle home image tag that you want to delete.

Q: What does the --imageTag option represent in the command?

A: The --imageTag option represents the identifier or tag associated with the Oracle home image that you want to delete.

Q: Can I delete multiple local images at once using this command?

A: No, the dbaascli cswlib deleteLocal command allows you to delete only one local image at a time, specified by its image tag.

Q: What happens if I run the dbaascli cswlib deleteLocal command without specifying the --imageTag?

A: The command will fail because the --imageTag is required to identify which local image should be deleted.

Q: Is it possible to recover a local image after it has been deleted using this command?

A: No, once the local image is deleted using the dbaascli cswlib deleteLocal command, it cannot be recovered. Make sure to verify the image tag before proceeding.

Q: When would I need to use the dbaascli cswlib deleteLocal command?

A: You would use this command when you need to remove an unused or outdated Oracle home image from the local system to free up space or clean up your environment.

Example 7-4 dbaascli cswlib deletelocal

dbaascli cswlib deletelocal --imagetag 19.15.0.0.0
DBAAS CLI version MAIN
Executing command cswlib deletelocal --imagetag 19.15.0.0.0
Job id: 8b3e71de-4b81-4832-b49c-7f892179bb4f
Log file location: /var/opt/oracle/log/cswLib/deleteLocal/dbaastools_2022-07-18_10-00-02-AM_73658.log
dbaascli execution completed
dbaascli cswlib download

To download available software images and make them available in your Exadata Database Service on Cloud@Customer environment, use the dbaascli cswlib download command.

Prerequisites

Run the command as the root user.

To use the utility, you must connect to an Exadata Database Service on Cloud@Customer virtual machine.

See, Connecting to a Virtual Machine with SSH.

Syntax

dbaascli cswlib download --version | --imageTag
[--product]
Where:
  • --version specifies an Oracle home image version
  • --imageTag specifies the image tag of the image
  • --product specifies the image type. Valid values: database or grid

Frequently Asked Questions

Q: What is the purpose of the dbaascli cswlib download command?

A: The dbaascli cswlib download command is used to download available software images and make them available in your Exadata Cloud Infrastructure.

Q: What are the prerequisites for running the dbaascli cswlib download command?

A: You must run the command as the root user. Additionally, you need to be connected to an Exadata Cloud Infrastructure virtual machine.

Q: How do I connect to the virtual machine required for this command?

A: You need to use SSH to connect to the Exadata Cloud Infrastructure virtual machine. Detailed instructions can be found in the documentation under "Connecting to a Virtual Machine with SSH."

Q: What does the --version option specify in the command?

A: The --version option specifies the Oracle home image version that you want to download.

Q: How do I use the --imageTag option in the dbaascli cswlib download command?

A: The --imageTag option is used to specify the image tag of the software image you want to download.

Q: What is the purpose of the --product option in the command?

A: The --product option specifies the type of image you want to download. The valid values are database or grid.

Q: Can I download both database and grid images simultaneously?

A: No, you must specify either database or grid using the --product option, so each download operation is specific to one type of image.

Q: What happens if I do not specify a version or image tag?

A: The command will likely fail or prompt you for the required information since the --version or --imageTag options are necessary to identify the specific software image to download.

Q: Is it necessary to specify both --version and --imageTag together?

A: No, you typically specify either --version or --imageTag depending on how you want to identify the image to download, but not both at the same time.

Q: When would I use the dbaascli cswlib download command?

A: You would use this command when you need to download Oracle home software images for database or grid environments in your Exadata Cloud Infrastructure setup.

Example 7-5 dbaascli cswlib download --product --imageTag

dbaascli cswlib download --product database --imageTag 19.14.0.0.0

Example 7-6 dbaascli cswlib download --version 19.9.0.0.0

dbaascli cswlib download --product database --imageTag 19.14.0.0.0
dbaascli cswlib listLocal

To view the list of locally available Database and Grid Infrastructure images, use the dbaascli cswlib listLocal command.

Run the command as the root user.

Syntax

dbaascli cswLib listLocal [--product <value>]

Where:

  • --product identifies Oracle home product type. Valid values: database or grid.

Frequently Asked Questions

Q: What is the purpose of the dbaascli cswlib listLocal command?

A: The dbaascli cswlib listLocal command is used to view the list of locally available Database and Grid Infrastructure images on your system.

Q: What are the prerequisites for running the dbaascli cswlib listLocal command?

A: The command must be run as the root user to have the necessary permissions to access and list the available images.

Q: How do I specify which type of images to list using this command?

A: Use the --product option to specify the type of Oracle home images you want to list. The valid values are database or grid.

Q: What does the --product option represent in the dbaascli cswlib listLocal command?

A: The --product option identifies the Oracle home product type, allowing you to filter the list of available images to either database or grid types.

Q: Can I list both database and grid images simultaneously?

A: No, the --product option allows you to list either database or grid images at a time. You need to run the command twice with different --product values to see both lists.

Q: What happens if I do not specify the --product option in the command?

A: If the --product option is not specified, the command might list all locally available images or it could require you to specify the product type. The behavior may depend on your environment setup.

Q: When should I use the dbaascli cswlib listLocal command?

A: You should use this command when you want to check which Database or Grid Infrastructure images are currently available locally on your system.

Q: How can I differentiate between database and grid images in the list?

A: The --product option lets you filter the list, so by specifying database or grid, you will only see the images relevant to that product type, making it easier to differentiate.

Q: Is there any risk associated with running the dbaascli cswlib listLocal command?

A: No, this command is non-destructive and only displays information about locally available images. It does not modify or delete any files.

Q: Does this command display remote or cloud-stored images?

A: No, the dbaascli cswlib listLocal command only displays images that are available locally on your system, not those stored remotely or in the cloud.

Example 7-7 dbaascli cswlib listlocal

dbaascli cswlib listlocal
DBAAS CLI version MAIN
Executing command cswlib listlocal
Job id: bc4f047c-0a34-4d4d-a1ea-21ddc2a9c627
Log file location: /var/opt/oracle/log/cswLib/listLocal/dbaastools_2022-07-18_10-29-53-AM_16077.log
############ List of Available Database Images  #############
1.IMAGE_TAG=12.2.0.1.220419
  IMAGE_SIZE=5GB
  VERSION=12.2.0.1.220419
  DESCRIPTION=12.2 APR 2022 DB Image
2.IMAGE_TAG=18.16.0.0.0
  IMAGE_SIZE=6GB
  VERSION=18.16.0.0.0
  DESCRIPTION=18c OCT 2021 DB Image
3.IMAGE_TAG=19.14.0.0.0
  IMAGE_SIZE=5GB
  VERSION=19.14.0.0.0
  DESCRIPTION=19c JAN 2022 DB Image
dbaascli execution completed
dbaascli cswlib showImages

To view the list of available Database and Grid Infrastructure images, use the dbaascli cswlib showImages command.

Run the command as the root user.

Syntax

dbaascli cswlib showImages 
[--product]

Where:

  • --product identifies Oracle home product type. Valid values: database or grid.

Frequently Asked Questions

Q: What is the purpose of the dbaascli cswlib showImages command?

A: The dbaascli cswlib showImages command is used to view the list of available Database and Grid Infrastructure images that can be downloaded or managed within your Oracle Exadata Database Service environment.

Q: What are the prerequisites for running the dbaascli cswlib showImages command?

A: The command must be run as the root user to ensure you have the necessary permissions to view the available images.

Q: How do I filter the images listed by this command?

A: You can filter the images by specifying the --product option with either database or grid to list only the images related to that product type.

Q: What does the --product option represent in the dbaascli cswlib showImages command?

A: The --product option identifies the Oracle home product type, allowing you to filter the list of images to either database or grid.

Q: Can I view both database and grid images in a single command execution?

A: No, you need to run the command twice with different --product values (database and grid) to view both types of images.

Q: What happens if I do not specify the --product option in the command?

A: If the --product option is not specified, the command may list all available images or it may prompt you to specify the product type, depending on your environment configuration.

Q: When should I use the dbaascli cswlib showImages command?

A: Use this command when you want to view the list of Database or Grid Infrastructure images that are available for download or deployment in your Oracle Exadata Database Service environment.

Q: Is there any difference between dbaascli cswlib showImages and dbaascli cswlib listLocal commands?

A: Yes, dbaascli cswlib showImages lists all available images that you can download or manage, while dbaascli cswlib listLocal lists only the images that are already downloaded and available locally on your system.

Q: Can this command be used to view images stored in the cloud?

A: Yes, this command can show images that are available for download from Oracle's repositories, not just those that are stored locally.

Q: What type of images can I expect to see with this command?

A: You can expect to see images related to Oracle Database and Grid Infrastructure, which are essential components for managing and running Oracle databases on Exadata platforms.

Example 7-8 dbaascli cswlib showImages

dbaascli cswlib showImages

Database Management

This section covers comprehensive tasks for managing Oracle Databases. It includes commands for creating (dbaascli database create), deleting (dbaascli database delete), and upgrading databases (dbaascli database upgrade). Other key tasks include adding and deleting instances (dbaascli database addInstance, dbaascli database deleteInstance), managing backups (dbaascli database backup), and handling database recovery (dbaascli database recover). You can also modify database parameters, manage pluggable databases, patch databases, and convert non-CDB databases to PDBs. These commands ensure efficient control over the entire database lifecycle.

dbaascli database addInstance

To add the database instance on the specified node, use the dbaascli database addInstance command.

Prerequisite

  • Run the command as the root user.

Syntax

dbaascli database addInstance --dbname <value> --node <value> [--newNodeSID <value>]
Where:
  • --dbname specifies Oracle Database name
  • --node specifies the node name for the database instance
    • --newNodeSID specifies SID for the instance to add in the new node

Frequently Asked Questions

Q: What is the purpose of the dbaascli database addInstance command?

A: The dbaascli database addInstance command is used to add a new database instance to a specified node in an Oracle Exadata Database Service environment.

Q: What are the prerequisites for running the dbaascli database addInstance command?

A: The command must be run as the root user to have the necessary permissions to add a database instance.

Q: What does the --dbname option represent in this command?

A: The --dbname option specifies the name of the Oracle Database for which you want to add a new instance.

Q: What is the --node option used for in the dbaascli database addInstance command?

A: The --node option specifies the name of the node where the new database instance will be added.

Q: What is the purpose of the --newNodeSID option in this command?

A: The --newNodeSID option allows you to specify the SID (System Identifier) for the new database instance that will be created on the specified node.

Q: Is it mandatory to specify the --newNodeSID option when adding a new instance?

A: The --newNodeSID option is optional. If not provided, Oracle will automatically generate an SID for the new database instance.

Q: When should I use the dbaascli database addInstance command?

A: Use this command when you want to scale your database by adding a new instance to an additional node in a multi-node Oracle Database setup.

Q: Can I add multiple database instances to different nodes using this command?

A: Yes, you can run the command multiple times to add database instances to different nodes by specifying the appropriate --node and --dbname values.

Q: What happens if the node specified in the --node option is not available?

A: The command will fail if the specified node is not available or reachable. Ensure that the node is properly configured and accessible before running the command.

Q: Can this command be used in a Data Guard environment?

A: Yes, you can use the dbaascli database addInstance command in a Data Guard environment to add instances, but it is recommended to follow the necessary Data Guard guidelines for such configurations.

Q: Will this command cause database downtime?

A: Adding an instance to a new node typically does not cause downtime for the existing database instances, but it’s recommended to check your environment for any specific dependencies.

dbaascli database backup

To configure Oracle Database with a backup storage destination, take database backups, query backups, and delete a backup, use the dbaascli database backup command.

Prerequisite

  • Run the command as the root user.

Syntax

dbaascli database backup --dbname <value>
        {
            --list
                {
                    [--backupType <value>]
                    | [--json <value>]
                }
            | --start [--level0] [--level1]
                {
                    [--archival --tag <value>]
                    | [--archivelog]
                }
            | --delete --backupTag <value>
            | --status --uuid <value>
            | --getBackupReport
                {
                    --tag <value>
                    | --latest
                }
                --json <value>
            | --configure
                {
                    --configFile <value>
                    | --enableRTRT
                    | --disableRTRT
                }
            | --getConfig [--configFile <value>]
            | --validate [--untilTime <value>]
            | --showHistory [--all]
        }
Where:
--dbname: Oracle Database name.
--list | --start | --delete | --status | --getBackupReport | --configure | --getConfig
--list: Returns database backup information.
    [--json: Specify the file name for JSON output.]
--start: Begins database backup.
        [--level0 | --level1 | --archival]
        [--level0: Creates a Level-0 (full) backup. ]
        [--level1: Creates a Level-1 (incremental) backup. ]
        [--archival: Creates an Archival full backup. ]
             --tag: Specify backup tag.
--delete: Deletes Archival backup.
            --backupTag <value>
--status
            --uuid <value>
--getBackupReport: Returns backup report.
            --tag: Specify backup tag.
            --latest: Returns latest backup report (all types of database backup).
            --json: Specify the file name for JSON output.
--configure: Configures database for backup.
            --configFile | --enableRTRT | --disableRTRT
            --configFile: Specify database backup configuration file.
            --enableRTRT: Enables Real Time Redo Transport.
            --disableRTRT: Disables Real Time Redo Transport.
--getConfig: Returns database backup configuration.
            [--configFile: Specify the database backup configuration file.]
--validate: Validates that backups are complete and corruption-free.
            [--untilTime: Validates from closest Level-0 (full) backup until time provided. Input format: DD-MON-YYYY HH24:MI:SS.]
--showHistory: Displays the history of backup operations.
            [--all: Displays all backup operations.]
Note

enableRTRT and disableRTRT are applicable only for ZDLRA backup destination on Exadata Database Service on Cloud@Customer.

Frequently Asked Questions

Q: What is the purpose of the dbaascli database backup command?

A: The dbaascli database backup command is used to configure Oracle Database backup storage destinations, take backups, query backups, and delete existing backups.

Q: What are the prerequisites for running the dbaascli database backup command?

A: The command must be run as the root user to have the necessary permissions for backup management.

Q: How do I start a full backup of the Oracle Database using this command?

A: To start a full backup (Level-0), use the following syntax:

dbaascli database backup --dbname <value> --start --level0

Q: How do I perform an incremental backup using the dbaascli database backup command?

A: To perform a Level-1 incremental backup, use this syntax:

dbaascli database backup --dbname <value> --start --level1

Q: What is the difference between Level-0 and Level-1 backups?

A: A Level-0 backup is a full backup of the database, while a Level-1 backup is an incremental backup that only captures changes made since the last Level-0 or Level-1 backup.

Q: Can I take an archival backup using this command?

A: Yes, you can create an archival backup by using the --archival option along with the --start command:

dbaascli database backup --dbname <value> --start --archival --tag <backup_tag>

Q: How do I delete an existing archival backup?

A: To delete an archival backup, use the following syntax:

dbaascli database backup --dbname <value> --delete --backupTag <tag_value>

Q: How can I check the status of a specific backup using the command?

A: You can check the status of a backup by using the --status option with the --uuid parameter, like this:

dbaascli database backup --dbname <value> --status --uuid <backup_uuid>

Q: How do I list all backups for a database?

A: To list all available backups for a specific database, use the --list option:

dbaascli database backup --dbname <value> --list

For JSON output, add the --json option:

dbaascli database backup --dbname <value> --list --json <file_name>

Q: How can I retrieve a backup report?

A: You can get a backup report using the --getBackupReport option, either for a specific tag or for the latest backup:

dbaascli database backup --dbname <value> --getBackupReport --tag <backup_tag> --json <file_name>

Or to retrieve the latest report:

dbaascli database backup --dbname <value> --getBackupReport --latest --json <file_name>

Q: How do I configure database backup settings?

A: Use the --configure option to specify the backup configuration file or to enable/disable Real-Time Redo Transport (RTRT):

dbaascli database backup --dbname <value> --configure --configFile <config_file>

To enable RTRT:

dbaascli database backup --dbname <value> --configure --enableRTRT

Q: How do I check the current backup configuration for my database?

A: To view the current database backup configuration, use the --getConfig option:

dbaascli database backup --dbname <value> --getConfig

Q: What does the --validate option do in the dbaascli database backup command?

A: The --validate option checks if backups are complete and free from corruption. You can specify a time range using the --untilTime option:

dbaascli database backup --dbname <value> --validate --untilTime "DD-MON-YYYY HH24:MI:SS"

Q: How do I view the history of all backup operations for a database?

A: Use the --showHistory option to display the history of all backup operations:

dbaascli database backup --dbname <value> --showHistory

For complete history, including all operations:

dbaascli database backup --dbname <value> --showHistory --all

Q: What are RTRT (Real-Time Redo Transport) options and when should I use them?

A: The RTRT options (--enableRTRT and --disableRTRT) are used to control Real-Time Redo Transport, applicable only for ZDLRA (Zero Data Loss Recovery Appliance) backup destinations in Exadata Cloud@Customer environments. Enable RTRT to ensure real-time redo log shipping.

Example 7-9 Examples

  • To change the archive log retention period follow the below steps:
    dbaascli database backup --getConfig --dbname <dbname>

    This will generate a backup config file .cfg.

    Update bkup_archlog_fra_retention value in this config file.

    Run the configure command:

    dbaascli database backup --configure --dbname <dbname> --configfile <config file generated above>
  • To get backup configuration for a database myTestDB:
    dbaascli database backup --dbName myTestDB --getConfig --configFile /tmp/configfile_1.txt
  • To set backup configuration for a database myTestDB by modifying the config file with configuration details:
    dbaascli database backup --dbName myTestDB --configure --configFile /tmp/configfile_1_modified.txt
  • To take backup of the database myTestDB:
    dbaascli database backup --dbName myTestDB --start
  • To query the status of backup request submitted with uuid 58fdcae0bd1c11eb92bc020017075151:
    dbaascli database backup --dbName myTestDB --status --uuid 58fdcae0bd1c11eb92bc020017075151
  • To enable RTRT for the database myTestDB:
    dbaascli database backup --dbName myTestDB --configure —enableRTRT
dbaascli database bounce

To shut down and restart a specified Exadata Database Service on Cloud@Customer database, use the dbaascli database bounce command.

Prerequisites

Run the command as the oracle user.

Syntax

dbaascli database bounce
[--dbname][--rolling <value>]
Where:
  • --dbname specifies the name of the database
  • --rolling specifies true or false to bounce the database in a rolling manner. Default value is false.

The command performs a database shutdown in immediate mode. The database is then restarted and opened. In Oracle Database 12c or later, all of the PDBs are also opened.

Frequently Asked Questions

Q: What is the purpose of the dbaascli database bounce command?

A: The dbaascli database bounce command is used to shut down and restart an Oracle Database in Exadata Cloud Infrastructure. It supports restarting the database in a rolling manner, ensuring minimal disruption.

Q: What are the prerequisites for running the dbaascli database bounce command?

A: The command must be run as the oracle user, which has the required privileges to shut down and restart the database.

Q: What does the --dbname option specify in this command?

A: The --dbname option specifies the name of the Oracle Database that you want to shut down and restart.

Q: What is the --rolling option used for in the dbaascli database bounce command?

A: The --rolling option specifies whether to bounce (restart) the database in a rolling manner. If set to true, the database instances are restarted one by one, ensuring minimal downtime. The default value is false, which restarts all instances at once.

Q: What does "bouncing the database" mean?

A: Bouncing the database refers to shutting it down and then restarting it. This operation can be used for maintenance, applying changes, or recovering from certain types of issues.

Q: Does the dbaascli database bounce command perform a graceful shutdown?

A: Yes, the command performs a shutdown in "immediate" mode, which closes the database and rolls back uncommitted transactions without waiting for users to disconnect.

Q: Will this command automatically open all PDBs in an Oracle 12c or later database?

A: Yes, if the database is running Oracle Database 12c or later, the command will automatically open all Pluggable Databases (PDBs) after restarting the database.

Q: Can the dbaascli database bounce command be used in a multi-node or RAC (Real Application Clusters) environment?

A: Yes, in a multi-node or RAC environment, you can use the --rolling option to restart the database instances one by one, minimizing downtime.

Q: What happens if I do not specify the --rolling option?

A: If the --rolling option is not specified, or if it's set to false, the command will shut down and restart all database instances at the same time, which may cause a brief downtime.

Q: Is there a default value for the --rolling option in the dbaascli database bounce command?

A: Yes, the default value for the --rolling option is false, meaning the database will be bounced in a non-rolling fashion unless otherwise specified.

Q: How do I restart a database in rolling mode?

A: To restart the database in rolling mode, use the following syntax:

dbaascli database bounce --dbname <value> --rolling true

Q: Is it safe to run the dbaascli database bounce command during active sessions?

A: While the command uses an immediate shutdown, which rolls back uncommitted transactions, it is always recommended to ensure there are no critical or active sessions before bouncing the database.

Q: Can this command be used for specific PDBs in a multitenant database?

A: No, the dbaascli database bounce command operates on the entire database. In Oracle 12c or later, it will bounce the Container Database (CDB) and open all PDBs, but it does not allow for bouncing individual PDBs.

Q: What should I do if the database does not come back online after bouncing it?

A: If the database fails to restart, check the logs for any errors during the shutdown or startup process. Investigating the Oracle alert logs may provide insight into what caused the issue.

Example 7-10 dbaascli database bounce

dbaascli database bounce --dbname dbname
dbaascli database changepassword

To change the password of a specified Oracle Database user, use the dbaascli database changePassword command. When prompted enter the user name for which you want to change the password and then enter the password.

Prerequisites

Run the command as the root or oracle user.

Syntax

dbaascli database changePassword [--dbname <value>] [--user <value>]
{
  [--prepareStandbyBlob <value> [--blobLocation <value>]] | [--standbyBlobFromPrimary <value>]
}
[--resume [--sessionID <value>]]
Where:
  • --dbname specifies the name of the Oracle Database that you want to act on
  • --user specifies the user name whose password change is required
  • --prepareStandbyBlob specifies true to generate a blob file containing the artifacts needed to change the password in a Data Guard environment. Valid values: true|false
  • --blobLocation specifies the custom path where blob file will be generated
  • --standbyBlobFromPrimary specifies the standby blob file, which is prepared from the primary database
  • --resume specifies to resume the previous execution
    • --sessionID specifies to resume a specific session ID

Frequently Asked Questions

Q: What does the dbaascli database changePassword command do?

A: The dbaascli database changePassword command is used to change the password of a specified Oracle Database user. You will be prompted to enter the username and then the new password.

Q: What are the prerequisites for using the dbaascli database changePassword command?

A: You must run the command as either the root or oracle user to change the password for a database user.

Q: How do I specify the database when using this command?

A: Use the --dbname option to specify the name of the Oracle Database you want to act on. For example:

dbaascli database changePassword --dbname <db_name>

Q: How do I specify the user whose password I want to change?

A: Use the --user option to specify the username whose password needs to be changed. For example:

dbaascli database changePassword --user <username>

Q: What is the purpose of the --prepareStandbyBlob option in the dbaascli database changePassword command?

A: The --prepareStandbyBlob option is used in Data Guard environments to generate a blob file that contains the artifacts required for the password change on the standby database. This ensures password synchronization across the Data Guard environment.

Q: What does the --blobLocation option specify?

A: The --blobLocation option allows you to specify a custom path where the standby blob file should be generated. If not provided, the file will be saved in the default location.

Q: How do I use the blob generated from the primary database to change the password on the standby?

A: You can use the --standbyBlobFromPrimary option to specify the blob file prepared from the primary database to apply the password change to the standby database. For example:

dbaascli database changePassword --standbyBlobFromPrimary <blob_file_path>

Q: What is the --resume option used for in this command?

A: The --resume option is used to resume a previously interrupted password change operation. You can specify the session ID if needed using the --sessionID option.

Q: Can I resume a specific session with the dbaascli database changePassword command?

A: Yes, you can use the --resume option along with --sessionID to resume a specific password change session by specifying the session ID.

Q: Is the dbaascli database changePassword command applicable in a Data Guard environment?

A: Yes, it is. The --prepareStandbyBlob option can be used to ensure that password changes are propagated to the standby database in a Data Guard setup.

Q: What happens if I don't provide a --blobLocation when using --prepareStandbyBlob?

A: If no --blobLocation is provided, the blob file containing the password change artifacts will be saved to the default location.

Q: How do I check the status of a resumed session using dbaascli database changePassword?

A: You can specify the session ID using the --sessionID option to resume a specific session. The system will pick up where it left off in changing the password.

Q: Can this command be used for both regular databases and those in a Data Guard environment?

A: Yes, the command works for both regular Oracle Databases and databases in a Data Guard environment. In Data Guard environments, additional options like --prepareStandbyBlob can be used to manage password changes on both primary and standby databases.

Example 7-11 dbaascli database changePassword

dbaascli database changepassword --dbname db19
dbaascli database convertToPDB

To convert the specified non-CDB database to PDB, use the dbaascli database convertToPDB command.

Syntax

dbaascli database convertToPDB --dbname <value> [--cdbName <value>] [--executePrereqs]
        {
            [--copyDatafiles]
            | [--backupPrepared]
        }
        [--targetPDBName <value>] [--waitForCompletion <value>] [--resume [--sessionID <value>]]
Where:
  • --dbname specifies the name of Oracle Database
  • --cdbName specifies the name of the target CDB in which the PDB will be created. If the CDB does not exist, then it will be created in the same Oracle home as the source non-CDB
  • --executePrereqs specifies to run only the pre-conversion checks
  • --copyDatafiles specifies to create a new copy of the data files instead of using the ones from the source database
  • --backupPrepared flag to acknowledge that a proper database backup is in place for the non-CDB prior to performing the conversion to PDB
  • --targetPDBName specifies the name of the PDB that will be created as part of the operation
  • --waitForCompletion specifies false to run the operation in the background. Valid values: true|false
  • --resume specifies to resume the previous execution
    • --sessionID specifies to resume a specific session ID

Frequently Asked Questions

Q: What does the dbaascli database convertToPDB command do?

A: The dbaascli database convertToPDB command converts a specified non-CDB Oracle Database into a Pluggable Database (PDB) within a Container Database (CDB).

Q: How do I specify which database to convert?

A: Use the --dbname option to specify the name of the non-CDB Oracle Database that you want to convert. For example:

dbaascli database convertToPDB --dbname <db_name>

Q: How do I specify the target CDB for the PDB conversion?

A: Use the --cdbName option to specify the name of the target Container Database (CDB) in which the new PDB will be created. If the CDB does not exist, a new one will be created in the same Oracle home as the source non-CDB.

Q: What does the --executePrereqs option do?

A: The --executePrereqs option runs pre-conversion checks to ensure that the database is ready for conversion. No changes will be made to the database during this step.

Q: How do I copy the data files during the conversion?

A: You can use the --copyDatafiles option to create a new copy of the data files rather than using the original files from the source database.

Q: What is the purpose of the --keepSourceDB option?

A: The --keepSourceDB option allows you to preserve the original source non-CDB after the conversion operation is completed. If you do not use this option, the source database will be removed after conversion.

Q: How do I confirm that a backup is prepared before conversion?

A: Use the --backupPrepared flag to acknowledge that you have taken a proper backup of the non-CDB database before performing the conversion. This step is crucial to avoid data loss.

Q: How do I specify a custom name for the new PDB?

A: Use the --targetPDBName option to provide a specific name for the new PDB that will be created as part of the conversion. For example:

dbaascli database convertToPDB --dbname <db_name> --targetPDBName <pdb_name>

Q: Can I run the conversion in the background?

A: Yes, you can use the --waitForCompletion option to specify whether the operation should be run in the background. Use false to run in the background and true to wait for the operation to complete before proceeding. The default is true.

Q: How do I resume a previously interrupted conversion?

A: You can use the --resume option to resume a previously interrupted conversion process. Optionally, you can provide the --sessionID to resume a specific session.

Q: What happens if I don't specify a CDB name?

A: If the --cdbName option is not provided, the system will create the new PDB in the same Oracle home as the source non-CDB database.

Q: Can I continue the conversion after an interruption without knowing the session ID?

A: Yes, using the --resume option without specifying a session ID will resume the last known session. If you want to resume a specific session, you can provide the --sessionID.

Q: What does the --sessionID option do?

A: The --sessionID option is used in conjunction with --resume to specify a particular session to resume, in case there were multiple interrupted sessions.

Q: Is it mandatory to have a backup before converting a non-CDB to a PDB?

A: While the --backupPrepared flag is optional, it is highly recommended to take a backup of the non-CDB before performing the conversion to PDB. This ensures that you can restore the database in case of any issues during the conversion.

Example 7-12 dbaascli database convertToPDB

To run pre-conversion prechecks:
dbaascli database convertToPDB --dbname ndb19 --cdbname cdb19 --backupPrepared --executePrereqs
To run a full conversion with a copy of the data files from the non-CDB:
dbaascli database convertToPDB --dbname tst19 --cdbname cdb19 --copyDatafiles
dbaascli database create

To create Oracle Database, use the dbaascli database create command. When prompted, enter the sys and tde passwords.

Use this command to create Oracle Database version 12.1.0.2 or higher with the release update JAN 2021 or higher. For databases with lower versions, it is recommended to use the OCI Console based API.

Prerequisite

Run the command as the root user.

Syntax

dbaascli database create --dbName {--oracleHome | --oracleHomeName}
[--dbUniqueName <value>]
[--dbSID <value>]
[--createAsCDB <value>]
[--pdbName <value>]
[--pdbAdminUserName <value>]
[--dbCharset <value>]
[--dbNCharset <value>]
[--dbLanguage <value>]
[--dbTerritory <value>]
[--sgaSizeInMB <value>]
[--pgaSizeInMB <value>]
[--datafileDestination <value>]
[--fraDestination <value>]
[--fraSizeInMB <value>]
[--nodeList <value>]
[--tdeConfigMethod <value>]
[--kmsKeyOCID <value>]
{
            [--resume [--sessionID <value>]]
            | [--revert [--sessionID <value>]]
        }
[--executePrereqs]
[--honorNodeNumberForInstance <value>]
[--lockPDBAdminAccount <value>]
[--dbcaTemplateFilePath <value>]
[--waitForCompletion]
Where:
  • --dbname specifies the name of the database
  • --oracleHome specifies the location of the Oracle home
  • --oracleHomeName specifies the name of the Oracle home
  • --dbUniqueName specifies database unique name
  • --dbSID specifies the SID of the database
  • --createAsCDB specifies true or false to create database as CDB or Non-CDB
  • --pdbName specifies the name of the PDB
  • --pdbAdminUserName specify PDB admin user name
  • --dbCharset specifies database character set
  • --dbNCharset specifies database national character set
  • --dbLanguage specifies the database language
  • --dbTerritory specifies the database territory
  • --sgaSizeInMB specifies the sga_target value in megabyte unit
  • --pgaSizeInMB specifies the pga_aggregate_target value in megabyte unit
  • --datafileDestination specifies the ASM disk group name to use for database datafiles
  • --fraDestination specifies ASM disk group name to use for database Fast Recovery Area
  • --fraSizeInMB specifies the Fast Recovery Area size value in megabyte unit
  • --nodeList specifies a comma-delimited list of nodes for the database
  • --tdeConfigMethod specifies TDE configuration method. Valid values: FILE, KMS
  • --kmsKeyOCID specifies KMS key OCID to use for TDE. This is applicable only if KMS is selected for TDE
  • --resume resumes the previous execution
  • --revert rolls back the previous run
  • --sessionID resumes or reverts to a specific session ID.
  • --executePrereqs specifies yes to run only the prereqs for this operation. Valid values: yes or no
  • --honorNodeNumberForInstance specifies true or false to indicate instance name to be suffixed with the cluster node numbers. Default value: true
  • --lockPDBAdminAccount specifies true or false to lock the PDB admin user account. Default value is true
  • --dbcaTemplateFilePath specifies the absolute path of the dbca template name to create the database.
  • --waitForCompletion specifies false to run the operation in the background. Valid values: true or false

Frequently Asked Questions

Q: What does the dbaascli database create command do?

A: The dbaascli database create command is used to create a new Oracle Database instance. It supports creating Oracle Database version 12.1.0.2 or higher with the release update JAN 2021 or higher.

Q: How do I specify the name of the Oracle Database to create?

A: Use the --dbName option to specify the name of the Oracle Database. For example:

dbaascli database create --dbName <db_name>

Q: How can I create a Container Database (CDB)?

A: Use the --createAsCDB option and specify true to create the database as a CDB. For example:

dbaascli database create --dbName <db_name> --createAsCDB true

Q: How do I specify the Oracle Home for the database?

A: You can use either the --oracleHome option to specify the location of the Oracle home or the --oracleHomeName option to specify the name of the Oracle home.

Q: How do I specify a unique database name or SID?

A: Use the --dbUniqueName option to specify a unique name for the database and the --dbSID option to specify the SID of the database.

Q: How do I create a Pluggable Database (PDB) along with a CDB?

A: You can use the --pdbName option to specify the name of the PDB, and the --pdbAdminUserName option to set the PDB admin username. For example:

dbaascli database create --dbName <db_name> --createAsCDB true --pdbName <pdb_name> --pdbAdminUserName <admin_user>

Q: How can I specify the database character set and national character set?

A: Use the --dbCharset option to specify the database character set and the --dbNCharset option to specify the national character set. For example:

dbaascli database create --dbName <db_name> --dbCharset AL32UTF8 --dbNCharset AL16UTF16

Q: How do I set the memory settings (SGA and PGA) for the database?

A: Use the --sgaSizeInMB option to specify the SGA size and the --pgaSizeInMB option to specify the PGA size, both in megabytes.

Q: How do I specify the destination for datafiles and Fast Recovery Area (FRA)?

A: Use the --datafileDestination option to specify the ASM disk group for datafiles, and the --fraDestination option to specify the ASM disk group for the FRA. You can also set the FRA size with the --fraSizeInMB option.

Q: Can I configure Transparent Data Encryption (TDE) during database creation?

A: Yes, you can configure TDE using the --tdeConfigMethod option. Valid values are FILE (for file-based encryption) or KMS (for using Oracle Key Management Service). If using KMS, provide the KMS key OCID with the --kmsKeyOCID option.

Q: How do I create the database on a specific list of nodes?

A: Use the --nodeList option to specify a comma-separated list of nodes where the database should be created.

Q: How can I resume or revert a previous database creation attempt?

A: Use the --resume option to resume the previous execution or the --revert option to roll back the previous run. You can also specify a --sessionID to resume or revert a specific session.

Q: What does the --executePrereqs option do?

A: The --executePrereqs option only runs the prerequisites for the database creation operation, without actually creating the database. Use yes or no to enable or disable this option.

Q: Can I specify a custom DBCA template for the database creation?

A: Yes, use the --dbcaTemplateFilePath option to provide the absolute path of the DBCA template file that should be used to create the database.

Q: Can I run the database creation operation in the background?

A: Yes, you can use the --waitForCompletion option to specify whether the command should wait for the database creation to complete (true) or run the operation in the background (false).

Q: What happens if I don’t specify the --dbUniqueName option?

A: If you don’t specify a unique name for the database using --dbUniqueName, the system will automatically generate one based on the provided --dbName.

Q: Can I lock the PDB admin account during the creation of a CDB?

A: Yes, you can use the --lockPDBAdminAccount option and set it to true to lock the PDB admin account after database creation. By default, this value is set to true.

Example 7-13 dbaascli database create

dbaascli database create --dbName db19 --oracleHomeName myhome19 --dbSid db19sid --nodeList node1,node2 --createAsCDB true
dbaascli database createTemplate

Use this command to create database templates (DBCA templates) that can subsequently be used to create databases.

Run the command as the root or oracle user.

Syntax

Create a new DBCA template from the specified database.

dbaascli database createTemplate --dbname <value>
 {
   --templateLocation <value> | --uploadToObjectStorage --objectStorageLoginUser <value> --objectStorageBucketName <value> [--objectStorageUrl <value>]
 }
 [--templateName <value>] [--rmanParallelism <value>]
Where:
  • --dbname specifies the name of the database
  • --templateLocation specifies the template name
  • --uploadToObjectStorage: specifies to upload the template to Object Storage
    • --objectStorageLoginUser: specifies the Object Storage login user
    • --objectStorageBucketName: specifies the Object Storage bucket name
    • --objectStorageUrl: specifies the Object Storage URL
  • --templateName: specifies the name of the template
  • --rmanParallelism specifies the parallelsim value

Frequently Asked Questions

Q: What is the purpose of the dbaascli database createTemplate command?

A: The dbaascli database createTemplate command is used to create database templates (DBCA templates) from a specified database, which can later be used to create new databases.

Q: How do I specify the name of the database for which I want to create a template?

A: Use the --dbname option to specify the name of the Oracle Database from which the template will be created. For example:

dbaascli database createTemplate --dbname <db_name>

Q: How do I specify where the template should be saved?

A: Use the --templateLocation option to specify the location where the DBCA template will be saved. For example:

dbaascli database createTemplate --dbname <db_name> --templateLocation /path/to/template

Q: Can I upload the template to Object Storage directly?

A: Yes, you can use the --uploadToObjectStorage option to upload the DBCA template to Object Storage. You will need to specify the Object Storage login user and bucket name with the --objectStorageLoginUser and --objectStorageBucketName options, respectively.

Q: How do I specify the Object Storage login details when uploading the template?

A: Use the following options to specify Object Storage details:

--objectStorageLoginUser: Specifies the Object Storage login user.

--objectStorageBucketName: Specifies the Object Storage bucket name.

--objectStorageUrl: (Optional) Specifies the URL of the Object Storage if it is different from the default one.

For example:

dbaascli database createTemplate --dbname <db_name> --uploadToObjectStorage --objectStorageLoginUser <user> --objectStorageBucketName <bucket_name>

Q: How do I specify a custom name for the DBCA template?

A: Use the --templateName option to specify a custom name for the DBCA template. For example:

dbaascli database createTemplate --dbname <db_name> --templateName <template_name>

Q: What is the --rmanParallelism option used for?

A: The --rmanParallelism option specifies the level of parallelism for RMAN operations during the template creation process. For example:

dbaascli database createTemplate --dbname <db_name> --rmanParallelism 4

Q: What happens if I don’t specify the --templateLocation or --uploadToObjectStorage options?

A: If you do not specify a template location using --templateLocation or choose to upload to Object Storage using --uploadToObjectStorage, the command will not know where to store the created template, and it will fail to complete.

Q: Can I use both --templateLocation and --uploadToObjectStorage at the same time?

A: No, you should choose either --templateLocation to save the template locally or --uploadToObjectStorage to upload it to Object Storage, but not both.

Q: Is the --objectStorageUrl option mandatory when uploading the template to Object Storage?

A: No, the --objectStorageUrl option is optional. If not specified, the default Object Storage URL will be used. You only need to specify this if using a custom Object Storage URL.

Q: What user privileges are required to run the dbaascli database createTemplate command?

A: The command must be run either as the root or oracle user.

Q: Can I resume a previously failed template creation process?

A: No, the dbaascli database createTemplate command does not support resuming a failed process. You will need to restart the command from the beginning.

dbaascli database delete

To delete an Oracle Database, use the dbaascli database delete command.

Prerequisite

Run the command as the root user.

Syntax

dbaascli database delete --dbname <value>
[--deleteArchiveLogs <value>]
[--deleteBackups <value>]
[--precheckOnly <value>]
[--waitForCompletion <value>]
[--force]
[--dbSID <value>]
[--resume [--sessionID <value>]]
Where:
  • --dbname specifies the name of the database.
  • --deleteArchiveLogs specifies true or false to indicate deletion of database archive logs.
  • --deleteBackups specifies true or false to indicate deletion of database backups.
  • --precheckOnly specifies yes to run only the prechecks for this operation. Valid values: yes or no.
  • --waitForCompletion specifies false to run the operation in the background. Valid values: true or false.
  • –-force flag to force delete database.
  • --dbSID specify database SID.
  • --resume to resume the previous execution.
  • --sessionID to resume a specific session id.

Frequently Asked Questions

Q: What is the purpose of the dbaascli database delete command?

A: The dbaascli database delete command is used to delete an Oracle Database on Exadata Cloud Infrastructure.

Q: How do I specify the database I want to delete?

A: Use the --dbname option to specify the name of the Oracle Database you want to delete. For example:

dbaascli database delete --dbname <db_name>

Q: How do I delete the archive logs when deleting a database?

A: You can delete the archive logs by setting the --deleteArchiveLogs option to true. For example:

dbaascli database delete --dbname <db_name> --deleteArchiveLogs true

Q: Can I also delete backups when deleting the database?

A: Yes, use the --deleteBackups option and set it to true to delete all associated backups. For example:

dbaascli database delete --dbname <db_name> --deleteBackups true

Q: How can I run only the prechecks for the delete operation without actually deleting the database?

A: You can use the --precheckOnly option and set it to yes to run the prechecks without deleting the database. For example:

dbaascli database delete --dbname <db_name> --precheckOnly yes

Q: How do I force the deletion of a database?

A: To force the deletion of a database, use the --force flag. This bypasses checks and forces the deletion process. For example:

dbaascli database delete --dbname <db_name> --force

Q: How do I run the delete operation in the background?

A: Use the --waitForCompletion option and set it to false to run the operation in the background. For example:

dbaascli database delete --dbname <db_name> --waitForCompletion false

Q: Can I specify the SID of the database I want to delete?

A: Yes, you can specify the SID of the database using the --dbSID option. For example:

dbaascli database delete --dbname <db_name> --dbSID <sid>

Q: How do I resume a previously interrupted delete operation?

A: To resume a previous delete execution, use the --resume option. You can also specify a session ID using the --sessionID option if needed. For example:

dbaascli database delete --dbname <db_name> --resume --sessionID <session_id>

Q: What user privileges are required to run the dbaascli database delete command?

A: The command must be run as the root user.

Q: What does the --precheckOnly option do in the dbaascli database delete command?

A: The --precheckOnly option allows you to run only the prechecks for the delete operation without actually deleting the database. It ensures that all checks pass before proceeding with the actual deletion.

Q: Can I delete a database without waiting for the operation to complete?

A: Yes, by setting the --waitForCompletion option to false, the delete operation will run in the background, and you don't have to wait for it to complete.

Example 7-14 dbaascli database delete

dbaascli database delete --dbname db19
dbaascli database deleteInstance

To delete the database instance on the specified node, use the dbaascli database deleteInstance command.

Prerequisite

  • Run the command as the root user.

Syntax

dbaascli database deleteInstance --dbname <value> --node <value> [--continueOnUnreachableNode]
Where:
  • --dbname specifies Oracle Database name
  • --node specifies the node name for database instance
  • --continueOnUnreachableNode specifies to perform the operation even if the node is unreachable

Frequently Asked Questions

Q: What is the purpose of the dbaascli database deleteInstance command?

A: The dbaascli database deleteInstance command is used to delete a specific Oracle Database instance on a specified node in an Exadata Cloud Infrastructure environment.

Q: How do I specify which Oracle Database instance to delete?

A: You can specify the Oracle Database instance to delete by using the --dbname option to provide the database name and the --node option to provide the node name. For example:

dbaascli database deleteInstance --dbname <db_name> --node <node_name>

Q: Can I delete the instance even if the node is unreachable?

A: Yes, you can use the --continueOnUnreachableNode option to proceed with the deletion, even if the specified node is unreachable. For example:

dbaascli database deleteInstance --dbname <db_name> --node <node_name> --continueOnUnreachableNode

Q: What happens if the node specified is unreachable during the delete instance operation?

A: If the node is unreachable and the --continueOnUnreachableNode option is not used, the operation will fail. If the option is used, the operation will continue even if the node cannot be accessed.

Q: How do I delete a database instance from a specific node?

A: Use the following command to delete a database instance from a specific node:

dbaascli database deleteInstance --dbname <db_name> --node <node_name>

Q: What user privileges are required to run the dbaascli database deleteInstance command?

A: The command must be run as the root user.

Q: Can I delete an instance without specifying the node?

A: No, the --node option is required to specify which node the database instance should be deleted from.

Q: What does the --continueOnUnreachableNode option do?

A: The --continueOnUnreachableNode option allows the operation to proceed even if the specified node cannot be reached, ensuring that the instance deletion continues in scenarios where the node might be down.

Q: Is it possible to delete multiple database instances at once using this command?

A: No, the dbaascli database deleteInstance command is used to delete a single database instance on a specified node at a time. You would need to run the command separately for each instance you want to delete.

Example 7-15 database deleteinstance

database deleteinstance --node test-node
dbaascli database duplicate

To create a database from an active database, use the dbaascli database duplicate command.

Prerequisite

  • Run the command as the root user.

Syntax

dbaascli database duplicate --dbName <value> --sourceDBConnectionString <value>
        {
            --oracleHome <value>
            | --oracleHomeName <value>
        }
[--dbSID <value>] 
[--dbUniqueName <value>] 
[--sgaSizeInMB <value>] 
[--pgaSizeInMB <value>] 
[--datafileDestination <value>] 
[--fraDestination <value>] 
[--fraSizeInMB <value>] 
[--sourceDBWalletLocation <value>] 
[--nodeList <value>]
        {
            [--resume [--sessionID <value>]]
            | [--revert [--sessionID <value>]]
        }
[--rmanParallelism <value>]
[--rmanSectionSizeInGB <value>]
[--tdeConfigMethod <value>]
[--kmsKeyOCID <value>]
[--sourceDBTdeConfigMethod <value>]
[--sourceDBKmsKeyOCID <value>]
[--executePrereqs <value>] 
[--waitForCompletion <value>]
[--skipPDBs <value>]
Where:
  • --dbName specifies Oracle Database name
  • --sourceDBConnectionString specifies source database connection string in the format of <scan_name>:<scan_port>/<database_service_name>
  • --oracleHome specifies Oracle home location
  • --oracleHomeName specifies Oracle home name
  • --dbSID specifies database SID
  • --dbUniqueName specifies database unique name
  • --sgaSizeInMB specifies sga_target value in mega byte unit
  • --pgaSizeInMB specifies pga_aggregate_target value in mega byte unit
  • --datafileDestination specifies ASM disk group name to use for database datafiles
  • --fraDestination specifies ASM disk group name to use for database fast recovery area
  • --fraSizeInMB specifies fast recovery area size value in mega byte unit
  • --sourceDBWalletLocation specifies source database TDE wallet file location. This is required to duplicate database from active database
  • --nodeList specifies a comma-delimited list of nodes for the database
  • --resume specifies to resume the previous execution
    • --sessionID specifies to resume a specific session ID
  • --revert specifies to rollback the previous execution
    • --sessionID specifies to rollback a specific session ID
  • --rmanParallelism specifies parallelsim value
  • --rmanSectionSizeInGB specifies RMAN section size in GB
  • --tdeConfigMethod specifies TDE configuration method. Allowed values are FILE and KMS.
  • --kmsKeyOCID specifies KMS key OCID to use for TDE. This is applicable only if KMS is selected for TDE.
  • --sourceDBTdeConfigMethod specifies source database TDE configuration method. Allowed values are FILE and KMS.
  • --sourceDBKmsKeyOCID specifies source database KMS key OCID to use for TDE. This is applicable only if KMS is selected for TDE.
  • --executePrereqs specifies yes to run only the prereqs for this operation. Valid values: yes|no
  • --waitForCompletion specifies false to run the operation in background. Valid values: true|false
  • --skipPDBs specifies a comma-delimited list of source database PDB names, which needs to be excluded for the duplicate database operation. Example: pdb1,pdb2...

Frequently Asked Questions

Q: What is the purpose of the dbaascli database duplicate command?

A: The dbaascli database duplicate command is used to create a new Oracle Database by duplicating an existing active database.

Q: What are the prerequisites for using the dbaascli database duplicate command?

A: You must run the command as the root user.

Q: How do I specify the source database for duplication?

A: Use the --sourceDBConnectionString option to provide the source database connection string in the format <scan_name>:<scan_port>/<database_service_name>. For example:

--sourceDBConnectionString <scan_name>:<scan_port>/<database_service_name>

Q: How do I specify the location of the Oracle Home for the new database?

A: You can specify the Oracle Home location using the --oracleHome option or the Oracle Home name using the --oracleHomeName option. For example:

--oracleHome <value>

or

--oracleHomeName <value>

Q: What is the purpose of the --sourceDBWalletLocation option?

A: The --sourceDBWalletLocation option specifies the location of the source database TDE wallet file, which is required to duplicate the database from an active source database.

Q: Can I skip duplicating specific PDBs from the source database?

A: Yes, you can use the --skipPDBs option to specify a comma-delimited list of PDB names that should be excluded from the duplicate operation. For example:

--skipPDBs pdb1,pdb2

Q: How do I configure TDE for the new database?

A: Use the --tdeConfigMethod option to specify the TDE configuration method (FILE or KMS). If you choose KMS, you can provide the KMS key OCID using the --kmsKeyOCID option. For example:

--tdeConfigMethod FILE

or

--tdeConfigMethod KMS --kmsKeyOCID <value>

Q: What does the --executePrereqs option do?

A: The --executePrereqs option specifies whether to run only the prerequisite checks for the operation. Valid values are yes to run prereqs only, or no to proceed with the full operation.

Q: How can I resume a previously interrupted duplicate operation?

A: Use the --resume option along with the --sessionID option to resume a previously interrupted duplicate operation. For example:

--resume --sessionID <value>

Q: What does the --waitForCompletion option do?

A: The --waitForCompletion option specifies whether to wait for the operation to complete. Setting this to true waits for completion, while false runs the operation in the background. For example:

--waitForCompletion true

Q: What is the purpose of the --rmanParallelism option?

A: The --rmanParallelism option specifies the parallelism value for RMAN (Recovery Manager) during the duplication process. This can improve the speed of the duplication operation by using multiple parallel processes.

Q: How do I specify the size of the SGA and PGA for the new database?

A: Use the --sgaSizeInMB and --pgaSizeInMB options to specify the sizes of the SGA (System Global Area) and PGA (Program Global Area) in megabytes, respectively. For example:

--sgaSizeInMB <value>

--pgaSizeInMB <value>

Q: What does the --revert option do?

A: The --revert option is used to roll back a previous duplicate operation. You need to provide the --sessionID to specify which session to revert.

Example 7-16 dbaascli database duplicate

dbaascli database duplicate --sourceDBConnectionString test-user-scan.dbaastoolslrgsu.dbaastoolslrgvc.oraclevcn.com:1521/mynew.dbaastoolslrgsu.dbaastoolslrgvc.oraclevcn.com --oracleHome /u02/app/oracle/product/19.0.0.0/dbhome_2 --dbName newdup --sourceDBWalletLocation /var/opt/oracle/dbaas_acfs/tmp/prim_wallet
dbaascli database getDetails

This command shows the detailed information of a given database e.g. dbname, node information, pluggable databases information etc.

Prerequisites

Run the command as the root user or the oracle user

Syntax

dbaascli database getDetails --dbname <value>
Where :
  • --dbname - Oracle database name.

Frequently Asked Questions

Q: What is the purpose of the dbaascli database getDetails command?

A: The dbaascli database getDetails command shows detailed information about a specified Oracle database, including the database name, node information, and pluggable database (PDB) details.

Q: Who can run the dbaascli database getDetails command?

A: The command can be run by the root user or the oracle user.

Q: What does the --dbname option specify in the dbaascli database getDetails command?

A: The --dbname option specifies the name of the Oracle database for which detailed information is being retrieved.

Q: What kind of information does the dbaascli database getDetails command provide?

A: The command provides details such as the database name, node information, and information about pluggable databases (PDBs) associated with the container database.

dbaascli database getPDBs

To view the list of all pluggable databases in a container database, use the dbaascli database getPDBs command.

Run the command as the root or oracleuser.

Syntax

dbaascli database getPDBs --dbname <value>
Where:
  • --dbname specifies the name of the container database

Frequently Asked Questions

Q: What is the purpose of the dbaascli database getPDBs command?

A: The dbaascli database getPDBs command is used to list all the pluggable databases (PDBs) within a specified container database (CDB).

Q: How do I specify the container database for the getPDBs command?

A: You use the --dbname option to specify the name of the container database. For example:

--dbname <value>

Q: Do I need to run the dbaascli database getPDBs command as a specific user?

A: Yes, you must run the command as either the root user or the oracle user.

Q: Can I view PDBs in a non-CDB database using the getPDBs command?

A: No, the getPDBs command is only applicable to container databases (CDBs). You cannot use this command for non-CDB databases.

Q: What is the format of the output from the dbaascli database getPDBs command?

A: The command returns a list of all PDBs within the specified container database. The output typically includes PDB names, statuses, and other relevant details about each pluggable database.

Q: Can this command be used for multiple databases at once?

A: No, the dbaascli database getPDBs command works with a single container database at a time, specified by the --dbname option.

Q: Is it necessary to shut down the database to use the getPDBs command?

A: No, the getPDBs command does not require the database to be shut down. It can be run while the container database is operational.

Example 7-17 dbaascli database getPDBs --dbname

dbaascli database getPDBs --dbname apr_db1
dbaascli database modifyParameters

To modify or reset initialization parameters for an Oracle Database, use the dbaascli database modifyParameters command.

Prerequisite

Run the command as the root user.

Syntax

dbaascli database modifyParameters --dbname <value> 
{
--setParameters <values>[--instance <value>] [--backupPrepared] [--allowBounce]|
--resetParameters <values> [--instance <value>] [--backupPrepared] [--allowBounce]
}
--responseFile
[--backupPrepared]
[--instance]
[--allowBounce]
[--waitForCompletion]
Where:
  • --dbname specifies the name of the database.
  • --setParameters specifies a comma-delimited list of parameters to modify with new values. For example: parameter1=valueA,parameter2=valueB, and so on. For blank values use parameter1=valueA,parameter2='',etc.
  • --resetParameters specifies a comma-delimited list of parameters to be reset to their corresponding default values. For example, parameter1,parameter2, and so on.
  • --instance specifies the name of the instance on which the parameters will be processed. If not specified, then the operation will be performed at the database level.
  • --backupPrepared acknowledges that a proper database backup is in place prior to modifying critical or sensitive parameters.
  • --allowBounce grants permission to bounce the database in order to reflect the changes on applicable static parameters.
  • --waitForCompletion specify false to run the operation in background. Valid values : true|false.]

Frequently Asked Questions

Q: What is the purpose of the dbaascli database modifyParameters command?

A: The dbaascli database modifyParameters command is used to modify or reset Oracle Database initialization parameters.

Q: How do I specify the database for which I want to modify parameters?

A: You must use the --dbname option to specify the name of the database for which you want to modify or reset parameters.

Q: How can I modify database parameters using the modifyParameters command?

A: Use the --setParameters option followed by a comma-delimited list of parameters and their new values. For example:

--setParameters parameter1=valueA,parameter2=valueB

Q: How do I reset parameters to their default values using this command?

A: Use the --resetParameters option followed by a comma-delimited list of parameters to reset to their default values. For example:

--resetParameters parameter1,parameter2

Q: Can I modify parameters using a response file?

A: Yes, you can specify the absolute location of a response JSON file using the --responseFile option. The file should contain the parameters you want to modify.

Q: Is it necessary to take a backup before modifying parameters?

A: While not mandatory for all changes, if you are modifying critical or sensitive parameters, it's recommended to have a backup in place. You can use the --backupPrepared option to acknowledge that a backup has been prepared.

Q: Can I apply changes only to a specific instance in a multi-instance database?

A: Yes, you can specify the instance name using the --instance option. If this option is not used, the changes will be applied at the database level.

Q: Will the database need to be bounced (restarted) after modifying parameters?

A: For some static parameters, a database bounce is required. You can use the --allowBounce option to grant permission for the database to bounce if necessary.

Q: What happens if I don't allow the database to bounce when changing static parameters?

A: If you do not use the --allowBounce option when modifying static parameters, the changes will not take effect until the next manual database restart.

Q: Can I resume modifying parameters if an earlier session was interrupted?

A: No, this command does not support session resumption. You will need to re-run the command from the beginning.

Example 7-18 dbaascli database modifyParameters

dbaascli database modifyParameters --dbname dbname --setParameters "log_archive_dest_state_17=ENABLE"
dbaascli database recover

To recover a database, use the dbaascli database recover command.

Prerequisite

  • Run the command as the root user.
  • Database must have been configured with backup storage destination details where backups are stored.

Syntax

dbaascli database recover --dbname <value>
        {
            --start
                {
                    --untilTime <value>
                    | --untilSCN <value>
                    | --latest
                    | --tag <value>
                }
            | --status --uuid <value>
        }
Where:
--dbname: Oracle Database name.
      --start | --status
--start: Begins database recovery.
      --untilTime | --untilSCN | --latest | --tag
      --untilTime: Recovers database until time. Input format: DD-MON-YYYY HH24:MI:SS.
      --untilSCN: Recovers database until SCN.
      --latest: Recovers database to last known state.
      --tag: Recovers database to archival tag.
--status
      --uuid <value>

Frequently Asked Questions

Q: What is the purpose of the dbaascli database recover command?

A: The dbaascli database recover command is used to recover an Oracle Database from backups stored in a backup storage destination.

Q: How do I specify which database to recover?

A: You can specify the database you want to recover using the --dbname option followed by the database name. For example:

--dbname <database_name>

Q: What are the recovery options available with the dbaascli database recover command?

A: The recovery options are:

--untilTime: Recover the database to a specific time.

--untilSCN: Recover the database to a specific System Change Number (SCN).

--latest: Recover the database to the last known state.

--tag: Recover the database using an archive tag.

Q: How do I recover the database to a specific time?

A: Use the --untilTime option followed by the time in the format DD-MON-YYYY HH24:MI:SS. For example:

--untilTime 05-SEP-2024 15:30:00

Q: How do I recover the database to a specific SCN?

A: Use the --untilSCN option followed by the SCN value. For example:

--untilSCN 123456789

Q: How can I recover the database to the latest known state?

A: Use the --latest option to recover the database to the most recent state possible. For example:

--latest

Q: What is the use of the --tag option in the recovery process?

A: The --tag option allows you to recover the database using an archival tag associated with the backups. For example:

--tag <backup_tag>

Q: How can I check the status of a recovery operation?

A: Use the --status option along with the --uuid value to check the status of an ongoing or previous recovery operation. For example:

--status --uuid <recovery_uuid>

Q: What does the --start option do in the recovery process?

A: The --start option initiates the recovery operation based on the selected recovery method (--untilTime, --untilSCN, --latest, or --tag).

Q: Is there a way to recover the database without specifying a time or SCN?

A: Yes, you can recover the database to its last known state using the --latest option, which doesn't require specifying a time or SCN.

Q: Can I perform a partial recovery?

A: Yes, you can recover the database to a specific point in time or SCN using the --untilTime or --untilSCN options, respectively.

Example 7-19 Examples

  • To recover the database myTestDb to latest:
    dbaascli database recover --dbname myTestDb --start --latest
  • To query the status of recovery request submitted with uuid 2508ea18be2911eb82d0020017075151:
    dbaascli database recover --dbname myTestDb --status --uuid 2508ea18be2911eb82d0020017075151
dbaascli database runDatapatch

To patch an Oracle Database, use the dbaascli database runDatapatch command.

Prerequisites

  • Before performing a runDatapatch operation, ensure that all of the database instances associated with the database are up and running.

  • Run the command as the root user.

Syntax

dbaascli database runDatapatch --dbname
[--resume]
    [--sessionID]
[--skipPdbs | --pdbs]
[--executePrereqs]
[--patchList]
[--skipClosedPdbs]
[--rollback]

Where:

  • --dbname specifies the name of the database
  • --resume resumes the previous run
    • --sessionID specifies to resume a specific session ID
  • --skipPdbs skips running the datapatch on a specified comma-delimited list of PDBs. For example: pdb1,pdb2...
  • --pdbs runs the datapatch only on a specified comma-delimited list of PDBs. For example: pdb1,pdb2...
  • --executePrereqs runs prerequisite checks
  • --patchList applies or rolls back the specified comma-delimited list of patches. For example: patch1,patch2...
  • --skipClosedPdbs skips running the datapatch on closed PDBs
  • --rollback rolls back the patches applied

Frequently Asked Questions

Q: What is the purpose of the dbaascli database runDatapatch command?

A: The dbaascli database runDatapatch command is used to apply patches to an Oracle Database.

Q: What must be ensured before running the dbaascli database runDatapatch command?

A: Before running the command, ensure that all instances of the database are up and running.

Q: How do I specify which database to patch?

A: Use the --dbname option followed by the name of the database. For example:

--dbname myDatabase

Q: How do I resume a previously interrupted runDatapatch operation?

A: Use the --resume option to resume the previous run or the --sessionID option to specify a specific session ID. For example:

--resume

--sessionID 12345

Q: How can I skip certain PDBs when running the patch?

A: Use the --skipPdbs option followed by a comma-delimited list of PDB names to skip. For example:

--skipPdbs pdb1,pdb2

Q: How can I run the patch only on certain PDBs?

A: Use the --pdbs option followed by a comma-delimited list of PDB names to include. For example:

--pdbs pdb1,pdb2

Q: How do I apply or roll back a specific set of patches?

A: Use the --patchList option followed by a comma-delimited list of patch names to apply or roll back. For example:

--patchList patch1,patch2

Q: What does the --rollback option do?

A: The --rollback option rolls back the patches that were applied during the patching operation.

Q: What happens if some PDBs are closed during the patching operation?

A: If some PDBs are closed, you can use the --skipClosedPdbs option to skip patching those closed PDBs.

Q: Can I run prerequisite checks before applying patches?

A: Yes, use the --executePrereqs option to run prerequisite checks before applying the patch.

Q: How do I find out which session ID to resume a patch?

A: After a runDatapatch operation, the session ID is typically logged. Use the --sessionID option to specify that ID when resuming a patch. For example:

--sessionID 67890

dbaascli database runDatapatch --dbname db19
dbaascli database start

To start an Oracle Database, use the dbaascli database start command.

Prerequisites

Run the command as the root user.

Syntax

dbaascli database start
[--dbname]
[--mode]
Where:
  • --dbname specifies the name of the database
  • --mode specifies mount or nomount to start database in the corresponding mode

The command starts and opens the database. In Oracle Database 12c or later, all of the PDBs are also opened.

Frequently Asked Questions

Q: What is the purpose of the dbaascli database start command?

A: The dbaascli database start command is used to start an Oracle Database.

Q: What must be done before running the dbaascli database start command?

A: The command must be run as the root user.

Q: How do I specify the database I want to start?

A: Use the --dbname option followed by the name of the database. For example:

--dbname myDatabase

Q: What are the possible modes in which I can start the database?

A: You can start the database in mount or nomount mode using the --mode option. For example:

--mode mount

Q: What is the default mode if I don't specify one?

A: If you don't specify a mode, the database will start in the default open mode.

Q: Will this command open all PDBs in Oracle Database 12c or later?

A: Yes, when starting the database in Oracle Database 12c or later, all pluggable databases (PDBs) will also be opened.

Q: How can I start a database in nomount mode?

A: Use the --mode option and set it to nomount. For example:

--mode nomount

Q: How can I start a database in mount mode?

A: Use the --mode option and set it to mount. For example:

--mode mount

Q: Is it mandatory to specify a database name when running the dbaascli database start command?

A: Yes, it is recommended to specify the database name using the --dbname option to ensure the correct database is started.

Example 7-20 dbaascli database start

dbaascli database start --dbname dbname --mode mount
dbaascli database stop

To stop an Oracle Database, use the dbaascli database stop command.

Prerequisites

Run the command as the root user.

Syntax

dbaascli database stop
[-–dbname <value>]
[--mode <value>]
Where:
  • --dbname specifies the name of the database that you want to stop
  • --mode specifies the mode of the database. Valid values: abort, immediate, normal, transactional

The command performs a database shutdown in immediate mode. No new connections or new transactions are permitted. Active transactions are rolled back, and all connected users are disconnected.

Frequently Asked Questions

Q: What is the purpose of the dbaascli database stop command?

A: The dbaascli database stop command is used to stop an Oracle Database.

Q: What are the prerequisites for using the dbaascli database stop command?

A: You must run the command as the root user, and you must connect to an Exadata Cloud@Customer virtual machine using SSH.

Q: How do I specify which database to stop?

A: You can specify the database by using the --dbname option followed by the name of the database. For example:

--dbname myDatabase

Q: What are the valid shutdown modes for the dbaascli database stop command?

A: The valid shutdown modes are:

abort

immediate

normal

transactional

Q: What is the default shutdown mode if no mode is specified?

A: If no mode is specified, the database will be shut down in immediate mode by default.

Q: What happens in immediate shutdown mode?

A: In immediate mode, no new connections or transactions are permitted, active transactions are rolled back, and all connected users are disconnected.

Q: How can I stop the database in abort mode?

A: To stop the database in abort mode, use the --mode option with abort. For example:

--mode abort

Q: What does normal mode do when stopping the database?

A: In normal mode, the database allows current user sessions to complete and then stops without affecting active transactions.

Q: What is transactional mode used for in the dbaascli database stop command?

A: In transactional mode, the database stops only after all active transactions are completed, but no new transactions are allowed.

Q: Is it mandatory to specify the shutdown mode in the dbaascli database stop command?

A: No, specifying a shutdown mode is optional. If not provided, the default immediate mode will be used.

Example 7-21 dbaascli database stop

dbaascli database stop --dbname db19
dbaascli database upgrade

To upgrade an Oracle Database, use the dbaascli database upgrade command.

Prerequisite

Run the command as the root user.

Syntax

dbaascli database upgrade --dbname <value> 
{--targetHome <value> | --targetHomeName <value>}
{ [--executePrereqs | --postUpgrade | --rollback]}
{[--standBy | --allStandbyPrepared]}
{[--upgradeOptions <value>]  | [--standBy]}
[--removeGRP]
[--increaseCompatibleParameter]
[--resume [--sessionID <value>]]
[--waitForCompletion <value>]
Where:
  • --dbname (mandatory) specifies the name of the database.
  • --targetHome specifies the target Oracle home location
  • --targetHomeName specifies the name of the target Oracle Database home
  • --standBy use this option to upgrade standby databases in Data Guard configurations
  • --allStandbyPrepared required for Data Guard configured primary databases. Flags to acknowledge that all the required operations are performed on the standby databases prior to upgrading primary database
  • --removeGRP automatically removes the Guaranteed Restore Point (GRP) backup only if the database upgrade was successful
  • --increaseCompatibleParameter automatically increases the compatible parameter as part of the database upgrade. The parameter will get increased only if the database upgrade was successful
  • --executePrereqs runs only the preupgrade checks
  • --postUpgrade use this option if postupgrade fails and needs to rerun the postupgrade steps
  • --rollback reverts an Oracle Database to its original Oracle home
  • --upgradeOptions use this option to pass DBUA-specific arguments to perform the Oracle Database upgrade. Refer to the corresponding Oracle documentation for the supported arguments and options.

    --standby

  • --resume to resume the previous execution
  • --sessionID to resume a specific session id.
  • --waitForCompletion specify false to run the operation in background. Valid values : true|false.

Frequently Asked Questions

Q: What is the purpose of the dbaascli database upgrade command?

A: The dbaascli database upgrade command is used to upgrade an Oracle Database to a new version.

Q: What are the prerequisites for using the dbaascli database upgrade command?

A: You must run the command as the root user and connect to an Exadata Cloud@Customer virtual machine using SSH.

Q: How do I specify the database that needs to be upgraded?

A: Use the --dbname option followed by the name of the database. For example:

--dbname myDatabase

Q: How can I specify the target Oracle home for the upgrade?

A: You can specify the target Oracle home location with the --targetHome option or the name of the target Oracle Database home with the --targetHomeName option.

Q: What does the --standBy option do?

A: The --standBy option is used to upgrade standby databases in Data Guard configurations.

Q: What is the purpose of the --allStandbyPrepared flag?

A: The --allStandbyPrepared flag acknowledges that all required operations on standby databases have been performed before upgrading the primary database in a Data Guard configuration.

Q: What does the --removeGRP option do?

A: The --removeGRP option automatically removes the Guaranteed Restore Point (GRP) backup if the database upgrade is successful.

Q: When should I use the --increaseCompatibleParameter option?

A: Use the --increaseCompatibleParameter option to automatically increase the compatible parameter during the database upgrade, provided the upgrade is successful.

Q: What does the --executePrereqs option do?

A: The --executePrereqs option runs only the pre-upgrade checks to ensure that the database is ready for the upgrade.

Q: How do I handle a failed post-upgrade step?

A: Use the --postUpgrade option to rerun the post-upgrade steps if the initial post-upgrade attempt fails.

Q: What is the purpose of the --revert option?

A: The --revert option reverts the Oracle Database to its original Oracle home, undoing the upgrade.

Q: How can I pass additional arguments specific to DBUA for the upgrade?

A: Use the --upgradeOptions option to pass DBUA-specific arguments for the Oracle Database upgrade. Refer to the Oracle documentation for supported arguments and options.

Q: Is it mandatory to specify the target Oracle home for the upgrade?

A: Yes, you must specify either the --targetHome or --targetHomeName to indicate the target Oracle home for the upgrade.

Q: What should I do if I need to perform a pre-upgrade check but not proceed with the upgrade?

A: Use the --executePrereqs option to perform only the pre-upgrade checks without proceeding with the actual upgrade.

Example 7-22 dbaascli database upgrade pre-upgrade requisite checks

dbaascli database upgrade --dbbname dbname --targetHome Target Oracle home location --executePrereqs

Data Guard Management

This section focuses on managing Oracle Data Guard configurations and operations. It includes commands like dbaascli dataguard prepareStandbyBlob to generate a blob file for setting up a standby site, and dbaascli dataguard updateDGConfigAttributes to update Data Guard automation attributes across all cluster nodes. These commands streamline the setup and maintenance of Data Guard environments for high availability and disaster recovery.

dbaascli dataguard prepareStandbyBlob

To generate a blob file containing various files that are required on the standby site in case of a dataguard environment, use the dbaascli dataguard prepareStandbyBlob command.

Run the command as the root or oracle user.

Syntax

dbaascli dataguard prepareStandbyBlob --dbname <value> --blobLocation <value>
Where:
  • --dbname specifies the Oracle Database name
  • --blobLocation specifies the custom directory location where the standby blob file will be generated in a Data Guard environment

Frequently Asked Questions

Q: What is the purpose of the dbaascli dataguard prepareStandbyBlob command?

A: The dbaascli dataguard prepareStandbyBlob command is used to generate a blob file containing various files required on the standby site in a Data Guard environment.

Q: What are the prerequisites for running the dbaascli dataguard prepareStandbyBlob command?

A: The command should be run as the root or oracle user.

Q: How do I specify the name of the Oracle Database for which I want to prepare the standby blob?

A: Use the --dbname option followed by the name of the Oracle Database. For example:

--dbname myDatabase

Q: How do I specify the location where the standby blob file will be generated?

A: Use the --blobLocation option to specify the custom directory path where the standby blob file will be generated. For example:

--blobLocation /path/to/standby_blob

Q: What does the --dbname option do in the command?

A: The --dbname option specifies the name of the Oracle Database for which the standby blob file is being prepared.

Q: What is the purpose of the --blobLocation option?

A: The --blobLocation option defines the custom directory path where the standby blob file will be created.

Q: Can I run the dbaascli dataguard prepareStandbyBlob command as a user other than root or oracle?

A: No, the command must be run as either the root or oracle user.

Q: Is it possible to use a relative path for the --blobLocation option?

A: It is recommended to use an absolute path for the --blobLocation option to ensure the standby blob file is created in the correct directory.

Q: What should I do if I want to change the location where the standby blob file is generated?

A: Modify the --blobLocation option to specify a new directory path for the standby blob file.

Q: Do I need to perform any additional steps after generating the standby blob file?

A: Yes, after generating the standby blob file, you need to transfer it to the standby site and use it for the Data Guard configuration.

dbaascli dataguard updateDGConfigAttributes

To update Data Guard automation attributes across all the cluster nodes, use the dbaascli dataguard updateDGConfigAttributes command.

Run the command as the root or oracleuser.

Syntax

dbaascli dataguard updateDGConfigAttributes --attributes <value>
Where:
  • --attributes contains the Data Guard automation attributes that are to be modified. Accepts comma-delimited values in the format <attribute=value>. Attributes must be predefined in the Data Guard configuration file.

Frequently Asked Questions

Q: What is the purpose of the dbaascli dataguard updateDGConfigAttributes command?

A: The dbaascli dataguard updateDGConfigAttributes command is used to update Data Guard automation attributes across all cluster nodes.

Q: What are the prerequisites for running the dbaascli dataguard updateDGConfigAttributes command?

A: The command must be run as either the root or oracle user.

Q: How do I specify the attributes that I want to update using this command?

A: Use the --attributes option followed by the attributes to be modified. The attributes should be in a comma-delimited format, such as attribute=value. For example:

--attributes attribute1=value1,attribute2=value2

Q: What format should the --attributes option values be in?

A: The --attributes option values should be in a comma-delimited format with each attribute specified as attribute=value.

Q: Can I specify multiple attributes in the --attributes option?

A: Yes, you can specify multiple attributes by separating them with commas. For example:

--attributes attribute1=value1,attribute2=value2

Q: What happens if I provide an attribute that is not predefined in the Data Guard configuration file?

A: If you provide an attribute that is not predefined, the command may fail or ignore the unrecognized attribute. Ensure that all attributes are predefined in the Data Guard configuration file.

Q: Do I need to restart any services after updating Data Guard automation attributes?

A: In most cases, you do not need to restart services after updating attributes. However, check the specific attributes and their impact to determine if a restart is required.

Q: How can I verify if the Data Guard attributes have been successfully updated?

A: After running the command, you can verify the updated attributes by checking the Data Guard configuration or using appropriate verification commands/tools specific to your setup.

Q: What should I do if the command fails to update the attributes?

A: Check the error messages for details on what went wrong. Ensure that you have specified the correct attributes and that they are predefined in the Data Guard configuration file. Verify user permissions and command syntax.

Q: Is it possible to update attributes for only specific nodes using this command?

A: No, the dbaascli dataguard updateDGConfigAttributes command updates attributes across all cluster nodes. If you need to update attributes for specific nodes, you may need to use different methods or commands.

Database Home Management

This section provides tools for managing Oracle Database homes. It includes commands such as dbaascli dbhome create to create a new Oracle Database home and dbaascli dbHome delete to remove an existing one. You can also view detailed information about a specific Oracle home with dbaascli dbHome getDetails and check which databases are running from a given Oracle home using dbaascli dbhome getDatabases. These commands ensure efficient management of database environments.

dbaascli dbhome create

To create an Oracle Database home of desired version, use the dbaascli dbhome create command.

Prerequisite

Run the command as the root user.

Syntax

dbaascli dbhome create --version <value>
[--oracleHome <value>]
[--oracleHomeName <value>]
[--enableUnifiedAuditing <value>] 
[--imageTag <value>]
[--ImageLocation <value>
Where:
  • --version specifies the version of Oracle Home specified as five numeric segments separated by periods, for example, 19.12.0.0.0
  • --oracleHome specifies the location of Oracle home
  • --oracleHomeName specifies user-defined Oracle home name. If not provided, then the default name will be used
  • --enableUnifiedAuditing specifies true or false to enable or disable unified auditing link option in Oracle home
  • --imageTag specifies Oracle home image tag
  • --imageLocation - path of the image to be used.
  • --waitForCompletion specifies false to run the operation in background. Valid values: true or false.

Frequently Asked Questions

Q: What is the purpose of the dbaascli dbhome create command?

A: The dbaascli dbhome create command is used to create a new Oracle Database home with the desired version.

Q: What are the prerequisites for running the dbaascli dbhome create command?

A: The command must be run as the root user.

Q: How do I specify the Oracle Database version while creating a new Oracle Home?

A: Use the --version option followed by the Oracle Database version in the format of five numeric segments separated by periods, such as 19.11.0.0.0.

Q: What does the --oracleHome option specify?

A: The --oracleHome option specifies the location where you want to install the Oracle Home. If not provided, the default location will be used.

Q: Can I assign a custom name to the new Oracle Home?

A: Yes, you can use the --oracleHomeName option to specify a user-defined name for the Oracle Home. If not specified, a default name will be used.

Q: How do I enable or disable Unified Auditing in the new Oracle Home?

A: Use the --enableUnifiedAuditing option and specify true to enable or false to disable Unified Auditing for the Oracle Home.

Q: What does the --imageTag option do?

A: The --imageTag option specifies the Oracle Home image tag, which can be used in cases where the image tag differs from the version.

Q: What is an example of using the dbaascli dbhome create command with version and image tag?

A: An example of the command with version and image tag is:

dbaascli dbhome create --version 19.8.0.0.0 --imageTag 19.8.0.0.0

This creates an Oracle Home for version 19.8.0.0.0 with the corresponding image tag.

Q: What happens if I don't provide the --oracleHome or --oracleHomeName options?

A: If --oracleHome is not provided, the Oracle Home will be installed in the default location. If --oracleHomeName is not specified, a default name will be assigned to the Oracle Home.

Q: How can I verify if the Oracle Home creation was successful?

A: After running the command, check the output logs for any success messages or errors. You can also verify the Oracle Home by navigating to the specified location or using Oracle tools like orainstRoot.sh.

Q: Is it possible to create multiple Oracle Homes with different versions on the same system?

A: Yes, you can create multiple Oracle Homes with different versions by specifying different values for the --version and --oracleHomeName options.

Q: What should I do if the Oracle Home creation fails?

A: Check the output logs for detailed error messages. Verify that you have the correct version format, required permissions, and sufficient disk space. Correct any issues and try running the command again.

Example 7-23 dbaascli dbhome create

dbaascli dbhome create --version 19.11.0.0.0

Alternatively, dbaascli dbhome create --version 19.8.0.0.0.0 --imageTag 19.8.0.0.0 for cases where image tags are different from version.

dbaascli dbHome delete

To delete a given Oracle Database home, use the dbaascli dbHome delete command.

Prerequisite

Run the command as the root user.

Syntax

dbaascli dbHome delete 
{ --oracleHome <value> 
| --oracleHomeName <value> } [--resume [--sessionID <value>]] 
Where:
  • --oracleHome specifies the location of the Oracle home
  • --oracleHomeName specifies the name of the Oracle home
  • --resume resumes the previous execution
    • --sessionID specifies to resume a specific session ID

Frequently Asked Questions

Q: What is the purpose of the dbaascli dbHome delete command?

A: The dbaascli dbHome delete command is used to delete a specified Oracle Database home from the system.

Q: What are the prerequisites for running the dbaascli dbHome delete command?

A: The command must be run as the root user.

Q: How do I specify the Oracle Home to be deleted?

A: You can specify the Oracle Home to be deleted using one of the following options:

--oracleHome <value> to provide the absolute path of the Oracle Home location.

--oracleHomeName <value> to provide the name of the Oracle Home.

Q: What is the difference between --oracleHome and --oracleHomeName options?

A:

--oracleHome specifies the physical location or path of the Oracle Home to be deleted.

--oracleHomeName specifies the user-defined name of the Oracle Home to be deleted.

Q: How can I resume a previously interrupted deletion process?

A: You can use the --resume option to resume a previous deletion process. If you know the specific session ID of the process, you can include it with the --sessionID option.

Q: What is the --sessionID option used for in the dbaascli dbHome delete command?

A: The --sessionID option is used to resume a specific session that was previously interrupted or failed during the deletion process.

Q: What happens if I do not provide the --resume or --sessionID options?

A: If the --resume or --sessionID options are not provided, the command will initiate a new deletion process instead of resuming an interrupted one.

Q: Is there any way to confirm the deletion of the Oracle Home after running the command?

A: You can verify the deletion by checking the output logs for success messages and ensuring the Oracle Home directory is no longer present at the specified location.

Q: Can I delete an Oracle Home that is currently in use by a running database?

A: No, the Oracle Home should not be in use by any running databases or services during the deletion process. Make sure to stop any related databases before running the delete command.

Q: What should I do if the dbaascli dbHome delete command fails?

A: Review the output logs for any error messages. Ensure that the Oracle Home is not in use, verify the correct Oracle Home location or name, and confirm that you have the necessary permissions. After resolving any issues, rerun the command or use the --resume option if needed.

Q: Can I delete multiple Oracle Homes at once using the dbaascli dbHome delete command?

A: No, the command only allows you to delete one Oracle Home at a time by specifying either the --oracleHome or --oracleHomeName option.

Q: What is an example of deleting an Oracle Home by its name?

A: Here is an example of deleting an Oracle Home by name:

dbaascli dbHome delete --oracleHomeName myOracleHome

This command deletes the Oracle Home with the name myOracleHome.

Q: What is an example of deleting an Oracle Home by its location?

A: Here is an example of deleting an Oracle Home by specifying its location:

dbaascli dbHome delete --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1

This command deletes the Oracle Home located at /u01/app/oracle/product/19.0.0/dbhome_1.

Q: Can I cancel the deletion process once it has started?

A: No, once the deletion process has started, it cannot be canceled. Ensure that the Oracle Home is ready for deletion before executing the command.

dbaascli dbhome getDatabases

To view information about all Oracle Databases running from a given database Oracle home, use the dbaascli dbHome getDatabases command. Specify either the Oracle home location or Oracle home name.

Run the command as the root user.

Syntax

dbaascli dbHome getDatabases
{ --oracleHomeName value | --oracleHome value }
Where:
  • --oracleHomeName specifies user-defined Oracle home name
  • --oracleHome specifies the location (path) of Oracle home

Frequently Asked Questions

Q: What is the purpose of the dbaascli dbHome getDatabases command?

A: The dbaascli dbHome getDatabases command is used to view information about all Oracle Databases running from a specified Oracle Database home.

Q: How can I specify the Oracle Database home to check?

A: You can specify the Oracle Database home by using one of the following options:

--oracleHomeName <value> to specify the user-defined name of the Oracle home.

--oracleHome <value> to specify the full location (path) of the Oracle home.

Q: What is the difference between --oracleHomeName and --oracleHome options?

A:

--oracleHomeName refers to a user-defined name for the Oracle home.

--oracleHome refers to the physical location (or directory path) of the Oracle home on the system.

Q: How do I run the dbaascli dbHome getDatabases command?

A: To run the command, use the following syntax:

dbaascli dbHome getDatabases --oracleHomeName <value>

or

dbaascli dbHome getDatabases --oracleHome <value>

Ensure to run the command as the root user.

Q: Can I specify both the Oracle home name and Oracle home location in the same command?

A: No, you can only specify either --oracleHomeName or --oracleHome in a single command execution. Choose one option based on how you identify the Oracle home.

Q: What kind of information does the dbaascli dbHome getDatabases command return?

A: The command returns information about all Oracle Databases running from the specified Oracle home. This includes details such as database names and statuses.

Q: What is an example of using dbaascli dbHome getDatabases with the Oracle home location?

A: Here is an example of using the command with the Oracle home location:

dbaascli dbHome getDatabases --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1

This command retrieves the list of databases running from the Oracle home located at /u01/app/oracle/product/19.0.0/dbhome_1.

Q: What is an example of using dbaascli dbHome getDatabases with the Oracle home name?

A: Here is an example of using the command with the Oracle home name:

dbaascli dbHome getDatabases --oracleHomeName myOracleHome

This command retrieves the list of databases running from the Oracle home named myOracleHome.

Q: Do I need any special permissions to run this command?

A: Yes, you must run the command as the root user to view the information about Oracle Databases running from a specified Oracle home.

Q: What should I check if the dbaascli dbHome getDatabases command returns no databases?

A: Ensure that you have specified the correct Oracle home name or location and that there are databases running from that Oracle home. Additionally, confirm that the Oracle home is properly configured and active.

Q: Can I use the dbaascli dbHome getDatabases command on multiple Oracle homes at once?

A: No, the command works on a single Oracle home at a time. You must run the command separately for each Oracle home you want to query.

Q: Is there a way to verify that the Oracle home specified in the command is correct?

A: You can verify the Oracle home by checking the directory structure or the configuration details in your system to ensure the path or name provided matches the actual Oracle home.

Q: What happens if I run the command without specifying an Oracle home or Oracle home name?

A: The command requires either the --oracleHome or --oracleHomeName option to be specified. If neither option is provided, the command will fail to execute.

Q: Can this command retrieve databases that are currently stopped?

A: Yes, the command will list all databases associated with the specified Oracle home, regardless of whether they are currently running or stopped.

Example 7-24 dbaascli dbHome getDatabases --oracleHome

dbaascli dbHome getDatabases --oracleHome /u02/app/mar_home/
dbaascli dbHome getDetails

To view information about a specific Oracle home, use the dbaascli dbHome getDetails command. Specify either the Oracle home location or Oracle home name.

Prerequisite

Run the command as the root user.

Syntax

dbaascli dbHome getDetails
{ --oracleHomeName value | --oracleHome value }
Where:
  • --oracleHomeName specifies user-defined Oracle home name
  • --oracleHome specifies the location of Oracle home

Frequently Asked Questions

Q: What is the purpose of the dbaascli dbHome getDetails command?

A: The dbaascli dbHome getDetails command is used to view detailed information about a specific Oracle home on the system.

Q: How do I specify the Oracle home I want to get details about?

A: You can specify the Oracle home using one of the following options:

--oracleHomeName <value> to specify the user-defined name of the Oracle home.

--oracleHome <value> to specify the full location (path) of the Oracle home.

Q: What is the difference between --oracleHomeName and --oracleHome?

A:

--oracleHomeName is the user-defined name for an Oracle home.

--oracleHome refers to the full directory path where the Oracle home is located.

Q: How do I run the dbaascli dbHome getDetails command?

A: To run the command, use the following syntax:

dbaascli dbHome getDetails --oracleHomeName <value>

or

dbaascli dbHome getDetails --oracleHome <value>

Make sure to run the command as the root user.

Q: Can I specify both --oracleHomeName and --oracleHome in the same command?

A: No, you can only use one option per command execution. You must either specify the Oracle home name or the Oracle home location, not both.

Q: What information does the dbaascli dbHome getDetails command return?

A: The command provides detailed information about the specified Oracle home, such as its version, status, and any other configuration details associated with the Oracle home.

Q: What is an example of using the dbaascli dbHome getDetails command with an Oracle home location?

A: Here is an example:

dbaascli dbHome getDetails --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1

This command retrieves detailed information about the Oracle home located at /u01/app/oracle/product/19.0.0/dbhome_1.

Q: What is an example of using the dbaascli dbHome getDetails command with an Oracle home name?

A: Here is an example:

dbaascli dbHome getDetails --oracleHomeName myOracleHome

This command retrieves detailed information about the Oracle home named myOracleHome.

Q: Do I need any special permissions to run this command?

A: Yes, you must run the command as the root user to view details about the Oracle home.

Q: What should I do if the dbaascli dbHome getDetails command returns no information?

A: Ensure that you have correctly specified the Oracle home name or location, and that the Oracle home is properly configured and exists on the system.

Q: Can I use the dbaascli dbHome getDetails command on multiple Oracle homes simultaneously?

A: No, the command only works on a single Oracle home at a time. You must run the command separately for each Oracle home.

Q: Is it possible to verify the Oracle home name before running the command?

A: Yes, you can verify the Oracle home name by checking your system’s configuration files or by listing all Oracle homes available on your system.

Q: What happens if I do not specify an Oracle home name or location in the command?

A: The command requires either the --oracleHome or --oracleHomeName option to be specified. If neither is provided, the command will fail to execute.

Q: Can I retrieve information about Oracle homes that are currently not in use?

A: Yes, the dbaascli dbHome getDetails command provides details about Oracle homes regardless of whether they are in use or idle.

Q: What should I check if the command returns an error?

A: Ensure that the Oracle home name or location is correct, the Oracle home exists, and that you are running the command as the root user. Double-check for typos or incorrect paths.

Example 7-25 dbaascli dbHome getDetails - using Oracle home location

dbaascli dbHome getDetails --oracleHome /u02/app/home_db19c/

Example 7-26 dbaascli dbHome getDetails - using Oracle home name

dbaascli dbHome getDetails --oracleHomeName home_db19c

Diagnostics and Health Checks

This section covers tools for maintaining the health and diagnosing issues in Oracle Database environments. Commands like dbaascli diag collect are used to gather diagnostic data, while dbaascli diag healthCheck allows you to run health checks to identify potential issues. These tools help ensure the system's stability and performance by proactively monitoring and addressing concerns.

dbaascli diag collect

To collect diagnostics, use the dbaascli diag collect command.

Prerequisite

Run the command as the root user.

Syntax

dbaascli diag collect [--components <value>] [--startTime <value>] [--endTime <value>] [--nodes <value>] [--dbNames <value>]
        {
            [--objectStoreBucketUri <value>]
            | [--destLocation <value>]
        }
        [--waitForCompletion <value>]
Where:
  • --components specifies a list of components for log collection.

    Valid values:

    • db
    • gi
    • os
    • dbaastools
    • all
  • --startTime specifies the start time for log collection. Valid date and time format: YYYY-MM-DDTHH24:MM:SS
  • --endTime specifies the end time for log collection. Valid date and time format: YYYY-MM-DDTHH24:MM:SS
  • --nodes specifies a comma-delimited list of nodes to collect logs
  • --dbNames specifies the database name for which to collect logs. You can specify only one database name.
  • --objectStoreBucketURI specifies an Object Storage service pre-authenticated request (PAR) URL used to upload collected logs. Logs are collected from Guest VM. For more information, see Using Pre-Authenticated Requests.
  • --destLocation specifies the location on Guest VM to collect logs. Default: /var/opt/oracle/dbaas_acfs
  • --waitForCompletion Values: true|false. Default true. Specify false to run in the background.

Frequently Asked Questions

Q: What is the purpose of the dbaascli diag collect command?

A: The dbaascli diag collect command is used to collect diagnostic logs for Oracle Database and associated components such as OS, Grid Infrastructure (GI), and DBaaS tools.

Q: How do I specify which components to collect diagnostics for?

A: You can specify the components using the --components option. Valid values are:

db (for database logs)

gi (for Grid Infrastructure logs)

os (for operating system logs)

dbaastools (for DBaaS tools logs)

all (for collecting logs for all components)

Q: How can I collect logs for a specific time range?

A: Use the following options to specify a time range:

--startTime <value> to set the start time for log collection.

--endTime <value> to set the end time for log collection.

The time must be in the format: YYYY-MM-DDTHH24:MM:SS.

Q: What format should the start and end times be in?

A: Both --startTime and --endTime should be in the format YYYY-MM-DDTHH24:MM:SS. For example, 2024-09-01T15:30:00.

Q: How do I specify which nodes to collect diagnostics from?

A: You can use the --nodes option to specify a comma-delimited list of nodes. For example:

--nodes node1,node2

Q: How do I collect logs for a specific database?

A: Use the --dbNames option to specify the name of the database for which you want to collect logs. Only one database name can be specified at a time.

Q: How can I store the collected logs in Object Storage?

A: Use the --objectStoreBucketUri option to specify the pre-authenticated request (PAR) URL for your Object Storage bucket where the logs will be uploaded.

Q: Can I collect logs to a local directory instead of Object Storage?

A: Yes, you can use the --destLocation option to specify a directory on the guest VM where the logs will be collected. The default location is /var/opt/oracle/dbaas_acfs.

Q: What happens if I don’t specify a destination for the logs?

A: If no destination is specified, the collected logs will be stored in the default location /var/opt/oracle/dbaas_acfs on the guest VM.

Q: What does the --waitForCompletion option do?

A: The --waitForCompletion option specifies whether to wait for the command to finish before returning control to the user. The default value is true. If you specify false, the operation runs in the background.

Q: How can I run the log collection in the background?

A: Set the --waitForCompletion option to false to run the log collection process in the background:

dbaascli diag collect --waitForCompletion false

Q: Can I resume a previous log collection session with this command?

A: No, the dbaascli diag collect command does not support resuming previous sessions. You will need to start a new log collection process.

Q: How can I ensure that logs are uploaded directly to the Object Storage?

A: You can provide a valid --objectStoreBucketUri (Object Storage pre-authenticated request URL) where the logs will be uploaded after collection.

Q: Can I collect logs for multiple databases at once?

A: No, you can only specify one database name at a time using the --dbNames option.

Q: What should I do if I want to collect all available logs for all components?

A: Use --components all to collect logs from all components, including the database, Grid Infrastructure, operating system, and DBaaS tools.

Q: What is an example command to collect logs for the database component from a specific time range?

A: Here's an example command:

dbaascli diag collect --components db --startTime 2024-09-01T12:00:00 --endTime 2024-09-01T14:00:00 --dbname orcl

Q: What is an example command to collect logs and upload them to Object Storage?

A: Here's an example command:

dbaascli diag collect --components db --objectStoreBucketUri https://objectstorage.example.com/n/namespace-string/b/bucket-name/o/PAR-URL

Q: What is the default behavior if the --components option is not specified?

A: If you do not specify the --components option, the command may not know which logs to collect and could fail. It is recommended to always specify the components you want to collect logs from.

Q: Can I specify both the --objectStoreBucketUri and --destLocation options in the same command?

A: No, you must choose one destination—either Object Storage via --objectStoreBucketUri or a local directory via --destLocation.

Q: What should I do if I encounter an error while using the dbaascli diag collect command?

A: Double-check that you have provided valid component names, date/time formats, and destination options. Also, ensure you are running the command as the root user.

dbaascli diag healthCheck

To run diagnostic health checks, use the dbaascli diag healthCheck command.

Prerequisite

Run the command as the root user.

Syntax

dbaascli diag healthCheck
[--destLocation]
[--nodes]
[--objectStoreBucketURI]
Where:
  • --destLocation specifies the location on Guest VM to collect logs. Default: /var/opt/oracle/dbaas_acfs
  • --nodes specifies a comma-delimited list of nodes to collect logs
  • --objectStoreBucketURI specifies an Object Storage service pre-authenticated request (PAR) URL used to upload collected logs. Logs are collected from Guest VM. For more information, see Using Pre-Authenticated Requests.

Frequently Asked Questions

Q: What is the purpose of the dbaascli diag healthCheck command?

A: The dbaascli diag healthCheck command is used to perform diagnostic health checks on an Oracle Database running in an Exadata Cloud@Customer environment.

Q: What are the prerequisites for using the dbaascli diag healthCheck command?

A: The command must be run as the root user, and you must be connected to an Exadata Cloud@Customer virtual machine.

Q: How do I specify a custom directory for collecting the logs?

A: Use the --destLocation option to specify the directory where the health check logs will be collected. The default location is /var/opt/oracle/dbaas_acfs.

Q: What is the default location for log collection if I don’t specify --destLocation?

A: The default directory for log collection is /var/opt/oracle/dbaas_acfs.

Q: Can I specify which nodes to run the health check on?

A: Yes, you can use the --nodes option to specify a comma-delimited list of nodes where the health check should be run.

Q: How do I upload the health check logs to Object Storage?

A: Use the --objectStoreBucketURI option to provide a pre-authenticated request (PAR) URL from the Object Storage service. This will upload the collected logs to the specified bucket.

Q: Can I collect logs from multiple nodes?

A: Yes, you can specify multiple nodes using the --nodes option in a comma-delimited format. For example: --nodes node1,node2.

Q: What is an example command to run a health check on a specific node?

A: Here’s an example command to run the health check on a specific node:

dbaascli diag healthCheck --nodes node1

Q: How can I store the logs in Object Storage instead of on the local machine?

A: You can provide a pre-authenticated request (PAR) URL using the --objectStoreBucketURI option to store the logs in Object Storage.

Q: Can I specify both --destLocation and --objectStoreBucketURI at the same time?

A: Yes, you can specify both --destLocation for local storage and --objectStoreBucketURI to upload logs to Object Storage.

Q: What should I do if I encounter an error while running the dbaascli diag healthCheck command?

A: Ensure that you are running the command as the root user and have provided valid options for --destLocation, --nodes, or --objectStoreBucketURI. Verify that the node names are correct if specified.

Q: Can I run the health check in the background?

A: The dbaascli diag healthCheck command does not have an explicit background mode, but you can run it in the background by appending & at the end of the command.

Q: What happens if I don’t provide the --nodes option?

A: If the --nodes option is not provided, the health check will be performed on all nodes in the cluster by default.

Q: Can I resume a previous health check session using this command?

A: No, the dbaascli diag healthCheck command does not support resuming previous sessions. You must initiate a new health check each time.

Q: What is an example command to run a health check and upload logs to Object Storage?

A: Here’s an example command:

dbaascli diag healthCheck --objectStoreBucketURI https://objectstorage.example.com/n/namespace-string/b/bucket-name/o/PAR-URL

Q: What is the default behavior if I don’t specify --destLocation or --objectStoreBucketURI?

A: If neither --destLocation nor --objectStoreBucketURI is specified, the health check logs will be collected in the default directory /var/opt/oracle/dbaas_acfs on the local machine.

Q: Can I limit the health check to specific components or logs?

A: No, the dbaascli diag healthCheck command does not allow you to specify individual components or logs. It performs a general diagnostic health check for the system.

Q: What should I verify before running the dbaascli diag healthCheck command?

A: Ensure that you are connected to an Exadata Cloud@Customer virtual machine and running the command as the root user.

Grid Infrastructure Management

This section focuses on managing Oracle Grid Infrastructure, which supports clustering and high availability. Key tasks include configuring a Grid Infrastructure home (dbaascli gridHome create), upgrading the Grid Infrastructure (dbaascli grid upgrade), and managing TCPS (Transport Layer Security) certificates by configuring (dbaascli grid configureTCPS), removing (dbaascli grid removeTCPSCert), or rotating them (dbaascli grid rotateTCPSCert). These commands ensure efficient setup, maintenance, and security of the Grid Infrastructure.

dbaascli gridHome create

To configure Grid Infrastructure home, use the dbaascli gridHome create command.

Prerequisite

Run the command as the root user.

Syntax

dbaascli gridHome create --version value [--resume [--sessionID value]] [--waitForCompletion value]
Where:
  • --version specifies the Grid home version
  • --resume resumes the previous run
    • --sessionID specifies to resume a specific session ID
  • --waitForCompletion specifies false to run the operation in the background. Valid values: true|false

Frequently Asked Questions

Q: What is the purpose of the dbaascli gridHome create command?

A: The dbaascli gridHome create command is used to configure a Grid Infrastructure home for Oracle Grid infrastructure in an Exadata Cloud@Customer environment.

Q: What is the prerequisite for running the dbaascli gridHome create command?

A: The command must be run as the root user.

Q: How do I specify the version of Grid Infrastructure home to be created?

A: Use the --version option to specify the Grid home version. This is a mandatory option when creating the Grid home.

Q: Can I resume a previous dbaascli gridHome create session?

A: Yes, you can use the --resume option to resume a previous session. Optionally, you can specify the session ID using the --sessionID option to resume a specific session.

Q: What does the --resume option do in the dbaascli gridHome create command?

A: The --resume option allows you to resume a previously interrupted or incomplete operation.

Q: How do I run the operation in the background?

A: You can set the --waitForCompletion option to false to run the operation in the background. The valid values for this option are true (default) or false.

Q: What is the default behavior if --waitForCompletion is not specified?

A: If --waitForCompletion is not specified, the operation will run in the foreground, and the command will wait for the operation to complete before returning control to the user.

Q: What is the purpose of the --sessionID option?

A: The --sessionID option is used to specify the ID of a previous session that you want to resume, in case of an incomplete or interrupted operation.

Q: Can I use the dbaascli gridHome create command to upgrade an existing Grid home?

A: No, this command is used specifically for configuring a new Grid Infrastructure home, not for upgrading an existing one.

Q: What is an example command to create a Grid home with version 19.9.0.0.0?

A: Here’s an example command:

dbaascli gridHome create --version 19.9.0.0.0

Q: What should I do if the dbaascli gridHome create command is interrupted?

A: You can resume the operation by using the --resume option. If you have the session ID, you can provide it using the --sessionID option to resume a specific session.

Q: Can I specify the --resume option without a session ID?

A: Yes, you can use the --resume option without specifying a session ID. In this case, the system will attempt to resume the most recent session.

Q: What happens if I specify --waitForCompletion false?

A: If you specify --waitForCompletion false, the operation will run in the background, allowing you to continue using the command line while the operation completes.

Q: Is it possible to track the progress of a background operation?

A: The dbaascli command does not provide a direct way to track background operations. You may need to check system logs or the session status manually.

Q: Can I specify an invalid Grid home version when creating it?

A: No, the --version option must contain a valid Grid Infrastructure version. If an invalid version is provided, the command will return an error.

Q: How can I determine the Grid home version to use for creation?

A: You can refer to Oracle's documentation or consult with your database administrator to determine the correct Grid home version to use for your environment.

Q: What should I verify before running the dbaascli gridHome create command?

A: Ensure that you are logged in as the root user and that the version you want to use for Grid Infrastructure is compatible with your environment.

dbaascli grid configureTCPS

To configure TCPS for the existing cluster, use the dbaascli grid configureTCPS command.

Prerequisite

Run the command as the root user.

Syntax

Note

By default, TCPS is enabled for databases on Oracle Exadata Database Service on Dedicated Infrastructure systems.
Note

TCPS is not enabled for databases on Exadata Database Service on Cloud@Customer systems. To enable TCPS for a given database, update the database specific sqlnet.ora file with WALLET_LOCATION = (SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/var/opt/oracle/dbaas_acfs/grid/tcps_wallets))) on all database nodes and then bounce the database. This will enable TCPS usage for the database. However, enabling TCPS will cause ZDLRA connection to fail. On Exadata Database Service on Cloud@Customer systems, you can enable either ZDLRA or TCPS configuration. Enabling both ZDLRA and TCPS simultaneously will not work.
dbaascli grid configureTCPS
[--pkcs12WalletFilePath]
[--caCertChain]
[--precheckOnly]
[--serverCert]
[--privateKey]
[--certType]
[--privateKeyPasswordProtected]
Where:
  • --pkcs12WalletFilePath specifies the absolute path of the certificate file, which is in the pkcs12 wallet format
  • --caCertChain concatenated list of certs, containing intermediate CA's and root CA certs
  • --precheckOnly specifies yes to run only the prechecks for this operation. Valid values: yes or no.
  • --serverCert specifies the path of PEM certificate to use or rotate for TCPS configuration.
  • --privateKey specifies the path of the private key file of the certificate.
  • --certType type of the cert to be added to the Grid Infrastructure wallet. Accepted values are: SELF_SIGNED_CERT, CA_SIGNED_CERT, or PKCS12_CERT. Default: SELF_SIGNED_CERT
  • --privateKeyPasswordProtected specifies if the private key is password protected or not. Valid values: true or false. Default: true.

Frequently Asked Questions

Q: What is the purpose of the dbaascli grid configureTCPS command?

A: The dbaascli grid configureTCPS command is used to configure Transport Layer Security (TCPS) for the existing cluster in an Oracle Exadata environment.

Q: What is the prerequisite for running the dbaascli grid configureTCPS command?

A: The command must be run as the root user.

Q: Is TCPS enabled by default on Exadata Database Service on Dedicated Infrastructure systems?

A: Yes, TCPS is enabled by default for databases on Oracle Exadata Database Service on Dedicated Infrastructure systems.

Q: Is TCPS enabled by default on Exadata Database Service on Cloud@Customer systems?

A: No, TCPS is not enabled by default on Exadata Database Service on Cloud@Customer systems. To enable TCPS, you need to update the sqlnet.ora file for the specific database and restart the database.

Q: What is the consequence of enabling TCPS on Exadata Cloud@Customer systems?

A: Enabling TCPS on Exadata Cloud@Customer systems will cause Zero Data Loss Recovery Appliance (ZDLRA) connections to fail. You can only enable either ZDLRA or TCPS configuration, but not both simultaneously.

Q: What does the --pkcs12WalletFilePath option specify?

A: The --pkcs12WalletFilePath option specifies the absolute path to the certificate file in the PKCS12 wallet format, which is used for TCPS configuration.

Q: What is the --caCertChain option used for?

A: The --caCertChain option specifies a concatenated list of certificates containing intermediate CA certificates and the root CA certificate.

Q: What does the --precheckOnly option do?

A: The --precheckOnly option specifies whether to run only the prechecks for the TCPS configuration operation. Accepted values are yes or no.

Q: What does the --serverCert option specify?

A: The --serverCert option specifies the path to the PEM certificate that will be used or rotated for the TCPS configuration.

Q: How do I specify the private key for TCPS configuration?

A: Use the --privateKey option to specify the path to the private key file associated with the server certificate.

Q: What are the accepted values for the --certType option?

A: The accepted values for the --certType option are:

SELF_SIGNED_CERT

CA_SIGNED_CERT

PKCS12_CERT

The default value is SELF_SIGNED_CERT.

Q: Is the private key password protected by default?

A: Yes, the --privateKeyPasswordProtected option is set to true by default, indicating that the private key is password protected. You can set it to false if the private key is not password protected.

Q: Can I run a precheck before configuring TCPS?

A: Yes, you can run only the prechecks for the operation by setting the --precheckOnly option to yes. This helps to validate the environment before making changes.

Q: What happens if I provide an incorrect path for the PKCS12 wallet file?

A: If the --pkcs12WalletFilePath contains an incorrect path, the command will fail, and the TCPS configuration will not proceed.

Q: What should I do if the private key is password protected?

A: If the private key is password protected, ensure that the --privateKeyPasswordProtected option is set to true (which is the default).

Q: Can I specify my own CA-signed certificate for TCPS configuration?

A: Yes, you can specify your own CA-signed certificate by using the --serverCert and --privateKey options, and by setting the --certType to CA_SIGNED_CERT.

Q: What is an example command to configure TCPS using a self-signed certificate?

A: Here’s an example:

dbaascli grid configureTCPS --serverCert /path/to/self_signed_cert.pem --privateKey /path/to/private_key.pem --certType SELF_SIGNED_CERT

Q: Can I use a PKCS12 certificate for TCPS configuration?

A: Yes, you can use a PKCS12 certificate by specifying the --pkcs12WalletFilePath option and setting the --certType to PKCS12_CERT.

Q: What should I verify before running the dbaascli grid configureTCPS command?

A: Verify that you have the correct certificate files, private key files, and that you are logged in as the root user. Also, ensure you understand the implications if you're using ZDLRA as it cannot run simultaneously with TCPS.

Example 7-27 dbaascli grid configureTCPS

To configure grid using self-signed certificate:
dbaascli grid configureTCPS
To configure grid using CA-signed certificate:
dbaascli grid configureTCPS --cert_type CA_SIGNED_CERT --server_cert /tmp/certs/server_cert.pem --ca_cert_chain /tmp/certs/ca.pem --private_key /tmp/certs/encrypted_private.key --private_key_password_protected false
dbaascli grid removeTCPSCert

To remove existing TCPS certificates from Grid Infrastructure wallet, use the dbaascli grid removeTCPSCert command.

Prerequisite

Run the command as the root user.

Syntax

dbaascli grid removeTCPSCert --subject <value>
 {
   --userCert | --trustedCert | --requestedCert
 }
 [--serialNumber <value>] [--executePrereqs] [--resume [--sessionID <value>]] [--bounceListeners]
Where:
  • --subject specifies subject of the certificate
  • --userCert flag to indicate user certificate
  • --trustedCert flag to indicate trusted certificate
  • --requestedCert flag to indicate requested certificate
  • --serialNumber specifies the serial number of the certificate
  • --executePrereqs runs the prerequisite checks and reports the results
  • --resume resumes the previous run
    • --sessionID specifies to resume a specific session ID
  • --bounceListeners flag to bounce the Grid Infrastructure listener and scan listener

Frequently Asked Questions

Q: What is the purpose of the dbaascli grid removeTCPSCert command?

A: The dbaascli grid removeTCPSCert command is used to remove existing TCPS certificates from the Grid Infrastructure wallet in an Oracle Exadata environment.

Q: What is the prerequisite for running the dbaascli grid removeTCPSCert command?

A: The command must be run as the root user.

Q: What does the --subject option specify in the dbaascli grid removeTCPSCert command?

A: The --subject option specifies the subject of the certificate to be removed from the Grid Infrastructure wallet.

Q: What is the purpose of the --userCert flag?

A: The --userCert flag indicates that the certificate to be removed is a user certificate.

Q: When should I use the --trustedCert flag?

A: Use the --trustedCert flag when removing a trusted certificate from the Grid Infrastructure wallet.

Q: What does the --requestedCert flag do?

A: The --requestedCert flag indicates that the certificate being removed is a requested certificate.

Q: What does the --serialNumber option specify?

A: The --serialNumber option specifies the serial number of the certificate to be removed. It is useful for uniquely identifying a certificate when there are multiple certificates with the same subject.

Q: What is the purpose of the --executePrereqs option?

A: The --executePrereqs option runs prerequisite checks before removing the certificate and reports the results, ensuring that the environment is properly prepared for the operation.

Q: What does the --resume option do?

A: The --resume option resumes the removal operation if it was previously interrupted.

Q: How do I specify a session ID when resuming an interrupted operation?

A: Use the --sessionID option to specify the session ID of the interrupted operation that you want to resume.

Q: What does the --bounceListeners flag do?

A: The --bounceListeners flag is used to restart the Grid Infrastructure listener and scan listener after the TCPS certificate is removed.

Q: Can I remove a TCPS certificate without bouncing the listeners?

A: Yes, the --bounceListeners flag is optional. If you don’t specify it, the listeners will not be bounced automatically.

Q: How can I ensure that the operation will run safely?

A: You can use the --executePrereqs option to perform prerequisite checks before running the command, ensuring that everything is in order before the removal process.

Q: What should I do if I need to remove a specific user certificate by serial number?

A: Use the --subject option to specify the certificate’s subject, the --userCert flag to indicate that it is a user certificate, and the --serialNumber option to specify the certificate’s serial number.

Q: Can I remove multiple certificates at once?

A: No, the command is designed to remove a single certificate at a time based on the provided subject and other parameters.

Q: What happens if the certificate removal process is interrupted?

A: You can resume the operation using the --resume option along with the --sessionID of the interrupted process.

Q: Do I need to run the command as the root user?

A: Yes, the dbaascli grid removeTCPSCert command must be run as the root user to have the necessary privileges for removing TCPS certificates.

Q: How can I identify the certificate I want to remove?

A: You can identify the certificate by its subject, and optionally, by its serial number to ensure you're targeting the correct certificate for removal.

Q: What is an example command to remove a trusted certificate?

A: Here’s an example:

dbaascli grid removeTCPSCert --subject "CN=example_cert" --trustedCert

dbaascli grid rotateTCPSCert

To rotate TCPS certificates, use the dbaascli grid rotateTCPSCert command.

Prerequisite

Run the command as the root user.

Syntax

dbaascli grid rotateTCPSCert
[--pkcs12WalletFilePath]
[--caCertChain]
[--precheckOnly]
[--serverCert]
[--privateKey]
[--certType]
[--privateKeyPasswordProtected]
Where:
  • --pkcs12WalletFilePath specifies the absolute path of the certificate file, which is in the pkcs12 wallet format
  • --caCertChain concatenated list of certs, containing intermediate CA's and root CA certs
  • --precheckOnly specifies yes to run only the prechecks for this operation. Valid values: yes or no.
  • --serverCert specifies the path of PEM certificate to use or rotate for TCPS configuration.
  • --privateKey specifies the path of the private key file of the certificate.
  • --certType type of the cert to be added to the Grid Infrastructure wallet. Accepted values are: SELF_SIGNED_CERT, CA_SIGNED_CERT, or PKCS12_CERT. Default: SELF_SIGNED_CERT
  • --privateKeyPasswordProtected specifies if the private key is password protected or not. Valid values: true or false. Default: true.

Frequently Asked Questions

Q: What is the purpose of the dbaascli grid rotateTCPSCert command?

A: The dbaascli grid rotateTCPSCert command is used to rotate TCPS (Transport Layer Security Protocol) certificates in the Grid Infrastructure wallet in Oracle Exadata environments.

Q: What is the prerequisite for running the dbaascli grid rotateTCPSCert command?

A: The command must be run as the root user.

Q: What does the --pkcs12WalletFilePath option specify?

A: The --pkcs12WalletFilePath option specifies the absolute path to the certificate file in the PKCS12 wallet format for the TCPS configuration.

Q: What is the purpose of the --caCertChain option?

A: The --caCertChain option specifies a concatenated list of certificates, including intermediate CA and root CA certificates, for the TCPS configuration.

Q: What does the --precheckOnly option do?

A: The --precheckOnly option allows you to run prechecks without making any actual changes. The valid values are "yes" to run only the prechecks and "no" to proceed with the rotation.

Q: How is the --serverCert option used?

A: The --serverCert option specifies the path to the PEM (Privacy Enhanced Mail) server certificate that is used or rotated for the TCPS configuration.

Q: What does the --privateKey option specify?

A: The --privateKey option specifies the path to the private key file corresponding to the server certificate used for TCPS rotation.

Q: What are the valid values for the --certType option?

A: The --certType option accepts the following values for specifying the type of certificate to be added to the Grid Infrastructure wallet:

SELF_SIGNED_CERT (default)

CA_SIGNED_CERT

PKCS12_CERT

Q: What does the --privateKeyPasswordProtected option do?

A: The --privateKeyPasswordProtected option indicates whether the private key is password-protected. Valid values are true (default) and false

Q: Can I run the dbaascli grid rotateTCPSCert command without rotating the certificates?

A: Yes, by using the --precheckOnly yes option, you can run only the prechecks without rotating the certificates.

Q: What is an example of a command to rotate a certificate using a PKCS12 wallet?

A: Here’s an example command:

dbaascli grid rotateTCPSCert --pkcs12WalletFilePath /path/to/wallet.p12 --certType PKCS12_CERT

Q: How do I rotate a server certificate with a CA-signed certificate chain?

A: Use the --serverCert and --caCertChain options as shown below:

dbaascli grid rotateTCPSCert --serverCert /path/to/serverCert.pem --caCertChain /path/to/caChain.pem

Q: What happens if I don't specify --privateKeyPasswordProtected?

A: If you don’t specify the --privateKeyPasswordProtected option, the command assumes that the private key is password-protected (default: true).

Q: Can I rotate a self-signed certificate?

A: Yes, you can rotate a self-signed certificate by using the default --certType SELF_SIGNED_CERT option or specifying it explicitly.

Q: How can I rotate a certificate without providing a private key?

A: For certain certificate types, like PKCS12, you may not need to provide a separate private key file, as it is included in the wallet. However, if a private key is required, it must be provided using the --privateKey option.

Q: What if I want to rotate a certificate in the background?

A: The dbaascli grid rotateTCPSCert command doesn’t provide an explicit option for background execution. You may run the command directly in a background session (e.g., using nohup or similar tools).

Q: What is the default certificate type if not specified?

A: The default certificate type is SELF_SIGNED_CERT.

Example 7-28 dbaascli grid rotateTCPSCert

To rotate cert using self-signed certificate (default option):
dbaascli grid rotateTCPSCert
To rotate cert using CA-signed certificate:
dbaascli grid rotateTCPSCert --cert_type CA_SIGNED_CERT --server_cert /tmp/certs/server_cert.pem --ca_cert_chain /tmp/certs/ca.pem --private_key /tmp/certs/encrypted_private.key --privateKeyPasswordProtected true
dbaascli grid upgrade

To upgrade Oracle Grid Infrastrucure from one major version to another, use the dbaascli grid upgrade command.

Prerequisite

Run the command as the root user.

Syntax

dbaascli grid upgrade --version
[--resume]
[--executePrereqs]
[--containerURL]
[--softwareOnly]
[--targetHome]
[--revert]
Where:
  • --version specifies the target version
  • --resume resumes the previous run
  • --executePrereqs runs prereqs for Grid Infrastrucure upgrade
  • --containerUrl specifies the custom URL for fetching Grid Infrastrucure image
  • --softwareOnly installs only the Grid Infrastructure software
  • --targetHome specifies the path of existing target Grid home
  • --revert reverts failed run

Frequently Asked Questions

Q: What is the purpose of the dbaascli grid upgrade command?

A: The dbaascli grid upgrade command is used to upgrade Oracle Grid Infrastructure from one major version to another on an Exadata Cloud@Customer virtual machine.

Q: What is the prerequisite for running the dbaascli grid upgrade command?

A: The command must be run as the root user, and you need to be connected to an Exadata Cloud@Customer virtual machine.

Q: What does the --version option specify?

A: The --version option specifies the target version of Oracle Grid Infrastructure that you want to upgrade to.

Q: What does the --resume option do?

A: The --resume option resumes a previously interrupted or failed Grid Infrastructure upgrade process.

Q: How is the --executePrereqs option used?

A: The --executePrereqs option runs only the prerequisite checks for the Grid Infrastructure upgrade without performing the actual upgrade.

Q: What is the purpose of the --containerURL option?

A: The --containerURL option specifies a custom URL to fetch the Grid Infrastructure software image for the upgrade.

Q: What does the --softwareOnly option do?

A: The --softwareOnly option installs only the Grid Infrastructure software without configuring or upgrading the Grid environment.

Q: When would you use the --targetHome option?

A: The --targetHome option specifies the path to the existing target Grid home where the upgrade will be performed.

Q: What happens if the upgrade fails?

A: If the upgrade fails, you can use the --revert option to roll back the upgrade to its previous state.

Q: Can I perform a Grid Infrastructure upgrade in stages?

A: Yes, by using the --softwareOnly option, you can first install the software and then later complete the full upgrade, allowing for staged upgrades.

Q: How do I use the dbaascli grid upgrade command to upgrade only the software?

A: Use the following syntax to upgrade only the software:

dbaascli grid upgrade --version <target_version> --softwareOnly

Q: Can I check for upgrade prerequisites without performing the upgrade?

A: Yes, you can run only the prerequisite checks using:

dbaascli grid upgrade --version <target_version> --executePrereqs

Q: How can I upgrade Grid Infrastructure using a custom container URL?

A: You can specify the URL for fetching the Grid Infrastructure image as follows:

dbaascli grid upgrade --version <target_version> --containerURL <custom_url>

Q: How can I resume a previously interrupted upgrade process?

A: To resume a previously interrupted or failed upgrade, use:

dbaascli grid upgrade --version <target_version> --resume

Q: What does the --revert option do in the dbaascli grid upgrade command?

A: The --revert option rolls back a failed or interrupted Grid Infrastructure upgrade to its original state.

Q: Can I perform a full upgrade without configuring the Grid Infrastructure immediately?

A: Yes, you can first install only the software using the --softwareOnly option and then configure it later.

Q: What should I do if an upgrade fails and I want to undo the changes?

A: Use the --revert option to roll back the failed upgrade:

dbaascli grid upgrade --version <target_version> --revert

Example 7-29 dbaascli grid upgrade

daascli grid upgrade --version 19.11.0.0.0 --executePrereqs
DBAAS CLI version MAIN
Executing command grid upgrade --version 19.11.0.0.0 --executePrereqs

Patching and Upgrading

This section provides tools for updating and maintaining Oracle environments through patching and upgrades. It includes commands such as dbaascli grid patch to patch Oracle Grid Infrastructure, dbaascli dbHome patch to apply patches to Oracle homes, and dbaascli database move to move databases between homes during upgrades or patching processes. These commands help ensure systems remain secure, stable, and up-to-date.

dbaascli grid patch

To patch Oracle Grid Infrastructure to the specified minor version, use the dbaascli grid patch command.

Prerequisites

Run the command as the root user.

Syntax

dbaascli grid patch
 {
            --targetVersion <value>
            | --targetHome <value>
        }
        [--executePrereqs] [--nodeList <value>] [--continueWithDbDowntime] [--drainTimeoutInSeconds <value>] [--containerURL <value>] [--imageFile <value>] [--patchInParallel]
        {
            [--resume [--sessionID <value>]]
            | [--rollback [--sessionID <value>]]
        }
        [--waitForCompletion <value>]

Where:

  • --targetVersion specifies the target version of Oracle Home specified as five numeric segments separated by periods (e.g. 19.12.0.0.0)
  • --targetHome specifies the fully qualified path of the target Grid Infrastructure home for the out of place patching
  • --containerURL specifies custom URL for fetching Grid Infrastructure image
  • --executePrereqs option to run prereqs
  • --nodeList specifies a comma-delimited list of nodes if patching has to be performed on a subset of nodes
  • --patchInParallel specifies to perform patching remote nodes in parallel
  • --rollback specifies to roll back patched Oracle home
  • --resume resumes the previous run
    • --sessionID specifies to resume a specific session ID
  • --continueWithDbDowntime continues patching with database downtime. This option can be used in environments wherein there is only 1 active instance up and the patching operation can be continued even with a downtime.
  • --drainTimeoutInSeconds specifies the time (in seconds) to complete the resource draining while stopping the database
  • --createImage creates an image from a copy of the active Grid home, patched to the specified target version
    • --createImageDir specifies fully qualified path of the directory where the image is to be created
  • --imageFile specifies fully qualified path of the image to be used
  • --patchInParallel performs the patching of the remote nodes in parallel
  • --waitForCompletion specifies false to run the operation in background. Valid values: true|false

Frequently Asked Questions

Q: What does the dbaascli grid patch command do?

A: The dbaascli grid patch command is used to patch Oracle Grid Infrastructure to a specified minor version.

Q: Do I need special permissions to run the dbaascli grid patch command?

A: Yes, you need to run the dbaascli grid patch command as the root user.

Q: Can I specify a target version when patching Oracle Grid Infrastructure?

A: Yes, you can specify the target version using the --targetVersion option.

Q: How do I specify the target version for the patch?

A: Use the --targetVersion option followed by the version number in the format 19.12.0.0.0.

Q: What does the --containerURL option do in the dbaascli grid patch command?

A: The --containerURL option allows you to specify a custom URL for fetching the Grid Infrastructure image.

Q: What is the purpose of the --executePrereqs option?

A: The --executePrereqs option is used to run prerequisite checks before applying the patch.

Q: How can I patch a subset of nodes using the dbaascli grid patch command?

A: Use the --nodeList option followed by a comma-delimited list of node names to patch only a subset of nodes.

Q: What happens if I use the --rollback option?

A: The --rollback option will roll back the patched Oracle home to its previous state.

Q: Can I resume a previous patching session?

A: Yes, you can use the --resume option to resume the last patching session. If you have a specific session ID, you can specify it with the --sessionID option.

Q: What is the --continueWithDbDowntime option used for?

A: The --continueWithDbDowntime option allows you to continue patching even if there is database downtime, typically used in environments where there is only one active instance.

Q: How do I create an image from a patched Grid home?

A: Use the --createImage option to create an image. You can specify the directory where the image should be created using the --createImageDir option.

Q: What is the purpose of the --imageFile option?

A: The --imageFile option allows you to specify the fully qualified path of the image file to be used for patching.

Q: How can I run the dbaascli grid patch command in the background?

A: You can use the --waitForCompletion option set to false to run the operation in the background.

Q: Can I use a custom URL to fetch the patch image?

A: Yes, you can use the --containerURL option to specify a custom URL for fetching the Grid Infrastructure image.

Q: How do I specify which nodes to patch if I don’t want to patch all of them?

A: You can specify the nodes you want to patch using the --nodeList option with a comma-separated list of node names.

Q: What should I do if I need to roll back a patch?

A: Use the --rollback option in the dbaascli grid patch command to roll back the patch.

Q: How do I handle a patching operation if my environment only has one active instance and I need to continue with downtime?

A: Use the --continueWithDbDowntime option to continue patching even with database downtime.

Q: Can I create an image of the patched Grid home?

A: Yes, you can use the --createImage option to create an image of the patched Grid home. If needed, specify the directory where the image should be saved using --createImageDir.

Q: What should I do if I want to resume a patching session after an interruption?

A: Use the --resume option to resume the patching session. If you know the session ID, you can specify it with --sessionID.

Q: What if the patching process fails midway?

A: If the patching process fails, you can use the --resume option to restart the process. You can also use the --rollback option to revert to the previous state.

Q: How can I ensure all prerequisites are met before patching?

A: Use the --executePrereqs option to run all prerequisite checks before applying the patch.

Q: Can I perform patching in the background to avoid holding up the terminal?

A: Yes, you can use the --waitForCompletion false option to run the patching process in the background.

Q: How can I create a Grid home image after patching?

A: Use the --createImage option to create a new image from the patched Grid home. Specify the directory using --createImageDir if needed.

Q: How do I use an existing image file for patching?

A: You can use the --imageFile option to specify the fully qualified path to the image file you want to use for patching.

Q: What should I do if I want to avoid database downtime during patching?

A: Ensure that your environment has more than one active instance running. You can avoid using the --continueWithDbDowntime option, which is meant for environments with only one active instance.

Q: How do I know the progress of a patch running in the background?

A: If you run the patch with --waitForCompletion false, you can check the status of the background job using operating system commands like ps or check the logs located in the Grid home.

Q: Is it possible to patch to a higher major version using dbaascli grid patch?

A: No, dbaascli grid patch only allows patching to a minor version of the current major version. For major upgrades, you will need to follow a different upgrade process.

Q: Can I skip specific prerequisite checks during patching?

A: No, when you use --executePrereqs, all prerequisite checks will be executed. However, you can review the results of the prerequisite checks and manually handle any issues before proceeding.

Q: What should I do if the patching process is stuck or hanging?

A: If the patching process is unresponsive, you can stop it using operating system commands and then resume using the --resume option. If that doesn't work, try using the --rollback option to revert the patch.

Q: Can I automate the patching process across multiple clusters?

A: Yes, using scripts that include the dbaascli grid patch command with appropriate options, you can automate patching across different clusters.

Q: Where can I find logs for the patching process?

A: Logs are typically located in the Oracle Grid home logs directory or the default location specified during setup. You can monitor these logs for details about the patching process.

Q: Is it possible to create a silent patch process with no user interaction?

A: Yes, by specifying all necessary options in the command and running it in the background (--waitForCompletion false), you can create a non-interactive patching process.

Q: Can I check for available patch updates before applying a patch?

A: The dbaascli grid patch command itself does not have an option to list available patches. However, you can use Oracle’s standard methods such as Oracle Support to identify the latest patches.

Q: Can I use dbaascli to patch multiple Oracle Homes?

A: No, the dbaascli grid patch command is designed to patch a specific Oracle Grid Infrastructure home at a time. You would need to run the command separately for each home.

Q: Is there a way to prevent downtime completely when patching Grid Infrastructure?

A: To minimize downtime, ensure that your environment has multiple active database instances (RAC configuration) so that patching can be done node by node. The --continueWithDbDowntime option should not be used in this case.

Q: How do I handle patching for RAC One Node environments?

A: In RAC One Node environments, you need to be cautious with the --continueWithDbDowntime option, as there may be only one active instance. Review the Oracle documentation for specific patching guidelines for RAC One Node.

Q: Can I view the session history of previous patches?

A: The dbaascli utility does not provide a direct way to view session history. However, logs of previous patching sessions can be found in the Grid home logs directory.

Example Use Cases

Example 1: Basic Grid Patching

dbaascli grid patch --targetVersion 19.12.0.0.0

Patches the Oracle Grid Infrastructure to version 19.12.0.0.0.

Example 2: Patching with a Custom Container URL

dbaascli grid patch --targetVersion 19.12.0.0.0 --containerURL https://example.com/custom/url

Patches Grid Infrastructure to version 19.12.0.0.0, using a custom container URL to fetch the Grid Infrastructure image.

Example 3: Patching with Prerequisite Checks

dbaascli grid patch --targetVersion 19.12.0.0.0 --executePrereqs

Patches Grid Infrastructure to version 19.12.0.0.0 after running the prerequisite checks.

Example 4: Patching on a Subset of Nodes

dbaascli grid patch --targetVersion 19.12.0.0.0 --nodeList node1,node2,node3

Patches Grid Infrastructure to version 19.12.0.0.0 on the specified nodes (node1, node2, and node3).

Example 5: Rolling Back the Patch

dbaascli grid patch --rollback

Rolls back the last applied patch on the Oracle Grid Infrastructure.

Example 6: Resuming a Previous Patch Operation

dbaascli grid patch --resume

Resumes the previous patching operation from where it was stopped.

Example 7: Resuming a Patch Operation with a Specific Session ID

dbaascli grid patch --resume --sessionID 12345

Resumes the patching operation using session ID 12345.

Example 8: Patching with Database Downtime Allowed

dbaascli grid patch --targetVersion 19.12.0.0.0 --continueWithDbDowntime

Patches the Grid Infrastructure to version 19.12.0.0.0 while allowing downtime of the database if needed.

Example 9: Creating a Patched Image

dbaascli grid patch --targetVersion 19.12.0.0.0 --createImage --createImageDir /path/to/dir

Creates an image of the patched Grid home (version 19.12.0.0.0) and stores it in the specified directory.

Example 10: Using an Existing Image File

dbaascli grid patch --targetVersion 19.12.0.0.0 --imageFile /path/to/image/file.zip

Patches Grid Infrastructure to version 19.12.0.0.0 using an existing image file located at /path/to/image/file.zip.

Example 11: Running the Patching Operation in the Background

dbaascli grid patch --targetVersion 19.12.0.0.0 --waitForCompletion false

Patches Grid Infrastructure to version 19.12.0.0.0 and runs the operation in the background.

Example 12: Combination of Prerequisites, Custom URL, and Subset of Nodes

dbaascli grid patch --targetVersion 19.12.0.0.0 --executePrereqs --containerURL https://example.com/custom/url --nodeList node1,node2

Patches Grid Infrastructure to version 19.12.0.0.0, runs prerequisite checks, uses a custom URL for the image, and applies the patch only on node1 and node2.

Example 13: Creating a Patched Image with an Existing Image File

dbaascli grid patch --targetVersion 19.12.0.0.0 --createImage --createImageDir /path/to/dir --imageFile /path/to/existing/image.zip

Creates a patched image and stores it in the specified directory while using an existing image file for the patch.

Example 14: Verifying Prerequisites Without Patching

dbaascli grid patch --targetVersion 19.12.0.0.0 --executePrereqs

Verifies whether all prerequisites are met for patching to version 19.12.0.0.0 without actually applying the patch.

Example 15: Running Patch and Ignoring Prerequisite Failures

dbaascli grid patch --targetVersion 19.12.0.0.0 --continueWithDbDowntime --executePrereqs

Runs the patch even if some prerequisite checks fail. This is useful in scenarios where downtime is allowed, and certain prerequisites can be ignored.

Example 16: Checking Patch Logs for Issues

tail -f /u01/app/grid/logs/grid_patch.log

Monitors the patch log in real time to diagnose any issues during the patching process.

Example 17: Applying the Patch in a Parallel Environment

dbaascli grid patch --targetVersion 19.12.0.0.0 --nodeList node1,node2 --waitForCompletion false

Patches Grid Infrastructure on a subset of nodes (node1 and node2) and runs the process in the background.

Example 18: Using a Specific Image File from an External Source

dbaascli grid patch --targetVersion 19.12.0.0.0 --imageFile /mnt/images/grid_patch_19.12.zip

Patches Grid Infrastructure using a pre-downloaded image file located on an external storage device.

Example 19: Running Patch with a Custom Session ID

dbaascli grid patch --targetVersion 19.12.0.0.0 --resume --sessionID 67890

Resumes a patching operation that was interrupted, using session ID 67890.

Example 20: Scheduling Patching to Run at a Later Time

echo "dbaascli grid patch --targetVersion 19.12.0.0.0" | at 02:00

Schedules the patching command to run at 2:00 AM using the at command in Linux.

Example 21: Specifying Timeout for Completion

dbaascli grid patch --targetVersion 19.12.0.0.0 --waitForCompletion true --continueWithDbDowntime --timeout 7200

Patches Grid Infrastructure while allowing downtime, but waits up to 7200 seconds (2 hours) for completion before timeout.

Example 22: Creating a Custom Image for Another Environment

dbaascli grid patch --targetVersion 19.12.0.0.0 --createImage --createImageDir /backups/images/grid_patch

Creates a custom image of the patched Grid Infrastructure to store in the /backups/images/grid_patch directory for use in other environments.

Example 23: Patch Recovery After Interruption

dbaascli grid patch --resume --continueWithDbDowntime

Recovers and resumes the patching process if it was interrupted, with database downtime allowed.

Example 24: Combining Prerequisites Check with Background Execution

dbaascli grid patch --targetVersion 19.12.0.0.0 --executePrereqs --waitForCompletion false

Checks prerequisites and runs the patch in the background.

Example 25: Skipping Image Creation for Faster Patching

dbaascli grid patch --targetVersion 19.12.0.0.0 --patchInParallel --continueWithDbDowntime --waitForCompletion false

Patches Grid Infrastructure to version 19.12.0.0.0 in parallel across nodes, with database downtime allowed, and without creating an image to speed up the process.

Example 26: Monitoring Patch Progress Through Logs

tail -f /u01/app/grid/logs/grid_patch_progress.log

Monitors the log file for patching progress in real-time, providing insights into each step of the patching process.

Example 27: Patching with Custom Drain Timeout

dbaascli grid patch --targetVersion 19.12.0.0.0 --drainTimeoutInSeconds 3600 --continueWithDbDowntime

Patches Grid Infrastructure and sets a custom timeout of 1 hour (3600 seconds) to allow graceful resource draining during database downtime.

Example 28: Applying a Patch to Specific Nodes with Prerequisite Checks

dbaascli grid patch --targetVersion 19.12.0.0.0 --nodeList node1,node4 --executePrereqs

Patches only nodes node1 and node4 to version 19.12.0.0.0 and runs the prerequisite checks beforehand.

Example 29: Patching Without Waiting for Completion

dbaascli grid patch --targetVersion 19.12.0.0.0 --waitForCompletion false

Begins patching the Grid Infrastructure to version 19.12.0.0.0 in the background, allowing other tasks to be performed without waiting for the process to complete.

Example 30: Reapplying a Failed Patch After a Drain Timeout Issue

dbaascli grid patch --resume --drainTimeoutInSeconds 7200

Resumes the previous patching session and extends the resource draining timeout to 2 hours (7200 seconds) in case it failed due to insufficient time in the previous attempt.

Example 31: Viewing Patch Logs in Real-Time with Specific Session ID

tail -f /u01/app/grid/logs/grid_patch_12345.log

Monitors the log file for the patching session with session ID 12345 in real-time.

Example 32: Patching to a New Target Home

dbaascli grid patch --targetHome /u01/app/grid_home_19c --executePrereqs

Performs an out-of-place patch to a new Oracle Grid home located at /u01/app/grid_home_19c, with prerequisite checks.

Example 33: Stopping a Background Patch Job

ps -ef | grep dbaascli | grep patch | awk '{print $2}' | xargs kill -9

Stops a background patch job by finding and killing the associated process ID (PID).

Example 34: Verifying Patch Completion Without Logs

dbaascli grid status --targetVersion 19.12.0.0.0

Verifies if the patch to version 19.12.0.0.0 has been successfully applied by checking the current Grid Infrastructure version status.

dbaascli dbHome patch

To patch Oracle home from one patch level to another, use the dbaascli dbHome patch command.

Prerequisite

Run the command as the root user.

Syntax

dbaascli dbHome patch

{
    --oracleHome <value>
    | --oracleHomeName <value>
 }
        [--imageFilePath <value>] [--executePrereqs] [--nodes <value>]
        {
            [--resume [--sessionID <value>]]
            | [--rollback [--sessionID <value>]]
        }
[--skipDatapatch] 
[--skipClosedPDBs] 
[--skipPDBs <value>] 
[--continueWithDbDowntime] 
[--skipUnreachableNodes] 
[--drainTimeoutInSeconds <value>] 
[--waitForCompletion <value>]
Where:
  • --oracleHome specifies the path of Oracle home
  • --oracleHomeName specifies the name of Oracle home
  • --targetVersion specifies the target version of Oracle Home specified as five numeric segments separated by periods, for example, 19.12.0.0.0.
  • --resume resumes the previous run
    • --sessionID specifies to resume a specific session ID
  • --continueWithDbDowntime continues patching with database downtime. This option can be used in environments wherein there is only one active instance up and the patching operation can be continued even with a downtime.
  • --skipUnreachableNodes skips operation on unreachable nodes
  • --nodes specifies a comma-delimited list of nodes if patching has to be performed on a subset of nodes
  • --executePrereqs runs prereqs
  • --skipDatapatch skips running datapatch on the databases
  • --imageFilePath specifies the absolute path of the image file to be used
  • --skipPDBs skips running the datapatch on a specified comma-delimited list of PDBs. For example: cdb1:pdb1,cdb2:pdb2, and so on
  • --skipClosedPdbs skips running datapatch on closed PDBs
  • --rollback rolls back patched Oracle home.
  • --waitForCompletion specifies false to run the operation in background. Valid values : true|false
  • --drainTimeoutInSeconds specifies time (in seconds) to complete the resource draining while stopping the database
  • --skipUnreachableNodes skips operation on unreachable nodes

Frequently Asked Questions

Q: What is the dbaascli dbHome patch command used for?

A: The dbaascli dbHome patch command is used to patch Oracle home from one patch level to another.

Q: Do I need special permissions to run the dbaascli dbHome patch command?

A: Yes, you need to run the command as the root user.

Q: How do I specify the Oracle home path or name for the patch?

A: Use the --oracleHome option to specify the path of the Oracle home, or --oracleHomeName to specify the name of the Oracle home.

Q: How can I define the target version for the patch?

A: Use the --targetVersion option followed by the version number in the format 19.12.0.0.0.

Q: What does the --resume option do?

A: The --resume option allows you to resume a previous patching session.

Q: How do I specify a particular session ID when resuming a patch?

A: Use the --sessionID option to specify the session ID of the patching session you want to resume.

Q: What is the --continueWithDbDowntime option used for?

A: The --continueWithDbDowntime option allows patching to continue even if there is database downtime, useful in environments with only one active instance.

Q: How can I skip patching on unreachable nodes?

A: Use the --skipUnreachableNodes option to skip operations on nodes that are unreachable.

Q: How do I patch only specific nodes in a cluster?

A: Use the --nodes option followed by a comma-delimited list of node names to patch a subset of nodes.

Q: What is the --executePrereqs option for?

A: The --executePrereqs option runs prerequisite checks before applying the patch.

Q: How can I skip running datapatch on the databases?

A: Use the --skipDatapatch option to skip the datapatch process during patching.

Q: Can I specify a custom location for the database image?

A: Yes, use the --imageLocation option to specify a custom location for the database image.

Q: What does the --skipPDBs option do?

A: The --skipPDBs option allows you to skip running datapatch on a specified comma-delimited list of pluggable databases (PDBs).

Q: How can I skip datapatch on closed PDBs?

A: Use the --skipClosedPDBs option to skip datapatch on PDBs that are closed.

Q: What happens if I use the --rollback option?

A: The --rollback option will revert the Oracle home to its previous state before the patch was applied.

Q: How do I specify the Oracle home path for patching?

A: Use the --oracleHome option followed by the path to the Oracle home directory.

Q: How can I patch an Oracle home by its name rather than the path?

A: Use the --oracleHomeName option followed by the name of the Oracle home.

Q: How do I resume a patching operation if it was interrupted?

A: Use the --resume option along with the --sessionID option to resume a specific interrupted session.

Q: Can I continue the patching process if the database is down?

A: Yes, use the --continueWithDbDowntime option to continue patching even if the database is down.

Q: What should I do if some nodes are unreachable during the patching process?

A: Use the --skipUnreachableNodes option to bypass the unreachable nodes.

Q: How can I apply the patch to only certain nodes?

A: Specify the nodes you want to patch using the --nodes option with a comma-separated list of node names.

Q: How do I check prerequisites before applying the patch?

A: Use the --executePrereqs option to run prerequisite checks before applying the patch.

Q: What should I do if I want to avoid applying datapatch during the patching process?

A: Use the --skipDatapatch option to skip the datapatch step.

Q: How can I specify a different location for the database image used in the patching process?

A: Use the --imageLocation option to specify a custom location for the image.

Q: What if I need to skip datapatch on certain PDBs?

A: Use the --skipPDBs option to skip datapatch on a specified comma-delimited list of PDBs.

Q: Can I skip datapatch on PDBs that are not currently open?

A: Yes, use the --skipClosedPDBs option to skip datapatch on closed PDBs.

Q: What should I do if the patching fails midway?

A: You can use the --rollback option to revert to the previous state or try resuming the patching process with the --resume option.

Q: How can I check if all prerequisites are met before applying the patch?

A: Run the patch command with the --executePrereqs option to ensure all prerequisites are satisfied.

Q: What if the patching operation does not complete successfully and I need to retry?

A: Use the --resume option to retry the patching operation from where it left off. If needed, you can specify a --sessionID to resume a specific session.

Q: How can I verify if the patch was successfully applied?

A: You can verify the patching process by checking the Oracle home version using the opatch lsinventory command after the patch is completed.

Q: Can I run the patching command in a dry run mode to preview actions?

A: No, the dbaascli dbHome patch command does not have a dry-run feature. However, you can use the --executePrereqs option to run prerequisite checks before actually applying the patch.

Q: Is it possible to apply multiple patches in one run?

A: The dbaascli dbHome patch command only allows for one target version at a time. You would need to run the command separately for each patch version.

Q: How do I handle patching if the environment uses multiple Oracle homes?

A: You can specify the Oracle home you want to patch using either the --oracleHome or --oracleHomeName options, depending on whether you're specifying the path or the name of the Oracle home.

Q: Can I skip both PDB and CDB datapatching in one command?

A: Yes, you can combine the --skipPDBs and --skipDatapatch options to skip datapatching for both PDBs and the CDB in a single patch run.

Q: Can I apply a patch and rollback immediately if it causes issues?

A: Yes, after applying a patch, you can use the --rollback option to revert to the previous patch level if any issues arise.

Q: Can I patch multiple Oracle homes simultaneously?

A: No, you need to run the dbaascli dbHome patch command individually for each Oracle home.

Q: How do I track the progress of the patching operation?

A: During the patching process, the command provides output messages that show the progress. You can also check the log files for detailed information.

Q: Can I run patching in parallel on a clustered environment?

A: Patching operations can be applied to a subset of nodes using the --nodes option. However, simultaneous patching should be handled carefully, and you should ensure no overlapping sessions.

Q: How can I identify which patches are available for my Oracle home?

A: You can check the available patches via the Oracle support portal or by running the opatch lsinventory command to see the current patches applied to your Oracle home.

Q: Can I specify a timeout for draining resources when stopping the database during patching?

A: Yes, you can use the --drainTimeoutInSeconds option to specify the time in seconds for resource draining when stopping the database.

Q: What happens if the patch fails on one of the nodes in a multi-node environment?

A: You can use the --skipUnreachableNodes option to skip the failed node and continue the patching process on the remaining nodes. You can then address the issue on the failed node separately.

Q: How can I make the patching process run in the background?

A: Use the --waitForCompletion option with a value of false to allow the patching process to run in the background. This way, you don't need to wait for the process to complete interactively.

Q: Can I perform a rollback operation on a subset of nodes in a clustered environment?

A: Yes, you can use the --nodes option along with the --rollback option to roll back the patching on a specific set of nodes.

Q: What if I need to update the image location after starting the patch process?

A: The --resume option does not allow changing the image location. However, you can stop the session and start a new patch process with the updated --imageLocation.

Q: Is there a way to check which session IDs are available for resuming a patch?

A: You can check the log files or use Oracle Cloud tools to identify active or paused patching sessions and their session IDs.

Q: Can I limit the downtime during patching?

A: If you need to limit downtime, use the --continueWithDbDowntime option carefully. This allows you to proceed even when downtime is expected but requires planning for minimal service impact.

Example Use Cases

Example 1: Basic Oracle Home Patching by Oracle Home Path

dbaascli dbHome patch --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --targetVersion 19.12.0.0.0

Patches the Oracle home located at /u01/app/oracle/product/19.0.0/dbhome_1 to version 19.12.0.0.0.

Example 2: Patching by Oracle Home Name

dbaascli dbHome patch --oracleHomeName DB_HOME_NAME --targetVersion 19.12.0.0.0

Patches Oracle home named DB_HOME_NAME to version 19.12.0.0.0.

Example 3: Resuming a Previous Patch Operation

dbaascli dbHome patch --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --resume

Resumes the previous patching operation for the Oracle home located at /u01/app/oracle/product/19.0.0/dbhome_1.

Example 4: Resuming a Patch with a Specific Session ID

dbaascli dbHome patch --oracleHomeName DB_HOME_NAME --resume --sessionID 12345

Resumes the patching operation for Oracle home DB_HOME_NAME using session ID 12345.

Example 5: Patching with Database Downtime Allowed

dbaascli dbHome patch --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --targetVersion 19.12.0.0.0 --continueWithDbDowntime

Patches the Oracle home located at /u01/app/oracle/product/19.0.0/dbhome_1 to version 19.12.0.0.0 while allowing database downtime.

Example 6: Skipping Unreachable Nodes

dbaascli dbHome patch --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --targetVersion 19.12.0.0.0 --skipUnreachableNodes

Patches Oracle home to version 19.12.0.0.0 while skipping any unreachable nodes.

Example 7: Patching a Subset of Nodes

dbaascli dbHome patch --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --targetVersion 19.12.0.0.0 --nodes node1,node2

Patches Oracle home to version 19.12.0.0.0 on node1 and node2 only.

Example 8: Running Prerequisite Checks Before Patching

dbaascli dbHome patch --oracleHomeName DB_HOME_NAME --targetVersion 19.12.0.0.0 --executePrereqs

Patches Oracle home DB_HOME_NAME to version 19.12.0.0.0 after running prerequisite checks.

Example 9: Skipping the Datapatch Step

dbaascli dbHome patch --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --targetVersion 19.12.0.0.0 --skipDatapatch

Patches Oracle home to version 19.12.0.0.0 without running datapatch on the databases.

Example 10: Using an Image File for Patching

dbaascli dbHome patch --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --targetVersion 19.12.0.0.0 --imageFilePath /path/to/image/file.zip

Patches Oracle home to version 19.12.0.0.0 using an image file located at /path/to/image/file.zip.

Example 11: Skipping Specific PDBs During Datapatch

dbaascli dbHome patch --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --targetVersion 19.12.0.0.0 --skipPDBs cdb1:pdb1,cdb2:pdb2

Patches Oracle home to version 19.12.0.0.0 and skips running datapatch on the specified PDBs (pdb1 in cdb1 and pdb2 in cdb2).

Example 12: Skipping Datapatch on Closed PDBs

dbaascli dbHome patch --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --targetVersion 19.12.0.0.0 --skipClosedPDBs

Patches Oracle home to version 19.12.0.0.0 while skipping running datapatch on any closed PDBs.

Example 13: Rolling Back Oracle Home

dbaascli dbHome patch --oracleHomeName DB_HOME_NAME --rollback

Rolls back the last applied patch on the Oracle home named DB_HOME_NAME.

Example 14: Combination of Patching with Prerequisite Checks and Specific Nodes

dbaascli dbHome patch --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --targetVersion 19.12.0.0.0 --executePrereqs --nodes node1,node2

Patches Oracle home to version 19.12.0.0.0, runs prerequisite checks, and applies the patch only on node1 and node2.

Example 15: Skipping Unreachable Nodes and Specific PDBs

dbaascli dbHome patch --oracleHomeName DB_HOME_NAME --targetVersion 19.12.0.0.0 --skipUnreachableNodes --skipPDBs cdb1:pdb1

Patches Oracle home DB_HOME_NAME to version 19.12.0.0.0 while skipping unreachable nodes and avoiding running datapatch on pdb1 within cdb1.

Example 16: Checking Oracle Home Version Post-Patch

dbaascli dbHome patch --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --targetVersion 19.12.0.0.0

opatch lsinventory

This example shows how to check the Oracle home version after a successful patch by running opatch lsinventory.

Example 17: Rolling Back Patching with Specific Session ID

dbaascli dbHome patch --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --rollback --sessionID 67890

Rolls back the Oracle home patching for a session ID of 67890.

Example 18: Patching with Skipping Prerequisite Checks

dbaascli dbHome patch --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --targetVersion 19.12.0.0.0 --skipPrereqs

Patches the Oracle home but skips the prerequisite checks before applying the patch.

Example 19: Applying a Patch to a Custom Oracle Home Image

dbaascli dbHome patch --oracleHomeName DB_HOME_NAME --targetVersion 19.12.0.0.0 --imageLocation /custom/location/image.zip

Patches Oracle home using a custom image file located at /custom/location/image.zip.

Example 20: Skipping Specific Nodes and Running Prereqs

dbaascli dbHome patch --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --targetVersion 19.12.0.0.0 --skipUnreachableNodes --executePrereqs

Skips patching unreachable nodes and runs prerequisite checks before applying the patch.

Example 21: Skipping Datapatch on All PDBs in Multiple CDBs

dbaascli dbHome patch --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --targetVersion 19.12.0.0.0 --skipPDBs cdb1:pdb1,cdb2:pdb2,cdb3:pdb3

Patches Oracle home but skips datapatch on the specified PDBs in multiple CDBs.

Example 22: Continuing Patching with Downtime on Multiple Nodes

dbaascli dbHome patch --oracleHomeName DB_HOME_NAME --targetVersion 19.12.0.0.0 --continueWithDbDowntime --nodes node3,node4

Continues patching on node3 and node4 with database downtime allowed.

Example 23: Skipping Datapatch on PDBs and Closed PDBs

dbaascli dbHome patch --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --targetVersion 19.12.0.0.0 --skipDatapatch --skipClosedPDBs

Patches Oracle home while skipping both the datapatch and closed PDBs.

Example 24: Rolling Back and Reapplying Patch

dbaascli dbHome patch --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --rollback

dbaascli dbHome patch --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --targetVersion 19.12.0.0.0

Rolls back the current patch and then reapplies the patch to the Oracle home.

Example 25: Skipping Datapatch and Allowing Downtime on a Specific Node

dbaascli dbHome patch --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --targetVersion 19.13.0.0.0 --skipDatapatch --continueWithDbDowntime --nodes node1

Patches Oracle home to version 19.13.0.0.0 on node1, skipping the datapatch step and allowing downtime.

Example 26: Specifying Drain Timeout During Database Shutdown

dbaascli dbHome patch --oracleHomeName DB_HOME_NAME --targetVersion 19.13.0.0.0 --drainTimeoutInSeconds 300

Patches the Oracle home DB_HOME_NAME to version 19.13.0.0.0 and allows a 5-minute timeout (300 seconds) for draining resources during shutdown.

Example 27: Running Patching in the Background

dbaascli dbHome patch --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --targetVersion 19.13.0.0.0 --waitForCompletion false

Patches Oracle home to version 19.13.0.0.0 and runs the patching process in the background without waiting for completion.

Example 28: Rolling Back Patch on a Subset of Nodes

dbaascli dbHome patch --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --rollback --nodes node1,node2

Rolls back the last applied patch on node1 and node2 only for the specified Oracle home.

Example 29: Skipping Prerequisites and Patching Multiple Nodes

dbaascli dbHome patch --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --targetVersion 19.13.0.0.0 --skipPrereqs --nodes node3,node4

Patches Oracle home to version 19.13.0.0.0 on node3 and node4 without running prerequisite checks.

Example 30: Rolling Back Patch and Skipping Unreachable Nodes

dbaascli dbHome patch --oracleHomeName DB_HOME_NAME --rollback --skipUnreachableNodes

Rolls back the last patch on Oracle home DB_HOME_NAME and skips unreachable nodes during the rollback process.

dbaascli database move

To move the database from one home to another, use the dbaascli database move command.

Prerequisites

  • Before performing a move operation, ensure that all of the database instances associated with the database are up and running.
  • Run the command as the root user.

Syntax

dbaascli database move
{
  --oracleHome <value> | --oracleHomeName <value>
}
--dbname <value> 
[--executePrereqs] 
[--resume [--sessionID <value>]] 
[--rollback [--sessionID <value>]] 
[--skipDatapatch] 
[--skipPDBs <value>] 
[--skipClosedPDBs] 
[--continueWithDbDowntime] 
[--allowParallelDBMove] 
[--waitForCompletion <value>] 
[--nodeList <value>]

Where:

  • --oracleHome specifies Oracle home path
  • --oracleHomeName specifies the name of Oracle home
  • --dbname specifies the name of the database
  • --executePrereqs runs the prerequisite checks and report the results
  • --resume resumes the previous run
    • --sessionID specifies to resume a specific session ID
  • --rollback rolls the database back to previous home
    • --sessionID specifies to resume a specific session ID
  • --skipDatapatch skips running the datapatch on the databases
  • --skipPdbs skips running the datapatch on a specified comma-delimited list of PDBs. For example: pdb1,pdb2...
  • --skipClosedPDBs skips patching closed PDBs
  • --continueWithDbDowntime continues patching with database downtime. This option can be used in environments wherein there is only one active instance up and the patching operation can be continued even with a downtime.
  • --allowParallelDBMove allows database move in parallel.
  • --waitForCompletion specifies false to run the operation in the background. Valid values: true|false
  • --nodeList specifies a comma-delimited list of nodes if operation has to be performed on a subset of nodes

Frequently Asked Questions

Q: What is the dbaascli database move command used for?

A: The dbaascli database move command is used to move a database from one Oracle home to another.

Q: What are the prerequisites for using the dbaascli database move command?

A: Before performing a move operation, ensure that all database instances associated with the database are up and running. Additionally, the command must be run as the root user.

Q: What does the --oracleHome parameter specify?

A: The --oracleHome parameter specifies the path of the Oracle home to which the database will be moved.

Q: What does the --oracleHomeName parameter specify?

A: The --oracleHomeName parameter specifies the name of the Oracle home to which the database will be moved.

Q: What is the purpose of the --dbname parameter?

A: The --dbname parameter specifies the name of the database that you want to move.

Q: What does the --executePrereqs option do?

A: The --executePrereqs option runs the prerequisite checks and reports the results.

Q: What is the --resume option used for?

A: The --resume option resumes a previously interrupted or incomplete move operation.

Q: How is --sessionID used in the command?

A: The --sessionID specifies the session ID to resume a previous run or rollback.

Q: What does the --rollback option do?

A: The --rollback option rolls the database back to its previous Oracle home.

Q: What does the --skipDatapatch option do?

A: The --skipDatapatch option skips running the datapatch on the databases during the move operation.

Q: What is the function of the --skipPDBs option?

A: The --skipPDBs option skips running the datapatch on a specified comma-delimited list of PDBs (e.g., pdb1, pdb2).

Q: What does the --skipClosedPDBs option do?

A: The --skipClosedPDBs option skips patching of closed PDBs.

Q: What does --continueWithDbDowntime mean?

A: The --continueWithDbDowntime option allows the move operation to proceed even if there is only one active instance up, allowing for downtime during the process.

Q: What is the purpose of the --allowParallelDBMove option?

A: The --allowParallelDBMove option allows the database move to be performed in parallel, potentially speeding up the process.

Q: What does --waitForCompletion specify?

A: The --waitForCompletion option specifies whether to wait for the operation to complete. Setting it to false runs the operation in the background.

Q: How do I use the --nodeList parameter?

A: The --nodeList parameter specifies a comma-delimited list of nodes on which the move operation will be performed, if it is not to be applied to all nodes.

Q: What should I do if I encounter issues with the dbaascli database move command?

A: Ensure all database instances are running and verify that you are running the command as the root user. If issues persist, consult the detailed command documentation or open a support ticket with Oracle.

Q: Can I perform a move operation if one of the database instances is down?

A: No, all associated database instances must be up and running before performing the move operation.

Q: What happens if the move operation is interrupted?

A: You can use the --resume option to continue the move operation from where it left off by using the same session or specifying the --sessionID.

Q: What does the --allowParallelDBMove option do?

A: It enables the database move to be performed in parallel, which can reduce the time it takes to complete the operation, especially on larger environments.

Q: How do I monitor the progress of a move operation that is running in the background?

A: When using --waitForCompletion false, the command does not wait for the operation to complete. You can check the status of the operation manually using appropriate Oracle logs or status commands.

Q: What is the significance of the --skipClosedPDBs option?

A: It skips patching for PDBs that are closed, reducing the operation time if there are PDBs that don’t need to be patched.

Q: Can the database move be rolled back at any time?

A: Yes, the move operation can be rolled back using the --rollback option, either by specifying the session ID or simply rolling back to the previous Oracle home.

Q: What is the role of --nodeList in a multi-node environment?

A: In a multi-node environment, you can restrict the move operation to specific nodes by providing a comma-delimited list of node names with --nodeList.

Q: Can I move the database to a new Oracle home while skipping specific nodes in a multi-node environment?

A: Yes, you can use the --nodeList option to specify which nodes to include in the move operation. Any nodes not listed will be skipped.

Q: What is the maximum number of nodes I can specify with the --nodeList parameter?

A: The --nodeList parameter allows you to specify a comma-delimited list of as many nodes as needed, limited only by your environment configuration. Ensure all nodes are valid and reachable.

Q: How do I know which PDBs are closed before using the --skipClosedPDBs option?

A: You can query the v$pdbs view to check the status of your PDBs. Any PDBs with a status of "MOUNTED" or "CLOSED" will be skipped when using --skipClosedPDBs.

Q: How do I verify if a rollback has completed successfully?

A: After running the rollback command, you can review the database logs or use the Oracle alert logs to verify that the database has been successfully rolled back to its previous Oracle home.

Q: Is there a way to force the move operation if some prerequisites fail?

A: The move command enforces prerequisite checks for system stability. You cannot bypass critical prerequisite failures. Address any issues reported by the --executePrereqs option before proceeding with the move.

Example Use Cases

Example 1: Basic Database Move by Oracle Home Path

dbaascli database move --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --dbname ORCL

Moves the database ORCL to the Oracle home located at /u01/app/oracle/product/19.0.0/dbhome_1.

Example 2: Database Move by Oracle Home Name

dbaascli database move --oracleHomeName DB_HOME_NAME --dbname ORCL

Moves the database ORCL to the Oracle home named DB_HOME_NAME.

Example 3: Running Prerequisite Checks Before Moving

dbaascli database move --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --dbname ORCL --executePrereqs

Moves the database ORCL to the Oracle home while running the prerequisite checks beforehand.

Example 4: Resuming a Previous Move Operation

dbaascli database move --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --dbname ORCL --resume

Resumes a previous move operation for the ORCL database.

Example 5: Resuming a Move Operation with a Specific Session ID

dbaascli database move --oracleHomeName DB_HOME_NAME --dbname ORCL --resume --sessionID 12345

Resumes the move operation for the ORCL database using session ID 12345.

Example 6: Rolling Back a Move Operation

dbaascli database move --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --dbname ORCL --rollback

Rolls back the move operation for the ORCL database, restoring it to the previous Oracle home.

Example 7: Rolling Back a Move Operation with a Session ID

dbaascli database move --oracleHomeName DB_HOME_NAME --dbname ORCL --rollback --sessionID 67890

Rolls back the move operation for ORCL using session ID 67890.

Example 8: Skipping Datapatch

dbaascli database move --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --dbname ORCL --skipDatapatch

Moves the database ORCL without running datapatch on the databases.

Example 9: Skipping Specific PDBs During Datapatch

dbaascli database move --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --dbname ORCL --skipPDBs pdb1,pdb2

Moves the ORCL database to a new Oracle home but skips running datapatch on the specified PDBs (pdb1 and pdb2).

Example 10: Skipping Datapatch on Closed PDBs

dbaascli database move --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --dbname ORCL --skipClosedPDBs

Moves the ORCL database and skips running datapatch on any closed PDBs.

Example 11: Allowing Database Downtime During Move

dbaascli database move --oracleHomeName DB_HOME_NAME --dbname ORCL --continueWithDbDowntime

Moves the ORCL database to the specified Oracle home while allowing downtime of the database during the move process.

Example 12: Moving Database in Parallel

dbaascli database move --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --dbname ORCL --allowParallelDBMove

Moves the database ORCL to the specified Oracle home with the option to run the move in parallel for better performance.

Example 13: Running the Operation in the Background

dbaascli database move --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --dbname ORCL --waitForCompletion false

Moves the database ORCL to a new Oracle home but runs the operation in the background.

Example 14: Specifying Nodes for the Move

dbaascli database move --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --dbname ORCL --nodeList node1,node2

Moves the database ORCL to the specified Oracle home but performs the operation only on node1 and node2.

Example 15: Combination of Move with Prerequisite Checks, Skipping Specific PDBs, and Allowing Downtime

dbaascli database move --oracleHomeName DB_HOME_NAME --dbname ORCL --executePrereqs --skipPDBs pdb1 --continueWithDbDowntime

Moves the ORCL database to the specified Oracle home, runs prerequisite checks, skips running datapatch on pdb1, and allows database downtime during the operation.

Example 16: Combination of Move in Parallel and Running in the Background

dbaascli database move --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --dbname ORCL --allowParallelDBMove --waitForCompletion false

Moves the ORCL database to a new Oracle home, runs the move in parallel, and executes the operation in the background.

Example 17: Combining Move with Parallel Execution and Skipping Closed PDBs

dbaascli database move --oracleHome /u02/app/oracle/product/19.0.0/dbhome_2 --dbname TESTDB --allowParallelDBMove --skipClosedPDBs

Moves the TESTDB database to the new Oracle home /u02/app/oracle/product/19.0.0/dbhome_2, while running the operation in parallel and skipping datapatch on closed PDBs.

Example 18: Running Prerequisites Check Only

dbaascli database move --oracleHome /u02/app/oracle/product/19.0.0/dbhome_2 --dbname PRODDB --executePrereqs

Checks the prerequisites for moving the PRODDB database to the Oracle home located at /u02/app/oracle/product/19.0.0/dbhome_2 without actually performing the move.

Example 19: Skipping Datapatch for Specific PDBs

dbaascli database move --oracleHome /u02/app/oracle/product/19.0.0/dbhome_2 --dbname HRDB --skipPDBs pdb1,pdb3

Moves the HRDB database to the new Oracle home, but skips running datapatch for pdb1 and pdb3.

Example 20: Running the Move on Specific Nodes

dbaascli database move --oracleHome /u02/app/oracle/product/19.0.0/dbhome_2 --dbname FINDB --nodeList node1,node3

Moves the FINDB database to the new Oracle home only on node1 and node3.

Example 21: Database Move with Downtime Allowed

dbaascli database move --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --dbname ORCL --continueWithDbDowntime

Moves the ORCL database to the specified Oracle home while allowing downtime during the move operation.

Example 22: Combination of Parallel Move and Skipping Datapatch

dbaascli database move --oracleHome /u02/app/oracle/product/19.0.0/dbhome_2 --dbname CRMDB --allowParallelDBMove --skipDatapatch

Moves the CRMDB database in parallel, skipping the datapatch process.

Example 23: Move Operation in Background with a Node List

dbaascli database move --oracleHome /u02/app/oracle/product/19.0.0/dbhome_2 --dbname SALESDB --waitForCompletion false --nodeList node2,node3

Moves the SALESDB database to the specified Oracle home in the background, and the operation is applied only on node2 and node3.

Example 24: Database Move with Prerequisite Check and Allowing Parallel Move

dbaascli database move --oracleHome /u01/app/oracle/product/19.0.0/dbhome_2 --dbname ORCL --executePrereqs --allowParallelDBMove

Moves the ORCL database to the new Oracle home after performing the prerequisite checks and running the move operation in parallel.

Example 25: Rolling Back a Move Operation and Skipping Closed PDBs

dbaascli database move --oracleHome /u02/app/oracle/product/19.0.0/dbhome_2 --dbname DEVDB --rollback --skipClosedPDBs

Rolls back the move operation for the DEVDB database, skipping any closed PDBs.

Example 26: Moving the Database with Specific Downtime and Parallel Execution

dbaascli database move --oracleHome /u02/app/oracle/product/19.0.0/dbhome_2 --dbname FINDB --allowParallelDBMove --continueWithDbDowntime

Moves the FINDB database to the specified Oracle home while allowing database downtime and enabling parallel execution to speed up the process.

Example 27: Checking Database Move Prerequisites without Executing the Move

dbaascli database move --oracleHome /u01/app/oracle/product/19.0.0/dbhome_1 --dbname HRDB --executePrereqs

Runs prerequisite checks to validate that the HRDB database can be moved to the specified Oracle home without executing the move itself.

Example 28: Moving Database and Running the Command in the Background on Specific Nodes

dbaascli database move --oracleHome /u02/app/oracle/product/19.0.0/dbhome_3 --dbname PRODDB --waitForCompletion false --nodeList node1,node4

Moves the PRODDB database to a new Oracle home, executing the operation in the background, and applying it only on node1 and node4.

Example 29: Combining Prerequisite Checks, Skipping Closed PDBs, and Allowing Parallel Execution

dbaascli database move --oracleHome /u02/app/oracle/product/19.0.0/dbhome_2 --dbname CRMDB --executePrereqs --skipClosedPDBs --allowParallelDBMove

Performs prerequisite checks before moving the CRMDB database to the new Oracle home, skips patching closed PDBs, and allows the operation to run in parallel for faster execution.

Example 30: Database Move with Rollback on Specific Session ID and Skipping Datapatch

dbaascli database move --oracleHomeName DB_HOME_NAME --dbname DEVDB --rollback --sessionID 45678 --skipDatapatch

Rolls back a previously executed move operation for the DEVDB database to its prior Oracle home using session ID 45678, skipping the datapatch process during the rollback.

Example 31: Moving Database with Allow Parallel Execution and Specifying Datapatch Skipping for PDBs

dbaascli database move --oracleHome /u02/app/oracle/product/19.0.0/dbhome_3 --dbname ANALYTICDB --allowParallelDBMove --skipPDBs pdb2,pdb4

Moves the ANALYTICDB database in parallel to the specified Oracle home and skips the datapatch process for pdb2 and pdb4.

Miscellaneous

Q: How can I skip the catbundle run while patching Oracle Database 11.2.0.4.0?

A: To skip the catbundle run during the Oracle Database patching process, use the --skipDatapatch option with the dbaascli database move or dbaascli dbHome patch command.

Q: What are the best practices to follow during Oracle Database patching?

A: Oracle recommends performing out-of-place patching using the dbaascli database move command to minimize the patching window.

Oracle advises using the --allowParallelDBMove option to enable parallel patching, which can expedite the process.

Q: Can warnings reported during Oracle Database patch prerequisites be ignored?

A: It is advisable to address and resolve any warnings reported during the prerequisites check before proceeding with the patching process. Ignoring warnings may lead to issues during the actual patching.

Q: How can I continue with Oracle Database patching if only one database instance is up and running?

A: It is recommended to have at least two instances running to avoid database downtime. If running two instances is not possible, you can use the --continueWithDbDowntime option with the dbaascli database move or dbaascli dbHome patch command to proceed with patching despite the downtime.

Q: In a Data Guard environment, does datapatch get executed on both the primary and standby databases?

A: No, in a Data Guard environment, datapatch is executed only as part of the primary database patching process.

Q: Can Interim Software Updates (one-off patches) or individual patches be applied manually on Oracle Homes in Exadata Cloud@Customer (ExaDB-C@C) environments?

A: Yes, one-off patches or individual patches can be applied manually to Oracle Homes in ExaDB-C@C environments. However, it is recommended to use the Oracle Database Software Image option for a more streamlined and supported patching process.

Q: How do I patch multiple Oracle databases running from the same Oracle Home when each database is running on just one node?

A: Use the dbaascli dbHome patch command to patch the specified Oracle Home, which will apply the patch to all databases running from that home. It is recommended to have multiple instances running to avoid downtime. If running multiple instances is not possible, you can use the --continueWithDbDowntime option to proceed with patching despite the downtime.

Pluggable Database (PDB) Management

This section covers the management of Pluggable Databases (PDBs) within a container database (CDB). It includes commands for creating (dbaascli pdb create), deleting (dbaascli pdb delete), and cloning PDBs (dbaascli pdb localClone, dbaascli pdb remoteClone). You can manage PDB states with commands to open, close, or bounce PDBs, and retrieve connection details (dbaascli pdb getConnectString). Additional commands support backup, recovery, and relocating PDBs, ensuring comprehensive control over PDB lifecycle and operations.

dbaascli pdb backup

To backup a pluggable database (PDB), query PDB backups, and delete a PDB backup, use the dbaascli pdb backup command.

Prerequisite

  • Run the command as the root user.

Syntax

dbaascli pdb backup --pdbName <value> --dbname <value>
        {
            --start
                {
                    [--level1]
                    | [--archival --tag <value>]
                }
            | --delete --backupTag <value>
            | --status --uuid <value>
            | --getBackupReport --json <value> --tag <value>
            | --list [--json <value>]
        }
Where:
--pdbName: PDB name.
--dbname: Oracle Database name.
--start | --delete | --status | --getBackupReport | --list
--start: Begins PDB backup.
      [--level1 | --archival]
      [--level1: Creates a Level-1 (incremental) backup.]
      [--archival: Creates an archival full backup.]
          --tag: Specify backup tag.
--delete: Deletes archival backup.
          --backupTag: Specify backup tag to delete.
--status
          --uuid <value>
--getBackupReport: Returns backup report.
         --json: Specify the file name for JSON output.
         --tag: Specify backup tag.
--list: Returns PDB backup information.
         [--json: Specify the file name for JSON output.]

Frequently Asked Questions

Q: What is the purpose of the dbaascli pdb backup command?

A: The dbaascli pdb backup command is used to create backups for a pluggable database (PDB), query backup status, generate backup reports, and delete PDB backups in an Exadata Cloud@Customer environment.

Q: What is the prerequisite for using the dbaascli pdb backup command?

A: The command must be run as the root user, and you need to be connected to an Exadata Cloud@Customer virtual machine.

Q: How do I start a PDB backup using the dbaascli pdb backup command?

A: You can start a PDB backup using the --start option. For example:

dbaascli pdb backup --pdbName <PDB_Name> --dbname <DB_Name> --start

Q: What options can be used with the --start flag?

A: With the --start flag, you can specify:

--level1 for a Level-1 incremental backup

--archival for a full archival backup (which also requires a --tag to specify the backup tag)

Q: How do I create a Level-1 incremental PDB backup?

A: Use the --level1 flag with the --start option to create a Level-1 incremental backup:

dbaascli pdb backup --pdbName <PDB_Name> --dbname <DB_Name> --start --level1

Q: How do I create an archival PDB backup?

A: Use the --archival flag with the --start option and specify a backup tag using --tag:

dbaascli pdb backup --pdbName <PDB_Name> --dbname <DB_Name> --start --archival --tag <backup_tag>

Q: How do I delete a specific PDB backup?

A: To delete a specific backup, use the --delete flag and specify the backup tag using --backupTag:

dbaascli pdb backup --pdbName <PDB_Name> --dbname <DB_Name> --delete --backupTag <backup_tag>

Q: How can I check the status of a PDB backup?

A: Use the --status flag along with the backup --uuid to check the status of a specific backup:

dbaascli pdb backup --pdbName <PDB_Name> --dbname <DB_Name> --status --uuid <backup_uuid>

Q: How do I retrieve a PDB backup report in JSON format?

A: To get a backup report in JSON format, use the --getBackupReport option, specify the file name with --json, and provide the backup tag with --tag:

dbaascli pdb backup --pdbName <PDB_Name> --dbname <DB_Name> --getBackupReport --json <file_name> --tag <backup_tag>

Q: How can I list all PDB backups for a specific PDB?

A: Use the --list option to get a list of all backups for a given PDB:

dbaascli pdb backup --pdbName <PDB_Name> --dbname <DB_Name> --list

Optionally, you can output the list in JSON format using the --json flag:

dbaascli pdb backup --pdbName <PDB_Name> --dbname <DB_Name> --list --json <file_name>

Q: What does the --pdbName option do?

A: The --pdbName option specifies the name of the pluggable database (PDB) that you want to back up, query, or delete backups for.

Q: What is the purpose of the --dbname option?

A: The --dbname option specifies the name of the Oracle Database to which the PDB belongs.

Q: How do I specify a backup tag for a PDB backup?

A: You specify a backup tag using the --tag option when starting an archival backup or when retrieving a backup report:

--tag <backup_tag>

Q: Can I run PDB backups in JSON mode?

A: Yes, both the backup report (--getBackupReport) and backup listing (--list) options support output in JSON format. You specify a JSON file name using the --json option.

Example 7-30 Examples

  • To take level1 backup for a PDB pdb1 in a CDB myTestDb:
    dbaascli pdb backup --dbname myTestDb --pdbName pdb1 --start --level1
  • To query the status of PDB backup request submitted with uuid eef16b26361411ecb13800163e8e4fac:
    dbaascli pdb backup --dbname myTestDb --pdbName pdb1 --status --uuid eef16b26361411ecb13800163e8e4fac
dbaascli pdb bounce

To bounce a pluggable database (PDB), use the dbaascli pdb bounce command.

Prerequisite

Run the command as the oracle user.

Syntax

dbaascli pdb bounce --dbname --pdbName | --pdbUID
[–openMode]
Where:
  • --dbname specifies the name of the container database that hosts the PDB
  • --pdbName specifies the name of the PDB
  • --pdbUID specifies the identifier of the PDB
  • --openMode specifies the target OPEN MODE of PDB

Frequently Asked Questions

Q: What is the purpose of the dbaascli pdb bounce command?

A: The dbaascli pdb bounce command is used to bounce (restart) a pluggable database (PDB) in an Exadata Cloud@Customer environment.

Q: What are the prerequisites for using the dbaascli pdb bounce command?

A: The command must be run as the oracle user, and you must be connected to an Exadata Cloud@Customer virtual machine.

Q: How do I bounce a PDB by specifying its name?

A: To bounce a PDB by specifying its name, use the following syntax:

dbaascli pdb bounce --dbname <CDB_Name> --pdbName <PDB_Name>

Q: How do I bounce a PDB by using its unique identifier (UID)?

A: To bounce a PDB using its unique identifier (UID), use the following syntax:

dbaascli pdb bounce --dbname <CDB_Name> --pdbUID <PDB_UID>

Q: What is the --dbname option used for?

A: The --dbname option specifies the name of the container database (CDB) that hosts the pluggable database (PDB) being bounced.

Q: What is the --pdbName option used for?

A: The --pdbName option specifies the name of the pluggable database (PDB) that you want to bounce.

Q: What is the --pdbUID option used for?

A: The --pdbUID option specifies the unique identifier (UID) of the pluggable database (PDB) that you want to bounce.

Q: How do I specify the target open mode for the PDB when bouncing it?

A: You can use the --openMode option to specify the desired open mode for the PDB after bouncing. The valid values are READ_WRITE and READ_ONLY. For example:

dbaascli pdb bounce --dbname <CDB_Name> --pdbName <PDB_Name> --openMode READ_WRITE

Q: Can I open the PDB in read-only mode after bouncing it?

A: Yes, you can use the --openMode READ_ONLY option to open the PDB in read-only mode after bouncing:

dbaascli pdb bounce --dbname <CDB_Name> --pdbName <PDB_Name> --openMode READ_ONLY

Q: What is the default open mode if --openMode is not specified?

A: If --openMode is not specified, the PDB will be opened in its default open mode, which is typically READ_WRITE.

Q: Can I use both --pdbName and --pdbUID in the same command?

A: No, you should specify either --pdbName or --pdbUID, but not both in the same command.

Q: How can I restart a PDB and ensure it opens in read-write mode?

A: To restart a PDB and ensure it opens in read-write mode, use the --openMode READ_WRITE option:

dbaascli pdb bounce --dbname <CDB_Name> --pdbName <PDB_Name> --openMode READ_WRITE

Q: Is it mandatory to specify the open mode when using the dbaascli pdb bounce command?

A: No, specifying the --openMode is optional. If not provided, the PDB will open in its default mode.

Q: What happens if I don't specify the --openMode flag?

A: If the --openMode flag is not specified, the PDB will be opened in its default mode, which is typically READ_WRITE.

Example 7-31 dbaascli pdb bounce

dbaascli pdb bounce --dbname cdb_name --pdbName pdb name associated with the CDB
dbaascli pdb bounce --dbname cdb_name --pdbUID con_uid of that pdb
Optional:
  • --openMode READ_WRITE
  • --openMode READ_ONLY
dbaascli pdb close

To close a pluggable database (PDB), use the dbaascli pdb close command.

Prerequisite

Run the command as the oracle user.

Syntax

dbaascli pdb close --dbname --pdbName | --pdbUID
Where:
  • --dbname specifies the name of the container database that hosts the PDB.
  • --pdbname specifies the name of the PDB that you want to close.
  • --pdbUID specifies the identifier of the PDB

Upon successful completion of running this command, the PDB is closed on all of the container database instances.

Frequently Asked Questions

Q: What is the purpose of the dbaascli pdb close command?

A: The dbaascli pdb close command is used to close a pluggable database (PDB) in an Exadata Cloud@Customer environment.

Q: What are the prerequisites for using the dbaascli pdb close command?

A: The command must be run as the oracle user, and you must be connected to an Exadata Cloud@Customer virtual machine.

Q: How do I close a PDB by specifying its name?

A: To close a PDB by specifying its name, use the following syntax:

dbaascli pdb close --dbname <CDB_Name> --pdbName <PDB_Name>

Q: How do I close a PDB by specifying its unique identifier (UID)?

A: To close a PDB by using its unique identifier (UID), use the following syntax:

dbaascli pdb close --dbname <CDB_Name> --pdbUID <PDB_UID>

Q: What does the --dbname option do in the dbaascli pdb close command?

A: The --dbname option specifies the name of the container database (CDB) that hosts the pluggable database (PDB) you want to close.

Q: What does the --pdbName option do in the dbaascli pdb close command?

A: The --pdbName option specifies the name of the pluggable database (PDB) that you want to close.

Q: What is the purpose of the --pdbUID option in the dbaascli pdb close command?

A: The --pdbUID option allows you to specify the unique identifier (UID) of the pluggable database (PDB) that you want to close.

Q: Can I close the PDB on a specific instance of the CDB?

A: No, upon successful completion, the PDB is closed on all instances of the container database (CDB).

Q: Is it possible to specify both --pdbName and --pdbUID in the same command?

A: No, you can specify either --pdbName or --pdbUID, but not both in the same command.

Q: What happens when the dbaascli pdb close command completes successfully?

A: When the command completes successfully, the pluggable database (PDB) is closed on all instances of the container database (CDB).

Q: How do I close a specific PDB within a CDB using its UID?

A: You can close a specific PDB using its UID by running:

dbaascli pdb close --dbname <CDB_Name> --pdbUID <PDB_UID>

Q: What happens if I forget to specify either --pdbName or --pdbUID?

A: You must specify either --pdbName or --pdbUID in the command. If neither is provided, the command will not run.

Q: Can I use the dbaascli pdb close command for a CDB directly?

A: No, the command is designed to close a pluggable database (PDB) within a container database (CDB), not the CDB itself.

Example 7-32 dbaascli pdb close

dbaascli pdb close --dbname cdb name --pdbName pdb name associated with the CDB
dbaascli pdb close --dbname cdb name --pdbUID con_uid of that pdb
dbaascli pdb create

To create a new pluggable database (PDB), use the dbaascli pdb create command.

Prerequisite

Run the command as the oracle user.

Syntax

dbaascli pdb create --pdbName <value> --dbName <value> 
[--maxCPU <value>] 
[--maxSize <value>] 
[--pdbAdminUserName <value>] 
[--lockPDBAdminAccount <value>] 
[--resume [--sessionID <value>]] 
[--executePrereqs <value>] 
[--waitForCompletion <value>] 
[--blobLocation |--standbyBlobFromPrimary <value>]
Where:
  • --pdbName specifies the name of the new PDB that you want to create
  • --dbName specifies the name of the container database that hosts the new PDB
  • --maxCPU optionally specifies the maximum number of CPUs that are available to the PDB. Setting this option is effectively the same as setting the CPU_COUNT parameter in the PDB
  • --maxSize optionally specifies the maximum total size of data files and temporary files for tablespaces belonging to the PDB. Setting this option is effectively the same as setting the MAXSIZE PDB storage clause in the CREATE PLUGGABLE DATABASE SQL command. You can impose a limit by specifying an integer followed by a size unit (K, M, G, or T), or you can specify UNLIMITED to explicitly enforce no limit
  • --pdbAdminUserName specifies the new PDB admin user name
  • --lockPDBAdminAccount specifies true or false to lock the PDB admin user account. Default value is true.
  • --resume resumes the previous run
    • --sessionID specifies to resume a specific session ID
  • --executePrereqs specifies yes to run only the prereqs for this operation. Valid values: yes or no
  • --waitForCompletion specifies false to run the operation in the background. Valid values: true or false
  • --blobLocation custom directory location where the standby blob file will be generated in a DG environment.
  • --standbyBlobFromPrimary specifies the location of the standby blob file, which is prepared from the primary database. This is required only for standby database PDB operations.
    Note

    the parametersblobLocation and standbyBlobFromPrimary are mutually exclusive.

During the PDB creation process, you are prompted to specify the administration password for the new PDB.

Frequently Asked Questions

Q: What is the purpose of the dbaascli pdb create command?

A: The dbaascli pdb create command is used to create a new pluggable database (PDB) in a container database (CDB) in an Exadata Cloud@Customer environment.

Q: What are the prerequisites for using the dbaascli pdb create command?

A: The command must be run as the oracle user, and you must be connected to an Exadata Cloud@Customer virtual machine.

Q: What does the --pdbName option do in the dbaascli pdb create command?

A: The --pdbName option specifies the name of the new pluggable database (PDB) you want to create.

Q: What does the --dbName option do in the dbaascli pdb create command?

A: The --dbName option specifies the name of the container database (CDB) that will host the new pluggable database (PDB).

Q: Can I limit the CPU resources for the new PDB?

A: Yes, you can use the --maxCPU option to specify the maximum number of CPUs that the PDB can use. This is equivalent to setting the CPU_COUNT parameter in the PDB.

Q: How can I limit the storage size of a PDB?

A: You can use the --maxSize option to specify the maximum total size of data files and temporary files for the PDB. You can either set a size limit (in K, M, G, or T) or specify UNLIMITED for no limit.

Q: What is the --pdbAdminUserName option used for?

A: The --pdbAdminUserName option specifies the name of the admin user for the new PDB. This user will have administrative privileges within the PDB.

Q: Is it possible to lock the admin user account during PDB creation?

A: Yes, you can use the --lockPDBAdminAccount option to specify whether the PDB admin account should be locked. The default value is true (locked).

Q: What does the --resume option do in the dbaascli pdb create command?

A: The --resume option allows you to resume a previously failed PDB creation process.

Q: How do I specify a session ID for resuming a previous run?

A: You can specify a session ID using the --sessionID option to resume a specific session of the PDB creation process.

Q: What is the purpose of the --executePrereqs option?

A: The --executePrereqs option specifies whether to run only the prerequisite checks for PDB creation. You can set this option to yes or no.

Q: Can I run the PDB creation process in the background?

A: Yes, you can use the --waitForCompletion option and set it to false to run the operation in the background.

Q: What is the --standbyBlobFromPrimary option used for?

A: The --standbyBlobFromPrimary option specifies the location of the standby blob file, which is prepared from the primary database. This is required for standby database PDB operations.

Q: How will I be prompted for the PDB admin password during the creation process?

A: During the PDB creation process, you will be prompted to specify the administration password for the new PDB.

Q: Can I create a standby PDB using the dbaascli pdb create command?

A: Yes, if you are creating a standby PDB, you can use the --standbyBlobFromPrimary option to specify the location of the standby blob file from the primary database.

Q: What happens if I don't use the --maxSize option?

A: If you do not specify the --maxSize option, the PDB will not have a storage size limit unless otherwise defined by the CDB policies.

Q: What happens if I do not provide the --pdbAdminUserName option?

A: If you do not provide the --pdbAdminUserName option, the PDB will be created without a specified admin user, and you will need to manually configure the admin user after creation.

Q: Can I resume a failed PDB creation at any point in the process?

A: Yes, as long as the session has not been terminated, you can resume a failed PDB creation using the --resume and --sessionID options.

Example 7-33 dbaascli pdb create

To create a PDB from seed in a standard database in a non-Data Guard environment:
dbaascli pdb create --dbName db721 --pdbName new_pdb1 --maxsize 5G --maxcpu 2
To create PDB in Data Guard environment:
dbaascli pdb create --dbName db721 --pdbName new_pdb1
dbaascli pdb create --dbName db721 --pdbName new_pdb1 --standbyBlobFromPrimary /tmp/send_db721.tar
dbaascli pdb delete

To delete a pluggable database (PDB) run the dbaascli pdb delete command.

Prerequisite

Run the command as the oracle user.

Syntax

dbaascli pdb delete --dbName value 
{ --pdbName value | --pdbUID value }
[--executePrereqs value]
[--waitForCompletion value]
[--resume [--sessionID value]]
[--allStandbyPrepared]
[--cleanupRelocatedPDB]
Where:
  • --dbName specifies the name of the container database that hosts the PDB
  • --pdbName specifies the name of the PDB that you want to delete
  • --pdbUID specifies the UID of the PDB that you want to delete
  • --executePrereqs specifies yes to run only the prereqs for this operation. Valid values: yes or no
  • --waitForCompletion specifies false to run the operation in the background. Valid values: true or false
  • --resume specifies to resume the previous execution
    • --sessionID specifies to resume a specific session ID
  • --allStandbyPrepared specifies to confirm that the operation has been successfully run on all the standby databases
  • --cleanupRelocatedPDB - option to cleanup source database after a PDB has been relocated.

Frequently Asked Questions

Q: What is the purpose of the dbaascli pdb delete command?

A: The dbaascli pdb delete command is used to delete a pluggable database (PDB) from a container database (CDB) in an Exadata Cloud@Customer environment.

Q: What are the prerequisites for running the dbaascli pdb delete command?

A: The command must be run as the oracle user, and you must be connected to an Exadata Cloud@Customer virtual machine.

Q: What does the --dbName option specify in the dbaascli pdb delete command?

A: The --dbName option specifies the name of the container database (CDB) that hosts the PDB you want to delete.

Q: How can I specify which PDB to delete using the dbaascli pdb delete command?

A: You can specify the PDB to delete using either the --pdbName option (specifies the PDB name) or the --pdbUID option (specifies the PDB UID).

Q: Can I run the prerequisite checks without actually deleting the PDB?

A: Yes, you can use the --executePrereqs option and set it to yes to run only the prerequisite checks for the PDB deletion operation.

Q: How can I run the PDB deletion process in the background?

A: Use the --waitForCompletion option and set it to false to run the deletion process in the background.

Q: What does the --resume option do in the dbaascli pdb delete command?

A: The --resume option allows you to resume a previously failed PDB deletion process.

Q: How do I resume a specific session for a PDB deletion?

A: You can specify a session ID using the --sessionID option to resume a specific session for the PDB deletion process.

Q: What does the --allStandbyPrepared option do?

A: The --allStandbyPrepared option is used to confirm that the deletion operation has been successfully run on all standby databases before proceeding with the primary PDB deletion.

Q: What is the purpose of the --cleanupRelocatedPDB option?

A: The --cleanupRelocatedPDB option cleans up the source database after a PDB has been relocated, ensuring no residuals are left after the relocation.

Q: Can I delete a PDB that has already been relocated?

A: Yes, you can use the --cleanupRelocatedPDB option to delete a PDB that has already been relocated to a new CDB.

Q: How do I ensure that the delete operation runs successfully on standby databases?

A: Use the --allStandbyPrepared option to confirm that the operation has run successfully on all standby databases before proceeding.

Q: What happens if the delete process fails and needs to be resumed?

A: You can resume the delete process by using the --resume option, and if needed, specify the session ID with --sessionID.

Q: What does setting --waitForCompletion to false do?

A: Setting --waitForCompletion to false allows the delete process to run in the background, letting you continue working without waiting for the operation to finish.

Example: dbaascli pdb delete

To delete a PDB from a standard database in a non-Data Guard environment or from Standby database in Data Guard environment.

dbaascli pdb delete --dbName db721 --pdbName pdb1

To create PDB from Primary database in Data Guard environment:

dbaascli pdb create --dbName db721 --pdbName pdb1 --allStandbyPrepared
dbaascli pdb getConnectString

To display Oracle Net connect string information for a pluggable database (PDB) run the dbaascli pdb getConnectString command.

Prerequisite

Run the command as the oracle user.

Syntax

dbaascli pdb getConnectString --dbname --pdbName | --pdbUID
Where:
  • --dbname specifies the name of the container database that hosts the PDB
  • --pdbname specifies the name of the PDB for which you want to display connect string information
  • --pdbUID specifies the identifier of the PDB

Frequently Asked Questions

Q: What is the purpose of the dbaascli pdb getConnectString command?

A: The dbaascli pdb getConnectString command is used to display the Oracle Net connect string information for a pluggable database (PDB) in an Exadata Cloud@Customer environment.

Q: What are the prerequisites for using the dbaascli pdb getConnectString command?

A: The command must be run as the oracle user, and you must be connected to an Exadata Cloud@Customer virtual machine.

Q: How do I retrieve the connect string of a PDB by specifying its name?

A: To retrieve the connect string by specifying the PDB name, use the following syntax:

dbaascli pdb getConnectString --dbname <CDB_Name> --pdbName <PDB_Name>

Q: How do I retrieve the connect string of a PDB by specifying its unique identifier (UID)?

A: To retrieve the connect string using the PDB's unique identifier (UID), use the following syntax:

dbaascli pdb getConnectString --dbname <CDB_Name> --pdbUID <PDB_UID>

Q: What does the --dbname option do in the dbaascli pdb getConnectString command?

A: The --dbname option specifies the name of the container database (CDB) that hosts the pluggable database (PDB) for which you want to display the connect string information.

Q: What does the --pdbName option do in the dbaascli pdb getConnectString command?

A: The --pdbName option specifies the name of the pluggable database (PDB) for which you want to retrieve the Oracle Net connect string information.

Q: What is the purpose of the --pdbUID option in the dbaascli pdb getConnectString command?

A: The --pdbUID option allows you to specify the unique identifier (UID) of the pluggable database (PDB) for which you want to display the connect string.

Q: Can I use both --pdbName and --pdbUID in the same command?

A: No, you can use either --pdbName or --pdbUID, but not both in the same command.

Q: What type of information is returned by the dbaascli pdb getConnectString command?

A: The command returns the Oracle Net connect string information for the specified pluggable database (PDB).

Q: Can I retrieve the connect string for a PDB on a specific container database instance?

A: No, the connect string is for the PDB as a whole, not for a specific instance of the container database.

Q: How can I get the connect string information if I only know the PDB's unique identifier (UID)?

A: You can retrieve the connect string using the PDB's UID by running:

dbaascli pdb getConnectString --dbname <CDB_Name> --pdbUID <PDB_UID>

Q: What happens if I don't provide either --pdbName or --pdbUID?

A: You must specify either --pdbName or --pdbUID to retrieve the connect string. The command will not run without one of these options.

Q: Is the connect string information for the PDB always the same across all instances of the CDB?

A: Yes, the connect string information is consistent for the PDB across all instances of the container database (CDB).

Example 7-34 dbaascli pdb getConnectString

dbaascli pdb getConnectString --dbname dbname --pdbName pdbName
dbaascli pdb getDetails

To view details of a pluggable database (PDB), use the dbaascli pdb getDetails command.

Prerequisite

Run the command as the oracle user.

Syntax

dbaascli pdb getDetails --dbname --pdbName | --pdbUID
Where:
  • --dbname specifies the name of the container database that hosts the PDB
  • --pdbname specifies the name of the PDB that you want to delete
  • --pdbUID specifies the identifier of the PDB

Frequently Asked Questions

Q: What is the purpose of the dbaascli pdb getDetails command?

A: The dbaascli pdb getDetails command is used to view details of a pluggable database (PDB) hosted in a container database (CDB) in an Exadata Cloud@Customer environment.

Q: What are the prerequisites for running the dbaascli pdb getDetails command?

A: The command must be run as the oracle user, and you must be connected to an Exadata Cloud@Customer virtual machine.

Q: What does the --dbname option specify in the dbaascli pdb getDetails command?

A: The --dbname option specifies the name of the container database (CDB) that hosts the PDB for which you want to view details.

Q: How do you specify the PDB for which you want to view details?

A: You can specify the PDB using either the --pdbName option (to provide the PDB name) or the --pdbUID option (to provide the PDB UID).

Q: What is the difference between --pdbName and --pdbUID?

A: The --pdbName option uses the name of the PDB to fetch details, whereas the --pdbUID option uses the unique identifier (UID) of the PDB to fetch its details.

Q: Can I use both --pdbName and --pdbUID together in the dbaascli pdb getDetails command?

A: No, you can specify either the --pdbName or the --pdbUID option to get details of the PDB, but not both at the same time.

Q: What are some use cases for the dbaascli pdb getDetails command?

A: You can use the dbaascli pdb getDetails command to:
  • Retrieve details about a specific PDB in a CDB.
  • Verify the configuration of a PDB.
  • Check the status of a PDB within a CDB.

Q: How can I view details of a PDB based on its name?

A: To view details of a PDB based on its name, use the following syntax:

dbaascli pdb getDetails --dbname <CDB_Name> --pdbName <PDB_Name>

Q: How can I view details of a PDB based on its UID?

A: To view details of a PDB based on its UID, use the following syntax:

dbaascli pdb getDetails --dbname <CDB_Name> --pdbUID <PDB_UID>

Q: Can this command be used for multiple PDBs in one execution?

A: No, the command can be used to fetch details of one PDB at a time by specifying either its name or UID.

Example 7-35 dbaascli pdb getDetails

dbaascli pdb getDetails--dbname cdb name --pdbName pdb name associated with the CDB
dbaascli pdb getDetails--dbname cdb name --pdbUID con_uid of that pdb
dbaascli pdb list

To view the list of pluggable databases (PDB) in a container database, use the dbaascli pdb list command.

Prerequisite

Run the command as the oracle user.

Syntax

dbaascli pdb list --dbname
Where:
  • --dbname specifies the name of the container database that hosts the PDB

Frequently Asked Questions

Q: What is the purpose of the dbaascli pdb list command?

A: The dbaascli pdb list command is used to view the list of pluggable databases (PDBs) in a specified container database (CDB) in an Exadata Cloud@Customer environment.

Q: What are the prerequisites for running the dbaascli pdb list command?

A: The command must be run as the oracle user, and you must be connected to an Exadata Cloud@Customer virtual machine.

Q: What does the --dbname option specify in the dbaascli pdb list command?

A: The --dbname option specifies the name of the container database (CDB) that hosts the pluggable databases (PDBs) for which you want to view the list.

Q: Can I view the list of PDBs from multiple container databases at once?

A: No, the dbaascli pdb list command allows you to list the PDBs from only one container database (CDB) at a time, specified by the --dbname option.

Q: How do I list the PDBs in a specific container database (CDB)?

A: You can list the PDBs in a specific CDB by using the following syntax:

dbaascli pdb list --dbname <CDB_Name>

Q: What information is displayed when using the dbaascli pdb list command?

A: The command returns a list of all pluggable databases (PDBs) within the specified container database (CDB). The list typically includes the names of the PDBs and possibly other details like their status.

Q: Can I filter the PDB list using additional options?

A: No, the dbaascli pdb list command does not support additional filtering options. It simply returns the complete list of PDBs within the specified CDB.

Q: What happens if the specified --dbname does not exist or is incorrect?

A: If the specified --dbname is incorrect or does not exist, the command will return an error, and no PDB list will be displayed.

Q: Can the dbaascli pdb list command be used for any Oracle database environment?

A: No, the dbaascli pdb list command is specifically designed for use in Exadata Cloud@Customer environments.

Example 7-36 dbaascli pdb list

dbaascli pdb list --dbname cdb name
dbaascli pdb localClone

To create a new pluggable database (PDB) as a clone of an existing PDB in the same container database (CDB), use the dbaascli pdb localClone command.

Prerequisite

Run the command as the oracle user.

Syntax

dbaascli pdb localClone --pdbName <value> --dbName <value>
[--targetPDBName <value>]
[--powerLimit <value>]
[--maxCPU <value]
[--maxSize <value>]
[--resume [--sessionID <value>]]
[--executePrereqs]
[--waitForCompletion <value>]
{[--blobLocation <value>]|[--standbyBlobFromPrimary <value>]}
[--excludeUserTablespaces <value>] 
[--excludePDBData <value>] 
[--pdbAdminUserName <value>] 
[--lockPDBAdminAccount <value>] 
[--sourcePDBServiceConvertList <value>]
Where:
  • --pdbName specifies the name of the new PDB that you want to clone
  • --dbName specifies the name of the database
  • --targetPDBName specifies the name for the target PDB (new cloned PDB)
  • --powerLimit specifies the degree of parallelism to be used for the clone operation. Valid value is between 1 and 128
  • --maxCPU specifies the maximum number of CPUs to be allocated for the PDB
  • --maxSize specifies the maximum storage size in GB for the new PDB
  • --resume resumes the previous run
    • --sessionID specifies to resume a specific session ID
  • --executePrereqs specifies yes to run only the prereqs for this operation. Valid values: yes or no
  • --waitForCompletion specifies false to run the operation in the background. Valid values: true or false
  • --blobLocation custom directory location where the standby blob file will be generated in a DG environment.
  • --standbyBlobFromPrimary specifies the location of the standby blob file which is prepared from the primary database. This is required only for standby database PDB operations.
    Note

    The parameters --blobLocation and --standbyBlobFromPrimary are mutually exclusive.
  • --excludeUserTablespaces option to skip user table spaces, example t1,t2,t3.
  • --excludePDBData specify true/yes to skip user data from source pdb.
  • --pdbAdminUserName specify new PDB admin user name.
  • --lockPDBAdminAccount specify true or false to lock the PDB admin user account. Default value is true.
  • --sourcePDBServiceConvertList specify comma separated list of source to target service names which need to be converted. Syntax is source_srv1:new_srv1,source_srv2:new_srv2.

The newly cloned PDB inherits administration passwords from the source PDB.

Frequently Asked Questions

Q: What is the purpose of the dbaascli pdb localClone command?

A: The dbaascli pdb localClone command is used to create a new pluggable database (PDB) as a clone of an existing PDB in the same container database (CDB) in an Exadata Cloud@Customer environment.

Q: What are the prerequisites for running the dbaascli pdb localClone command?

A: The command must be run as the oracle user, and you must be connected to an Exadata Cloud@Customer virtual machine. Additionally, the source PDB must already exist in the specified CDB.

Q: What does the --dbName option specify in the dbaascli pdb localClone command?

A: The --dbName option specifies the name of the container database (CDB) that hosts the source PDB from which the new PDB will be cloned.

Q: What does the --pdbName option specify in the dbaascli pdb localClone command?

A: The --pdbName option specifies the name of the new PDB that you want to create as a clone of the existing PDB in the same CDB.

Q: Can I clone a PDB with a different name using the dbaascli pdb localClone command?

A: Yes, you can specify a different name for the cloned PDB using the --targetPDBName option. If this option is not provided, the cloned PDB will inherit the name of the source PDB.

Q: What does the --resume option do in the dbaascli pdb localClone command?

A: The --resume option allows you to resume a previously interrupted PDB cloning operation.

Q: How do I limit the CPU resources available to the cloned PDB?

A: You can limit the CPU resources for the cloned PDB using the --maxCPU option, which specifies the maximum number of CPUs that will be allocated to the new PDB.

Q: Can I run the PDB cloning operation in the background?

A: Yes, you can run the operation in the background by setting the --waitForCompletion option to false. If you set it to true, the operation will run in the foreground and wait for completion.

Q: What is the purpose of the --maxSize option in the dbaascli pdb localClone command?

A: The --maxSize option specifies the maximum storage size (in GB) for the newly cloned PDB. If no size is specified, the cloned PDB inherits the same storage limits as the source PDB.

Q: Can I control the parallelism of the PDB clone operation?

A: Yes, you can control the degree of parallelism for the cloning operation using the --powerLimit option. This option accepts values between 1 and 128 to define the degree of parallelism.

Q: What is the --primaryDBWalletTar option used for?

A: The --primaryDBWalletTar option specifies the location of the primary database wallet tar file. This option is only required if the cloning operation involves standby database PDB operations.

Q: Can I run only the prerequisite checks for the cloning operation?

A: Yes, you can run only the prerequisite checks by using the --executePrereqs option and setting it to yes. The valid values are yes and no.

Q: What happens if the PDB cloning operation fails or is interrupted?

A: If the cloning operation fails or is interrupted, you can resume it by using the --resume option to continue from where the operation stopped.

Example 7-37 dbaascli pdb localClone

dbaascli pdb localClone --dbName db35 --pdbName PDB35 --targetPDBName local_clone1 --maxCPU 2 --maxSize 15
dbaascli pdb open

To open a pluggable database (PDB), use the dbaascli pdb open command.

Run the command as the root or oracle user.

Syntax

dbaascli pdb open
 {
   --pdbName <value> | --pdbUID <value>
 }
--dbname <value> [--openMode <value>] [--startServices <value>] [--waitForCompletion <value>] [--setPDBRefreshModeNone [--skipPDBRefresh] [--pdbAdminUserName <value>]]
Where:
  • --pdbName specifies the name of the PDB that you want to open
  • --pdbUID specifies the identifier of the PDB
  • --dbname specifies the name of the container database that hosts the PDB.
  • --openMode specifies the target OPEN MODE of PDB
  • --startServices: specifies to start all or list all services corresponding to a PDB. Accepted values are all or a comma-delimited list of PDB services.
  • --waitForCompletion: specify false to run the operation in the background. Valid values: true|false
  • --setPDBRefreshModeNone: specifies to convert a refreshable PDB to non-refreshable PDB
    • --skipPDBRefresh: specifies to skip refreshable PDB refresh
    • --pdbAdminUserName: specifies new PDB admin user name

Upon successful completion, the PDB is opened on all of the container database instances.

Frequently Asked Questions

Q: What is the purpose of the dbaascli pdb open command?

A: The dbaascli pdb open command is used to open a pluggable database (PDB) in an Oracle container database (CDB) in an Exadata Cloud@Customer environment.

Q: Who can run the dbaascli pdb open command?

A: The command can be run as either the root or oracle user.

Q: What does the --pdbName option specify in the dbaascli pdb open command?

A: The --pdbName option specifies the name of the PDB that you want to open.

Q: What does the --pdbUID option specify in the dbaascli pdb open command?

A: The --pdbUID option specifies the unique identifier (UID) of the PDB that you want to open.

Q: What does the --dbname option specify in the dbaascli pdb open command?

A: The --dbname option specifies the name of the container database (CDB) that hosts the PDB.

Q: What is the purpose of the --openMode option?

A: The --openMode option specifies the mode in which the PDB will be opened. Valid values are READ_WRITE and READ_ONLY.

Q: Can I start services when opening the PDB?

A: Yes, you can use the --startServices option to either start all services associated with the PDB by specifying all or provide a comma-delimited list of specific services to start.

Q: What happens if I set the --waitForCompletion option to false?

A: If --waitForCompletion is set to false, the command will run in the background, and the user does not need to wait for the operation to complete. If set to true, the command will wait for completion before exiting.

Q: What does the --setPDBRefreshModeNone option do?

A: The --setPDBRefreshModeNone option converts a refreshable PDB (one that is regularly updated from a primary database) into a non-refreshable PDB.

Q: What is the function of the --skipPDBRefresh option?

A: The --skipPDBRefresh option allows you to skip the refresh operation when opening a refreshable PDB, preventing the PDB from syncing with the primary database at that time.

Q: What does the --pdbAdminUserName option do in the dbaascli pdb open command?

A: The --pdbAdminUserName option allows you to specify a new PDB admin username when opening the PDB.

Q: What happens if the dbaascli pdb open command is successful?

A: Upon successful completion, the specified PDB will be opened on all instances of the container database (CDB).

Q: Is it possible to run the dbaascli pdb open command for a refreshable PDB?

A: Yes, the command can be used for refreshable PDBs. The --setPDBRefreshModeNone option converts the PDB to non-refreshable, and the --skipPDBRefresh option skips the refresh operation during the opening process.

Q: What is the default open mode for a PDB if no --openMode is specified?

A: If no --openMode is specified, the PDB is typically opened in READ_WRITE mode by default.

Example 7-38 dbaascli pdb open

dbaascli pdb open --dbname cdb name --pdbName pdb name associated with the CDB
dbaascli pdb open --dbname cdb name --pdbUID con_uid of that pdb

Optional: --openMode READ_WRITE/READ_ONLY

dbaascli pdb recover

To recover a pluggable database (PDB), use the dbaascli pdb recover command.

Prerequisite

  • Run the command as the root user.
  • Database must be configured with backup storage destination details where backups are stored.

Syntax

dbaascli pdb recover --pdbName <value> --dbname <value>
        {
            --start
                {
                    --untilTime <value>
                    | --untilSCN <value>
                    | --latest
                    | --tag <value>
                }
            | --status --uuid <value>
        }
Where:
--pdbName: PDB name.
--dbname: Oracle Database name.
--start | --status
--start
       --untilTime | --untilSCN | --latest | --tag
       --untilTime: Recovers PDB until time. Input format: DD-MON-YYYY HH24:MI:SS.
       --untilSCN: Recovers PDB until SCN.
       --latest: Recovers PDB to last known state.
       --tag: Recovers PDB to archival tag.
--status
       --uuid <value>

Frequently Asked Questions

Q: What is the purpose of the dbaascli pdb recover command?

A: The dbaascli pdb recover command is used to recover a pluggable database (PDB) to a previous state using backups stored in a configured backup storage destination.

Q: Who can run the dbaascli pdb recover command?

A: The command must be run as the root user.

Q: What is required before running the dbaascli pdb recover command?

A: Before running the command, the database must be configured with backup storage destination details where backups are stored.

Q: What does the --pdbName option specify in the dbaascli pdb recover command?

A: The --pdbName option specifies the name of the pluggable database (PDB) that you want to recover.

Q: What does the --dbname option specify in the dbaascli pdb recover command?

A: The --dbname option specifies the name of the container database (CDB) that hosts the PDB.

Q: What are the possible options for starting a PDB recovery using the --start option?

A: You can recover the PDB using one of the following options:
  • --untilTime <value>: Recovers the PDB until a specified time (format: DD-MON-YYYY HH24:MI).
  • --untilSCN <value>: Recovers the PDB until a specified System Change Number (SCN).
  • --latest: Recovers the PDB to the latest known state.
  • --tag <value>: Recovers the PDB to a specific archival tag.

Q: What is the format required for specifying the time in the --untilTime option?

A: The time must be in the format DD-MON-YYYY HH24:MI:SS.

Q: How can I recover a PDB to the latest state using dbaascli pdb recover?

A: To recover the PDB to the latest known state, use the --latest option:

dbaascli pdb recover --pdbName <value> --dbname <value> --start --latest

Q: How do I recover a PDB to a specific archival tag?

A: You can recover the PDB to a specific tag using the --tag option:

dbaascli pdb recover --pdbName <value> --dbname <value> --start --tag <tag_value>

Q: Can I recover a PDB using a specific SCN?

A: Yes, you can recover the PDB to a specific SCN using the --untilSCN option:

dbaascli pdb recover --pdbName <value> --dbname <value> --start --untilSCN <SCN_value>

Q: What does the --status option do in the dbaascli pdb recover command?

A: The --status option is used to check the status of a recovery operation. You must provide the --uuid to specify the recovery session.

Q: How can I check the status of a PDB recovery?

A: To check the status of a recovery operation, use the --status option with the --uuid of the recovery session:

dbaascli pdb recover --pdbName <value> --dbname <value> --status --uuid <uuid_value>

Q: What happens if I specify the --latest option in the recovery command?

A: If you specify the --latest option, the PDB will be recovered to the most recent state available in the backup.

Example 7-39 Examples

  • To recover a PDB pdb1 in a CDB myTestDb to latest:
    dbaascli pdb recover --dbname myTestDb --pdbName pdb1 --start --latest
  • To query the status of PDB recovery request submitted with uuid 81a17352362011ecbc3000163e8e4fac:
    dbaascli pdb recover --dbname myTestDb --pdbName pdb1 --status --uuid 81a17352362011ecbc3000163e8e4fac
dbaascli pdb refresh

To refresh a specified pluggable database (PDB), use the dbaascli pdb refresh command.

Run the command as the root or oracle user.

Syntax

dbaascli pdb refresh --dbname <value>
   {
      --pdbName <value> | --pdbUID <value>
    }
    [--waitForCompletion <value>]

Where:

  • --dbname: specifies the name of the Oracle Database
  • --pdbName: specifies the name of the pluggable database
  • --pdbUID: specifies the identifier of the pluggable database
  • --waitForCompletion: specify false to run the operation in the background. Valid values: true|false

Frequently Asked Questions

Q: What is the purpose of the dbaascli pdb refresh command?

A: The dbaascli pdb refresh command is used to refresh a specified pluggable database (PDB) in a container database (CDB).

Q: Who can run the dbaascli pdb refresh command?

A: The command can be run by either the root or oracle user.

Q: What does the --dbname option specify in the dbaascli pdb refresh command?

A: The --dbname option specifies the name of the container database (CDB) that hosts the pluggable database (PDB) to be refreshed.

Q: What does the --pdbName option specify in the dbaascli pdb refresh command?

A: The --pdbName option specifies the name of the pluggable database (PDB) that you want to refresh.

Q: What does the --pdbUID option specify in the dbaascli pdb refresh command?

A: The --pdbUID option specifies the unique identifier (UID) of the pluggable database (PDB) that you want to refresh.

Q: What does the --waitForCompletion option do in the dbaascli pdb refresh command?

A: The --waitForCompletion option specifies whether the operation should be run in the foreground or background. If set to true, the operation will run in the foreground and wait for completion. If set to false, the operation will run in the background.

Q: How can I refresh a PDB and run the operation in the background?

A: To refresh a PDB and run the operation in the background, use the --waitForCompletion false option:

dbaascli pdb refresh --dbname <value> --pdbName <value> --waitForCompletion false

Q: How do I refresh a PDB using its unique identifier (UID)?

A: You can refresh the PDB using the --pdbUID option:

dbaascli pdb refresh --dbname <value> --pdbUID <value>

Q: Can I specify both --pdbName and --pdbUID together in the dbaascli pdb refresh command?

A: No, you must specify either --pdbName or --pdbUID, but not both, when refreshing a PDB.

Q: What happens if I don't include the --waitForCompletion option in the command?

A: If you don't specify the --waitForCompletion option, the default behavior will be to wait for the operation to complete before returning control to the user.

Q: Can I refresh a PDB while the database is running?

A: Yes, you can refresh a PDB while the database is running, as long as the command is executed by a user with appropriate privileges.

dbaascli pdb remoteClone

To create a new pluggable database (PDB) as a clone of an existing PDB in another container database (CDB), use the dbaascli pdb remoteClone command.

Run the command as the root or oracle user.

Syntax

dbaascli pdb remoteClone --pdbName <value> --dbName <value> --sourceDBConnectionString <value> [--targetPDBName <value>] [--powerLimit <value>] [--maxCPU <value>] [--maxSize <value>] [--resume [--sessionID <value>]] [--executePrereqs] [--waitForCompletion <value>] [--sourcePDBExportedTDEKeyFile <value>]
        {
            [--blobLocation <value>]
            | [--standbyBlobFromPrimary <value>]
        }
[--excludeUserTablespaces <value>] 
[--excludePDBData <value>] 
[--pdbAdminUserName <value>] 
[--lockPDBAdminAccount <value>] 
[--sourcePDBServiceConvertList <value>] 
[--refreshablePDB --refreshMode <value> [--refreshIntervalInMinutes <value>] --dblinkUsername <value> [--honorCaseSensitiveUserName]] 
[--updateDBBlockCacheSize]
Where:
  • --pdbName specifies the name of the source PDB that you want to clone
  • --dbname specifies the name (DB_NAME) of the CDB that hosts the newly cloned PDB
  • --sourceDBConnectionString specifies the source database connection string in the format scan_name:scan_port/database_service_name
  • --targetPDBName specifies the name for the target PDB (new cloned PDB)
  • --powerLimit specifies the degree of parallelism to be used for the clone operation. Valid value is between 1 and 128
  • --maxCPU specifies the maximum number of CPUs to be allocated for the PDB
  • --maxSize specifies the maximum storage size in GB for the new PDB
  • --resume resumes the previous run
    • --sessionID specifies to resume a specific session ID
  • --executePrereqs specifies yes to run only the prereqs for this operation. Valid values: yes or no
  • --waitForCompletion specifies false to run the operation in the background. Valid values: true or false
  • --sourcePDBExportedTDEKeyFile specifies the source PDB exported key file. This variable is applicable to only 12.1 database.
  • --blobLocation specifies the custom path where the standby blob file will be generated in a Data Guard environment
  • --standbyBlobFromPrimary specify the location of the standby blob file, which is prepared from the primary database. This is required only for standby database PDB operations
    Note

    The parameters --blobLocation and --standbyBlobFromPrimary are mutually exclusive.
  • --excludeUserTablespaces option to skip user table spaces, example t1,t2,t3.
  • --excludePDBData specify true/yes to skip user data from source PDB.
  • --pdbAdminUserName specifies new PDB admin user name
  • --lockPDBAdminAccount specify true or false to lock the PDB admin user account. Default value is true.
  • --sourcePDBServiceConvertList specify a comma-delimited list of source to target service names, which need to be converted. Syntax is source_srv1:new_srv1, source_srv2:new_srv2.
  • --refreshablePDB specifies to create refreshable PDB
    • --refreshMode specifies refresh mode for refreshable PDB. Valid values: AUTO|MANUAL
      • --refreshIntervalInMinutes specifies refresh interval for refreshablePDB in minutes
    • --dblinkUsername specifies common user of a remote database used for database link to connect to the remote database
      • --honorCaseSensitiveUserName indicates specified username is case sensitive
  • --updateDBBlockCacheSize: specifies to enable application to set db block cache size initialization parameters to support data copy with a different block size

When promoted, you must supply the SYS user password for the source PDB. The newly cloned PDB inherits administration passwords from the source PDB. The cloned PDB is named using the following format: dbname_sourcepdbname. This command is supported only for databases that are not in a Data Guard configuration and use Oracle Database version 12.2.0.1, or later.

Frequently Asked Questions

Q: What is the dbaascli pdb remoteClone command used for?

A: The dbaascli pdb remoteClone command is used to create a new Pluggable Database (PDB) as a clone of an existing PDB in another container database (CDB).

Q: What user should execute the dbaascli pdb remoteClone command?

A: The command should be executed as either the root or oracle user.

Q: What is required when prompted during the dbaascli pdb remoteClone operation?

A: You must supply the SYS user password for the source PDB.

Q: What does the --pdbName parameter specify?

A: The --pdbName parameter specifies the name of the source PDB that you want to clone.

Q: What does the --dbName parameter represent?

A: The --dbName parameter represents the name (DB_NAME) of the CDB that will host the newly cloned PDB.

Q: How should the --sourceDBConnectionString be formatted?

A: The --sourceDBConnectionString should be formatted as <scan_name>:<scan_port>/<database_service_name>.

Q: What is the purpose of the --targetPDBName parameter?

A: The --targetPDBName parameter specifies the name for the newly cloned PDB.

Q: What does --powerLimit control?

A: The --powerLimit parameter controls the degree of parallelism used for the cloning operation. The valid value is between 1 and 128.

Q: What does the --maxCPU parameter define?

A: The --maxCPU parameter defines the maximum number of CPUs to be allocated for the PDB cloning process.

Q: What is the function of --maxSize?

A: The --maxSize parameter specifies the maximum storage size in GB for the new PDB.

Q: What does the --resume parameter do?

A: The --resume parameter resumes the previous cloning operation.

Q: What should you provide with the --resume option?

A: You can specify a --sessionID to resume a specific session if you are resuming a previous operation.

Q: What does --executePrereqs control?

A: The --executePrereqs parameter determines if only the prerequisites for the cloning operation should be run. Valid values are yes or no.

Q: How does --waitForCompletion affect the operation?

A: The --waitForCompletion parameter specifies whether to wait for the operation to complete or run it in the background. Valid values are true or false.

Q: What is specified by the --sourcePDBExportedTDEKeyFile parameter?

A: The --sourcePDBExportedTDEKeyFile parameter specifies the exported key file from the source PDB. This parameter is applicable only for Oracle Database version 12.1.

Q: What does the --blobLocation parameter define?

A: The --blobLocation parameter specifies the custom path where the standby BLOB file will be generated in a Data Guard environment.

Q: When is --standbyBlobFromPrimary used?

A: The --standbyBlobFromPrimary parameter specifies the location of the standby BLOB file prepared from the primary database. This is required only for standby database PDB operations.

Q: Can --blobLocation and --standbyBlobFromPrimary be used together?

A: No, --blobLocation and --standbyBlobFromPrimary are mutually exclusive and cannot be used together.

Q: What does the --excludeUserTablespaces option do?

A: The --excludeUserTablespaces option allows you to skip specific user tablespaces from being cloned. For example, t1,t2,t3.

Q: What is the effect of --excludePDBData?

A: The --excludePDBData option specifies whether to skip user data from the source PDB during cloning. Valid values are true or yes.

Q: What is specified by --pdbAdminUserName?

A: The --pdbAdminUserName parameter specifies the new admin user name for the cloned PDB.

Q: What does the --lockPDBAdminAccount option control?

A: The --lockPDBAdminAccount option specifies whether to lock the PDB admin user account. The default value is true.

Q: What does --sourcePDBServiceConvertList specify?

A: The --sourcePDBServiceConvertList parameter specifies a comma-delimited list of source to target service name conversions. For example, source_srv1:new_srv1,source_srv2:new_srv2.

Q: What is the purpose of --refreshablePDB?

A: The --refreshablePDB parameter specifies whether to create a refreshable PDB.

Q: What does --refreshMode control?

A: The --refreshMode parameter controls the refresh mode for a refreshable PDB. Valid values are AUTO or MANUAL.

Q: How does --refreshIntervalInMinutes work?

A: The --refreshIntervalInMinutes parameter specifies the interval in minutes for refreshing the refreshable PDB.

Q: What is --dblinkUsername used for?

A: The --dblinkUsername parameter specifies a common user of a remote database used for the database link to connect to the remote database.

Q: What does the --honorCaseSensitiveUserName option indicate?

A: The --honorCaseSensitiveUserName option indicates that the specified username is case sensitive.

Q: What is the effect of --updateDBBlockCacheSize?

A: The --updateDBBlockCacheSize option enables the application to set the DB block cache size initialization parameters to support data copy with a different block size.

Q: What should I do if I encounter an error with the dbaascli pdb remoteClone command?

A: Review the error message for details, ensure all parameters are correctly specified, and verify that you have the necessary permissions and credentials. Additionally, check that the source and target databases meet all the requirements.

Q: What if I forget the SYS user password for the source PDB?

A: You will need to reset or recover the SYS user password for the source PDB. Without it, the cloning operation cannot be completed.

Example 7-40 dbaascli pdb remoteClone

dbaascli pdb remoteClone --sourceDBConnectionString test-can.dbaastoolslrgsu.dbaastoolslrgvc.oraclevcn.com:1521 --pdbName source_pdb1 --dbName db9944 --targetPDBName new_pdb1 --maxsize 5 --maxcpu 2
dbaascli pdb remoteClone --sourceDBConnectionString orcla.dbaastoolslrgsu.dbaastoolslrgvc.oraclevcn.com --pdbName source_pdb1 --dbName db9944 --targetPDBName new_pdb1 --maxsize 5 --maxcpu 2
dbaascli pdb relocate

To relocate the specified PDB from the remote database into local database, use the dbaascli pdb relocate command.

Prerequisite

Run the command as the oracle user. When prompted, you must supply the SYS user password for the source database.

Syntax

dbaascli pdb relocate --pdbName <value> --dbName <value> --sourceDBConnectionString <value> 
[--targetPDBName <value>]
[--powerLimit <value>]
[--maxCpu <value>]
[--maxSize <value>]
[--resume [--sessionID <value>]]
[--executePrereqs <value>]
[--sourcePDBServices <value>]
[--sourcePDBReadOnlyServices <value>]
[--waitForCompletion <value>]
{
    [--blobLocation <value>] | [--standbyBlobFromPrimary <value>]
}
[--upgradePDB <value>]
[--updateDBBlockCacheSize]
{
    [skipOpenPDB] | [--completePDBRelocate]
}
Where:
  • --pdbName specifies the source PDB name to relocate
  • --dbName specifies the target database name
  • --sourceDBConnectionString specifies the source database connection string in the format <scan_name>:<scan_port>/<database_service_name>
  • --targetPDBName specifies a name for the target PDB (new relocated PDB)
  • --powerLimit specifies the degree of parallelism to be used for the relocate operation
  • --maxCpu specifies the maximum number of CPUs to be allocated for the PDB
  • --maxSize specifies the maximum storage size in GB for the new PDB
  • --resume specifies to resume the previous execution
    • --sessionID specifies to resume a specific session ID
  • --executePrereqs specifies yes to run only the prereqs for this operation. Valid values: yes|no
  • --sourcePDBServices specifies a list of comma-delimited source PDB services
  • --sourcePDBReadOnlyServices specifies a comma-delimited list of source PDB read-only services
  • --waitForCompletion specifies false to run the operation in the background. Valid values: true|false
  • --blobLocation specifies the location of a custom directory where the standby BLOB file will be generated in a Data Guard environment.
  • --standbyBlobFromPrimary specifies the location of the standby BLOB file, which is prepared from the primary database. This is required only for standby operations.
    Note

    The parameters --blobLocation and mutually exclusive.
  • --upgradePDB specifies true to upgrade the PDB as part of this operation. Valid values : true | false.
  • --updateDBBlockCachesize option to enable application to set db block cache size initialization parameters to support data copy with different block size.
  • --skipOpenPDB - indicates that the PDB should not be opened at the end of the current operation.
  • --completePDBRelocate - completes the PDB relocation if done as a two-step operation.

Frequently Asked Questions

Q: What is the dbaascli pdb relocate command used for?

A: The dbaascli pdb relocate command is used to relocate a Pluggable Database (PDB) from a remote database to a local database.

Q: What user should run the dbaascli pdb relocate command?

A: The command should be run as the Oracle user.

Q: What is required when prompted during the dbaascli pdb relocate operation?

A: You must supply the SYS user password for the source database.

Q: What does the --pdbName parameter specify?

A: The --pdbName parameter specifies the name of the source PDB to be relocated.

Q: What is the purpose of the --dbName parameter?

A: The --dbName parameter specifies the target database name where the PDB will be relocated.

Q: How should the --sourceDBConnectionString be formatted?

A: The --sourceDBConnectionString should be formatted as <scan_name>:<scan_port>/<database_service_name>.

Q: What does the --targetPDBName parameter do?

A: The --targetPDBName parameter specifies a new name for the relocated PDB.

Q: What is the use of --powerLimit?

A: The --powerLimit parameter specifies the degree of parallelism to be used during the relocate operation.

Q: How does --maxCpu affect the relocation process?

A: The --maxCpu parameter specifies the maximum number of CPUs to be allocated for the PDB relocation process.

Q: What does the --maxSize parameter define?

A: The --maxSize parameter defines the maximum storage size in GB for the new PDB.

Q: What is the function of --resume?

A: The --resume parameter indicates that the relocation operation should resume from where it left off.

Q: What should I provide with the --resume option?

A: You can specify a --sessionID to resume a specific session if you are resuming a previous operation.

Q: What does the --executePrereqs parameter do?

A: The --executePrereqs parameter determines if only the prerequisites for the operation should be run. Valid values are yes or no.

Q: What is specified by the --sourcePDBServices parameter?

A: The --sourcePDBServices parameter specifies a list of comma-delimited source PDB services.

Q: What does the --sourcePDBReadOnlyServices parameter list?

A: The --sourcePDBReadOnlyServices parameter lists a comma-delimited list of source PDB read-only services.

Q: What is the effect of --waitForCompletion?

A: The --waitForCompletion parameter specifies whether to run the operation in the background. Valid values are true or false.

Q: What does the --blobLocation parameter specify?

A: The --blobLocation parameter specifies the location of a custom directory where the standby BLOB file will be generated in a Data Guard environment.

Q: When should I use --standbyBlobFromPrimary?

A: Use --standbyBlobFromPrimary to specify the location of the standby BLOB file, which is prepared from the primary database. This is required only for standby operations.

Q: Can I use --blobLocation and --standbyBlobFromPrimary together?

A: No, the --blobLocation and --standbyBlobFromPrimary parameters are mutually exclusive and cannot be used together.

Q: What does --upgradePDB do?

A: The --upgradePDB parameter specifies whether to upgrade the PDB as part of the relocation operation. Valid values are true or false.

Q: What is the purpose of --updateDBBlockCacheSize?

A: The --updateDBBlockCacheSize option allows the application to set the DB block cache size initialization parameters to support data copy with a different block size.

Q: What does the --skipOpenPDB option do?

A: The --skipOpenPDB option indicates that the PDB should not be opened at the end of the relocation operation.

Q: When should I use --completePDBRelocate?

A: Use --completePDBRelocate to complete the PDB relocation if it is done as a two-step operation.

Q: What should I do if I encounter an error while using the dbaascli pdb relocate command?

A: Check the error message for details, ensure all parameters are correctly specified, and verify that you have the necessary permissions and credentials. You might also need to review the prerequisites and configurations.

Q: What if I forget the SYS user password for the source database?

A: You will need to reset or recover the SYS user password for the source database. Without it, you cannot complete the relocation operation.

Example 7-41 dbaascli pdb relocate

dbaascli pdb relocate --sourceDBConnectionString test-scan.dbaastoolslrgsu.dbaastoolslrgvc.oraclevcn.com:1521/source_cdb_service_name --pdbName source_pdb --dbName target_db

System Management

This section focuses on overseeing and managing Oracle homes within the system. It includes commands like dbaascli system getDBHomes to view details about all Oracle Database homes and dbaascli system getGridHomes to list the details of all Grid Infrastructure homes. These commands provide essential information for maintaining and troubleshooting the overall system environment.

dbaascli system getDBHomes

To view information about all the Oracle homes, use the dbaascli system getDBHomes command.

Prerequisite

Run the command as the root or oracle user.

Syntax

dbaascli system getDBHomes

Frequently Asked Questions

Q: What is the dbaascli system getDBHomes command used for?

A: The dbaascli system getDBHomes command is used to view information about all the Oracle homes on a system.

Q: What user should execute the dbaascli system getDBHomes command?

A: The command should be executed as either the root or oracle user.

Q: Are there any parameters for the dbaascli system getDBHomes command?

A: No, the dbaascli system getDBHomes command does not have any parameters.

Q: What kind of information does the dbaascli system getDBHomes command provide?

A: The command provides details about all Oracle homes on the system, including their paths and other relevant information.

Q: How can I interpret the output from the dbaascli system getDBHomes command?

A: The output will list all Oracle homes with information such as the location of each Oracle home. This information can help in managing and configuring Oracle environments.

Q: What should I do if the dbaascli system getDBHomes command does not return any output?

A: Ensure that you are running the command as the root or oracle user and verify that Oracle homes are properly installed on the system. You may also want to check system permissions and configurations.

Q: What if I receive an error message while executing the dbaascli system getDBHomes command?

A: Check the error message for specific details, verify that you have the appropriate permissions, and ensure that the dbaascli tool is correctly installed and configured.

Q: Can I run dbaascli system getDBHomes on a non-Oracle system?

A: No, the dbaascli system getDBHomes command is specific to Oracle systems and requires Oracle software to be installed.

Example 7-42 dbaascli system getDBHomes

dbaascli system getDBHomes
dbaascli system getGridHomes

To list the details of all Grid homes, use the dbaascli system getGridHomes command.

Prerequisite

Run the command as the root or oracle user.

Syntax

dbaascli system getGridHomes

Frequently Asked Questions

Q: What is the dbaascli system getGridHomes command used for?

A: The dbaascli system getGridHomes command is used to list the details of all Grid homes on a system.

Q: What user should execute the dbaascli system getGridHomes command?

A: The command should be executed as either the root or oracle user.

Q: Are there any parameters for the dbaascli system getGridHomes command?

A: No, the dbaascli system getGridHomes command does not have any parameters.

Q: What kind of information does the dbaascli system getGridHomes command provide?

A: The command provides details about all Grid homes on the system, including their locations and other relevant information.

Q: How can I interpret the output from the dbaascli system getGridHomes command?

A: The output will list all Grid homes with information such as their paths and configurations. This helps in managing and configuring Oracle Grid infrastructure.

Q: What should I do if the dbaascli system getGridHomes command does not return any output?

A: Ensure you are running the command as the root or oracle user and verify that Oracle Grid homes are properly installed on the system. Check system permissions and configurations if needed.

Q: What if I receive an error message while executing the dbaascli system getGridHomes command?

A: Review the error message for specific details, ensure you have the appropriate permissions, and verify that the dbaascli tool is properly installed and configured.

Q: Can I run dbaascli system getGridHomes on a system without Oracle Grid infrastructure?

A: No, the dbaascli system getGridHomes command is specific to systems with Oracle Grid infrastructure installed. If no Grid homes are present, the command may not return any results.

Transparent Data Encryption (TDE) Management

This section encompasses the management of Transparent Data Encryption (TDE) for securing database data. It includes commands for handling encryption keys and keystores, such as dbaascli tde addSecondaryHsmKey to add secondary HSM keys, dbaascli tde rotateMasterKey to rotate the master key, and dbaascli tde encryptTablespacesInPDB to encrypt tablespaces within a pluggable database. You can also convert between FILE and HSM-based TDE (dbaascli tde fileToHsm, dbaascli tde hsmToFile), manage key versions, and retrieve key details with various commands. These tools ensure effective encryption management and data security.

dbaascli tde addSecondaryHsmKey

To add a secondary HSM (KMS) key to the existing HSM (KMS) configuration, use the dbaascli tde addSecondaryHsmKey command.

Prerequisite

Run the command as the root user.

Syntax

dbaascli tde addSecondaryHsmKey --dbname <value> --secondaryKmsKeyOCID <value>
[--executePrereqs]
Where:
  • --secondaryKmsKeyOCID specifies the secondary KMS key to add to the existing HSM (KMS) configuration
  • --dbname specifies the name of the database
  • --executePrereqs sexecute the prerequisites checks and report the results.

Frequently Asked Questions

Q: What does the dbaascli tde addSecondaryHsmKey command do?

A: The dbaascli tde addSecondaryHsmKey command adds a secondary HSM (KMS) key to the existing HSM (KMS) configuration for an Exadata Cloud@Customer database.

Q: Who should run the dbaascli tde addSecondaryHsmKey command?

A: The command must be run as the root user.

Q: On which machine should I run the dbaascli tde addSecondaryHsmKey command?

A: You need to connect to an Exadata Cloud@Customer virtual machine using SSH to run this command.

Q: Where can I find more details about connecting to a virtual machine to run this command?

A: You can refer to the guide "Connecting to a Virtual Machine with SSH" for instructions on how to connect.

Q: What does the --secondaryKmsKeyOCID option specify?

A: The --secondaryKmsKeyOCID option specifies the OCID (Oracle Cloud Identifier) of the secondary KMS key to be added to the existing HSM (KMS) configuration.

Q: What does the --dbname option do?

A: The --dbname option allows you to specify the name of the database for which the secondary KMS key should be added. It is optional.

Q: What does the --precheckOnly option do?

A: The --precheckOnly option, when set to yes, runs a precheck of the operation without making any actual changes. The valid values are yes or no.

Q: Can I run the precheck only without making changes?

A: Yes, you can use the --precheckOnly yes option to run just the precheck without making changes.

Q: Can you give an example of how to run this command to add a secondary HSM key?

A: Here’s an example:

dbaascli tde addSecondaryHsmKey --secondaryKmsKeyOCID ocid1.kms.key.oc1..example

Q: How do I run the command for a specific database?

A: You can specify the database name like this:

dbaascli tde addSecondaryHsmKey --secondaryKmsKeyOCID ocid1.kms.key.oc1..example --dbname mydatabase

Q: How do I run the command with a precheck only?

A: To run the precheck, use the following syntax:

dbaascli tde addSecondaryHsmKey --secondaryKmsKeyOCID ocid1.kms.key.oc1..example --precheckOnly yes

Q: What should I do if the command fails?

A: Ensure that you are running the command as the root user and that you have connected to the correct Exadata Cloud@Customer virtual machine. Also, verify the OCID of the KMS key and check if the required permissions are granted.

Q: How can I check if I have the correct OCID for the secondary KMS key?

A: You can retrieve the OCID of the KMS key from the Oracle Cloud Infrastructure console, under the Key Management Service (KMS) section.

Q: What permissions are required to add a secondary KMS key?

A: You need appropriate permissions in Oracle Cloud Infrastructure for KMS operations, including the ability to manage KMS keys for the relevant compartment.

Q: Can I use the dbaascli tde addSecondaryHsmKey command without specifying the --dbname option?

A: Yes, the --dbname option is optional. If omitted, the command applies to all databases using the existing HSM (KMS) configuration.

Q: What happens if I add a secondary KMS key?

A: The secondary KMS key will be added to the existing configuration, providing an additional layer of encryption key management redundancy.

Q: Can I remove a secondary KMS key once it is added?

A: No, once a secondary KMS key is added, it cannot be removed. You can only rotate or update keys in the future.

Example 7-43 dbaascli tde addSecondaryHsmKey

dbaascli tde addSecondaryHsmKey --dbname dbname --secondaryKmsKeyOCID ocid1.key.oc1.eu-frankfurt-1.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza
dbaascli tde addSecondaryHsmKey --dbname dbname --secondaryKmsKeyOCID ocid1.key.oc1.eu-frankfurt-1.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza --precheckOnly yes
dbaascli tde changePassword

To change TDE keystore password as well as DB wallet password for the alias tde_ks_passwd, use the dbaascli tde changePassword command.

Prerequisite

Run the command as the root user.

Syntax

dbaascli tde changePassword [--dbname <value>]
  {            [--prepareStandbyBlob <value> [--blobLocation <value>]]
               | [--standbyBlobFromPrimary <value>]
  }
  [--resume [--sessionID <value>]]
Where:
  • --dbname specifies the name of the database
  • --prepareStandbyBlob - specify true to generate a blob file containing the artifacts needed to perform the operation in a DG environment.
  • --blobLocation - custom path where the standby blob file will be generated in a DG environment.
  • --standbyBlobFromPrimary - specify the location of the standby blob file which is prepared from the primary database. This is required only for standby operations.
  • --resume - to resume the previous execution
  • --sessionID - to resume a specific session id.

Frequently Asked Questions

Q: What does the dbaascli tde changePassword command do?

A: The dbaascli tde changePassword command changes the Transparent Data Encryption (TDE) keystore password as well as the database wallet password for the alias tde_ks_passwd.

Q: Who should run the dbaascli tde changePassword command?

A: The command must be run as the root user.

Q: When should I use the dbaascli tde changePassword command?

A: Use this command when you need to change the TDE keystore password or the DB wallet password for an Exadata Cloud@Customer database.

Q: What does the --dbname option do?

A: The --dbname option specifies the name of the database for which you want to change the TDE keystore password.

Q: What does the --pdbName option do?

A: The --pdbName option specifies the name of the pluggable database (PDB) for which the TDE keystore password needs to be changed. This option is used for multitenant databases.

Q: Can you give an example of how to run this command for a specific database?

A: Here’s an example to change the TDE keystore password for a specific database:

dbaascli tde changePassword --dbname mydatabase

Q: How do I run the command for a specific PDB within a multitenant database?

A: You can specify the PDB name using this syntax:

dbaascli tde changePassword --dbname mydatabase --pdbName mypdb

Q: What are the prerequisites for running the dbaascli tde changePassword command?

A: You must run the command as the root user and have access to the Exadata Cloud@Customer virtual machine where the database is running.

Q: Do I need to stop the database to change the TDE keystore password?

A: No, the database does not need to be stopped to change the TDE keystore password.

Q: What should I do if the command fails?

A: Ensure that you are running the command as the root user and that the database name (--dbname) and PDB name (--pdbName, if applicable) are correct.

Q: What if I get an "invalid password" error when changing the TDE keystore password?

A: Make sure the new password meets your system's password complexity requirements, and that you are entering the correct old password if prompted.

Q: How do I check if the TDE keystore password has been changed successfully?

A: You can check the database logs or use the Oracle Database Vault and Key Management views to verify that the TDE keystore password change was successful.

Q: Can I change the TDE keystore password for a multitenant database and all PDBs at once?

A: No, the dbaascli tde changePassword command needs to be run for each PDB individually if you need to change the password for multiple PDBs.

Q: What happens if I forget the new TDE keystore password?

A: If the new password is forgotten, you may need to restore the keystore from a backup or follow Oracle's recovery process to reset it, depending on your setup.

Q: Can I automate the process of changing the TDE keystore password?

A: While the dbaascli tde changePassword command itself is not designed for automation, you can script it as part of your regular database maintenance procedures if needed.

Q: How often should I change the TDE keystore password?

A: Oracle recommends periodically changing your TDE keystore password based on your organization's security policies. Best practices typically involve rotating encryption keys and keystore passwords regularly.

To change the TDE password in a non-Data Guard environment
dbaascli tde changepassword --dbname
      <dbname>
To change the TDE password in a Data Guard environment
  1. Change the TDE password in primary database.
    dbaascli tde changepassword --dbname
          <dbname> --prepareStandbyBlob true --blobLocation
          <Location where blob file has to be generated>
  2. Copy the created standby blob to standby database environment.
  3. Change the TDE password in standby database
    dbaascli tde changepassword --dbname
         <dbname> --standbyBlobFromPrimary <Location of blob generated from
        primary>

dbaascli tde enableWalletRoot

To enable wallet_root spfile parameter for the existing database, use the dbaascli tde enableWalletRoot command.

Prerequisite

Run the command as the root user.

Syntax

dbaascli tde enableWalletRoot --dbname <value>
[--dbRestart <value>]
[--executePrereqs]
[--resume [--sessionID <value>]]
Where:
  • --dbname specifies the name of the Oracle Database.
  • --dbrestart specifies the database restart option. Valid values are: rolling or full. Default value: rolling

    If you do not pass the dbrestart argument, then the database restarts in a rolling manner.

  • --precheckOnly runs only the precheck for this operation. Valid values are: yes or no
  • --resume to resume the previous execution
  • --sessionID to resume a specific session id.

Frequently Asked Questions

Q: What does the dbaascli tde enableWalletRoot command do?

A: The dbaascli tde enableWalletRoot command enables the wallet_root parameter in the spfile for an existing Oracle database on Exadata Cloud@Customer.

Q: Who should run the dbaascli tde enableWalletRoot command?

A: The command must be run as the root user.

Q: On which machine should I run the dbaascli tde enableWalletRoot command?

A: You must connect to an Exadata Cloud@Customer virtual machine using SSH to run this command.

Q: Where can I find instructions to connect to the virtual machine?

A: You can refer to the guide "Connecting to a Virtual Machine with SSH" for instructions on connecting.

Q: What does the --dbRestart option do?

A: The --dbRestart option specifies how the database should be restarted after enabling wallet_root. The valid values are:
  • rolling: Restarts the database in a rolling manner (default behavior).
  • full: Performs a full database restart.

Q: What does the --dbname option do?

A: The --dbname option allows you to specify the name of the Oracle Database for which the wallet_root parameter should be enabled.

Q: What does the --precheckOnly option do?

A: The --precheckOnly option runs a precheck of the operation without making actual changes. The valid values are yes or no.

Q: What happens if I do not specify the --dbRestart option?

A: If you do not specify the --dbRestart option, the database will restart in a rolling manner by default.

Q: Can you give an example of how to enable wallet_root for a specific database?

A: Here’s an example to enable wallet_root for a database named mydatabase:

dbaascli tde enableWalletRoot --dbname mydatabase

Q: How do I enable wallet_root and specify a full database restart?

A: You can enable wallet_root with a full database restart using the following command:

dbaascli tde enableWalletRoot --dbname mydatabase --dbRestart full

Q: How do I run the command with a precheck only?

A: To perform a precheck without making changes, use the following syntax:

dbaascli tde enableWalletRoot --dbname mydatabase --precheckOnly yes

Q: What are the prerequisites for running the dbaascli tde enableWalletRoot command?

A: You must run the command as the root user and be connected to the correct Exadata Cloud@Customer virtual machine.

Q: Do I need to restart the database to enable wallet_root?

A: Yes, the database will need to restart either in a rolling manner (default) or fully, depending on the option you choose.

Q: What should I do if the command fails?

A: Ensure that you are running the command as the root user, and verify that the database name (--dbname) is correct. Check for any precheck errors if you are running with --precheckOnly.

Q: What if the database fails to restart after running the command?

A: Verify that the correct restart option was used (rolling or full) and check the database logs for any errors. You may need to manually restart the database if the automatic restart fails.

Q: How can I check if wallet_root was enabled successfully?

A: You can verify the change by checking the database’s spfile or using Oracle SQL queries to confirm that the wallet_root parameter is enabled.

Q: Can I enable wallet_root without restarting the database?

A: No, the database needs to restart for the change to take effect. You can choose between a rolling restart or a full restart.

Q: What is the difference between a rolling and full database restart?

A: A rolling restart restarts the database one instance at a time, allowing the database to remain partially available during the operation. A full restart shuts down and restarts the entire database, causing a complete downtime.

Q: Can I run this command for multiple databases simultaneously?

A: You need to run the dbaascli tde enableWalletRoot command separately for each database you wish to enable wallet_root on.

Q: How does enabling wallet_root affect the existing TDE keystore configuration?

A: Enabling wallet_root updates the TDE keystore location to the new wallet root directory, making it easier to manage multiple keystores and wallets in Oracle databases.

Example 7-44 dbaascli tde enableWalletRoot

dbaascli tde enableWalletRoot --dbname db name --dbrestart rolling|full
dbaascli tde enableWalletRoot --dbname orcl
dbaascli tde enableWalletRoot --dbname orcl--dbrestart full
dbaascli tde encryptTablespacesInPDB

To encrypt all the tablespaces in the specified PDB, use the dbaascli tde encryptTablespacesInPDB command.

Prerequisite

Run the command as the root user.

Syntax

dbaascli tde encryptTablespacesInPDB --dbname <value> --pdbName <value>
[--executePrereqs]
Where:
  • --pdbName specifies the name of the PDB to encrypt all the tablespaces.
  • --dbname specifies the name of the Oracle Database.
  • --executePrereqs execute the prerequisites checks and report the results.

Frequently Asked Questions

Q: What does the dbaascli tde encryptTablespacesInPDB command do?

A: The dbaascli tde encryptTablespacesInPDB command encrypts all the tablespaces in the specified pluggable database (PDB) for an Oracle Database on Exadata Cloud@Customer.

Q: Who should run the dbaascli tde encryptTablespacesInPDB command?

A: The command must be run as the root user.

Q: On which machine should I run the dbaascli tde encryptTablespacesInPDB command?

A: You need to connect to an Exadata Cloud@Customer virtual machine using SSH to run this command.

Q: Where can I find instructions for connecting to the virtual machine?

A: Refer to the guide "Connecting to a Virtual Machine with SSH" for connection instructions.

Q: What does the --pdbName option specify?

A: The --pdbName option specifies the name of the pluggable database (PDB) whose tablespaces need to be encrypted.

Q: What does the --dbname option do?

A: The --dbname option allows you to specify the name of the Oracle Database to which the PDB belongs.

Q: What does the --precheckOnly option do?

A: The --precheckOnly option runs a precheck of the encryption operation without making any actual changes. Valid values are yes or no.

Q: What does the --useSysdbaCredential option do?

A: The --useSysdbaCredential option specifies whether SYSDBA credentials should be used for the operation. Valid values are true or false.

Q: Can you give an example of how to encrypt tablespaces in a specific PDB?

A: Here’s an example to encrypt all tablespaces in a PDB named mypdb:

dbaascli tde encryptTablespacesInPDB --pdbName mypdb

Q: How do I encrypt tablespaces in a specific PDB within a database?

A: Use the following command to specify both the PDB and the database:

dbaascli tde encryptTablespacesInPDB --pdbName mypdb --dbname mydatabase

Q: How do I run a precheck without performing the encryption?

A: You can run a precheck only using this syntax:

dbaascli tde encryptTablespacesInPDB --pdbName mypdb --precheckOnly yes

Q: How do I use SYSDBA credentials to encrypt the tablespaces?

A: You can use the SYSDBA credentials by adding the --useSysdbaCredential true option:

dbaascli tde encryptTablespacesInPDB --pdbName mypdb --useSysdbaCredential true

Q: What are the prerequisites for running the dbaascli tde encryptTablespacesInPDB command?

A: You must run the command as the root user and have access to the Exadata Cloud@Customer virtual machine.

Q: Do I need to restart the database to encrypt the tablespaces?

A: No, the command does not require a database restart. The encryption is performed while the database is online.

Q: Do I need SYSDBA credentials to encrypt tablespaces?

A: You may need SYSDBA credentials for this operation if specified using the --useSysdbaCredential option.

Q: What should I do if the command fails?

A: Ensure you are running the command as the root user, and verify that the PDB name (--pdbName) and database name (--dbname) are correct. You can also run the command with --precheckOnly yes to check for issues before running the full encryption.

Q: What should I do if encryption of the tablespaces fails?

A: Check the database logs and ensure that you have the necessary privileges and resources to perform the encryption. You may also need to verify that there is enough space to handle the encryption process.

Q: How can I check if the tablespaces in a PDB are encrypted?

A: You can query the database views related to encryption, such as V$ENCRYPTED_TABLESPACES, to verify if the tablespaces have been successfully encrypted.

Q: How do I verify if the precheck was successful?

A: If you ran the command with --precheckOnly yes, you can check the output for any warnings or errors indicating potential issues with the encryption process.

Q: Can I encrypt the tablespaces for multiple PDBs simultaneously?

A: No, you need to run the dbaascli tde encryptTablespacesInPDB command separately for each PDB.

Q: Can I partially encrypt some tablespaces in a PDB?

A: No, this command encrypts all tablespaces within the specified PDB. For partial encryption, you would need to use different database management commands.

Q: Does encrypting tablespaces impact database performance?

A: Encrypting tablespaces can have a temporary performance impact during the encryption process. However, the impact should be minimal once the encryption is complete.

Q: Can I undo the encryption of tablespaces?

A: No, once the tablespaces are encrypted, the encryption cannot be undone. You can only rotate or re-encrypt the keys as needed.

Q: What happens if the operation is interrupted during the encryption process?

A: If the operation is interrupted, you may need to rerun the command. The system will resume encryption from where it left off, and you can verify the status using database views.

Example 7-45 dbaascli tde encryptTablespacesInPDB

dbaascli tde encryptTablespacesInPDB --dbname dbname --pdbName pdb
dbaascli tde encryptTablespacesInPDB --dbname dbname --pdbName pdb --executePrereqs 
dbaascli tde fileToHsm

To convert FILE based TDE to HSM (KMS/OKV) based TDE, use the dbaascli tde fileToHsm command.

Prerequisite

Run the command as the root user.

Syntax

dbaascli tde fileToHsm --kmsKeyOCID <value> --dbname <value> 
[--skipPatchCheck <value>] 
[--executePrereqs ] 
[--primarySuc <value>]
{
    [--resume [--sessionID <value>]] | [--revert [--sessionID <value>]]
}
[--waitForCompletion <value>]
Where:
  • --kmsKeyOCID specifies the KMS key OCID to use for TDE. This is applicable only if KMS is selected for TDE
  • --dbname specifies the name of the database
  • --skipPatchCheck skips validation check for required patches if the value passed for this argument is true. Valid values: true or false
  • --executePrereqs sexecute the prerequisites checks and report the results.
  • --primarySuc specify this property in the standby database of the Data Guard environment once the command is successfully run on the primary database
  • --resume specifies to resume the previous run
    • --sessionID specifies to resume a specific session ID
  • --revert specifies to rollback the previous run
    • --sessionID specifies to rollback a specific session ID
  • --waitForCompletion specify false to run the operation in background. Valid values : true|false.

Frequently Asked Questions

Q: What is the purpose of the dbaascli tde fileToHsm command?

A: The dbaascli tde fileToHsm command is used to convert a FILE-based Transparent Data Encryption (TDE) to Hardware Security Module (HSM)-based TDE, such as KMS or OKV, in an Oracle Database Cloud Service environment.

Q: Who can run the dbaascli tde fileToHsm command?

A: The command must be run as the root user.

Q: What is the purpose of the --kmsKeyOCID parameter?

A: The --kmsKeyOCID parameter specifies the KMS key OCID that will be used for TDE encryption when transitioning from file-based to HSM-based TDE.

Q: What does the --dbname parameter do?

A: The --dbname parameter specifies the name of the database for which you are converting the TDE from file-based to HSM-based.

Q: Can I skip the patch validation check while converting TDE?

A: Yes, by using the --skipPatchCheck parameter with the value true, you can skip the validation check for required patches.

Q: What is the --executePrereqs parameter used for?

A: The --executePrereqs parameter allows you to run only the prechecks for the TDE conversion process without performing the actual conversion. Valid values are yes or no.

Q: What does the --primarySuc parameter do in a Data Guard setup?

A: The --primarySuc parameter is used in a Data Guard environment to indicate that the command has been successfully run on the primary database. It should be specified on the standby database after the primary conversion is complete.

Q: How do I resume a previous TDE conversion?

A: You can resume a previously incomplete TDE conversion by using the --resume parameter. Optionally, you can specify a specific session ID with --sessionID.

Q: How do I revert a TDE conversion?

A: To revert a previous TDE conversion, use the --revert parameter. You can also provide the specific session ID you want to revert using --sessionID.

Q: How do I specify a session ID when resuming or reverting a TDE conversion?

A: You can use the --sessionID parameter to specify the ID of the session you want to resume or revert. Example: --resume --sessionID <ID> or --revert --sessionID <ID>.

Q: What happens if I set --waitForCompletion to false?

A: If you set --waitForCompletion to false, the TDE conversion process will run in the background, and the command prompt will return immediately. If set to true, the command will wait for the process to finish before returning control to the user.

Q: What are the valid values for the --waitForCompletion parameter?

A: Valid values are true or false. Setting it to true makes the command wait until the process is complete; setting it to false runs the process in the background.

Q: Can I run dbaascli tde fileToHsm without converting the TDE immediately?

A: Yes, you can use the --executePrereqs yes parameter to perform only the prechecks for the conversion, without making any changes to the TDE.

Q: In a Data Guard environment, how do I handle the standby database after converting TDE on the primary?

A: After successfully running the conversion on the primary database, you need to specify --primarySuc when running the command on the standby database.

Q: What should I do if the TDE conversion process fails?

A: If the process fails, you can use the --resume parameter to try resuming from where it left off. If necessary, you can use the --revert parameter to roll back the changes made during the failed session.

Example 7-46 dbaascli tde fileToHsm --kmsKeyOCID

dbaascli tde fileToHSM --dbname dbname --kmsKeyOCID ocid1.key.oc1.eu-frankfurt-.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza
dbaascli tde fileToHSM --dbname dbname --kmsKeyOCID ocid1.key.oc1.eu-frankfurt-.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza --executePrereqs 
dbaascli tde fileToHSM --dbname dbname --kmsKeyOCID ocid1.key.oc1.eu-frankfurt-.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza --resume
dbaascli tde getHsmKeys

To get TDE active key details, use the dbaascli tde getHsmKeys command.

Prerequisite

Run the command as the root user.

Syntax

dbaascli tde getHsmKeys
[--dbname]
[--infoFile]
Where:
  • --dbname specifies the name of the database
  • --infoFile specifies the file path where the list of OCIDs will be saved. The output is in JSON format

Frequently Asked Questions

Q: What does the dbaascli tde getHsmKeys command do?

A: The dbaascli tde getHsmKeys command retrieves details of active Transparent Data Encryption (TDE) keys from the Hardware Security Module (HSM) for a specified database.

Q: Who should run the dbaascli tde getHsmKeys command?

A: The command must be run as the root user.

Q: On which machine should I run the dbaascli tde getHsmKeys command?

A: You must connect to an Exadata Cloud@Customer virtual machine using SSH to run this command.

Q: Where can I find instructions for connecting to the virtual machine?

A: Refer to the guide "Connecting to a Virtual Machine with SSH" for instructions on connecting.

Q: What does the --dbname option do?

A: The --dbname option allows you to specify the name of the Oracle Database for which you want to retrieve TDE key details.

Q: What does the --infoFile option do?

A: The --infoFile option specifies the file path where the list of key OCIDs (Oracle Cloud Identifiers) will be saved. The output is in JSON format.

Q: Can you give an example of how to retrieve TDE key details for a specific database?

A: Here’s an example to get the TDE key details for a database named mydatabase:

dbaascli tde getHsmKeys --dbname mydatabase

Q: How do I save the TDE key details to a file?

A: You can specify a file path using the --infoFile option to save the output in JSON format:

dbaascli tde getHsmKeys --dbname mydatabase --infoFile /path/to/output.json

Q: What are the prerequisites for running the dbaascli tde getHsmKeys command?

A: You must run the command as the root user and be connected to the Exadata Cloud@Customer virtual machine.

Q: Do I need SYSDBA credentials to retrieve TDE key details?

A: No, SYSDBA credentials are not required to run the dbaascli tde getHsmKeys command.

Q: In what format is the TDE key information saved when using the --infoFile option?

A: The output is saved in JSON format.

Q: What information is included in the TDE key details?

A: The details include key OCIDs and other metadata about the active encryption keys stored in the HSM for the specified database.

Q: What should I do if the command fails to retrieve the key details?

A: Ensure that you are running the command as the root user and that the database name (--dbname) is correct. Check your connection to the Exadata Cloud@Customer virtual machine.

Q: How do I check if the output file was created successfully?

A: You can check the specified file path for the output JSON file. If the file is missing, verify that the file path is correct and that you have write permissions to the directory.

Q: What should I do if the output file is empty?

A: Ensure that the database specified contains active TDE keys and that the --dbname parameter is correct. You may also need to check if there are any errors in the database logs.

Q: Can I retrieve TDE key details for multiple databases at once?

A: No, you must run the dbaascli tde getHsmKeys command separately for each database.

Q: How can I use the output file from the --infoFile option in other operations?

A: Since the output is in JSON format, you can parse the file programmatically or use it as input for other database or encryption management tasks.

Q: Can I get historical TDE key details using this command?

A: No, the command only retrieves details about the currently active keys in the HSM.

Q: How do I verify that the keys retrieved are correct?

A: You can verify the keys by cross-referencing them with the Oracle Cloud Infrastructure (OCI) console or using database views related to encryption management.

Example 7-47 dbaascli tde getHsmKeys

dbaascli tde getHsmkeys --dbname dbname
dbaascli tde getHsmkeys --dbname dbname --infoFile infoFilePath
dbaascli tde getMkidForKeyVersionOCID

To get Master Key ID associated with the KMS key version OCID, use the dbaascli tde getMkidForKeyVersionOCID command.

Prerequisite

Run the command as the root user.

Syntax

dbaascli tde getMkidForKeyVersionOCID --kmsKeyVersionOCID <value>
[--dbname <value>]
[--waitForCompletion <value>]
Where:
  • --kmsKeyVersionOCID specifies the KMS key version OCID to set
  • --dbname specifies the name of the database
  • --waitForCompletion specify false to run the operation in background. Valid values : true|false.

Frequently Asked Questions

Q: What is the purpose of the dbaascli tde getMkidForKeyVersionOCID command?

A: The dbaascli tde getMkidForKeyVersionOCID command retrieves the Master Key ID (MKID) associated with a specific KMS key version OCID in Oracle Database Cloud Service environments.

Q: What are the prerequisites for running the dbaascli tde getMkidForKeyVersionOCID command?

A: You must:
  • Run the command as the root user.
  • Be connected to an Exadata Cloud@Customer virtual machine via SSH.

Q: Who can run the dbaascli tde getMkidForKeyVersionOCID command?

A: Only the root user can run this command.

Q: What does the --kmsKeyVersionOCID parameter specify?

A: The --kmsKeyVersionOCID parameter specifies the KMS key version OCID for which you want to retrieve the associated Master Key ID (MKID).

Q: What does the --dbname parameter specify?

A: The --dbname parameter specifies the name of the database for which the KMS key version OCID is being queried.

Q: Is the --dbname parameter mandatory?

A: No, the --dbname parameter is optional. If you don’t specify a database name, the command will retrieve the MKID for the default database on the system.

Q: What should I do if I don’t know the KMS key version OCID?

A: You must retrieve the KMS key version OCID from your KMS management console or service provider before using this command. Without it, the command cannot retrieve the Master Key ID (MKID).

Q: Can I run this command on a non-Exadata Cloud@Customer environment?

A: No, this command is specifically for use in an Exadata Cloud@Customer environment, and you need to connect to a virtual machine using SSH to execute it.

Q: What happens if I run the command without specifying a database name using --dbname?

A: If the --dbname parameter is not provided, the command will attempt to retrieve the MKID for the default database configured on the system.

Q: What should I do if I encounter an error while retrieving the MKID?

A: Ensure that:
  • You are running the command as the root user.
  • You are correctly connected to the Exadata Cloud@Customer virtual machine.
  • The KMS key version OCID you provided is valid. If the error persists, check the system logs for more details.

Q: How do I connect to the Exadata Cloud@Customer virtual machine?

A: You can connect to the virtual machine via SSH. Refer to the Exadata Cloud@Customer documentation for steps on how to securely connect.

Example 7-48 dbaascli tde getMkidForKeyVersionOCID

dbaascli tde getMkidForKeyVersionOCID --dbname dbname --kmsKeyVersionOCID ocid1.keyversion.oc1.eu-frankfurt-1.bjqnwclvaafak.bc4hmd3olgaaa.abtheljsyxtgn4vzi2bbpcej6a7abcwvylkd2lx56lu2s6iwnxwgigu23nha
dbaascli tde getPrimaryHsmKey

To get primary HSM (KMS) key from the existing HSM (KMS) configuration, use the dbaascli tde getPrimaryHsmKey command.

Prerequisite

Run the command as the root user.

Syntax

dbaascli tde getPrimaryHsmKey
[--dbname]
Where:
  • --dbname specifies the name of the database

Frequently Asked Questions

Q: What is the purpose of the dbaascli tde getPrimaryHsmKey command?

A: The dbaascli tde getPrimaryHsmKey command retrieves the primary Hardware Security Module (HSM) key from the existing HSM (KMS) configuration in an Oracle Database environment.

Q: What are the prerequisites for running the dbaascli tde getPrimaryHsmKey command?

A: You must:
  • Run the command as the root user.
  • Be connected to an Exadata Cloud@Customer virtual machine via SSH.

Q: Who can execute the dbaascli tde getPrimaryHsmKey command?

A: Only the root user can execute this command.

Q: What does the --dbname parameter specify in this command?

A: The --dbname parameter specifies the name of the database for which you want to retrieve the primary HSM key.

Q: Is the --dbname parameter mandatory?

A: No, the --dbname parameter is optional. If not provided, the command will retrieve the primary HSM key for the default database on the system.

Q: What should I do if I don’t specify a database name with --dbname?

A: If the --dbname parameter is not specified, the command will attempt to retrieve the primary HSM key for the default database configured on the system.

Q: Can I run this command on a non-Exadata Cloud@Customer environment?

A: No, this command is designed specifically for use in an Exadata Cloud@Customer environment, and you must be connected to the virtual machine using SSH to run it.

Q: How do I connect to the Exadata Cloud@Customer virtual machine to run the command?

A: You can connect to the virtual machine via SSH. Refer to the Exadata Cloud@Customer documentation for instructions on how to securely connect.

Q: What should I check if I encounter an error while retrieving the primary HSM key?

A: If you encounter an error, ensure that:
  • You are running the command as the root user.
  • You are correctly connected to the Exadata Cloud@Customer virtual machine.
  • The database name (if specified) is valid. If the issue persists, consult system logs or error messages for more details.

Q: Do I need to stop the database to run the dbaascli tde getPrimaryHsmKey command?

A: No, the database does not need to be stopped to run this command. You can execute it while the database is running.

Q: What is the purpose of retrieving the primary HSM key?

A: Retrieving the primary HSM key allows you to identify the current HSM key that is being used for encryption in the database’s existing HSM (KMS) configuration.

Example 7-49 dbaascli tde getPrimaryHsmKey

dbaascli tde getPrimaryHsmKey --dbname dbname
dbaascli tde hsmToFile

To convert HSM (KMS/OKV) based TDE to FILE based TDE, use the dbaascli tde hsmToFile command.

Run the command as the root user.

Syntax

dbaascli tde hsmToFile 
[--dbname <value>] 
{
    [--prepareStandbyBlob <value> [--blobLocation <value>]
   | [--standbyBlobFromPrimary <value>]
}
] 
[--skipPatchCheck <value>] 
[--executePrereqs ] 
[--primarySuc <value>] 
{
     [--resume [--sessionID <value>]] |
     [--revert [--sessionID <value>]]
} 
[--waitForCompletion <value>]
Where:
  • --dbname specifies the name of the database
  • --prepareStandbyBlob specify true to generate a blob file containing the artifacts needed to perform the operation in a DG environment.
  • --blobLocation custom directory location where the standby blob file will be generated in a DG environment.
  • --standbyBlobFromPrimary specify the location of the standby blob file which is prepared from the primary database. This is required only for standby operations. ]
  • --skipPatchCheck skips validation check for required patches if the value passed for this argument is true. Valid values: true or false
  • --executePrereqs execute the prerequisites checks and report the results.
  • --primarySuc specify this property in the standby database of the Data Guard environment once the command is successfully run on the primary database
  • --resume resumes the previous run
    • --sessionID specifies to resume a specific session ID
  • --revert specifies to roll back the previous run
    • --sessionID specifies to rollback a specific session ID
  • --waitForCompletion specifies false to run the operation in background. Valid values: true|false

Frequently Asked Questions

Q: What is the purpose of the dbaascli tde hsmToFile command?

A: The dbaascli tde hsmToFile command is used to convert a Hardware Security Module (HSM)-based Transparent Data Encryption (TDE) to a file-based TDE in Oracle Database Cloud Service environments.

Q: What are the prerequisites for running the dbaascli tde hsmToFile command?

A: You must:
  • Run the command as the root user.
  • Ensure you have the necessary permissions and configurations set in the database environment.

Q: What does the --dbname parameter specify?

A: The --dbname parameter specifies the name of the database for which you are converting TDE from HSM-based to file-based.

Q: When is the --primaryDBWalletTar parameter required?

A: The --primaryDBWalletTar parameter is required only when performing the hsmToFile conversion on a standby database. It specifies the tar file of the primary database’s wallet.

Q: What is the purpose of the --skipPatchCheck parameter?

A: The --skipPatchCheck parameter allows you to skip the validation check for required patches. Set this to true to skip the check or false to enforce it.

Q: How do I run only prechecks for the conversion process without performing the actual conversion?

A: You can use the --executePrereqs parameter and set it to yes to run only the prechecks. Set it to no to perform the full conversion.

Q: What does the --primarySuc parameter do in a Data Guard environment?

A: The --primarySuc parameter is used in a Data Guard setup to indicate that the conversion has successfully run on the primary database. It should be used when running the conversion on the standby database.

Q: How can I resume a previous hsmToFile conversion?

A: You can resume a previous conversion by using the --resume parameter. Optionally, you can specify the session ID of the previous run with --sessionID.

Q: What is the purpose of the --revert parameter?

A: The --revert parameter is used to roll back a previously initiated conversion process in case of failure or if you need to undo the operation.

Q: What happens if I set --waitForCompletion to false?

A: If you set --waitForCompletion to false, the operation will run in the background, allowing you to continue other tasks. If set to true, the command will wait for the process to complete before returning control to the user.

Q: What should I do if I need to convert the TDE in a standby database in a Data Guard setup?

A: In a Data Guard setup, after converting TDE on the primary database, you must run the command on the standby database using the --primaryDBWalletTar parameter, specifying the wallet tar file from the primary database, and include --primarySuc.

Q: What should I do if I want to skip checking for required patches during the conversion?

A: You can skip the patch check by using the --skipPatchCheck parameter and setting it to true.

Q: How do I check if the system is ready for the hsmToFile conversion without making changes?

A: You can perform only the prechecks by using the --executePrereqs parameter and setting it to yes.

Q: What should I do if the conversion process is interrupted?

A: You can use the --resume parameter to restart the process from where it left off. Optionally, you can specify a particular session ID with --sessionID.

Q: What should I do if the conversion process fails?

A: If the conversion fails, you can roll back the process using the --revert parameter. Additionally, review any error messages and check system logs for more details.

Q: Can I run the dbaascli tde hsmToFile command on a non-Exadata environment?

A: This command is designed for use in Exadata Cloud@Customer environments. If you are not using Exadata, ensure that you are in a supported environment for the command to work properly.

Example 7-50 dbaascli tde hsmToFile

dbaascli tde hsmToFile --dbname dbname
dbaascli tde hsmToFile --dbname dbname --executePrereqs
dbaascli tde hsmToFile --dbname dbname --resume
dbaascli tde listKeys

To list TDE master keys, use the dbaascli tde listKeys command.

Prerequisite

Run the command as the root user.

Syntax

dbaascli tde listKeys
[--dbname <value>]
[--infoFilePath <value>]
Where:
  • --dbname specifies the name of the database
  • --infoFilePath specify the absolute path of the file where the results will be saved.

Frequently Asked Questions

Q: What is the purpose of the dbaascli tde listKeys command?

A: The dbaascli tde listKeys command is used to list all the Transparent Data Encryption (TDE) master keys for a specified database in an Oracle Database environment.

Q: What are the prerequisites for running the dbaascli tde listKeys command?

A: You must:
  • Run the command as the root user.
  • Be connected to an Exadata Cloud@Customer virtual machine using SSH.

Q: What does the --file parameter do in the dbaascli tde listKeys command?

A: The --file parameter specifies the file path where the list of TDE master keys should be saved. If this parameter is not provided, the results will be displayed directly in the terminal.

Q: What does the --dbname parameter specify?

A: The --dbname parameter specifies the name of the database for which you want to list the TDE master keys.

Q: Is the --file parameter mandatory?

A: No, the --file parameter is optional. If not provided, the list of TDE keys will be shown in the terminal output instead of being saved to a file.

Q: Is the --dbname parameter mandatory?

A: No, the --dbname parameter is optional. If not specified, the command will list the TDE master keys for the default database configured on the system.

Q: What should I do if I want to save the list of keys to a file?

A: You should provide the --file parameter along with the desired file path. For example:

dbaascli tde listKeys --file /path/to/output.txt

Q: What happens if I don’t provide a database name with --dbname?

A: If the --dbname parameter is not provided, the command will list the TDE master keys for the default database on the system.

Q: Can I use this command in environments other than Exadata Cloud@Customer?

A: This command is designed specifically for Exadata Cloud@Customer environments. Ensure you are connected to the appropriate virtual machine to run it.

Q: What should I do if the command fails to list keys?

A: Ensure that:
  • You are running the command as the root user.
  • You are connected to the Exadata Cloud@Customer virtual machine.
  • The database name (if specified) is correct. Check the error messages and logs for more details on the failure.

Q: Can I run the dbaascli tde listKeys command while the database is running?

A: Yes, the command can be executed while the database is running. It simply lists the TDE master keys and does not alter the state of the database.

Q: Do I need special permissions to run this command?

A: You must run this command as the root user. Without root permissions, you will not be able to execute the command.

Q: What is the purpose of listing TDE master keys?

A: Listing TDE master keys allows you to review the encryption keys being used for protecting your database’s data. It is essential for monitoring and managing encryption settings.

Q: How do I connect to the Exadata Cloud@Customer virtual machine to run the command?

A: You can connect to the virtual machine using SSH. Refer to the Exadata Cloud@Customer documentation for instructions on how to establish a secure connection.

Example 7-51 dbaascli tde listKeys

dbaascli tde listKeys --dbname dbname
dbaascli tde listKeys --dbname dbname --infoFilePath infoFilePath
dbaascli tde removeSecondaryHsmKey

To remove secondary HSM (KMS) key from the existing HSM (KMS) configuration, use the dbaascli tde removeSecondaryHsmKey command.

Prerequisite

Run the command as the root user.

Syntax

dbaascli tde removeSecondaryHsmKey --dbname <value>
[--confirmDeletion]
[--secondaryKmsKeyOCID]
[--executePrereqs]
Where:
  • --dbname specifies the name of the database
  • --confirmDeletion if not specified the user will be prompted while deleting all existing HSM(KMS) keys.
  • --secondaryKmsKeyOCID secondary KMS key to be removed from existing HSM(KMS) configuration. If not specified all secondary KMS keys will be removed.
  • --executePrereqs execute the prerequisites checks and report the results.

Frequently Asked Questions

Q: What is the purpose of the dbaascli tde removeSecondaryHsmKey command?

A: The dbaascli tde removeSecondaryHsmKey command is used to remove a secondary Hardware Security Module (HSM) key from the existing HSM (KMS) configuration in an Oracle Database environment.

Q: What are the prerequisites for running the dbaascli tde removeSecondaryHsmKey command?

A: You must:
  • Run the command as the root user.
  • Be connected to an Exadata Cloud@Customer virtual machine using SSH.

Q: What does the --force parameter do in the dbaascli tde removeSecondaryHsmKey command?

A: The --force parameter allows the removal of the secondary HSM key without prompting the user for confirmation. If not specified, the command will prompt the user before deleting any keys.

Q: What does the --secondaryKmsKeyOCID parameter specify?

A: The --secondaryKmsKeyOCID parameter specifies the OCID (Oracle Cloud Identifier) of the secondary KMS key you want to remove from the existing HSM configuration.

Q: What does the --dbname parameter do?

A: The --dbname parameter specifies the name of the database for which the secondary HSM key is being removed.

Q: What is the purpose of the --precheckOnly parameter?

A: The --precheckOnly parameter, if set to yes, will only run the prechecks to validate the readiness for the removal operation without actually removing the secondary HSM key. If set to no, the full removal operation is performed.

Q: Is the --force parameter mandatory?

A: No, the --force parameter is optional. If it’s not specified, the system will prompt the user for confirmation before proceeding with the key removal.

Q: Is the --secondaryKmsKeyOCID parameter mandatory?

A: Yes, you must provide the --secondaryKmsKeyOCID to identify the specific secondary HSM key that you want to remove from the configuration.

Q: Is the --dbname parameter mandatory?

A: No, the --dbname parameter is optional. If not specified, the command will attempt to remove the secondary HSM key from the default database on the system.

Q: What should I do if I want to remove the secondary HSM key without any user prompts?

A: You should use the --force parameter to bypass the confirmation prompt and remove the secondary HSM key directly:

dbaascli tde removeSecondaryHsmKey --force --secondaryKmsKeyOCID <value>

Q: How can I test whether the system is ready to remove the secondary HSM key without actually removing it?

A: You can use the --precheckOnly parameter set to yes to perform a precheck:

dbaascli tde removeSecondaryHsmKey --precheckOnly yes --secondaryKmsKeyOCID <value>

Q: What happens if I don’t provide a database name with --dbname?

A: If the --dbname parameter is not specified, the command will attempt to remove the secondary HSM key from the default database configured on the system.

Q: What should I check if the command fails to remove the secondary HSM key?

A: Ensure that:
  • You are running the command as the root user.
  • You are connected to the Exadata Cloud@Customer virtual machine.
  • The correct --secondaryKmsKeyOCID and --dbname values are provided. Check the error messages and logs for more details on the failure.

Q: What should I do if the removal operation fails partway through?

A: If the operation fails, review the error logs and try running the command with --precheckOnly to ensure the system is ready for the operation. If necessary, correct any issues before retrying.

Q: Can I run the dbaascli tde removeSecondaryHsmKey command while the database is running?

A: Yes, the command can be executed while the database is running, as it does not require the database to be stopped.

Q: What is the purpose of removing a secondary HSM key?

A: Removing a secondary HSM key is typically done when the key is no longer needed or when you want to manage the encryption keys used in your TDE (Transparent Data Encryption) configuration.

Q: How do I connect to the Exadata Cloud@Customer virtual machine to run the command?

A: You can connect to the virtual machine using SSH. Refer to the Exadata Cloud@Customer documentation for instructions on establishing a secure connection.

Example 7-52 dbaascli tde removeSecondaryHsmKey

dbaascli tde removeSecondaryHsmKey --dbname dbname
dbaascli tde removeSecondaryHsmKey --dbname dbname --secondaryKmsKeyOCID ocid1.key.oc1.eu-frankfurt-1.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza
dbaascli tde removeSecondaryHsmKey --dbname dbname --secondaryKmsKeyOCID ocid1.key.oc1.eu-frankfurt-1.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza --executePrereqs 
dbaascli tde rotateMasterKey

To rotate the master key for database encryption, use the dbaascli tde rotateMasterKey command.

Prerequisites:

Run the command as the root user.

Syntax

dbaascli tde rotateMasterKey --dbname <value> 
[--rotateMasterKeyOnAllPDBs] 
[--pdbName <value>] 
[--executePrereqs] 
[--resume [--sessionID <value>]]
{
     [--prepareStandbyBlob <value> [--blobLocation <value>]]
     | [--standbyBlobFromPrimary <value>]
 }
Where:
  • --dbname specifies the name of the Oracle Database
  • --rotateMasterKeyOnAllPDBs specifies true to rotate master key of all PDBs in CDB. Valid values: true|false
  • --pdbName specifies the name of the PDB
  • --executePrereqs runs the prerequisites checks and report the results
  • --resume specifes to resume the previous execution
  • --sessionID specifies to resume a specific session ID
  • --prepareStandbyBlob specifies true to generate a BLOB file containing the artifacts needed to perform the operation in a Data Guard environment
  • --blobLocation specifies the location of the custom directory where the standby BLOB file will be generated in a Data Guard environment
  • --standbyBlobFromPrimary specifies the location of the standby BLOB file, which is prepared from the primary database. This is required only for standby operations.

Frequently Asked Questions

Q: What is the purpose of the dbaascli tde rotateMasterKey command?

A: The dbaascli tde rotateMasterKey command is used to rotate the master key used for Transparent Data Encryption (TDE) in an Oracle Database. This process ensures the encryption keys are updated for better security.

Q: What are the prerequisites for running the dbaascli tde rotateMasterKey command?

A: You must:
  • Run the command as the root user.
  • Ensure that the database is configured correctly for TDE.

Q: What does the --dbname parameter specify?

A: The --dbname parameter specifies the name of the Oracle Database for which you want to rotate the master encryption key.

Q: What is the purpose of the --rotateMasterKeyOnAllPDBs parameter?

A: The --rotateMasterKeyOnAllPDBs parameter specifies whether to rotate the master key for all Pluggable Databases (PDBs) in a Container Database (CDB). Valid values are true or false.

Q: What does the --pdbName parameter do?

A: The --pdbName parameter specifies the name of a particular Pluggable Database (PDB) if you want to rotate the master key for a specific PDB rather than all PDBs.

Q: What does the --executePrereqs parameter do?

A: The --executePrereqs parameter runs prerequisite checks to validate whether the environment is ready for the master key rotation without performing the actual rotation.

Q: What does the --resume parameter specify?

A: The --resume parameter is used to resume a previously started operation. You can also provide a specific session ID using --sessionID to resume a particular session.

Q: What is the purpose of the --prepareStandbyBlob parameter?

A: The --prepareStandbyBlob parameter, if set to true, generates a BLOB file containing the necessary artifacts to perform master key rotation in a Data Guard environment.

Q: What does the --blobLocation parameter do?

A: The --blobLocation parameter specifies a custom directory path where the standby BLOB file will be generated. This is applicable when --prepareStandbyBlob is set to true.

Q: What does the --standbyBlobFromPrimary parameter specify?

A: The --standbyBlobFromPrimary parameter specifies the location of the standby BLOB file that was generated from the primary database. This parameter is used when performing the master key rotation on a standby database in a Data Guard environment.

Q: Is the --rotateMasterKeyOnAllPDBs parameter mandatory?

A: No, the --rotateMasterKeyOnAllPDBs parameter is optional. If it is not specified, the master key will only be rotated for the database (or specific PDB) provided in the --dbname or --pdbName parameters.

Q: Is the --pdbName parameter required if I'm rotating keys for a CDB?

A: No, the --pdbName parameter is only required if you want to rotate the master key for a specific Pluggable Database (PDB). It is optional when rotating the key for the entire CDB.

Q: Do I need to use the --prepareStandbyBlob and --standbyBlobFromPrimary parameters for standalone databases?

A: No, these parameters are only relevant in a Data Guard environment where a standby database is involved.

Q: How can I rotate the master key for all PDBs in a CDB?

A: You should use the --rotateMasterKeyOnAllPDBs parameter set to true to rotate the master key for all PDBs in the CDB. For example:

dbaascli tde rotateMasterKey --dbname CDB_NAME --rotateMasterKeyOnAllPDBs true

Q: How do I run a check to validate that the system is ready for master key rotation without performing the actual operation?

A: You can use the --executePrereqs parameter to run the prerequisite checks. This will report any issues that might prevent the master key rotation:

dbaascli tde rotateMasterKey --dbname DB_NAME --executePrereqs

Q: What should I do if the operation was interrupted, and I want to resume it?

A: You can use the --resume parameter to resume the previously interrupted operation. If you have a session ID, provide it with the --sessionID parameter:

dbaascli tde rotateMasterKey --dbname DB_NAME --resume --sessionID <value>

Q: How can I prepare for key rotation in a Data Guard environment?

A: You should use the --prepareStandbyBlob parameter to generate a BLOB file that contains the required artifacts for rotating the master key in a standby environment:

dbaascli tde rotateMasterKey --dbname DB_NAME --prepareStandbyBlob true --blobLocation /path/to/blob

Q: How do I apply the standby BLOB file from the primary database when rotating keys on a standby database?

A: Use the --standbyBlobFromPrimary parameter to specify the location of the BLOB file that was prepared on the primary database:

dbaascli tde rotateMasterKey --dbname DB_NAME --standbyBlobFromPrimary /path/to/blob

Q: What should I check if the master key rotation fails?

A: Ensure that:
  • You are running the command as the root user.
  • The database name (--dbname) is correct.
  • Any prerequisite checks were run using --executePrereqs to ensure readiness. Review the error logs for more detailed information on the failure.

Q: What should I do if the operation does not complete successfully in a Data Guard environment?

A: Ensure that the BLOB file from the primary database was prepared correctly using --prepareStandbyBlob, and then use --standbyBlobFromPrimary to apply it on the standby database.

Q: Can I run the dbaascli tde rotateMasterKey command while the database is running?

A: Yes, the command can be executed while the database is running. However, it is recommended to run prerequisite checks beforehand using the --executePrereqs option.

Q: Why is rotating the master key important?

A: Rotating the master key improves database security by ensuring that the encryption keys used for data protection are periodically updated, reducing the risk of key compromise.

Q: Do I need to restart the database after rotating the master key?

A: No, restarting the database is not required after rotating the master key. The key rotation will take effect immediately without any service disruption.

dbaascli tde setKeyVersion

To set the version of the primary key to be used in DB/CDB or PDB, use the dbaascli tde setKeyVersion command.

Run the command as the root user.

Syntax

dbaascli tde setKeyVersion --kmsKeyVersionOCID <value> --dbname <value>
[--pdbName <value>]
[--masterKeyID <value>]
[--standbySuc]
[--executePrereqs]
[--waitForCompletion <value>]
Where:
  • --kmsKeyVersionOCID specifies the KMS key version OCID to set.
  • --dbname specifies the name of the database.
  • --pdbName name of the PDB to use the key version OCID.
  • --masterKeyID specifies the master key ID of the given key version OCID. This is applicable to the Data Guard environment.
  • --standbySuc specify this property in the primary database of the Data Guard environment once the command is successfully run on the standby database
  • --executePrereqs execute the prerequisites checks and report the results.
  • --waitForCompletion specify false to run the operation in background. Valid values: true|false

Frequently Asked Questions

Q: What is the purpose of the dbaascli tde setKeyVersion command?

A: The dbaascli tde setKeyVersion command is used to set the version of the primary encryption key that should be used for Transparent Data Encryption (TDE) in a database or Pluggable Database (PDB). This allows for the specific version of a KMS key to be assigned to the database.

Q: What are the prerequisites for using the dbaascli tde setKeyVersion command?

A: You must run the command as the root user and ensure that you are connected to an Exadata Cloud@Customer virtual machine.

Q: What does the --kmsKeyVersionOCID parameter specify?

A: The --kmsKeyVersionOCID parameter specifies the KMS key version OCID (Oracle Cloud Identifier) that you want to set for the database or PDB.

Q: What does the --dbname parameter specify?

A: The --dbname parameter specifies the name of the Oracle Database for which the key version will be set.

Q: What is the purpose of the --pdbName parameter?

A: The --pdbName parameter specifies the name of the Pluggable Database (PDB) within a Container Database (CDB) where you want to set the specific KMS key version.

Q: What is the --masterKeyID parameter used for?

A: The --masterKeyID parameter specifies the master key ID that is associated with the given KMS key version OCID. This is particularly important in a Data Guard environment.

Q: What is the role of the --standbySuc parameter?

A: The --standbySuc parameter is used in a Data Guard environment. It specifies that this property should be set on the primary database after successfully running the command on the standby database.

Q: What does the --executePrereqs parameter do?

A: The --executePrereqs parameter specifies whether to run prerequisite checks before executing the operation. Valid values are yes or no.

Q: What does the --waitForCompletion parameter control?

A: The --waitForCompletion parameter determines whether the operation will run synchronously (waiting for completion) or asynchronously (in the background). Valid values are true or false.

Q: Is the --pdbName parameter required if setting the key version for a CDB?

A: No, the --pdbName parameter is only required if you are setting the key version for a specific Pluggable Database (PDB). It is optional if you are setting the key version for the entire Container Database (CDB).

Q: Is the --masterKeyID parameter necessary for non-Data Guard environments?

A: No, the --masterKeyID parameter is typically only used in Data Guard environments. For standalone databases, this parameter is not required.

Q: How do I set the key version for a database?

A: You can set the key version for a database by running:

dbaascli tde setKeyVersion --kmsKeyVersionOCID <value> --dbname <DB_NAME>

Q: How do I set the key version for a specific PDB?

A: To set the key version for a specific Pluggable Database (PDB), use the --pdbName parameter along with the database name:

dbaascli tde setKeyVersion --kmsKeyVersionOCID <value> --dbname <DB_NAME> --pdbName <PDB_NAME>

Q: How can I ensure that all prerequisites are met before setting the key version?

A: You can run the prerequisite checks by using the --executePrereqs parameter:

dbaascli tde setKeyVersion --kmsKeyVersionOCID <value> --executePrereqs yes

Q: How do I set the key version in a Data Guard environment?

A: In a Data Guard environment, you should:
  • Run the command on the standby database:

    dbaascli tde setKeyVersion --kmsKeyVersionOCID <value> --masterKeyID <keyID> --dbname <DB_NAME>

  • After successfully running the command on the standby database, run the command on the primary database using the --standbySuc parameter:

    dbaascli tde setKeyVersion --kmsKeyVersionOCID <value> --dbname <DB_NAME> --standbySuc yes

Q: How can I run the operation in the background without waiting for it to complete?

A: You can run the operation asynchronously by setting --waitForCompletion to false:

dbaascli tde setKeyVersion --kmsKeyVersionOCID <value> --waitForCompletion false

Q: What should I do if the key version fails to set?

A: Ensure that:
  • You are running the command as the root user.
  • The KMS key version OCID is correct.
  • Any prerequisite checks were run using --executePrereqs to ensure readiness. Review error logs for specific details and rerun the operation if needed.

Q: What should I check if the operation doesn't complete successfully in a Data Guard environment?

A: Ensure that the --masterKeyID parameter is correctly specified when running the command on the standby database. Once completed on the standby, the --standbySuc parameter should be used when running the command on the primary database.

Q: Can I run the dbaascli tde setKeyVersion command while the database is running?

A: Yes, the command can be executed while the database is running. However, running the prerequisite checks beforehand using --executePrereqs is recommended.

Q: Why is it important to set the correct KMS key version for a database?

A: Setting the correct KMS key version ensures that the database is using the appropriate encryption key version for TDE, which helps maintain data security and compliance with organizational policies.

Q: What happens if I use the wrong KMS key version OCID?

A: If an incorrect KMS key version OCID is used, the encryption may fail, and the database will not be able to use the incorrect key for encryption operations. You should ensure that the correct key version OCID is provided.

Q: Do I need to restart the database after setting the key version?

A: No, restarting the database is not necessary after setting the key version. The new key version will take effect immediately without requiring a restart.

Example 7-53 dbaascli tde setKeyVersion

dbaascli tde setKeyVersion --dbname dbname --kmsKeyVersionOCID ocid1.keyversion.oc1.eu-frankfurt-1.bjqnwclvaafak.bc4hmd3olgaaa.abtheljsyxtgn4vzi2bbpcej6a7abcwvylkd2lx56lu2s6iwnxwgigu23nha
dbaascli tde setKeyVersion --dbname dbname --kmsKeyVersionOCID ocid1.keyversion.oc1.eu-frankfurt-1.bjqnwclvaafak.bc4hmd3olgaaa.abtheljsyxtgn4vzi2bbpcej6a7abcwvylkd2lx56lu2s6iwnxwgigu23nha --executePrereqs
dbaascli tde setKeyVersion --dbname dbname --pdbName pdb --kmsKeyVersionOCID ocid1.keyversion.oc1.eu-frankfurt-1.bjqnwclvaafak.bc4hmd3olgaaa.abtheljsyxtgn4vzi2bbpcej6a7abcwvylkd2lx56lu2s6iwnxwgigu23nha
dbaascli tde setPrimaryHsmKey

To change the primary HSM (KMS) key for the existing HSM (KMS) configuration, use the dbaascli tde setPrimaryHsmKey command.

Run the command as the root user.

Syntax

dbaascli tde setPrimaryHsmKey --primaryKmsKeyOCID <value> --dbname <value>
[--allStandbyPrepared]
[--bounceDatabase]
[--executePrereqs]
[--resume [--sessionID <value>]]
Where:
  • --primaryKmsKeyOCID specifies the primary KMS key to set
  • --dbname specifies the name of the database
  • --allStandbyPrepared specify to confirm that the operation has been successfully run on all the standby databases.
  • --bounceDatabase specify this flag to do rolling database bounce for this operation
  • --executePrereqs execute the prerequisites checks and report the results.
  • --resume to resume the previous execution
  • --sessionID to resume a specific session id.

Frequently Asked Questions

Q: What is the purpose of the dbaascli tde setPrimaryHsmKey command?

A: The dbaascli tde setPrimaryHsmKey command is used to change the primary HSM (Hardware Security Module) or KMS (Key Management Service) key in an existing HSM/KMS configuration for Transparent Data Encryption (TDE).

Q: What are the prerequisites for running the dbaascli tde setPrimaryHsmKey command?

A: The command must be executed as the root user, and the environment should be an Exadata Cloud@Customer virtual machine.

Q: What does the --primaryKmsKeyOCID parameter specify?

A: The --primaryKmsKeyOCID parameter specifies the OCID (Oracle Cloud Identifier) of the primary KMS key to be set for the TDE environment.

Q: What is the function of the --dbname parameter?

A: The --dbname parameter specifies the name of the Oracle Database for which the primary HSM/KMS key will be set.

Q: What does the --standbySuc parameter do?

A: The --standbySuc parameter is used in a Data Guard environment. It specifies that the command should be run on the primary database after successfully executing it on the standby database.

Q: What is the purpose of the --precheckOnly parameter?

A: The --precheckOnly parameter allows you to run only the prechecks for this operation. It validates the environment without making any actual changes. Valid values are yes or no.

Q: What does the --bounceDatabase parameter control?

A: The --bounceDatabase parameter specifies whether the database should be bounced (restarted) in a rolling manner as part of the operation. This ensures minimal downtime by restarting parts of the database one by one.

Q: How do I set the primary KMS key for my database?

A: To set the primary KMS key, run the following command:

dbaascli tde setPrimaryHsmKey --primaryKmsKeyOCID <key_OCID> --dbname <DB_NAME>

Q: How do I ensure that the operation can be executed without any issues?

A: Run the operation with the --precheckOnly parameter to verify that all prerequisites are met:

dbaascli tde setPrimaryHsmKey --primaryKmsKeyOCID <key_OCID> --precheckOnly yes

Q: How do I set the primary KMS key in a Data Guard environment?

A: First, run the command on the standby database:

dbaascli tde setPrimaryHsmKey --primaryKmsKeyOCID <key_OCID> --dbname <DB_NAME>

Then, run the command on the primary database with the --standbySuc parameter:

dbaascli tde setPrimaryHsmKey --primaryKmsKeyOCID <key_OCID> --dbname <DB_NAME> --standbySuc yes

Q: How do I minimize downtime while changing the primary KMS key?

A: You can use the --bounceDatabase parameter to perform a rolling restart, minimizing downtime:

dbaascli tde setPrimaryHsmKey --primaryKmsKeyOCID <key_OCID> --bounceDatabase

Q: Is the --dbname parameter required for all databases?

A: Yes, you should specify the --dbname parameter to indicate the target database for which the primary KMS key should be set.

Q: Is it mandatory to use the --standbySuc parameter in a Data Guard environment?

A: Yes, the --standbySuc parameter must be used when running the command on the primary database after successfully executing it on the standby database.

Q: Can I skip the bounce operation for the database?

A: Yes, if you do not specify the --bounceDatabase parameter, the database will not be bounced (restarted) as part of the operation.

Q: What should I do if the command fails during execution?

A: If the command fails, ensure:
  • You are running it as the root user.
  • The correct --primaryKmsKeyOCID and --dbname values are provided.
  • The environment passes all prerequisite checks (run with --precheckOnly).

Q: What if the operation fails in a Data Guard environment?

A: Ensure that the command has been successfully executed on the standby database before running it on the primary. Check for errors in the logs and rerun the operation with correct parameters.

Q: Can I run the dbaascli tde setPrimaryHsmKey command on a live database?

A: Yes, the command can be run while the database is live. However, using the --bounceDatabase parameter will restart the database in a rolling fashion, which minimizes the impact.

Q: How do I run the command in a rolling manner to avoid complete downtime?

A: Use the --bounceDatabase parameter to perform a rolling restart of the database while changing the primary KMS key:

dbaascli tde setPrimaryHsmKey --primaryKmsKeyOCID <key_OCID> --bounceDatabase

Q: What is the significance of changing the primary KMS key?

A: Changing the primary KMS key ensures that the database uses an updated or different encryption key for Transparent Data Encryption (TDE). This may be required for security or compliance reasons.

Q: How often should the primary KMS key be rotated or changed?

A: While there is no strict rule, organizations may rotate the primary KMS key based on security policies, such as key rotation intervals or compliance requirements.

Q: What happens if the primary KMS key is set incorrectly?

A: If the incorrect key OCID is set, database encryption operations may fail, and you may need to revert to the correct key or rectify the configuration by setting the correct KMS key OCID.

Q: Do I need to restart the database after changing the primary KMS key?

A: No, you do not need to restart the database unless you choose to use the --bounceDatabase parameter, which will automatically restart the database to apply the change.

Example 7-54 dbaascli tde setPrimaryHsmKey

dbaascli tde setPrimaryHsmKey --dbname dbname --primaryKmsKeyOCID ocid1.key.oc1.eu-frankfurt-1.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza
dbaascli tde setPrimaryHsmKey --dbname dbname --primaryKmsKeyOCID ocid1.key.oc1.eu-frankfurt-1.bjqnwclvaafak.abtheljsgfxa2xe5prvlzdxtygoiqpm2pu2afgta54krxwllk5uxainvvxza --executePrereqs
dbaascli tde status

To display information about the keystore for the specified database, use the dbaascli tde status command.

Prerequisite

Run the command as the oracle user.

Syntax

dbaascli tde status --dbname dbname
Where:
  • --dbname specifies the name of the database that you want to check.

Output from the command includes the type of keystore, and the status of the keystore.

Frequently Asked Questions

Q: What does the dbaascli tde status command do?

A: The dbaascli tde status command displays information about the keystore for a specified database. This includes details about the type of keystore and its status.

Q: Who should run the dbaascli tde status command?

A: The command must be executed as the oracle user.

Q: Where should the dbaascli tde status command be run?

A: The command should be run on an Exadata Cloud@Customer virtual machine. You must connect to the virtual machine via SSH to run the utility.

Q: What is the function of the --dbname parameter?

A: The --dbname parameter specifies the name of the database for which the TDE keystore status will be checked.

Q: What information does the dbaascli tde status command return?

A: The output of the command includes the type of keystore (e.g., HSM-based or file-based) and the current status of the keystore, such as whether it is open, closed, or in some other state.

Q: How can I know if the keystore is open or closed using the dbaascli tde status command?

A: The status of the keystore, including whether it is open or closed, is part of the output returned by the dbaascli tde status command.

Q: How do I check the status of the TDE keystore for a specific database?

A: To check the TDE keystore status for a specific database, run:

dbaascli tde status --dbname <DB_NAME>

Q: Can I check the status of the keystore for multiple databases?

A: Yes, but you need to run the command separately for each database, specifying its name using the --dbname parameter.

Q: Can the dbaascli tde status command be run as the root user?

A: No, the command should be executed as the oracle user, not the root user.

Q: Do I need special permissions to run the dbaascli tde status command?

A: Yes, you need to have oracle user privileges and be connected to an Exadata Cloud@Customer virtual machine to run the command.

Q: What should I do if I get an error when running the dbaascli tde status command?

A: Ensure you are running the command as the oracle user, and verify that you have the necessary permissions and are connected to the correct virtual machine.

Q: How do I know what type of keystore my database is using?

A: The type of keystore, such as whether it is file-based or HSM/KMS-based, is displayed in the output of the dbaascli tde status command.

Q: What should I do if the keystore is closed?

A: If the keystore is closed, you may need to open it manually, depending on the operation you are trying to perform. The exact process will depend on the keystore type and your environment.

Q: Can I view keystore status for a CDB (Container Database) or PDB (Pluggable Database)?

A: Yes, by specifying the appropriate database name using the --dbname parameter, you can view the keystore status for both CDBs and PDBs.

Q: What does it mean if the command returns an error about database connectivity?

A: This could indicate an issue with the connection to the database or a problem with your environment. Ensure that the database is running and accessible, and verify your SSH connection to the Exadata Cloud@Customer virtual machine.

Q: What happens if the database name is incorrect?

A: If the --dbname parameter specifies an incorrect or non-existent database, the command will fail, and you’ll receive an error message indicating the problem.

Q: How do I troubleshoot if the keystore status indicates an unexpected state?

A: If the keystore status indicates an unexpected state, review the database logs for more details and check the configuration of the keystore to ensure it is properly set up.

Q: Can I automate the check of keystore status for monitoring purposes?

A: Yes, you can script the dbaascli tde status command to check keystore status periodically or integrate it into your database monitoring tools.

Q: How do I verify that Transparent Data Encryption (TDE) is correctly enabled?

A: You can verify TDE is correctly enabled by checking the status of the keystore using the dbaascli tde status command. A valid and open keystore indicates that TDE is properly configured.

Example 7-55 dbaascli tde status

dbaascli tde status --dbname dbname

Deprecated dbaascli commands

The dbaascli patch db prereq and dbaascli patch db apply commands have been deprecated in dbaascli release 21.2.1.2.0, and replaced with dbaascli grid patch, dbaascli dbhome patch, and dbaascli database move commands.

dbaascli patch db apply
Note

dbaascli patch db prereq and dbaascli patch db apply commands have been deprecated in dbaascli release 21.2.1.2.0, and replaced with dbaascli grid patch, dbaascli dbhome patch, and dbaascli database move commands.
For more information, see:
  • dbaascli grid patch
  • dbaascli dbhome patch
  • dbaascli database move
  • Patching Oracle Grid Infrastructure and Oracle Databases Using dbaascli
dbaascli patch db prereq

Note

dbaascli patch db prereq and dbaascli patch db apply commands have been deprecated in dbaascli release 21.2.1.2.0, and replaced with dbaascli grid patch, dbaascli dbhome patch, and dbaascli database move commands.
For more information, see:
  • dbaascli grid patch
  • dbaascli dbhome patch
  • dbaascli database move
  • Patching Oracle Grid Infrastructure and Oracle Databases Using dbaascli
dbaascli tde status

To display information about the keystore for the specified database, use the dbaascli tde status command.

Prerequisite

Run the command as the oracle user.

Syntax

dbaascli tde status --dbname dbname
Where:
  • --dbname specifies the name of the database that you want to check.

Output from the command includes the type of keystore, and the status of the keystore.

Frequently Asked Questions

Q: What does the dbaascli tde status command do?

A: The dbaascli tde status command displays information about the keystore for a specified database. This includes details about the type of keystore and its status.

Q: Who should run the dbaascli tde status command?

A: The command must be executed as the oracle user.

Q: Where should the dbaascli tde status command be run?

A: The command should be run on an Exadata Cloud@Customer virtual machine. You must connect to the virtual machine via SSH to run the utility.

Q: What is the function of the --dbname parameter?

A: The --dbname parameter specifies the name of the database for which the TDE keystore status will be checked.

Q: What information does the dbaascli tde status command return?

A: The output of the command includes the type of keystore (e.g., HSM-based or file-based) and the current status of the keystore, such as whether it is open, closed, or in some other state.

Q: How can I know if the keystore is open or closed using the dbaascli tde status command?

A: The status of the keystore, including whether it is open or closed, is part of the output returned by the dbaascli tde status command.

Q: How do I check the status of the TDE keystore for a specific database?

A: To check the TDE keystore status for a specific database, run:

dbaascli tde status --dbname <DB_NAME>

Q: Can I check the status of the keystore for multiple databases?

A: Yes, but you need to run the command separately for each database, specifying its name using the --dbname parameter.

Q: Can the dbaascli tde status command be run as the root user?

A: No, the command should be executed as the oracle user, not the root user.

Q: Do I need special permissions to run the dbaascli tde status command?

A: Yes, you need to have oracle user privileges and be connected to an Exadata Cloud@Customer virtual machine to run the command.

Q: What should I do if I get an error when running the dbaascli tde status command?

A: Ensure you are running the command as the oracle user, and verify that you have the necessary permissions and are connected to the correct virtual machine.

Q: How do I know what type of keystore my database is using?

A: The type of keystore, such as whether it is file-based or HSM/KMS-based, is displayed in the output of the dbaascli tde status command.

Q: What should I do if the keystore is closed?

A: If the keystore is closed, you may need to open it manually, depending on the operation you are trying to perform. The exact process will depend on the keystore type and your environment.

Q: Can I view keystore status for a CDB (Container Database) or PDB (Pluggable Database)?

A: Yes, by specifying the appropriate database name using the --dbname parameter, you can view the keystore status for both CDBs and PDBs.

Q: What does it mean if the command returns an error about database connectivity?

A: This could indicate an issue with the connection to the database or a problem with your environment. Ensure that the database is running and accessible, and verify your SSH connection to the Exadata Cloud@Customer virtual machine.

Q: What happens if the database name is incorrect?

A: If the --dbname parameter specifies an incorrect or non-existent database, the command will fail, and you’ll receive an error message indicating the problem.

Q: How do I troubleshoot if the keystore status indicates an unexpected state?

A: If the keystore status indicates an unexpected state, review the database logs for more details and check the configuration of the keystore to ensure it is properly set up.

Q: Can I automate the check of keystore status for monitoring purposes?

A: Yes, you can script the dbaascli tde status command to check keystore status periodically or integrate it into your database monitoring tools.

Q: How do I verify that Transparent Data Encryption (TDE) is correctly enabled?

A: You can verify TDE is correctly enabled by checking the status of the keystore using the dbaascli tde status command. A valid and open keystore indicates that TDE is properly configured.

Example 7-56 dbaascli tde status

dbaascli tde status --dbname dbname