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.

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.

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.

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. 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

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

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

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

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

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]

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.

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

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.

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

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."

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

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.

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.

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]

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.

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.

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.

Prerequisite

• Run the command as the root user.

Syntax

dbaascli database addInstance --dbname <value> --node <value> [--newNodeSID <value>]

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.

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]
        }

--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.]

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.

Prerequisites

Run the command as the oracle user.

Syntax

dbaascli database bounce
[--dbname][--rolling <value>]

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.

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>]]

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.

Syntax

dbaascli database convertToPDB --dbname <value> [--cdbName <value>] [--executePrereqs]
        {
            [--copyDatafiles]
            | [--backupPrepared]
        }
        [--targetPDBName <value>] [--waitForCompletion <value>] [--resume [--sessionID <value>]]

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.

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]

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.

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>]

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.

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>]]

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.

Prerequisite

• Run the command as the root user.

Syntax

dbaascli database deleteInstance --dbname <value> --node <value> [--continueOnUnreachableNode]

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.

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>]

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.

Run the command as the root or oracleuser.

Syntax

dbaascli database getPDBs --dbname <value>

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.

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]

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.

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>
        }

--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.

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

Prerequisites

Run the command as the root user.

Syntax

dbaascli database start
[--dbname]
[--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.

Prerequisites

Run the command as the root user.

Syntax

dbaascli database stop
[-–dbname <value>]
[--mode <value>]

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.

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>]

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.

Run the command as the root or oracle user.

Syntax

dbaascli dataguard prepareStandbyBlob --dbname <value> --blobLocation <value>

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.

Run the command as the root or oracleuser.

Syntax

dbaascli dataguard updateDGConfigAttributes --attributes <value>

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.

Prerequisite

Run the command as the root user.

Syntax

dbaascli dbhome create --version <value>
[--oracleHome <value>]
[--oracleHomeName <value>]
[--enableUnifiedAuditing <value>] 
[--imageTag <value>]
[--ImageLocation <value>

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.

Prerequisite

Run the command as the root user.

Syntax

dbaascli dbHome delete 
{ --oracleHome <value> 
| --oracleHomeName <value> } [--resume [--sessionID <value>]] 

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.

Run the command as the root user.

Syntax

dbaascli dbHome getDatabases
{ --oracleHomeName value | --oracleHome value }

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.

Prerequisite

Run the command as the root user.

Syntax

dbaascli dbHome getDetails
{ --oracleHomeName value | --oracleHome value }

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.

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>]

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.

Prerequisite

Run the command as the root user.

Syntax

dbaascli diag healthCheck
[--destLocation]
[--nodes]
[--objectStoreBucketURI]

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.

Prerequisite

Run the command as the root user.

Syntax

dbaascli gridHome create --version value [--resume [--sessionID value]] [--waitForCompletion value]

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.

Prerequisite

Run the command as the root user.

Syntax

dbaascli grid configureTCPS
[--pkcs12WalletFilePath]
[--caCertChain]
[--precheckOnly]
[--serverCert]
[--privateKey]
[--certType]
[--privateKeyPasswordProtected]

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.

Prerequisite

Run the command as the root user.

Syntax

dbaascli grid removeTCPSCert --subject <value>
 {
   --userCert | --trustedCert | --requestedCert
 }
 [--serialNumber <value>] [--executePrereqs] [--resume [--sessionID <value>]] [--bounceListeners]

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

Prerequisite

Run the command as the root user.

Syntax

dbaascli grid rotateTCPSCert
[--pkcs12WalletFilePath]
[--caCertChain]
[--precheckOnly]
[--serverCert]
[--privateKey]
[--certType]
[--privateKeyPasswordProtected]

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.

Prerequisite

Run the command as the root user.

Syntax

dbaascli grid upgrade --version
[--resume]
[--executePrereqs]
[--containerURL]
[--softwareOnly]
[--targetHome]
[--revert]

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

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.