Using the dbaascli Utility with Oracle Exadata Database Service on
Cloud@Customer
Learn to use the dbaascli utility on Oracle Exadata Database Service on
Cloud@Customer.
About Using the dbaascli Utility on Oracle Exadata Database Service on Cloud@Customer You can use the dbaascli utility to perform various database lifecycle and administration operations on Oracle Exadata Database Service on Cloud@Customer such as creating an Oracle Database, patching an Oracle Database, managing pluggable databases (PDBs), scaling the CPU core count in disconnected mode, and more.
Creating Oracle Database Using dbaascli Using dbaascli, you can create an Oracle Database by first creating an Oracle Database home of desired version, followed by creating a database in that Oracle Database home.
Updating Cloud Tooling Using dbaascli To update the cloud tooling release for Oracle Exadata Database Service on Cloud@Customer, complete this procedure.
About Using the dbaascli Utility on Oracle Exadata Database Service on
Cloud@Customer 🔗
You can use the dbaascli utility to perform various database lifecycle and administration operations on Oracle Exadata Database Service on
Cloud@Customer such as creating an Oracle Database, patching an Oracle Database, managing pluggable databases (PDBs), scaling the CPU core count in disconnected mode, and more.
You must use the DBaaS console or command-line interface to scale
resources. The capabilities of the dbaascli utility are in
addition to, and separate from, the Oracle Cloud Infrastructure Console,
API, or command-line interface (CLI). Unless specified differently, you need
root access to dbaascli to run all
administration commands.
To use the utility, you must be connected to an Exadata
Cloud@Customer virtual machine. See Connecting to a
Virtual Machine with SSH.
To get possible commands available with dbaascli,
run dbaascli --help.
To get command-specific help, run dbaascli command --help. For example,
dbaascli database create --help.
Using dbaascli, you can create an Oracle Database by first
creating an Oracle Database home of desired version,
followed by creating a database in that Oracle
Database home.
Listing Available Software Images and Versions
for Database 🔗
To get a list of available supported versions for creating Oracle
Database, use the dbaascli cswlib showImages command.
Connect to the virtual machine as the opc user.
For detailed
instructions, see Connecting to a Virtual Machine with
SSH.
Start a root user command
shell:
sudo -s
Run the following
command:
dbaascli cswlib showImages
The command output lists the available database software
images.
Exit the root user command
shell:
exit
For more details on advanced
supported options, see dbaascli cswlib showImages.
Example 7-1 dbaascli cswlib showImages
dbaascli cswlib showImages
DBAAS CLI version MAIN Executing command cswlib showImages
INFO : Log file => /var/opt/oracle/log/list/list_2021-05-10_10:11:00.56966610630.log
############ List of Available DB Images #############
1.IMAGE_TAG=19.8.0.0.0
VERSION=19.8.0.0.0
DESCRIPTION=19c JUL 2020 DB Image
IMAGE_ALIASES=19000-19800,19000-JUL2020
2.IMAGE_TAG=19.8.0.0.0-NC
VERSION=19.8.0.0.0
DESCRIPTION=19c JUL 2020 Non CDB Image
IMAGE_ALIASES=19000-NC19800,19000-NCJUL2020
3.IMAGE_TAG=19.9.0.0.0
VERSION=19.9.0.0.0
DESCRIPTION=19c OCT 2020 DB Image
IMAGE_ALIASES=19000-19900,19000-OCT2020
4.IMAGE_TAG=19.9.0.0.0-NC
VERSION=19.9.0.0.0
DESCRIPTION=19c OCT 2020 Non CDB Image
IMAGE_ALIASES=19000-NC19900,19000-NCOCT2020
Note
You can specify the target version in dbaascli dbhome create
command as --version value from the dbaascli cswlib
showImages command output.
To create an Oracle Database home of desired version, use the
dbaascli dbhome create command.
Note
You can create an Oracle Database
home with a specified Oracle home name. If you do not specify, then this is computed
automatically (recommended).
Connect to the virtual machine as the opc user.
For detailed
instructions, see Connecting to a Virtual Machine with
SSH.
Start a root user command
shell:
sudo -s
Run the following command:
dbaascli dbhome create --version Oracle Home Version --imageTag image Tag Value
Where:
--version specifies the Oracle
Database version
--imageTag specifies the Image Tag of
the image to be used
For
example:
dbaascli dbhome create --version 19.9.0.0.0
Note
Specifying
imageTag is optional. To view the Image Tags, refer to
command dbaascli cswlib showImages. Image Tags are
typically same as the version of the database. However, it is kept as a
provision for cases where multiple images may need to be released for the
same version - each catering to a specific customer requirement.
Exit the root user command
shell:
exit
For more
details on advanced supported options, see dbaascli dbhome
create.
Creating Oracle Database In the Specified
Oracle Database Home 🔗
To create an Oracle Database in the specified Oracle Database home of
desired version, use the dbaascli database create command.
You can use the dbaascli database create command
to:
Create a Container Database (CDB) or non-Container Database
Create a CDB with pluggable databases (PDBs)
Create an Oracle Database with the specified Character Set
Create Oracle Databases on a subset of cluster nodes
Note
Databases
created on a subset of nodes will not be displayed in the OCI
console.
Create Oracle Database version 12.1.0.2 or higher with the release update JAN
2021 or higher. For databases with lower versions, it is recommended to use the
OCI Console based API.
Connect to the virtual machine as the opc user.
For detailed
instructions, see Connecting to a Virtual Machine with
SSH.
Start a root user command
shell:
sudo -s
Run the following
command:
dbaascli database create --dbName database name --oracleHome Oracle Home Path
Where:
--dbName specifies the name of the
database
--oracleHome specifies Oracle home
location
To create a CDB, run the following
command:
dbaascli database create --dbName database name --oracleHome Oracle Home Path
To
create a non-CDB, run the following
command:
dbaascli database create --dbName database name --oracleHome Oracle Home Path --createAsCDB false
When
prompted, enter the sys and tde
passwords.
Exit the root user command
shell:
exit
For more
details on advanced supported options, see dbaascli database
create.
Running Prerequisite Checks Prior to Creating
Oracle Database 🔗
To run prerequisites checks, use the --executePrereqs
command option. This will perform only the prerequisite checks without performing the actual
Oracle Database creation.
Connect to the virtual machine as the opc user.
For detailed
instructions, see Connecting to a Virtual Machine with
SSH.
Start a root user command
shell:
sudo -s
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
Exit the root user command
shell:
exit
For more
details on advanced supported options, see dbaascli database
create.
Resuming or Reverting Oracle Database Creation
Operation 🔗
To resume or revert a failed database creation operation, use the
--resume or --revert command option.
For
example:
dbaascli database create --dbName database name --oracleHome Oracle Home Path --resume
Note
While using the --resume or --revert
command options, ensure that you use the same command from the same node
that was used for actual create operation flow.
You can resume database creation only if there is a failure in the post
database creation step.
To change the SYS password, or to change the TDE wallet password, use this
procedure.
The password that you specify in the Database Admin
Password field when you create a new Exadata Database Service on Cloud@Customer instance or database is set as the password for the
SYS, SYSTEM, TDE wallet, and PDB administrator credentials. Use the following
procedures if you need to change passwords for an existing database.
Note
if you are enabling Data Guard for a database, then the SYS password and the TDE
wallet password of the primary and standby databases must all be the same.
Note
Using the dbaascli
to change the SYS password will ensure the backup/restore automation can parallelize
channels across all nodes in the
cluster.
Managing Oracle Exadata Database Service on
Cloud@Customer Software Images Using the Dbaascli Utility
🔗
You can list and download the Oracle database software images on an Oracle Exadata Database Service on
Cloud@Customer instance, which can then be used for provisioning a database home.
Note
You can create custom database software images for your Oracle Exadata Database Service on
Cloud@Customer instances using the Console or API. These images are stored in Object Storage, and can be used to provision a Database Home in your Exadata instance. See Oracle Database Software Images more information.
You can control the version of Oracle binaries that is installed when you provision a new database on an Oracle Exadata Database Service on
Cloud@Customer instance by maintaining the software images on the system. Oracle provides a library of cloud software images that you can view and download onto your instance by using the dbaascli utility.
To download a software image You can download available software images onto your Oracle Exadata Database Service on Cloud@Customer instance by using the cswlib download subcommand of the dbaascli utility.
Listing Available Software Images and Versions
for Database and Grid Infrastructure 🔗
To produce a list of available supported versions for patching, use the
dbaascli cswlib showImages command.
Connect to the virtual machine as the opc user.
For detailed
instructions, see Connecting to a Virtual Machine with
SSH.
Start a root user command
shell:
sudo -s
Run the following
command:
dbaascli cswlib showImages --product database
The command output lists the available database software
images.
dbaascli cswlib showImages --product grid
The command output lists the available grid software
images.
Exit the root user command
shell:
exit
For more details on advanced
supported options, see dbaascli cswlib showImages.
Example 7-2 dbaascli cswlib showImages
[root@dg11lrg1 dbhome_1]# dbaascli cswlib showImages
DBAAS CLI version <version>
Executing command cswlib
showImagesJob id: 00e89b1a-1607-422c-a920-22f44bec1953Log file location:
/var/opt/oracle/log/cswLib/showImages/dbaastools_2022-05-11_08-49-12-AM_46941.log
############
List of Available Database Images
#############
17.IMAGE_TAG=18.17.0.0.0
VERSION=18.17.0.0.0
DESCRIPTION=18c JAN 2022 DB Image
18.IMAGE_TAG=19.10.0.0.0
VERSION=19.10.0.0.0
DESCRIPTION=19c JAN 2021 DB Image
19.IMAGE_TAG=19.11.0.0.0
VERSION=19.11.0.0.0
DESCRIPTION=19c APR 2021 DB Image
20.IMAGE_TAG=19.12.0.0.0
VERSION=19.12.0.0.0
DESCRIPTION=19c JUL 2021 DB Image
21.IMAGE_TAG=19.13.0.0.0
VERSION=19.13.0.0.0
DESCRIPTION=19c OCT 2021 DB Image
Images can be downloaded using their image tags. For details, see help using 'dbaascli cswlib download --help'.
dbaascli execution completed
You can download available software images onto your Oracle Exadata Database Service on
Cloud@Customer instance by using the cswlib download subcommand of the dbaascli utility.
Connect to a compute node as the opc user. For detailed instructions, see Connecting to a Virtual Machine with SSH.
Start a root user command shell:
$ sudo -s
#
Execute the dbaascli command with the cswlib
download subcommand:
# dbaascli cswlib download [--version <software_version>] [--imageTag <image tag
value>]
The command displays the location of software images that are downloaded to your Oracle Exadata Database Service on
Cloud@Customer environment.
The optional parameters are:
version: specifies an Oracle Database software version. For example, 19.14.0.0.0.
Patching Oracle Grid
Infrastructure and Oracle Databases Using dbaascli 🔗
Learn to use the dbaascli utility to perform patching
operations for Oracle Grid Infrastructure and Oracle Database on an Exadata
Cloud@Customer system.
Patching Databases using dbaascli Using dbaascli, you can choose to patch a database by patching Oracle home, or by moving the database to an Oracle home with the desired patch level.
Patching a Database Home (In-Place Database
Patching) 🔗
To patch an Oracle home, use the dbaascli dbHome patch
command.
This will patch all databases running in the specified home, and the
databases will remain in the home after the patching is complete. The following
apply to using the dbHome patch command for in-place patching
operations:
You can patch all of your database nodes or a subset of
nodes.
Multi-node patching takes place in a rolling fashion.
Optionally, you can perform a software-only patch operation.
Then, when you are ready, you can run datapatch to perform
post-patch SQL actions.
You can patch an Oracle home containing one or more
databases.
To patch an Oracle Home (dbhome):
Connect to the virtual machine as the opc user.
For detailed
instructions, see Connecting to a Virtual Machine with
SSH.
--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).
--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.
Patching Oracle Grid Infrastructure (GI) Using
GI Software Image 🔗
To patch Oracle Grid Infrastructure (GI) using GI software image, use this
procedure.
Oracle Grid Infrastructure can also be patched by first creating a
patched software image, and then using that image to perform the patching operation.
This provides the advantage that an image can be created ahead of time outside of
the patching window. It also helps in conflict resolution as any conflicts among the
patches are highlighted during the image creation process without impacting the
patching window.
Listing Available Software Images and Versions
for Database and Grid Infrastructure 🔗
To produce a list of available supported versions for patching, use the
dbaascli cswlib showImages command.
Connect to the virtual machine as the opc user.
For detailed
instructions, see Connecting to a Virtual Machine with
SSH.
Start a root user command
shell:
sudo -s
Run the following
command:
dbaascli cswlib showImages --product database
The command output lists the available database software
images.
dbaascli cswlib showImages --product grid
The command output lists the available grid software
images.
Exit the root user command
shell:
exit
For more details on advanced
supported options, see dbaascli cswlib showImages.
Example 7-3 dbaascli cswlib showImages
[root@dg11lrg1 dbhome_1]# dbaascli cswlib showImages
DBAAS CLI version <version>
Executing command cswlib
showImagesJob id: 00e89b1a-1607-422c-a920-22f44bec1953Log file location:
/var/opt/oracle/log/cswLib/showImages/dbaastools_2022-05-11_08-49-12-AM_46941.log
############
List of Available Database Images
#############
17.IMAGE_TAG=18.17.0.0.0
VERSION=18.17.0.0.0
DESCRIPTION=18c JAN 2022 DB Image
18.IMAGE_TAG=19.10.0.0.0
VERSION=19.10.0.0.0
DESCRIPTION=19c JAN 2021 DB Image
19.IMAGE_TAG=19.11.0.0.0
VERSION=19.11.0.0.0
DESCRIPTION=19c APR 2021 DB Image
20.IMAGE_TAG=19.12.0.0.0
VERSION=19.12.0.0.0
DESCRIPTION=19c JUL 2021 DB Image
21.IMAGE_TAG=19.13.0.0.0
VERSION=19.13.0.0.0
DESCRIPTION=19c OCT 2021 DB Image
Images can be downloaded using their image tags. For details, see help using 'dbaascli cswlib download --help'.
dbaascli execution completed
Performing a Precheck Before
Patching Databases and Grid Infrastructure 🔗
You can perform a prerequisites-checking operation (also called a
"precheck") for the commands in this topic using the applicable precheck flag.
Running prechecks allows you to run only the precheck portion of the patching operation
without performing actual patching. Oracle recommends running prechecks to discover
software issues that could prevent successful patching.
To perform patching prechecks, first, connect to a virtual machine in your Exadata
Cloud@Customer instance as the root user.
--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).
--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
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
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.
To update the cloud tooling release for Oracle Exadata Database Service on
Cloud@Customer,
complete this procedure.
Cloud-specific tooling is used on the Exadata Cloud@Customer Guest VMs
for local operations, including dbaascli
commands.
The cloud tooling is automatically updated by Oracle when
new releases are made available. If needed, you can follow the steps
below to ensure you have the latest version of the cloud-specific
tooling on all of the virtual machines in the VM cluster.
Note
You can
update the cloud-specific tooling by downloading and
applying a software package containing the updated
tools.
Connect to a virtual machine as the
opc user.
For
detailed instructions, see Connecting to a Virtual Machine with
SSH.
Start a root user command
shell:
sudo -s
To update to the latest available cloud tooling release, run the following command:
dbaascli admin updateStack
The command takes care of updating the cloud tooling
release on all the nodes of the cluster.
For
more details and other available options, refer to
dbaascli admin updateStack
--help.
You can create a duplicate database using dbaascli. This new database
can be in the same cloud region as the source region or across the regions. The
following steps describe how to create a duplicate database on cloud.
Note
If a database is configured with OCI Vault for TDE encryption and you want to
duplicate a database, then refer to the following sections.
Prepare for duplication
Ensure that the following prerequisites are ment:
Make sure that there is a network path setup to access the source database
through the EZConnect string.
Copy the TDE wallet file (ewallet.p12 ) to the target
database node. The node where you decide to run the dbaascli
command.
Create an Oracle home on the target node if required. Oracle home version must
be the same version as the source or of higher RU version.
Run prerequisite checks
To run prerequisites checks, use the --executePrereqs command
option. This will perform only the prerequisite checks without performing the actual
Oracle Database duplication.
Using dbaascli, you can duplicate an on-prem database onto the cloud. This can be done with the dbaascli database duplicate command. This command creates a new database on the cloud, which is a duplicate of an on-prem database along with its data. While this process is going on, the on-prem database remains still operational. You can migrate your applications to the duplicated database on the cloud after due verification.
Prepare for duplication
The migration process includes the following prerequisites to be met.
Make sure that there is a network path setup to access an on-prem database from the OCI node through the EZConnect string.
If an on-prem database is configured with TDE, copy the TDE wallet file (ewallet.p12 ) to the OCI node, where you decide to run the dbaascli command.
Create an Oracle home on the OCI node if required. The Oracle home version must be the same as the source or of a higher RU version.
Verify the necessary RPMs
This process requires a minimum dbaastools RPM version of 23.3.2.0.0 but updating to the latest dbaastools rpm is always recommended.
To check the currently installed version, run:
dbaascli --version
DBAAS CLI version 23.3.2.0.0
To apply the latest tools RPM, as the root user, run:
# dbaascli admin updateStack
Run the prerequisite checks
To run the prerequisite checks, use the --executePrereqs command option. This will perform only the prerequisite checks without performing the actual Oracle Database duplication.
Upon successful completion of this command, the database is duplicated to Cloud and ready for sanity checks for application usage. Once verification is done, application connections can be migrated to the Cloud database.
Refer to dbaascli database duplicate –help for additional configuration options.
Few considerations for migration
If you prefer to allocate multiple channels for RMAN duplicate, you could do so by specifying the --rmanParallelism argument.
Exadata Cloud Service configures database memory as Automatic Shared Memory Management (ASMM). If your on-prem database is configured with different memory management, make sure to adjust memory parameter values accordingly on the OCI side by providing values for --sgaSizeInMB and --pgaSizeInMB.
Verify that the on-prem database does not contain any deprecated or invalid initialization parameters.
Database initialization parameters related to database storage (datafile location, redo location, recovery area destination, control file multiplexing) may be changed using the --initParams argument.
For example, to override db_create_online_log_dest value for the duplicate database: --initParams db_create_online_log_dest_1=+DATAC1,db_create_online_log_dest_2=+RECOC1
Troubleshooting the database duplication
dbaascli operation log file can be found under /var/opt/oracle/log/<dbname>/database/duplicate
One of the jobs of the duplicate is to run dbca. Its log file can be found under /u02/app/oracle/cfgtoollogs/dbca and /u02/app/oracle/cfgtoollogs/dbca/<dbuniquename>.
If the operation fails, you will have an option to resume the operation by providing the --resume argument to the same command. Alternatively, clean up the database using dbaascli database delete –dbname <dbname> –force, and then rerun the database duplicate command.
(240219) Bug 36309260 fix applicable to DBCS agent version 21.2 or
earlier: communication between OCI Control Plane and DBCS agent does not work in
some VMs.
Added support to set custom key version OCID (Bring Your Own Key - BYOK) of
OCI Vault during create and clone operations. For details, see respective
PDB commands help.
Grid Infrastructure (GI) Patching
Enhanced the patching workflow to improve patching time, especially in
environments having high number of databases.
A new option --patchInParallel is introduced that can be used to perform patching remote nodes in parallel.
Database Patching
Provided option to run datapatch on a specific node of cluster.
dbaascli gridHome create - This command can be used to
create a Grid Infrastructure home of a supported version. For details, see
dbaascli gridHome create --help.
dbaascli system getGridHomes - This command gives details
on the available Grid Infrastructure homes on the system. For details, see
dbaascli system getGridHomes --help.
Pluggable Database Operations
Improvements in the area of refreshable pluggagble database lifecycle.
Database Backup and Recovery
Added support to configure backups on standby sites in case of
Data Guard configurations. The backups configuration are Data Guard
site-specific, that is, the change of roles (for example, with Data Guard
switchover operation) will not impact the backup operations of the database
on primary or standby sites. Backups, if configured on primary site or
stand-by site, will continue regardless of the role-change.
Includes AHF version 23.5.2 - Release 23.3.1.0.0 (230817)
Includes AHF version 23.5.4 - Release 23.3.1.0.0 (231020)
Introduced dbaascli grid removeTCPSCert to remove expired
TCPS certificates. For details, see dbaascli grid removeTCPSCert
--help.
Added option to exclude specific PDBs during database duplicate. For
details, see skipPDBs argument in dbaascli database
duplicate --help.
Database Backup and Recovery
Changed the default for FILES_PER_SET to 64
for OSS backups. This can be changed with dbaascli database backup
--configure. For details, see dbaascli database backup
--help.
Archive log backups continue from the standby site after the role switchover
in data guard environments.
For backups that are not managed by Oracle, the schedules for L0
and L1 backups are not created by default. They must be be created
explicitly by using dbaascli database backup --configure
command.
Includes AHF version 23.3.4 - Release 23.2.1.0.0 (230708)
Includes AHF version 23.3.5 - Release 23.2.1.0.0 (230724)
Added option to create database templates (DBCA temapltes) to object store.
DBCA templates can subsequently be used to create databases. For details,
see dbaascli database createTemplate --help.
Pluggable Database Operations
Introduced dbaascli pdb refresh to refresh a pluggable
database that was created using manual refresh option. For details, see
dbaascli pdb refresh --help.
Added option to convert refreshable pluggable database to a regular
pluggable database. For details, see dbaascli pdb open
--help.
Creation of a refreshable pluggable database now requires existing source
database user for creation of database link to the source pluggable
database. For details, see dblinkUserName argument in
dbaascli pdb remoteClone --help.
Added option to not open the PDB at the end of relocate. For
details, see skipOpenPDB argument in dbaascli pdb
relocate --help. After using this option, the pdb relocate can
be completed by running the command using
completePDBRelocate argument.
Added option to clean up the relocated PDB metadata/services at the source
location. For details, see cleanupRelocatedPDB argument in
dbaascli pdb delete --help
New dbaascli commands
dbaascli database createTemplate - This command
can be used to create database templates (DBCA templates) that can
subsequently be used to create databases. DBCA templates are widely used for
creating a clone database with DBCA - a tool that is shipped with Oracle
Database server software. For details, see dbaascli database
createTemplate --help
Introduced dbaascli tde rotateMasterKey to
rotate the master key for database encryption. For details, see
dbaascli tde rotateMasterKey --help. The command
dbaascli tde rotate masterkey is now deprecated.
Database Lifecycle related improvements
Added support to use dbca templates in database creation workflows. For
details, see dbcaTemplateFilePath argument in
dbaascli database create --help
Improved performance for duplicate database creation. For details on how to
create duplicate database, see dbaascli database duplicate
--help
Added support to create a duplicate database from a source database which is
not TDE-encrypted.
TDE management
Introduced dbaascli tde rotateMasterKey to rotate the
master key for database encryption. For details, see dbaascli tde
rotateMasterKey --help. The command dbaascli tde rotate
masterkey is now deprecated.
Revamped workflow for all TDE operations. For details, see dbaascli
tde --help
Grid Infrastructure (GI) Patching
Added support to allow parallel execution of patching operation on nodes.
This option needs to be carefully exercised as it results into reduced
database availability.
Database Backup and Recovery
Revamped workflow for creating database from standalone backups
dbaascli database getDetails - This command
shows the detailed information of a given database, for example, dbname,
node information, pluggable databases information, and so on. For details,
see dbaascli database getDetails --help.
Pluggable Database Operations
Added support for creating pluggable databases as refreshable
clone using refreshablePDB argument. For details, see
dbaascli pdb remoteClone --help
dbaascli database addInstance - This command can be used to
add a database instance to one of the nodes of the cluster where database is
not already configured. For details, see dbaascli database
addInstance --help.
dbaascli database deleteInstance - This command can be used
to delete a database instance from one of the nodes of the cluster where
database is configured. For details, see dbaascli database
deleteInstance --help.
dbaascli database duplicate - This command can be used to
create a new database from an already existing database within a cluster, or
across clusters, provided network connection exists between the clusters.
For details, see dbaascli database duplicate --help.
Cloud Software Library
Introduced dbaascli cswlib listLocal command to
list images that are downloaded from software library locally on the system.
For details, see dbaascli cswlib listLocal --help. The
command dbaascli dbimage list is now deprecated.
Introduced dbaascli cswlib deleteLocal command
to delete images that are downloaded from cloud software library. For
details, see dbaascli cswlib deleteLocal --help. The
command dbaascli dbImage purge is now deprecated.
The log location for the command dbaascli admin
updateStack has been changed to follow the convention of other
dbaascli commands. The logs can be conveniently found under
/var/opt/oracle/log/admin/updateStack directory. The
earlier location was /var/opt/oracle/log/tooling/Update.
dbaascli help is now cloud platform aware in that it will list help
output for commands applicable for the cloud environment it is operating on.
Added support for changing TDE password in dataguard environments. For
details, see dbaascli tde changePassword --help. This support is
currently not available for 11.2.0.4 release.
Included AHF version 22.1.5.
Revamped workflow for database upgrade operation.
Revamped workflow for database home create operation.
dbaascli dbHome getDatabases - This command
lists all the databases running from a given database Oracle home. The
output is returned in JSON format to facilitate automation. For details, see
dbaascli dbHome getDatabases --help.
dbaascli database getPDBs - This command lists
all the pluggable databases of a given container database. The output is
returned in JSON format to facilitate automation. For details, see
dbaascli database getPDBs --help.
dbaascli dbHome delete - This command deletes
a given database Oracle home. For details, see dbaascli dbHome
delete --help.
dbaascli dataguard prepareStandbyBlob - This
command generates a blob file containing various files that are required on
the standby site for a Data Guard environment. For details, see
dbaascli dataguard prepareStandbyBlob --help.
Grid Infrastructure (GI) Patching:
New optimized workflow
Introduced a way to create the Grid Infrastructure (GI)
software image prior to patching. This GI image can be subsequently used for
performing the GI patching operation. The advantage of this approach is that
it results in reduced patching window as the image is already prepared. The
GI stack on the node is not brought down to create the image. For details,
see createImage option in dbaascli grid patch
--help
Introduced a way to perform the Grid Infrastructure patching
through the use of user specified GI software image, created using
createImage option of the dbaascli grid
patch command. For details, see imageLocation
option in dbaascli grid patch --help.
Change Password support in Data Guard environment:
Added support to change password in Data Guard environments.
For details, see dbaascli database changePassword --help
and dbaascli dataguard prepareStandbyBlob --help
Data Guard configuration:
Added support to update Data Guard Automation Attributes (in the
/var/opt/oracle/dg/dg.conf file). For details, see
dbaascli dataguard --help.
Introduced dbaascli admin showLatestStackVersion to show
the latest dbaastools version available for customers to download and
install. The installation of dbaastools RPM can be performed by using
the command dbaascli admin updateStack. For details see the
dbaascli Command Reference section.
Cloud Software Library:
Deprecated the support for BP activation (dbaascli cswlib
activateBP) as BPs (Bundle Patches) are now replaced with RUs
("Release Updates"). Cloud deployment consumes RUs in the form of software
images, identified with Image Tags. It is therefore
recommended to use image tags while interfacing with Cloud Software Library
(cswlib) commands. For details, see dbaasscli
cswlib download –help.
Eliminated the need to download non-CDB images to create non-CDB
databases. Now users can create the non-CDB database using regular images.
For details, see createAsCDB option in dbaascli
database create –help.
Non-CDB Database Creation:
Enhanced database creation workflow to create a non-CDB database
using standard database software image. For details, see
createAsCDB option in dbaascli database create
–help.
Database Home Patching:
New optimized workflow
Grid Infrastructure Upgrade:
New optimized workflow
Pluggable Database (PDB) Operations:
Deletion of PDB in Data Guard environments requires explicit acknowledgment
to indicate that operations necessary on standby site are completed, by
passing of additional argument –allStandByPrepared. For
details, see dbaascli pdb delete --help.
Provided rolling capability for database bounce operation. For details, see
dbaascli database bounce –help.
Introduced dbaascli system getDBHomes to get all the
database Oracle homes on the cluster. The output is returned in JSON format
to facilitate automation.
Introduced dbaascli dbhome getDetails to get detailed
information on a specific Oracle home. The output is returned in JSON format
to facilitate automation.
Cloud Software Library (cswlib):
Deprecated the support for dbaascli cswlib list command for
cloud software library listing operations. The new command is
dbaascli cswlib showImages that lists the images along
with its of ImageTag. It is recommended to use
Image tags to download the images from the cloud
software library. For details on downloads using image tags, see
dbaascli cswlib download –help.
Internal update to metadata repository for backup metadata
Introduced deprecation messages for bkup_api commands as
they are now replaced with dbaascli commands. For details,
see dbaascli database backup --help and dbaascli
database recover –help
Pluggable Database (PDB) Operations:
Relocate operation of PDB is now supported. For details, see
dbaascli pdb relocate –help.
Revamped workflow for non-CDB to PDB conversion. For details, see
dbaascli database convertToPDB –help.
Encryption Key Management:
Transparent Data Encryption (TDE) heartbeat-specific initialization
parameters are set to the cloud recommended values for databases with
'Customer Managed Keys'.
Cloud Software Library Management:
Revamped software library download of artifacts through
imageTags. It is recommended to use
imageTags to download the database and grid software
images. For details, see dbaascli cswlib showimages and
dbaascli cswlib download –help
Enabled encryption of the system level tablespaces
(SYSTEM, SYSAUX, UNDO, and
TEMP) for databases that will get created with this version of
dbaastools onwards. This feature is enabled for Oracle Database version 19.6.0.0.0
and above.
Grid Patching:
Prerequisite condition added to check for following file
ownership to be owned by grid user.
Simultaneous database move operation is
disallowed by default. A new option –allowParallelDBMove is
introduced that can be used to override the default behavior for Oracle
Database releases 12.2 and above.
Fixed issues related to move of standby databases being in
MOUNT mode.
Database Backup and Recovery:
Added new command-line options for database backup. For more
details, refer to dbaascli database backup command
reference.
Added new command-line options for database recovery. For more
details, refer to dbaascli database recover command
reference.
bkup_api usage for backup and recovery
operations will be deprecated in future.
To align with the Oracle recommended practice of using
SYSBACKUP administrative privilege for Backup and
Recovery operations, cloud automation creates a common administrative user
C##DBLCMUSER with SYSBACKUP role at
the CDB$ROOT container level. Backup and Recovery
operations are therefore performed with the user having the least required
privileges. Credentials for this user are randomly generated and securely
managed by cloud automation. If the user is not found or is
LOCKED and EXPIRED, then cloud
automation will recreate or unlock this user during the backup or recovery
operation. This change in the cloud automation is made starting with
dbaastools version 21.4.1.1.0.
Enhanced dbaascli resume functionality to resume any
previous session by specifying the –sessionID <value> argument to the resume command. The session ID
is shared in the dbaascli output as well as in the logs.
Enhanced dbaascli help output to show the command
usage.
Deprecated the usage of dbaascli shell (interactive
session). This will be completely unsupported after March 2022. It is recommended to
execute complete dbaascli commands on command prompt as suggested
in all document examples.
Included Autonomous Health Framework (AHF) version 21.2.8.
Improved the timing of dbaascli operations with
enhanced Control Plane metadata synchronization logic.
Enhanced dbaascli logs to have millisecond-level
information along with the associated thread.
Introduced more prerequisite checks in database home patching and
database move operations to catch potential failures scenarios with suggestions to
corrective action.
Database patching operations now retain the state of the databases to
be same as it was prior to patching. For pluggable databases, pdb saved state is
honored.
Added support to unlock PDB Admin user account as part of PDB creation,
localClone, or remoteClone operation. For
details, see option --lockPDBAdminAccount in dbaascli pdb
create --help.
Fixed an issue that updates the database resource registered with Oracle
Grid Infrastructure in existing environments with the correct value of database
name.
Support for the following dbaascli commands to be run
as oracle user.
dbaascli pdb bounce
dbaascli pdb close
dbaascli pdb connectString
dbaascli pdb create
dbaascli pdb delete
dbaascli pdb getDetails
dbaascli pdb list
dbaascli pdb localClone
dbaascli pdb open
dbaascli pdb remoteClone
Revamped out-of-place patching of database. For details, see
dbaascli database move –help.
Timing related enhancements in Oracle Grid Infrastructure patching
workflow. For details, see dbaascli grid patch –help.
Deprecated the support for exadbcpatchmulti /
dbaascli patch for patching operations. The dbaascli
dbhome patch and dbaascli grid patch commands are
provided for patching operation for database homes and Oracle Grid Infrastructure.
Refer to the Patching Oracle Grid Infrastructure and Oracle Database Using dbaascli section for details. Also see,
dbaascli Command Reference section.
Deprecated the support for dbaascli tools patch command
to bring consistency in the dbaascli command conventions. The new
command is dbaascli admin updateStack. For details, see section
Updating Cloud Tooling using dbaascli.
Ability to run dbaascli in disconnected mode for long
running operations. Executing dbaascli command with
--waitForCompletion false gets you a job ID that can be queried
later to get the status of the operation, using dbaascli job getStatus
–jobid job_id. This is useful for long
running operations where users may want to get the control back immediately after
command execution. In this release, this option is available only for
dbaascli database create command. More commands will be added
in subsequent releases to have this support. The help output for those commands will
reflect the support of --waitForCompletion option.
Deprecated the support for dbaascli shell. It is
recommended that users run the complete dbaascli commands on the
command prompt as suggested in all the document examples. Execution of just
dbaascli will show the output of its usage help instead of
entering into a dbaascli shell.
Redesigned Oracle Grid Infrastructure patching operation and added
ability to resume from failed point, patch on subset of nodes, instance draining,
and other enhancements. For details, see dbaascli grid patch
--help. Also refer to the Patching Oracle Grid
Infrastructure and Oracle Database Using dbaascli section.
Deprecated the support for exadbcpatchmulti /
dbaascli patch for patching operations. dbaascli dbhome
patch and dbaascli grid patch commands are provided
for patching operation for database homes and Oracle Grid Infrastructure. Refer to
the Patching Oracle Grid Infrastructure and Oracle Database Using
dbaascli section for details. Also see, dbaascli
Command Reference section.
Deprecated the support for dbaascli tools patch command
to bring consistency in the command conventions. The new command is dbaascli
admin updateStack.
Redesigned PDB management APIs for create, local clone, and remote clone
operations. For details, see dbaascli pdb --help.
Redesigned database delete API. For details, see dbaascli
database delete --help.
Revamped dbhome creation (support for custom software image, scale-out
operation). For details, see dbaascli dbhome create --help.
Support for database creation on subset of cluster nodes. For details,
see dbaascli database create --help.
Ability to run dbaascli in disconnected mode for long
running operations. Executing dbaascli command with
--waitForCompletion false gets you a job ID that can be queried
later to get the status of the operation, using dbaascli job getStatus
–jobid job_id. This is useful for long
running operations where users may want to get the control back immediately after
command execution. In this release, this option is available only for
dbaascli database create command. More commands will be added
in subsequent releases to have this support. The help output for those commands will
reflect the support of --waitForCompletion option.
Enhanced dbhome patching experience with introduction of multiple
options like skipPDBs, continueWithDowntime, and
so on. For details, see dbaascli dbhome patch --help.
Support for better diagnostic collection. For details, see
dbaascli diag collect --help.
Minor improvements in the area of database upgrade automation.
You
must use dbaascli to create databases and integrate them with the cloud
automation framework.
dbaascli is a cloud native interface that can take DBCA
templates as inputs, calls the functionality of DBCA to create databases, and then calls
OCI APIs to integrate the database into the cloud automation framework. Customers using
DBCA in scripts today can update their existing scripts to call
dbaascli instead of DBCA. If dbaascli cannot be
used due to a particular feature of DBCA being unavailable in dbaascl, then customers
should open a My Oracle Support (MOS) request to add that functionality to
dbaascli.
Administration and Configuration This section covers essential tasks for managing and configuring Oracle Database environments. It includes commands such as dbaascli admin updateStack for installing or updating the dbaastools RPM, and dbaascli job getStatus for checking the status of specific jobs.
CPU Scaling This section focuses on adjusting CPU resources in a VM cluster. It includes commands like dbaascli cpuscale get_status to check the status of current or past scaling requests, and dbaascli cpuscale update to increase or decrease the number of CPU cores allocated to a virtual machine, allowing flexible resource management based on workload demands.
Cloud Software Library (CSWLIB) Management This section provides tools for managing software images in Exadata Database Service on Cloud@Customer environments. Commands like dbaascli cswlib deleteLocal allow for the removal of local images, while dbaascli cswlib download enables the download of new software images. You can also view available images locally with dbaascli cswlib listLocal or check all available Database and Grid Infrastructure images using dbaascli cswlib showImages. These commands help manage and maintain software libraries efficiently.
Database Management This section covers comprehensive tasks for managing Oracle Databases. It includes commands for creating (dbaascli database create), deleting (dbaascli database delete), and upgrading databases (dbaascli database upgrade). Other key tasks include adding and deleting instances (dbaascli database addInstance, dbaascli database deleteInstance), managing backups (dbaascli database backup), and handling database recovery (dbaascli database recover). You can also modify database parameters, manage pluggable databases, patch databases, and convert non-CDB databases to PDBs. These commands ensure efficient control over the entire database lifecycle.
Data Guard Management This section focuses on managing Oracle Data Guard configurations and operations. It includes commands like dbaascli dataguard prepareStandbyBlob to generate a blob file for setting up a standby site, and dbaascli dataguard updateDGConfigAttributes to update Data Guard automation attributes across all cluster nodes. These commands streamline the setup and maintenance of Data Guard environments for high availability and disaster recovery.
Database Home Management This section provides tools for managing Oracle Database homes. It includes commands such as dbaascli dbhome create to create a new Oracle Database home and dbaascli dbHome delete to remove an existing one. You can also view detailed information about a specific Oracle home with dbaascli dbHome getDetails and check which databases are running from a given Oracle home using dbaascli dbhome getDatabases. These commands ensure efficient management of database environments.
Diagnostics and Health Checks This section covers tools for maintaining the health and diagnosing issues in Oracle Database environments. Commands like dbaascli diag collect are used to gather diagnostic data, while dbaascli diag healthCheck allows you to run health checks to identify potential issues. These tools help ensure the system's stability and performance by proactively monitoring and addressing concerns.
Grid Infrastructure Management This section focuses on managing Oracle Grid Infrastructure, which supports clustering and high availability. Key tasks include configuring a Grid Infrastructure home (dbaascli gridHome create), upgrading the Grid Infrastructure (dbaascli grid upgrade), and managing TCPS (Transport Layer Security) certificates by configuring (dbaascli grid configureTCPS), removing (dbaascli grid removeTCPSCert), or rotating them (dbaascli grid rotateTCPSCert). These commands ensure efficient setup, maintenance, and security of the Grid Infrastructure.
Patching and Upgrading This section provides tools for updating and maintaining Oracle environments through patching and upgrades. It includes commands such as dbaascli grid patch to patch Oracle Grid Infrastructure, dbaascli dbHome patch to apply patches to Oracle homes, and dbaascli database move to move databases between homes during upgrades or patching processes. These commands help ensure systems remain secure, stable, and up-to-date.
Pluggable Database (PDB) Management This section covers the management of Pluggable Databases (PDBs) within a container database (CDB). It includes commands for creating (dbaascli pdb create), deleting (dbaascli pdb delete), and cloning PDBs (dbaascli pdb localClone, dbaascli pdb remoteClone). You can manage PDB states with commands to open, close, or bounce PDBs, and retrieve connection details (dbaascli pdb getConnectString). Additional commands support backup, recovery, and relocating PDBs, ensuring comprehensive control over PDB lifecycle and operations.
System Management This section focuses on overseeing and managing Oracle homes within the system. It includes commands like dbaascli system getDBHomes to view details about all Oracle Database homes and dbaascli system getGridHomes to list the details of all Grid Infrastructure homes. These commands provide essential information for maintaining and troubleshooting the overall system environment.
Transparent Data Encryption (TDE) Management This section encompasses the management of Transparent Data Encryption (TDE) for securing database data. It includes commands for handling encryption keys and keystores, such as dbaascli tde addSecondaryHsmKey to add secondary HSM keys, dbaascli tde rotateMasterKey to rotate the master key, and dbaascli tde encryptTablespacesInPDB to encrypt tablespaces within a pluggable database. You can also convert between FILE and HSM-based TDE (dbaascli tde fileToHsm, dbaascli tde hsmToFile), manage key versions, and retrieve key details with various commands. These tools ensure effective encryption management and data security.
Deprecated dbaascli commands The dbaascli patch db prereq and dbaascli patch db apply commands have been deprecated in dbaascli release 21.2.1.2.0, and replaced with dbaascli grid patch, dbaascli dbhome patch, and dbaascli database move commands.
This section covers essential tasks for managing and configuring Oracle Database environments. It includes commands such as dbaascli admin updateStack for installing or updating the dbaastools RPM, and dbaascli job getStatus for checking the status of specific jobs.
dbaascli admin updateStack To install or update a dbaastools RPM, use the dbaascli admin updateStack command.
dbaascli job getStatus To view the status of a specified job, use the dbaascli job getStatus command.
--prechecksOnly runs only the prechecks for
this operation
--nodes specifies a comma-delimited list of
nodes to install the RPM on. If you do not pass this argument, then the RPM
will be installed on all of the cluster nodes
Frequently Asked Questions
Q: What is the dbaascli admin updateStack command used for?
A: The dbaascli admin updateStack command is used to install or update a dbaastools RPM on Exadata Cloud Infrastructure.
Q: What are the prerequisites for using the dbaascli admin updateStack command?
A: You must run the command as the root user and connect to an Exadata Cloud Infrastructure virtual machine.
Q: What does the --resume option do?
A: The --resume option resumes the previous execution of the updateStack command if it was interrupted or incomplete.
Q: What is the purpose of the --prechecksOnly option?
A: The --prechecksOnly option runs only the prechecks for the operation without actually performing the installation or update.
Q: How is the --nodes parameter used?
A: The --nodes parameter specifies a comma-delimited list of nodes on which the RPM should be installed. If not provided, the RPM will be installed on all cluster nodes.
Q: What should I do if I encounter issues with the dbaascli admin updateStack command?
A: Ensure you are running the command as the root user and that you are connected to an Exadata Cloud Infrastructure virtual machine. Check if there are any specific error messages and consult the command documentation or Oracle support if needed.
Q: How do I connect to an Exadata Cloud Infrastructure virtual machine to use the dbaascli admin updateStack command?
A: You need to use SSH to connect to the virtual machine. Refer to the section on "Connecting to a Virtual Machine with SSH" in the documentation for detailed instructions.
Example Use Cases
Example 1: Installing or updating the dbaastools RPM on all nodes
dbaascli admin updateStack
Installs or updates the dbaastools RPM on all nodes of the Exadata Cloud@Customer environment.
Example 2: Running prechecks only before installing or updating the RPM
dbaascli admin updateStack --prechecksOnly
Runs only the prechecks for the dbaastools RPM update, without actually performing the installation. It ensures that all prerequisites are satisfied before proceeding with the update.
Example 3: Resuming a previously interrupted updateStack operation
dbaascli admin updateStack --resume
Resumes a previous dbaastools RPM update operation that was interrupted or did not complete successfully.
Example 4: Installing or updating dbaastools on specific nodes
dbaascli admin updateStack --nodes node1,node2
Installs or updates the dbaastools RPM on the specified nodes node1 and node2 only, without affecting other nodes in the cluster.
Example 5: Resuming the updateStack process on specific nodes
This section focuses on adjusting CPU resources in a VM cluster. It includes commands like dbaascli cpuscale get_status to check the status of current or past scaling requests, and dbaascli cpuscale update to increase or decrease the number of CPU cores allocated to a virtual machine, allowing flexible resource management based on workload demands.
dbaascli cpuscale get_status To check the status of current or last scale request performed when network connectivity between the Control Plane Server and OCI region is disrupted, use the dbaascli cpuscale get_status command.
dbaascli cpuscale update To scale up or down the CPU core count for a virtual machine in a VM cluster when network connectivity between the Control Plane Server and OCI region is disrupted, use the dbaascli cpuscale update command.
To check the status of current or last scale request performed when network
connectivity between the Control Plane Server and OCI region is disrupted, use the
dbaascli cpuscale get_status command.
Prerequisites
Run the command as the root user.
To use the utility, you must connect to an Exadata Cloud@Customer virtual
machine.
See, Connecting to a Virtual Machine with SSH.
Syntax
Displays various command execution states as it progresses from scheduled, running, and finally to success or failure.
dbaascli cpuscale get_status
Frequently Asked Questions
Q: What is the dbaascli cpuscale get_status command used for?
A: The dbaascli cpuscale get_status command is used to check the status of the current or last CPU scale request, especially when network connectivity between the Control Plane Server and OCI region is disrupted.
Q: What are the prerequisites for using the dbaascli cpuscale get_status command?
A: You must run the command as the root user and connect to an Exadata Cloud@Customer virtual machine.
Q: What should I do if I encounter issues running the dbaascli cpuscale get_status command?
A: Ensure you are running the command as the root user and that you are connected to an Exadata Cloud@Customer virtual machine. If issues persist, consult the command documentation or seek support from Oracle.
Q: What if the command shows a status of failure?
A: If the command shows a failure status, check the detailed logs for error messages and troubleshoot based on the specific error. You may need to address network issues or review the scale request details.
Example Use Cases
Example 1: Checking the status of the most recent CPU scaling operation
dbaascli cpuscale get_status
Checks the status of the current or last CPU scaling request. It will provide information on whether the scaling is scheduled, running, or has completed with success or failure.
Example 2: Checking the status after a scaling request failed
A scaling operation was requested but encountered network issues between the Control Plane Server and the OCI region.
dbaascli cpuscale get_status
Checks the status of the scaling request. Since the scaling process failed due to network issues, the output will provide details about the failure state.
Example 3: Checking the status when scaling is in progress
A CPU scaling operation is ongoing, and the user wants to monitor its progress.
dbaascli cpuscale get_status
Checks the current status, showing that the scaling request is in the "running" state. It allows the user to track the operation until it completes or fails.
Example 4: Checking the status after successful scaling completion
A scaling operation was performed and completed successfully.
dbaascli cpuscale get_status
Checks the status and confirms that the scaling operation has successfully completed. It reports the final state as "success."
To scale up or down the CPU core count for a virtual machine in a VM cluster
when network connectivity between the Control Plane Server and OCI region is disrupted, use
the dbaascli cpuscale update command.
Prerequisites
To scale OCPUs up or down in a VM cluster in disconnected mode, run the
dbaascli cpuscale update and dbaascli cpuscale
get_status commands from any node inside a VM cluster to change the CPU
core count for that cluster. If you have more than one VM cluster, then run a
separate command from any node inside each VM cluster you want to scale up or down.
These commands are designed to not work if issued during the normal connected mode
and will time out after 600 seconds (10 minutes).
Run the command as the root user.
To use the utility, you must connect to an Exadata Cloud@Customer virtual
machine.
See, Connecting to a Virtual Machine with SSH.
Syntax
Exadata Database Service on Cloud@Customer is considered to be
in a Disconnected mode when there is a loss of connectivity with the DBaaS
control plane running on Oracle Cloud Infrastructure (OCI).
--coreCount specifies the target number of CPUs you want to scale up or down for each VM in the cluster
--message optionally, you can include a message for your
reference
Frequently Asked Questions
Q: What is the dbaascli cpuscale update command used for?
A: The dbaascli cpuscale update command is used to scale up or down the CPU core count for a virtual machine in a VM cluster when network connectivity between the Control Plane Server and Oracle Cloud Infrastructure (OCI) is disrupted.
Q: What are the prerequisites for using the dbaascli cpuscale update command?
A: Before using this command, ensure you are running it in disconnected mode, meaning there is a loss of connectivity with the DBaaS control plane on OCI. Run the command from any node inside the VM cluster, and note that it will time out after 600 seconds (10 minutes) if used in connected mode. The command must be executed as the root user.
Q: How do I connect to a virtual machine to use this command?
A: To use the dbaascli cpuscale update command, you need to connect to an Exadata Cloud@Customer virtual machine using SSH. Refer to "Connecting to a Virtual Machine with SSH" for detailed instructions.
Q: What does the --coreCount option specify in the command?
A: The --coreCount option specifies the target number of CPUs you want to scale up or down for each VM in the cluster.
Q: Can I include a message with the dbaascli cpuscale update command?
A: Yes, you can include an optional message using the --message option for your reference.
Q: How do I check the status of a CPU scale operation?
A: To check the status of a CPU scale operation, use the dbaascli cpuscale get_status command. This should be run from any node inside the VM cluster as well.
Q: What happens if I run the dbaascli cpuscale update command in connected mode?
A: The command is designed to not work in connected mode and will time out after 600 seconds (10 minutes). It should only be used in disconnected mode.
Q: How do I scale CPU cores for multiple VM clusters?
A: If you have more than one VM cluster, you need to run the dbaascli cpuscale update command separately from any node inside each VM cluster that you want to scale up or down.
Example Use Cases
Example 1: Scaling up CPU cores to 20
The VM cluster is running with 16 cores, and you want to increase it to 20.
dbaascli cpuscale update --coreCount 20 --message "Scaling up for increased demand"
Scales the CPU core count up to 20, and includes a message "Scaling up for increased demand" for reference.
Example 2: Scaling down CPU cores to 8
The VM cluster is currently using 12 cores, but you want to reduce the count to 8 to save resources.
dbaascli cpuscale update --coreCount 8 --message "Reducing CPU for maintenance period"
Reduces the number of CPU cores to 8 and provides a message for future reference about why the scaling operation was performed.
Example 3: Scaling CPU without a message
You need to scale the CPU cores from 32 to 24, but no additional message is necessary.
dbaascli cpuscale update --coreCount 24
This command scales the core count down to 24 without any message. The operation will be carried out with the default logging of actions.
Example 4: Verifying the status after scaling CPU
After running the scaling command, you want to check if the update was successful.
dbaascli cpuscale get_status
Checks the status of the current or last scaling request, allowing you to confirm whether the scale-up or scale-down operation was successful.
Example 5: Attempting to scale when VM is already at maximum cores
The VM cluster already has the maximum allowed CPU cores (48), but an attempt is made to scale up.
This section provides tools for managing software images in Exadata Database Service on Cloud@Customer environments. Commands like dbaascli cswlib deleteLocal allow for the removal of local images, while dbaascli cswlib download enables the download of new software images. You can also view available images locally with dbaascli cswlib listLocal or check all available Database and Grid Infrastructure images using dbaascli cswlib showImages. These commands help manage and maintain software libraries efficiently.
dbaascli cswlib download To download available software images and make them available in your Exadata Database Service on Cloud@Customer environment, use the dbaascli cswlib download command.
dbaascli cswlib listLocal To view the list of locally available Database and Grid Infrastructure images, use the dbaascli cswlib listLocal command.
dbaascli cswlib showImages To view the list of available Database and Grid Infrastructure images, use the dbaascli cswlib showImages command.
To delete the local image, use the dbaascli cswlib
deleteLocal command.
Run the command as the root user.
Syntax
dbaascli cswLib deleteLocal --imageTag <value>
Where:
--imageTag specifies Oracle home image tag
Frequently Asked Questions
Q: What is the purpose of the dbaascli cswlib deleteLocal command?
A: The dbaascli cswlib deleteLocal command is used to delete a local Oracle home image from the system.
Q: What are the prerequisites for running the dbaascli cswlib deleteLocal command?
A: The command must be run as the root user to ensure the necessary permissions are available to delete the local image.
Q: How do I specify which local image to delete?
A: Use the --imageTag option to specify the Oracle home image tag that you want to delete.
Q: What does the --imageTag option represent in the command?
A: The --imageTag option represents the identifier or tag associated with the Oracle home image that you want to delete.
Q: Can I delete multiple local images at once using this command?
A: No, the dbaascli cswlib deleteLocal command allows you to delete only one local image at a time, specified by its image tag.
Q: What happens if I run the dbaascli cswlib deleteLocal command without specifying the --imageTag?
A: The command will fail because the --imageTag is required to identify which local image should be deleted.
Q: Is it possible to recover a local image after it has been deleted using this command?
A: No, once the local image is deleted using the dbaascli cswlib deleteLocal command, it cannot be recovered. Make sure to verify the image tag before proceeding.
Q: When would I need to use the dbaascli cswlib deleteLocal command?
A: You would use this command when you need to remove an unused or outdated Oracle home image from the local system to free up space or clean up your environment.
To download available software images and make them available in your
Exadata Database Service on Cloud@Customer environment, use the
dbaascli cswlib download command.
Prerequisites
Run the command as the root user.
To use the utility, you must connect to an Exadata Database Service on Cloud@Customer virtual machine.
--product specifies the image type. Valid
values: database or grid
Frequently Asked Questions
Q: What is the purpose of the dbaascli cswlib download command?
A: The dbaascli cswlib download command is used to download available software images and make them available in your Exadata Cloud Infrastructure.
Q: What are the prerequisites for running the dbaascli cswlib download command?
A: You must run the command as the root user. Additionally, you need to be connected to an Exadata Cloud Infrastructure virtual machine.
Q: How do I connect to the virtual machine required for this command?
A: You need to use SSH to connect to the Exadata Cloud Infrastructure virtual machine. Detailed instructions can be found in the documentation under "Connecting to a Virtual Machine with SSH."
Q: What does the --version option specify in the command?
A: The --version option specifies the Oracle home image version that you want to download.
Q: How do I use the --imageTag option in the dbaascli cswlib download command?
A: The --imageTag option is used to specify the image tag of the software image you want to download.
Q: What is the purpose of the --product option in the command?
A: The --product option specifies the type of image you want to download. The valid values are database or grid.
Q: Can I download both database and grid images simultaneously?
A: No, you must specify either database or grid using the --product option, so each download operation is specific to one type of image.
Q: What happens if I do not specify a version or image tag?
A: The command will likely fail or prompt you for the required information since the --version or --imageTag options are necessary to identify the specific software image to download.
Q: Is it necessary to specify both --version and --imageTag together?
A: No, you typically specify either --version or --imageTag depending on how you want to identify the image to download, but not both at the same time.
Q: When would I use the dbaascli cswlib download command?
A: You would use this command when you need to download Oracle home software images for database or grid environments in your Exadata Cloud Infrastructure setup.
Example 7-5 dbaascli cswlib download --product
--imageTag
To view the list of locally available Database and Grid Infrastructure
images, use the dbaascli cswlib listLocal command.
Run the command as the root user.
Syntax
dbaascli cswLib listLocal [--product <value>]
Where:
--product identifies Oracle home product type.
Valid values: database or grid.
Frequently Asked Questions
Q: What is the purpose of the dbaascli cswlib listLocal command?
A: The dbaascli cswlib listLocal command is used to view the list of locally available Database and Grid Infrastructure images on your system.
Q: What are the prerequisites for running the dbaascli cswlib listLocal command?
A: The command must be run as the root user to have the necessary permissions to access and list the available images.
Q: How do I specify which type of images to list using this command?
A: Use the --product option to specify the type of Oracle home images you want to list. The valid values are database or grid.
Q: What does the --product option represent in the dbaascli cswlib listLocal command?
A: The --product option identifies the Oracle home product type, allowing you to filter the list of available images to either database or grid types.
Q: Can I list both database and grid images simultaneously?
A: No, the --product option allows you to list either database or grid images at a time. You need to run the command twice with different --product values to see both lists.
Q: What happens if I do not specify the --product option in the command?
A: If the --product option is not specified, the command might list all locally available images or it could require you to specify the product type. The behavior may depend on your environment setup.
Q: When should I use the dbaascli cswlib listLocal command?
A: You should use this command when you want to check which Database or Grid Infrastructure images are currently available locally on your system.
Q: How can I differentiate between database and grid images in the list?
A: The --product option lets you filter the list, so by specifying database or grid, you will only see the images relevant to that product type, making it easier to differentiate.
Q: Is there any risk associated with running the dbaascli cswlib listLocal command?
A: No, this command is non-destructive and only displays information about locally available images. It does not modify or delete any files.
Q: Does this command display remote or cloud-stored images?
A: No, the dbaascli cswlib listLocal command only displays images that are available locally on your system, not those stored remotely or in the cloud.
Example 7-7 dbaascli cswlib listlocal
dbaascli cswlib listlocal
DBAAS CLI version MAIN
Executing command cswlib listlocal
Job id: bc4f047c-0a34-4d4d-a1ea-21ddc2a9c627
Log file location: /var/opt/oracle/log/cswLib/listLocal/dbaastools_2022-07-18_10-29-53-AM_16077.log
############ List of Available Database Images #############
1.IMAGE_TAG=12.2.0.1.220419
IMAGE_SIZE=5GB
VERSION=12.2.0.1.220419
DESCRIPTION=12.2 APR 2022 DB Image
2.IMAGE_TAG=18.16.0.0.0
IMAGE_SIZE=6GB
VERSION=18.16.0.0.0
DESCRIPTION=18c OCT 2021 DB Image
3.IMAGE_TAG=19.14.0.0.0
IMAGE_SIZE=5GB
VERSION=19.14.0.0.0
DESCRIPTION=19c JAN 2022 DB Image
dbaascli execution completed
To view the list of available Database and Grid Infrastructure images,
use the dbaascli cswlib showImages command.
Run the command as the root user.
Syntax
dbaascli cswlib showImages
[--product]
Where:
--product identifies Oracle home product type.
Valid values: database or grid.
Frequently Asked Questions
Q: What is the purpose of the dbaascli cswlib showImages command?
A: The dbaascli cswlib showImages command is used to view the list of available Database and Grid Infrastructure images that can be downloaded or managed within your Oracle Exadata Database Service environment.
Q: What are the prerequisites for running the dbaascli cswlib showImages command?
A: The command must be run as the root user to ensure you have the necessary permissions to view the available images.
Q: How do I filter the images listed by this command?
A: You can filter the images by specifying the --product option with either database or grid to list only the images related to that product type.
Q: What does the --product option represent in the dbaascli cswlib showImages command?
A: The --product option identifies the Oracle home product type, allowing you to filter the list of images to either database or grid.
Q: Can I view both database and grid images in a single command execution?
A: No, you need to run the command twice with different --product values (database and grid) to view both types of images.
Q: What happens if I do not specify the --product option in the command?
A: If the --product option is not specified, the command may list all available images or it may prompt you to specify the product type, depending on your environment configuration.
Q: When should I use the dbaascli cswlib showImages command?
A: Use this command when you want to view the list of Database or Grid Infrastructure images that are available for download or deployment in your Oracle Exadata Database Service environment.
Q: Is there any difference between dbaascli cswlib showImages and dbaascli cswlib listLocal commands?
A: Yes, dbaascli cswlib showImages lists all available images that you can download or manage, while dbaascli cswlib listLocal lists only the images that are already downloaded and available locally on your system.
Q: Can this command be used to view images stored in the cloud?
A: Yes, this command can show images that are available for download from Oracle's repositories, not just those that are stored locally.
Q: What type of images can I expect to see with this command?
A: You can expect to see images related to Oracle Database and Grid Infrastructure, which are essential components for managing and running Oracle databases on Exadata platforms.
This section covers comprehensive tasks for managing Oracle Databases. It includes commands for creating (dbaascli database create), deleting (dbaascli database delete), and upgrading databases (dbaascli database upgrade). Other key tasks include adding and deleting instances (dbaascli database addInstance, dbaascli database deleteInstance), managing backups (dbaascli database backup), and handling database recovery (dbaascli database recover). You can also modify database parameters, manage pluggable databases, patch databases, and convert non-CDB databases to PDBs. These commands ensure efficient control over the entire database lifecycle.
dbaascli database addInstance To add the database instance on the specified node, use the dbaascli database addInstance command.
dbaascli database backup To configure Oracle Database with a backup storage destination, take database backups, query backups, and delete a backup, use the dbaascli database backup command.
dbaascli database bounce To shut down and restart a specified Exadata Database Service on Cloud@Customer database, use the dbaascli database bounce command.
dbaascli database changepassword To change the password of a specified Oracle Database user, use the dbaascli database changePassword command. When prompted enter the user name for which you want to change the password and then enter the password.
dbaascli database convertToPDB To convert the specified non-CDB database to PDB, use the dbaascli database convertToPDB command.
dbaascli database create To create Oracle Database, use the dbaascli database create command. When prompted, enter the sys and tde passwords.
dbaascli database createTemplate Use this command to create database templates (DBCA templates) that can subsequently be used to create databases.
dbaascli database delete To delete an Oracle Database, use the dbaascli database delete command.
dbaascli database deleteInstance To delete the database instance on the specified node, use the dbaascli database deleteInstance command.
dbaascli database duplicate To create a database from an active database, use the dbaascli database duplicate command.
dbaascli database getDetails This command shows the detailed information of a given database e.g. dbname, node information, pluggable databases information etc.
dbaascli database getPDBs To view the list of all pluggable databases in a container database, use the dbaascli database getPDBs command.
dbaascli database modifyParameters To modify or reset initialization parameters for an Oracle Database, use the dbaascli database modifyParameters command.
--node specifies the node name for the database instance
--newNodeSID specifies SID for the instance to add
in the new node
Frequently Asked Questions
Q: What is the purpose of the dbaascli database addInstance command?
A: The dbaascli database addInstance command is used to add a new database instance to a specified node in an Oracle Exadata Database Service environment.
Q: What are the prerequisites for running the dbaascli database addInstance command?
A: The command must be run as the root user to have the necessary permissions to add a database instance.
Q: What does the --dbname option represent in this command?
A: The --dbname option specifies the name of the Oracle Database for which you want to add a new instance.
Q: What is the --node option used for in the dbaascli database addInstance command?
A: The --node option specifies the name of the node where the new database instance will be added.
Q: What is the purpose of the --newNodeSID option in this command?
A: The --newNodeSID option allows you to specify the SID (System Identifier) for the new database instance that will be created on the specified node.
Q: Is it mandatory to specify the --newNodeSID option when adding a new instance?
A: The --newNodeSID option is optional. If not provided, Oracle will automatically generate an SID for the new database instance.
Q: When should I use the dbaascli database addInstance command?
A: Use this command when you want to scale your database by adding a new instance to an additional node in a multi-node Oracle Database setup.
Q: Can I add multiple database instances to different nodes using this command?
A: Yes, you can run the command multiple times to add database instances to different nodes by specifying the appropriate --node and --dbname values.
Q: What happens if the node specified in the --node option is not available?
A: The command will fail if the specified node is not available or reachable. Ensure that the node is properly configured and accessible before running the command.
Q: Can this command be used in a Data Guard environment?
A: Yes, you can use the dbaascli database addInstance command in a Data Guard environment to add instances, but it is recommended to follow the necessary Data Guard guidelines for such configurations.
Q: Will this command cause database downtime?
A: Adding an instance to a new node typically does not cause downtime for the existing database instances, but it’s recommended to check your environment for any specific dependencies.
To configure Oracle Database with a backup storage destination, take database
backups, query backups, and delete a backup, use the dbaascli database
backup command.
--dbname: Oracle Database name.
--list | --start | --delete | --status | --getBackupReport | --configure | --getConfig--list: Returns database backup information.
[--json: Specify the file name for JSON output.]
--start: Begins database backup.
[--level0 | --level1 | --archival]
[--level0: Creates a Level-0 (full) backup. ]
[--level1: Creates a Level-1 (incremental) backup. ]
[--archival: Creates an Archival full backup. ]
--tag: Specify backup tag.
--delete: Deletes Archival backup.
--backupTag <value>--status--uuid <value>--getBackupReport: Returns backup report.
--tag: Specify backup tag.
--latest: Returns latest backup report (all types of database backup).
--json: Specify the file name for JSON output.
--configure: Configures database for backup.
--configFile | --enableRTRT | --disableRTRT--configFile: Specify database backup configuration file.
--enableRTRT: Enables Real Time Redo Transport.
--disableRTRT: Disables Real Time Redo Transport.
--getConfig: Returns database backup configuration.
[--configFile: Specify the database backup configuration file.]
--validate: Validates that backups are complete and corruption-free.
[--untilTime: Validates from closest Level-0 (full) backup until time provided. Input format: DD-MON-YYYY HH24:MI:SS.]
--showHistory: Displays the history of backup operations.
[--all: Displays all backup operations.]
Note
enableRTRT and
disableRTRT are applicable only for ZDLRA backup destination on
Exadata Database Service on Cloud@Customer.
Frequently Asked Questions
Q: What is the purpose of the dbaascli database backup command?
A: The dbaascli database backup command is used to configure Oracle Database backup storage destinations, take backups, query backups, and delete existing backups.
Q: What are the prerequisites for running the dbaascli database backup command?
A: The command must be run as the root user to have the necessary permissions for backup management.
Q: How do I start a full backup of the Oracle Database using this command?
A: To start a full backup (Level-0), use the following syntax:
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:
Q: What are RTRT (Real-Time Redo Transport) options and when should I use them?
A: The RTRT options (--enableRTRT and --disableRTRT) are used to control Real-Time Redo Transport, applicable only for ZDLRA (Zero Data Loss Recovery Appliance) backup destinations in Exadata Cloud@Customer environments. Enable RTRT to ensure real-time redo log shipping.
Example 7-9 Examples
To change the archive log retention period follow the below steps:
--rolling specifies true or
false to bounce the database in a rolling manner.
Default value is false.
The command performs a database shutdown in immediate mode. The database
is then restarted and opened. In Oracle Database 12c or later, all of the PDBs are
also opened.
Frequently Asked Questions
Q: What is the purpose of the dbaascli database bounce command?
A: The dbaascli database bounce command is used to shut down and restart an Oracle Database in Exadata Cloud Infrastructure. It supports restarting the database in a rolling manner, ensuring minimal disruption.
Q: What are the prerequisites for running the dbaascli database bounce command?
A: The command must be run as the oracle user, which has the required privileges to shut down and restart the database.
Q: What does the --dbname option specify in this command?
A: The --dbname option specifies the name of the Oracle Database that you want to shut down and restart.
Q: What is the --rolling option used for in the dbaascli database bounce command?
A: The --rolling option specifies whether to bounce (restart) the database in a rolling manner. If set to true, the database instances are restarted one by one, ensuring minimal downtime. The default value is false, which restarts all instances at once.
Q: What does "bouncing the database" mean?
A: Bouncing the database refers to shutting it down and then restarting it. This operation can be used for maintenance, applying changes, or recovering from certain types of issues.
Q: Does the dbaascli database bounce command perform a graceful shutdown?
A: Yes, the command performs a shutdown in "immediate" mode, which closes the database and rolls back uncommitted transactions without waiting for users to disconnect.
Q: Will this command automatically open all PDBs in an Oracle 12c or later database?
A: Yes, if the database is running Oracle Database 12c or later, the command will automatically open all Pluggable Databases (PDBs) after restarting the database.
Q: Can the dbaascli database bounce command be used in a multi-node or RAC (Real Application Clusters) environment?
A: Yes, in a multi-node or RAC environment, you can use the --rolling option to restart the database instances one by one, minimizing downtime.
Q: What happens if I do not specify the --rolling option?
A: If the --rolling option is not specified, or if it's set to false, the command will shut down and restart all database instances at the same time, which may cause a brief downtime.
Q: Is there a default value for the --rolling option in the dbaascli database bounce command?
A: Yes, the default value for the --rolling option is false, meaning the database will be bounced in a non-rolling fashion unless otherwise specified.
Q: How do I restart a database in rolling mode?
A: To restart the database in rolling mode, use the following syntax:
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.
To
change the password of a specified Oracle Database user, use the dbaascli database
changePassword command. When prompted enter the user name for which you want to
change the password and then enter the password.
--dbname specifies the name of the Oracle
Database that you want to act on
--user specifies the user name whose password
change is required
--prepareStandbyBlob specifies
true to generate a blob file containing the artifacts
needed to change the password in a Data Guard environment. Valid values:
true|false
--blobLocation specifies the custom path where
blob file will be generated
--standbyBlobFromPrimary specifies the standby
blob file, which is prepared from the primary database
--resume specifies to resume the previous
execution
--sessionID specifies to resume a specific session
ID
Frequently Asked Questions
Q: What does the dbaascli database changePassword command do?
A: The dbaascli database changePassword command is used to change the password of a specified Oracle Database user. You will be prompted to enter the username and then the new password.
Q: What are the prerequisites for using the dbaascli database changePassword command?
A: You must run the command as either the root or oracle user to change the password for a database user.
Q: How do I specify the database when using this command?
A: Use the --dbname option to specify the name of the Oracle Database you want to act on. For example:
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:
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.
--cdbName specifies the name of the target CDB
in which the PDB will be created. If the CDB does not exist, then it will be
created in the same Oracle home as the source non-CDB
--executePrereqs specifies to run only the
pre-conversion checks
--copyDatafiles specifies to create a new copy
of the data files instead of using the ones from the source database
--backupPrepared flag to acknowledge that a proper database
backup is in place for the non-CDB prior to performing the conversion to
PDB
--targetPDBName specifies the name of the PDB
that will be created as part of the operation
--waitForCompletion specifies
false to run the operation in the background. Valid
values: true|false
--resume specifies to resume the previous
execution
--sessionID specifies to resume a
specific session ID
Frequently Asked Questions
Q: What does the dbaascli database convertToPDB command do?
A: The dbaascli database convertToPDB command converts a specified non-CDB Oracle Database into a Pluggable Database (PDB) within a Container Database (CDB).
Q: How do I specify which database to convert?
A: Use the --dbname option to specify the name of the non-CDB Oracle Database that you want to convert. For example:
dbaascli database convertToPDB --dbname <db_name>
Q: How do I specify the target CDB for the PDB conversion?
A: Use the --cdbName option to specify the name of the target Container Database (CDB) in which the new PDB will be created. If the CDB does not exist, a new one will be created in the same Oracle home as the source non-CDB.
Q: What does the --executePrereqs option do?
A: The --executePrereqs option runs pre-conversion checks to ensure that the database is ready for conversion. No changes will be made to the database during this step.
Q: How do I copy the data files during the conversion?
A: You can use the --copyDatafiles option to create a new copy of the data files rather than using the original files from the source database.
Q: What is the purpose of the --keepSourceDB option?
A: The --keepSourceDB option allows you to preserve the original source non-CDB after the conversion operation is completed. If you do not use this option, the source database will be removed after conversion.
Q: How do I confirm that a backup is prepared before conversion?
A: Use the --backupPrepared flag to acknowledge that you have taken a proper backup of the non-CDB database before performing the conversion. This step is crucial to avoid data loss.
Q: How do I specify a custom name for the new PDB?
A: Use the --targetPDBName option to provide a specific name for the new PDB that will be created as part of the conversion. For example:
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.
To create Oracle Database, use the dbaascli database
create command. When prompted, enter the sys and
tde passwords.
Use this command to create Oracle Database version 12.1.0.2 or higher
with the release update JAN 2021 or higher. For databases with lower versions, it is
recommended to use the OCI Console based API.
--kmsKeyOCID specifies KMS key OCID to use for TDE. This is
applicable only if KMS is selected for TDE
--resume resumes the previous execution
--revert rolls back the previous run
--sessionID resumes or reverts to a specific
session ID.
--executePrereqs specifies
yes to run only the prereqs for this operation. Valid
values: yes or no
--honorNodeNumberForInstance specifies
true or false to indicate instance
name to be suffixed with the cluster node numbers. Default value:
true
--lockPDBAdminAccount specifies
true or false to lock the PDB admin
user account. Default value is true
--dbcaTemplateFilePath specifies the absolute
path of the dbca template name to create the database.
--waitForCompletion specifies
false to run the operation in the background. Valid
values: true or false
Frequently Asked Questions
Q: What does the dbaascli database create command do?
A: The dbaascli database create command is used to create a new Oracle Database instance. It supports creating Oracle Database version 12.1.0.2 or higher with the release update JAN 2021 or higher.
Q: How do I specify the name of the Oracle Database to create?
A: Use the --dbName option to specify the name of the Oracle Database. For example:
dbaascli database create --dbName <db_name>
Q: How can I create a Container Database (CDB)?
A: Use the --createAsCDB option and specify true to create the database as a CDB. For example:
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:
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.
--uploadToObjectStorage: specifies to upload the template
to Object Storage
--objectStorageLoginUser: specifies the Object
Storage login user
--objectStorageBucketName: specifies the Object
Storage bucket name
--objectStorageUrl: specifies the Object Storage
URL
--templateName: specifies the name of the template
--rmanParallelism specifies the parallelsim
value
Frequently Asked Questions
Q: What is the purpose of the dbaascli database createTemplate command?
A: The dbaascli database createTemplate command is used to create database templates (DBCA templates) from a specified database, which can later be used to create new databases.
Q: How do I specify the name of the database for which I want to create a template?
A: Use the --dbname option to specify the name of the Oracle Database from which the template will be created. For example:
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.
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.
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:
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.
--node specifies the node name for database instance
--continueOnUnreachableNode specifies to perform the
operation even if the node is unreachable
Frequently Asked Questions
Q: What is the purpose of the dbaascli database deleteInstance command?
A: The dbaascli database deleteInstance command is used to delete a specific Oracle Database instance on a specified node in an Exadata Cloud Infrastructure environment.
Q: How do I specify which Oracle Database instance to delete?
A: You can specify the Oracle Database instance to delete by using the --dbname option to provide the database name and the --node option to provide the node name. For example:
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:
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.
--sourceDBConnectionString specifies source
database connection string in the format of <scan_name>:<scan_port>/<database_service_name>
--oracleHome specifies Oracle home
location
--oracleHomeName specifies Oracle home
name
--dbSID specifies database SID
--dbUniqueName specifies database unique
name
--sgaSizeInMB specifies
sga_target value in mega byte unit
--pgaSizeInMB specifies
pga_aggregate_target value in mega byte unit
--datafileDestination specifies ASM disk group
name to use for database datafiles
--fraDestination specifies ASM disk group name
to use for database fast recovery area
--fraSizeInMB specifies fast recovery area
size value in mega byte unit
--sourceDBWalletLocation specifies source
database TDE wallet file location. This is required to duplicate database
from active database
--nodeList specifies a comma-delimited list of
nodes for the database
--resume specifies to resume the previous
execution
--sessionID specifies to resume a
specific session ID
--revert specifies to rollback the previous
execution
--sessionID specifies to rollback a
specific session ID
--rmanParallelism specifies parallelsim
value
--rmanSectionSizeInGB specifies RMAN section
size in GB
--tdeConfigMethod specifies TDE configuration method.
Allowed values are FILE and KMS.
--kmsKeyOCID specifies KMS key OCID to use for TDE. This is
applicable only if KMS is selected for TDE.
--sourceDBTdeConfigMethod specifies source database TDE
configuration method. Allowed values are FILE and
KMS.
--sourceDBKmsKeyOCID specifies source database KMS key OCID
to use for TDE. This is applicable only if KMS is selected for TDE.
--executePrereqs specifies yes
to run only the prereqs for this operation. Valid values:
yes|no
--waitForCompletion specifies
false to run the operation in background. Valid values:
true|false
--skipPDBs specifies a comma-delimited list of source
database PDB names, which needs to be excluded for the duplicate database
operation. Example: pdb1,pdb2...
Frequently Asked Questions
Q: What is the purpose of the dbaascli database duplicate command?
A: The dbaascli database duplicate command is used to create a new Oracle Database by duplicating an existing active database.
Q: What are the prerequisites for using the dbaascli database duplicate command?
A: You must run the command as the root user.
Q: How do I specify the source database for duplication?
A: Use the --sourceDBConnectionString option to provide the source database connection string in the format <scan_name>:<scan_port>/<database_service_name>. For example:
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.
This command shows the detailed information of a given database e.g. dbname,
node information, pluggable databases information etc.
Prerequisites
Run the command as the root user or the
oracle user
Syntax
dbaascli database getDetails --dbname <value>
Where :
--dbname - Oracle database name.
Frequently Asked Questions
Q: What is the purpose of the dbaascli database getDetails command?
A: The dbaascli database getDetails command shows detailed information about a specified Oracle database, including the database name, node information, and pluggable database (PDB) details.
Q: Who can run the dbaascli database getDetails command?
A: The command can be run by the root user or the oracle user.
Q: What does the --dbname option specify in the dbaascli database getDetails command?
A: The --dbname option specifies the name of the Oracle database for which detailed information is being retrieved.
Q: What kind of information does the dbaascli database getDetails command provide?
A: The command provides details such as the database name, node information, and information about pluggable databases (PDBs) associated with the container database.
To view the list of all pluggable databases in a container database, use the
dbaascli database getPDBs command.
Run the command as the root or
oracleuser.
Syntax
dbaascli database getPDBs --dbname <value>
Where:
--dbname specifies the name of the container
database
Frequently Asked Questions
Q: What is the purpose of the dbaascli database getPDBs command?
A: The dbaascli database getPDBs command is used to list all the pluggable databases (PDBs) within a specified container database (CDB).
Q: How do I specify the container database for the getPDBs command?
A: You use the --dbname option to specify the name of the container database. For example:
--dbname <value>
Q: Do I need to run the dbaascli database getPDBs command as a specific user?
A: Yes, you must run the command as either the root user or the oracle user.
Q: Can I view PDBs in a non-CDB database using the getPDBs command?
A: No, the getPDBs command is only applicable to container databases (CDBs). You cannot use this command for non-CDB databases.
Q: What is the format of the output from the dbaascli database getPDBs command?
A: The command returns a list of all PDBs within the specified container database. The output typically includes PDB names, statuses, and other relevant details about each pluggable database.
Q: Can this command be used for multiple databases at once?
A: No, the dbaascli database getPDBs command works with a single container database at a time, specified by the --dbname option.
Q: Is it necessary to shut down the database to use the getPDBs command?
A: No, the getPDBs command does not require the database to be shut down. It can be run while the container database is operational.
--setParameters specifies a comma-delimited
list of parameters to modify with new values. For example:
parameter1=valueA,parameter2=valueB, and so on. For blank values use
parameter1=valueA,parameter2='',etc.
--resetParameters specifies a comma-delimited
list of parameters to be reset to their corresponding default values. For
example, parameter1,parameter2, and so
on.
--instance specifies the name of the instance
on which the parameters will be processed. If not specified, then the
operation will be performed at the database level.
--backupPrepared acknowledges that a proper
database backup is in place prior to modifying critical or sensitive
parameters.
--allowBounce grants permission to bounce the
database in order to reflect the changes on applicable static
parameters.
--waitForCompletion specify false to run the operation in
background. Valid values : true|false.]
Frequently Asked Questions
Q: What is the purpose of the dbaascli database modifyParameters command?
A: The dbaascli database modifyParameters command is used to modify or reset Oracle Database initialization parameters.
Q: How do I specify the database for which I want to modify parameters?
A: You must use the --dbname option to specify the name of the database for which you want to modify or reset parameters.
Q: How can I modify database parameters using the modifyParameters command?
A: Use the --setParameters option followed by a comma-delimited list of parameters and their new values. For example:
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.
--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:
--dbname specifies the name of the database that you want
to stop
--mode specifies the mode of the database. Valid values:
abort, immediate,
normal, transactional
The command performs a database shutdown in immediate mode. No new
connections or new transactions are permitted. Active transactions are rolled back,
and all connected users are disconnected.
Frequently Asked Questions
Q: What is the purpose of the dbaascli database stop command?
A: The dbaascli database stop command is used to stop an Oracle Database.
Q: What are the prerequisites for using the dbaascli database stop command?
A: You must run the command as the root user, and you must connect to an Exadata Cloud@Customer virtual machine using SSH.
Q: How do I specify which database to stop?
A: You can specify the database by using the --dbname option followed by the name of the database. For example:
--dbname myDatabase
Q: What are the valid shutdown modes for the dbaascli database stop command?
A: The valid shutdown modes are:
abort
immediate
normal
transactional
Q: What is the default shutdown mode if no mode is specified?
A: If no mode is specified, the database will be shut down in immediate mode by default.
Q: What happens in immediate shutdown mode?
A: In immediate mode, no new connections or transactions are permitted, active transactions are rolled back, and all connected users are disconnected.
Q: How can I stop the database in abort mode?
A: To stop the database in abort mode, use the --mode option with abort. For example:
--mode abort
Q: What does normal mode do when stopping the database?
A: In normal mode, the database allows current user sessions to complete and then stops without affecting active transactions.
Q: What is transactional mode used for in the dbaascli database stop command?
A: In transactional mode, the database stops only after all active transactions are completed, but no new transactions are allowed.
Q: Is it mandatory to specify the shutdown mode in the dbaascli database stop command?
A: No, specifying a shutdown mode is optional. If not provided, the default immediate mode will be used.
--dbname (mandatory) specifies the name of the
database.
--targetHome specifies the target Oracle home
location
--targetHomeName specifies the name of the target Oracle
Database home
--standBy use this option to upgrade standby
databases in Data Guard configurations
--allStandbyPrepared required for Data Guard
configured primary databases. Flags to acknowledge that all the required
operations are performed on the standby databases prior to upgrading primary
database
--removeGRP automatically removes the
Guaranteed Restore Point (GRP) backup only if the database upgrade was
successful
--increaseCompatibleParameter automatically
increases the compatible parameter as part of the database upgrade. The
parameter will get increased only if the database upgrade was
successful
--executePrereqs runs only the preupgrade
checks
--postUpgrade use this option if postupgrade
fails and needs to rerun the postupgrade steps
--rollback reverts an Oracle Database to its
original Oracle home
--upgradeOptions use this option to pass
DBUA-specific arguments to perform the Oracle Database upgrade. Refer to the
corresponding Oracle documentation for the supported arguments and
options.
--standby
--resume to resume the previous execution
--sessionID to resume a specific session id.
--waitForCompletion specify false to run the operation in
background. Valid values : true|false.
Frequently Asked Questions
Q: What is the purpose of the dbaascli database upgrade command?
A: The dbaascli database upgrade command is used to upgrade an Oracle Database to a new version.
Q: What are the prerequisites for using the dbaascli database upgrade command?
A: You must run the command as the root user and connect to an Exadata Cloud@Customer virtual machine using SSH.
Q: How do I specify the database that needs to be upgraded?
A: Use the --dbname option followed by the name of the database. For example:
--dbname myDatabase
Q: How can I specify the target Oracle home for the upgrade?
A: You can specify the target Oracle home location with the --targetHome option or the name of the target Oracle Database home with the --targetHomeName option.
Q: What does the --standBy option do?
A: The --standBy option is used to upgrade standby databases in Data Guard configurations.
Q: What is the purpose of the --allStandbyPrepared flag?
A: The --allStandbyPrepared flag acknowledges that all required operations on standby databases have been performed before upgrading the primary database in a Data Guard configuration.
Q: What does the --removeGRP option do?
A: The --removeGRP option automatically removes the Guaranteed Restore Point (GRP) backup if the database upgrade is successful.
Q: When should I use the --increaseCompatibleParameter option?
A: Use the --increaseCompatibleParameter option to automatically increase the compatible parameter during the database upgrade, provided the upgrade is successful.
Q: What does the --executePrereqs option do?
A: The --executePrereqs option runs only the pre-upgrade checks to ensure that the database is ready for the upgrade.
Q: How do I handle a failed post-upgrade step?
A: Use the --postUpgrade option to rerun the post-upgrade steps if the initial post-upgrade attempt fails.
Q: What is the purpose of the --revert option?
A: The --revert option reverts the Oracle Database to its original Oracle home, undoing the upgrade.
Q: How can I pass additional arguments specific to DBUA for the upgrade?
A: Use the --upgradeOptions option to pass DBUA-specific arguments for the Oracle Database upgrade. Refer to the Oracle documentation for supported arguments and options.
Q: Is it mandatory to specify the target Oracle home for the upgrade?
A: Yes, you must specify either the --targetHome or --targetHomeName to indicate the target Oracle home for the upgrade.
Q: What should I do if I need to perform a pre-upgrade check but not proceed with the upgrade?
A: Use the --executePrereqs option to perform only the pre-upgrade checks without proceeding with the actual upgrade.
Example 7-22 dbaascli database upgrade pre-upgrade requisite checks
This section focuses on managing Oracle Data Guard configurations and operations. It includes commands like dbaascli dataguard prepareStandbyBlob to generate a blob file for setting up a standby site, and dbaascli dataguard updateDGConfigAttributes to update Data Guard automation attributes across all cluster nodes. These commands streamline the setup and maintenance of Data Guard environments for high availability and disaster recovery.
dbaascli dataguard prepareStandbyBlob To generate a blob file containing various files that are required on the standby site in case of a dataguard environment, use the dbaascli dataguard prepareStandbyBlob command.
dbaascli dataguard updateDGConfigAttributes To update Data Guard automation attributes across all the cluster nodes, use the dbaascli dataguard updateDGConfigAttributes command.
To generate a blob file containing various files that are required on the
standby site in case of a dataguard environment, use the dbaascli dataguard
prepareStandbyBlob command.
--blobLocation specifies
the custom directory location where the standby blob
file will be generated in a Data Guard
environment
Frequently Asked Questions
Q: What is the purpose of the dbaascli dataguard prepareStandbyBlob command?
A: The dbaascli dataguard prepareStandbyBlob command is used to generate a blob file containing various files required on the standby site in a Data Guard environment.
Q: What are the prerequisites for running the dbaascli dataguard prepareStandbyBlob command?
A: The command should be run as the root or oracle user.
Q: How do I specify the name of the Oracle Database for which I want to prepare the standby blob?
A: Use the --dbname option followed by the name of the Oracle Database. For example:
--dbname myDatabase
Q: How do I specify the location where the standby blob file will be generated?
A: Use the --blobLocation option to specify the custom directory path where the standby blob file will be generated. For example:
--blobLocation /path/to/standby_blob
Q: What does the --dbname option do in the command?
A: The --dbname option specifies the name of the Oracle Database for which the standby blob file is being prepared.
Q: What is the purpose of the --blobLocation option?
A: The --blobLocation option defines the custom directory path where the standby blob file will be created.
Q: Can I run the dbaascli dataguard prepareStandbyBlob command as a user other than root or oracle?
A: No, the command must be run as either the root or oracle user.
Q: Is it possible to use a relative path for the --blobLocation option?
A: It is recommended to use an absolute path for the --blobLocation option to ensure the standby blob file is created in the correct directory.
Q: What should I do if I want to change the location where the standby blob file is generated?
A: Modify the --blobLocation option to specify a new directory path for the standby blob file.
Q: Do I need to perform any additional steps after generating the standby blob file?
A: Yes, after generating the standby blob file, you need to transfer it to the standby site and use it for the Data Guard configuration.
--attributes contains the
Data Guard automation attributes that are to be
modified. Accepts comma-delimited values in the
format <attribute=value>.
Attributes must be predefined in the Data Guard
configuration file.
Frequently Asked Questions
Q: What is the purpose of the dbaascli dataguard updateDGConfigAttributes command?
A: The dbaascli dataguard updateDGConfigAttributes command is used to update Data Guard automation attributes across all cluster nodes.
Q: What are the prerequisites for running the dbaascli dataguard updateDGConfigAttributes command?
A: The command must be run as either the root or oracle user.
Q: How do I specify the attributes that I want to update using this command?
A: Use the --attributes option followed by the attributes to be modified. The attributes should be in a comma-delimited format, such as attribute=value. For example:
--attributes attribute1=value1,attribute2=value2
Q: What format should the --attributes option values be in?
A: The --attributes option values should be in a comma-delimited format with each attribute specified as attribute=value.
Q: Can I specify multiple attributes in the --attributes option?
A: Yes, you can specify multiple attributes by separating them with commas. For example:
--attributes attribute1=value1,attribute2=value2
Q: What happens if I provide an attribute that is not predefined in the Data Guard configuration file?
A: If you provide an attribute that is not predefined, the command may fail or ignore the unrecognized attribute. Ensure that all attributes are predefined in the Data Guard configuration file.
Q: Do I need to restart any services after updating Data Guard automation attributes?
A: In most cases, you do not need to restart services after updating attributes. However, check the specific attributes and their impact to determine if a restart is required.
Q: How can I verify if the Data Guard attributes have been successfully updated?
A: After running the command, you can verify the updated attributes by checking the Data Guard configuration or using appropriate verification commands/tools specific to your setup.
Q: What should I do if the command fails to update the attributes?
A: Check the error messages for details on what went wrong. Ensure that you have specified the correct attributes and that they are predefined in the Data Guard configuration file. Verify user permissions and command syntax.
Q: Is it possible to update attributes for only specific nodes using this command?
A: No, the dbaascli dataguard updateDGConfigAttributes command updates attributes across all cluster nodes. If you need to update attributes for specific nodes, you may need to use different methods or commands.
This section provides tools for managing Oracle Database homes. It includes commands such as dbaascli dbhome create to create a new Oracle Database home and dbaascli dbHome delete to remove an existing one. You can also view detailed information about a specific Oracle home with dbaascli dbHome getDetails and check which databases are running from a given Oracle home using dbaascli dbhome getDatabases. These commands ensure efficient management of database environments.
dbaascli dbhome create To create an Oracle Database home of desired version, use the dbaascli dbhome create command.
dbaascli dbHome delete To delete a given Oracle Database home, use the dbaascli dbHome delete command.
dbaascli dbhome getDatabases To view information about all Oracle Databases running from a given database Oracle home, use the dbaascli dbHome getDatabases command. Specify either the Oracle home location or Oracle home name.
dbaascli dbHome getDetails To view information about a specific Oracle home, use the dbaascli dbHome getDetails command. Specify either the Oracle home location or Oracle home name.
This creates an Oracle Home for version 19.8.0.0.0 with the corresponding image tag.
Q: What happens if I don't provide the --oracleHome or --oracleHomeName options?
A: If --oracleHome is not provided, the Oracle Home will be installed in the default location. If --oracleHomeName is not specified, a default name will be assigned to the Oracle Home.
Q: How can I verify if the Oracle Home creation was successful?
A: After running the command, check the output logs for any success messages or errors. You can also verify the Oracle Home by navigating to the specified location or using Oracle tools like orainstRoot.sh.
Q: Is it possible to create multiple Oracle Homes with different versions on the same system?
A: Yes, you can create multiple Oracle Homes with different versions by specifying different values for the --version and --oracleHomeName options.
Q: What should I do if the Oracle Home creation fails?
A: Check the output logs for detailed error messages. Verify that you have the correct version format, required permissions, and sufficient disk space. Correct any issues and try running the command again.
Example 7-23 dbaascli dbhome create
dbaascli dbhome create --version 19.11.0.0.0
Alternatively, dbaascli dbhome create --version
19.8.0.0.0.0 --imageTag
19.8.0.0.0 for cases where image tags are different
from version.
--oracleHome specifies the location of the Oracle home
--oracleHomeName specifies the name of the Oracle home
--resume resumes the previous execution
--sessionID specifies to resume a specific session
ID
Frequently Asked Questions
Q: What is the purpose of the dbaascli dbHome delete command?
A: The dbaascli dbHome delete command is used to delete a specified Oracle Database home from the system.
Q: What are the prerequisites for running the dbaascli dbHome delete command?
A: The command must be run as the root user.
Q: How do I specify the Oracle Home to be deleted?
A: You can specify the Oracle Home to be deleted using one of the following options:
--oracleHome <value> to provide the absolute path of the Oracle Home location.
--oracleHomeName <value> to provide the name of the Oracle Home.
Q: What is the difference between --oracleHome and --oracleHomeName options?
A:
--oracleHome specifies the physical location or path of the Oracle Home to be deleted.
--oracleHomeName specifies the user-defined name of the Oracle Home to be deleted.
Q: How can I resume a previously interrupted deletion process?
A: You can use the --resume option to resume a previous deletion process. If you know the specific session ID of the process, you can include it with the --sessionID option.
Q: What is the --sessionID option used for in the dbaascli dbHome delete command?
A: The --sessionID option is used to resume a specific session that was previously interrupted or failed during the deletion process.
Q: What happens if I do not provide the --resume or --sessionID options?
A: If the --resume or --sessionID options are not provided, the command will initiate a new deletion process instead of resuming an interrupted one.
Q: Is there any way to confirm the deletion of the Oracle Home after running the command?
A: You can verify the deletion by checking the output logs for success messages and ensuring the Oracle Home directory is no longer present at the specified location.
Q: Can I delete an Oracle Home that is currently in use by a running database?
A: No, the Oracle Home should not be in use by any running databases or services during the deletion process. Make sure to stop any related databases before running the delete command.
Q: What should I do if the dbaascli dbHome delete command fails?
A: Review the output logs for any error messages. Ensure that the Oracle Home is not in use, verify the correct Oracle Home location or name, and confirm that you have the necessary permissions. After resolving any issues, rerun the command or use the --resume option if needed.
Q: Can I delete multiple Oracle Homes at once using the dbaascli dbHome delete command?
A: No, the command only allows you to delete one Oracle Home at a time by specifying either the --oracleHome or --oracleHomeName option.
Q: What is an example of deleting an Oracle Home by its name?
A: Here is an example of deleting an Oracle Home by name:
To view information about all Oracle Databases running from a given database
Oracle home, use the dbaascli dbHome getDatabases command. Specify either
the Oracle home location or Oracle home name.
Run the command as the root user.
Syntax
dbaascli dbHome getDatabases
{ --oracleHomeName value | --oracleHome value }
Where:
--oracleHomeName specifies user-defined Oracle
home name
--oracleHome specifies the location (path) of
Oracle home
Frequently Asked Questions
Q: What is the purpose of the dbaascli dbHome getDatabases command?
A: The dbaascli dbHome getDatabases command is used to view information about all Oracle Databases running from a specified Oracle Database home.
Q: How can I specify the Oracle Database home to check?
A: You can specify the Oracle Database home by using one of the following options:
--oracleHomeName <value> to specify the user-defined name of the Oracle home.
--oracleHome <value> to specify the full location (path) of the Oracle home.
Q: What is the difference between --oracleHomeName and --oracleHome options?
A:
--oracleHomeName refers to a user-defined name for the Oracle home.
--oracleHome refers to the physical location (or directory path) of the Oracle home on the system.
Q: How do I run the dbaascli dbHome getDatabases command?
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:
This command retrieves the list of databases running from the Oracle home named myOracleHome.
Q: Do I need any special permissions to run this command?
A: Yes, you must run the command as the root user to view the information about Oracle Databases running from a specified Oracle home.
Q: What should I check if the dbaascli dbHome getDatabases command returns no databases?
A: Ensure that you have specified the correct Oracle home name or location and that there are databases running from that Oracle home. Additionally, confirm that the Oracle home is properly configured and active.
Q: Can I use the dbaascli dbHome getDatabases command on multiple Oracle homes at once?
A: No, the command works on a single Oracle home at a time. You must run the command separately for each Oracle home you want to query.
Q: Is there a way to verify that the Oracle home specified in the command is correct?
A: You can verify the Oracle home by checking the directory structure or the configuration details in your system to ensure the path or name provided matches the actual Oracle home.
Q: What happens if I run the command without specifying an Oracle home or Oracle home name?
A: The command requires either the --oracleHome or --oracleHomeName option to be specified. If neither option is provided, the command will fail to execute.
Q: Can this command retrieve databases that are currently stopped?
A: Yes, the command will list all databases associated with the specified Oracle home, regardless of whether they are currently running or stopped.
Example 7-24 dbaascli dbHome getDatabases --oracleHome
To view information about a specific Oracle home, use the
dbaascli dbHome getDetails command. Specify either the Oracle home
location or Oracle home name.
Prerequisite
Run the command as the root user.
Syntax
dbaascli dbHome getDetails
{ --oracleHomeName value | --oracleHome value }
Where:
--oracleHomeName specifies user-defined Oracle
home name
--oracleHome specifies the location of Oracle home
Frequently Asked Questions
Q: What is the purpose of the dbaascli dbHome getDetails command?
A: The dbaascli dbHome getDetails command is used to view detailed information about a specific Oracle home on the system.
Q: How do I specify the Oracle home I want to get details about?
A: You can specify the Oracle home using one of the following options:
--oracleHomeName <value> to specify the user-defined name of the Oracle home.
--oracleHome <value> to specify the full location (path) of the Oracle home.
Q: What is the difference between --oracleHomeName and --oracleHome?
A:
--oracleHomeName is the user-defined name for an Oracle home.
--oracleHome refers to the full directory path where the Oracle home is located.
Q: How do I run the dbaascli dbHome getDetails command?
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?
This command retrieves detailed information about the Oracle home named myOracleHome.
Q: Do I need any special permissions to run this command?
A: Yes, you must run the command as the root user to view details about the Oracle home.
Q: What should I do if the dbaascli dbHome getDetails command returns no information?
A: Ensure that you have correctly specified the Oracle home name or location, and that the Oracle home is properly configured and exists on the system.
Q: Can I use the dbaascli dbHome getDetails command on multiple Oracle homes simultaneously?
A: No, the command only works on a single Oracle home at a time. You must run the command separately for each Oracle home.
Q: Is it possible to verify the Oracle home name before running the command?
A: Yes, you can verify the Oracle home name by checking your system’s configuration files or by listing all Oracle homes available on your system.
Q: What happens if I do not specify an Oracle home name or location in the command?
A: The command requires either the --oracleHome or --oracleHomeName option to be specified. If neither is provided, the command will fail to execute.
Q: Can I retrieve information about Oracle homes that are currently not in use?
A: Yes, the dbaascli dbHome getDetails command provides details about Oracle homes regardless of whether they are in use or idle.
Q: What should I check if the command returns an error?
A: Ensure that the Oracle home name or location is correct, the Oracle home exists, and that you are running the command as the root user. Double-check for typos or incorrect paths.
Example 7-25 dbaascli dbHome getDetails - using
Oracle home location
This section covers tools for maintaining the health and diagnosing issues in Oracle Database environments. Commands like dbaascli diag collect are used to gather diagnostic data, while dbaascli diag healthCheck allows you to run health checks to identify potential issues. These tools help ensure the system's stability and performance by proactively monitoring and addressing concerns.
dbaascli diag collect To collect diagnostics, use the dbaascli diag collect command.
dbaascli diag healthCheck To run diagnostic health checks, use the dbaascli diag healthCheck command.
--components specifies a list of components for
log collection.
Valid values:
db
gi
os
dbaastools
all
--startTime specifies the start time for log
collection. Valid date and time format:
YYYY-MM-DDTHH24:MM:SS
--endTime specifies the end time for log
collection. Valid date and time format:
YYYY-MM-DDTHH24:MM:SS
--nodes specifies a comma-delimited list of
nodes to collect logs
--dbNames specifies the database name for
which to collect logs. You can specify only one database name.
--objectStoreBucketURI specifies an Object
Storage service pre-authenticated request (PAR) URL used to upload collected
logs. Logs are collected from Guest VM. For more information, see
Using Pre-Authenticated Requests.
--destLocation specifies the location on Guest
VM to collect logs. Default:
/var/opt/oracle/dbaas_acfs
--waitForCompletion Values:
true|false. Default
true. Specify false to run in the
background.
Frequently Asked Questions
Q: What is the purpose of the dbaascli diag collect command?
A: The dbaascli diag collect command is used to collect diagnostic logs for Oracle Database and associated components such as OS, Grid Infrastructure (GI), and DBaaS tools.
Q: How do I specify which components to collect diagnostics for?
A: You can specify the components using the --components option. Valid values are:
db (for database logs)
gi (for Grid Infrastructure logs)
os (for operating system logs)
dbaastools (for DBaaS tools logs)
all (for collecting logs for all components)
Q: How can I collect logs for a specific time range?
A: Use the following options to specify a time range:
--startTime <value> to set the start time for log collection.
--endTime <value> to set the end time for log collection.
The time must be in the format: YYYY-MM-DDTHH24:MM:SS.
Q: What format should the start and end times be in?
A: Both --startTime and --endTime should be in the format YYYY-MM-DDTHH24:MM:SS. For example, 2024-09-01T15:30:00.
Q: How do I specify which nodes to collect diagnostics from?
A: You can use the --nodes option to specify a comma-delimited list of nodes. For example:
--nodes node1,node2
Q: How do I collect logs for a specific database?
A: Use the --dbNames option to specify the name of the database for which you want to collect logs. Only one database name can be specified at a time.
Q: How can I store the collected logs in Object Storage?
A: Use the --objectStoreBucketUri option to specify the pre-authenticated request (PAR) URL for your Object Storage bucket where the logs will be uploaded.
Q: Can I collect logs to a local directory instead of Object Storage?
A: Yes, you can use the --destLocation option to specify a directory on the guest VM where the logs will be collected. The default location is /var/opt/oracle/dbaas_acfs.
Q: What happens if I don’t specify a destination for the logs?
A: If no destination is specified, the collected logs will be stored in the default location /var/opt/oracle/dbaas_acfs on the guest VM.
Q: What does the --waitForCompletion option do?
A: The --waitForCompletion option specifies whether to wait for the command to finish before returning control to the user. The default value is true. If you specify false, the operation runs in the background.
Q: How can I run the log collection in the background?
A: Set the --waitForCompletion option to false to run the log collection process in the background:
dbaascli diag collect --waitForCompletion false
Q: Can I resume a previous log collection session with this command?
A: No, the dbaascli diag collect command does not support resuming previous sessions. You will need to start a new log collection process.
Q: How can I ensure that logs are uploaded directly to the Object Storage?
A: You can provide a valid --objectStoreBucketUri (Object Storage pre-authenticated request URL) where the logs will be uploaded after collection.
Q: Can I collect logs for multiple databases at once?
A: No, you can only specify one database name at a time using the --dbNames option.
Q: What should I do if I want to collect all available logs for all components?
A: Use --components all to collect logs from all components, including the database, Grid Infrastructure, operating system, and DBaaS tools.
Q: What is an example command to collect logs for the database component from a specific time range?
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.
--destLocation specifies the location on Guest
VM to collect logs. Default:
/var/opt/oracle/dbaas_acfs
--nodes specifies a comma-delimited list of nodes to
collect logs
--objectStoreBucketURI specifies an Object
Storage service pre-authenticated request (PAR) URL used to upload collected
logs. Logs are collected from Guest VM. For more information, see
Using Pre-Authenticated Requests.
Frequently Asked Questions
Q: What is the purpose of the dbaascli diag healthCheck command?
A: The dbaascli diag healthCheck command is used to perform diagnostic health checks on an Oracle Database running in an Exadata Cloud@Customer environment.
Q: What are the prerequisites for using the dbaascli diag healthCheck command?
A: The command must be run as the root user, and you must be connected to an Exadata Cloud@Customer virtual machine.
Q: How do I specify a custom directory for collecting the logs?
A: Use the --destLocation option to specify the directory where the health check logs will be collected. The default location is /var/opt/oracle/dbaas_acfs.
Q: What is the default location for log collection if I don’t specify --destLocation?
A: The default directory for log collection is /var/opt/oracle/dbaas_acfs.
Q: Can I specify which nodes to run the health check on?
A: Yes, you can use the --nodes option to specify a comma-delimited list of nodes where the health check should be run.
Q: How do I upload the health check logs to Object Storage?
A: Use the --objectStoreBucketURI option to provide a pre-authenticated request (PAR) URL from the Object Storage service. This will upload the collected logs to the specified bucket.
Q: Can I collect logs from multiple nodes?
A: Yes, you can specify multiple nodes using the --nodes option in a comma-delimited format. For example: --nodes node1,node2.
Q: What is an example command to run a health check on a specific node?
A: Here’s an example command to run the health check on a specific node:
dbaascli diag healthCheck --nodes node1
Q: How can I store the logs in Object Storage instead of on the local machine?
A: You can provide a pre-authenticated request (PAR) URL using the --objectStoreBucketURI option to store the logs in Object Storage.
Q: Can I specify both --destLocation and --objectStoreBucketURI at the same time?
A: Yes, you can specify both --destLocation for local storage and --objectStoreBucketURI to upload logs to Object Storage.
Q: What should I do if I encounter an error while running the dbaascli diag healthCheck command?
A: Ensure that you are running the command as the root user and have provided valid options for --destLocation, --nodes, or --objectStoreBucketURI. Verify that the node names are correct if specified.
Q: Can I run the health check in the background?
A: The dbaascli diag healthCheck command does not have an explicit background mode, but you can run it in the background by appending & at the end of the command.
Q: What happens if I don’t provide the --nodes option?
A: If the --nodes option is not provided, the health check will be performed on all nodes in the cluster by default.
Q: Can I resume a previous health check session using this command?
A: No, the dbaascli diag healthCheck command does not support resuming previous sessions. You must initiate a new health check each time.
Q: What is an example command to run a health check and upload logs to Object Storage?
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.
This section focuses on managing Oracle Grid Infrastructure, which supports clustering and high availability. Key tasks include configuring a Grid Infrastructure home (dbaascli gridHome create), upgrading the Grid Infrastructure (dbaascli grid upgrade), and managing TCPS (Transport Layer Security) certificates by configuring (dbaascli grid configureTCPS), removing (dbaascli grid removeTCPSCert), or rotating them (dbaascli grid rotateTCPSCert). These commands ensure efficient setup, maintenance, and security of the Grid Infrastructure.
dbaascli gridHome create To configure Grid Infrastructure home, use the dbaascli gridHome create command.
dbaascli grid configureTCPS To configure TCPS for the existing cluster, use the dbaascli grid configureTCPS command.
dbaascli grid removeTCPSCert To remove existing TCPS certificates from Grid Infrastructure wallet, use the dbaascli grid removeTCPSCert command.
To configure Grid Infrastructure home, use the dbaascli gridHome
create command.
Prerequisite
Run the command as the root user.
Syntax
dbaascli gridHome create --version value [--resume [--sessionID value]] [--waitForCompletion value]
Where:
--version specifies the Grid home version
--resume resumes the previous run
--sessionID specifies to resume a specific session
ID
--waitForCompletion specifies
false to run the operation in the background. Valid
values: true|false
Frequently Asked Questions
Q: What is the purpose of the dbaascli gridHome create command?
A: The dbaascli gridHome create command is used to configure a Grid Infrastructure home for Oracle Grid infrastructure in an Exadata Cloud@Customer environment.
Q: What is the prerequisite for running the dbaascli gridHome create command?
A: The command must be run as the root user.
Q: How do I specify the version of Grid Infrastructure home to be created?
A: Use the --version option to specify the Grid home version. This is a mandatory option when creating the Grid home.
Q: Can I resume a previous dbaascli gridHome create session?
A: Yes, you can use the --resume option to resume a previous session. Optionally, you can specify the session ID using the --sessionID option to resume a specific session.
Q: What does the --resume option do in the dbaascli gridHome create command?
A: The --resume option allows you to resume a previously interrupted or incomplete operation.
Q: How do I run the operation in the background?
A: You can set the --waitForCompletion option to false to run the operation in the background. The valid values for this option are true (default) or false.
Q: What is the default behavior if --waitForCompletion is not specified?
A: If --waitForCompletion is not specified, the operation will run in the foreground, and the command will wait for the operation to complete before returning control to the user.
Q: What is the purpose of the --sessionID option?
A: The --sessionID option is used to specify the ID of a previous session that you want to resume, in case of an incomplete or interrupted operation.
Q: Can I use the dbaascli gridHome create command to upgrade an existing Grid home?
A: No, this command is used specifically for configuring a new Grid Infrastructure home, not for upgrading an existing one.
Q: What is an example command to create a Grid home with version 19.9.0.0.0?
A: Here’s an example command:
dbaascli gridHome create --version 19.9.0.0.0
Q: What should I do if the dbaascli gridHome create command is interrupted?
A: You can resume the operation by using the --resume option. If you have the session ID, you can provide it using the --sessionID option to resume a specific session.
Q: Can I specify the --resume option without a session ID?
A: Yes, you can use the --resume option without specifying a session ID. In this case, the system will attempt to resume the most recent session.
Q: What happens if I specify --waitForCompletion false?
A: If you specify --waitForCompletion false, the operation will run in the background, allowing you to continue using the command line while the operation completes.
Q: Is it possible to track the progress of a background operation?
A: The dbaascli command does not provide a direct way to track background operations. You may need to check system logs or the session status manually.
Q: Can I specify an invalid Grid home version when creating it?
A: No, the --version option must contain a valid Grid Infrastructure version. If an invalid version is provided, the command will return an error.
Q: How can I determine the Grid home version to use for creation?
A: You can refer to Oracle's documentation or consult with your database administrator to determine the correct Grid home version to use for your environment.
Q: What should I verify before running the dbaascli gridHome create command?
A: Ensure that you are logged in as the root user and that the version you want to use for Grid Infrastructure is compatible with your environment.
To configure TCPS for the existing cluster, use the dbaascli
grid configureTCPS command.
Prerequisite
Run the command as the root user.
Syntax
Note
By default, TCPS is enabled for
databases on Oracle Exadata Database Service on Dedicated Infrastructure
systems.
Note
TCPS is not enabled for databases on Exadata Database Service on Cloud@Customer
systems. To enable TCPS for a given database, update the database specific
sqlnet.ora file with WALLET_LOCATION =
(SOURCE=(METHOD=FILE)(METHOD_DATA=(DIRECTORY=/var/opt/oracle/dbaas_acfs/grid/tcps_wallets)))
on all database nodes and then bounce the database. This will enable TCPS usage for
the database. However, enabling TCPS will cause ZDLRA connection to fail. On Exadata
Database Service on Cloud@Customer systems, you can enable either ZDLRA or TCPS
configuration. Enabling both ZDLRA and TCPS simultaneously will not work.
--pkcs12WalletFilePath specifies the absolute
path of the certificate file, which is in the pkcs12 wallet
format
--caCertChain concatenated list of certs,
containing intermediate CA's and root CA certs
--precheckOnly specifies yes
to run only the prechecks for this operation. Valid values:
yes or no.
--serverCert specifies the path of PEM
certificate to use or rotate for TCPS configuration.
--privateKey specifies the path of the private
key file of the certificate.
--certType type of the cert to be added to the
Grid Infrastructure wallet. Accepted values are:
SELF_SIGNED_CERT, CA_SIGNED_CERT, or
PKCS12_CERT. Default:
SELF_SIGNED_CERT
--privateKeyPasswordProtected specifies if the
private key is password protected or not. Valid values:
true or false. Default:
true.
Frequently Asked Questions
Q: What is the purpose of the dbaascli grid configureTCPS command?
A: The dbaascli grid configureTCPS command is used to configure Transport Layer Security (TCPS) for the existing cluster in an Oracle Exadata environment.
Q: What is the prerequisite for running the dbaascli grid configureTCPS command?
A: The command must be run as the root user.
Q: Is TCPS enabled by default on Exadata Database Service on Dedicated Infrastructure systems?
A: Yes, TCPS is enabled by default for databases on Oracle Exadata Database Service on Dedicated Infrastructure systems.
Q: Is TCPS enabled by default on Exadata Database Service on Cloud@Customer systems?
A: No, TCPS is not enabled by default on Exadata Database Service on Cloud@Customer systems. To enable TCPS, you need to update the sqlnet.ora file for the specific database and restart the database.
Q: What is the consequence of enabling TCPS on Exadata Cloud@Customer systems?
A: Enabling TCPS on Exadata Cloud@Customer systems will cause Zero Data Loss Recovery Appliance (ZDLRA) connections to fail. You can only enable either ZDLRA or TCPS configuration, but not both simultaneously.
Q: What does the --pkcs12WalletFilePath option specify?
A: The --pkcs12WalletFilePath option specifies the absolute path to the certificate file in the PKCS12 wallet format, which is used for TCPS configuration.
Q: What is the --caCertChain option used for?
A: The --caCertChain option specifies a concatenated list of certificates containing intermediate CA certificates and the root CA certificate.
Q: What does the --precheckOnly option do?
A: The --precheckOnly option specifies whether to run only the prechecks for the TCPS configuration operation. Accepted values are yes or no.
Q: What does the --serverCert option specify?
A: The --serverCert option specifies the path to the PEM certificate that will be used or rotated for the TCPS configuration.
Q: How do I specify the private key for TCPS configuration?
A: Use the --privateKey option to specify the path to the private key file associated with the server certificate.
Q: What are the accepted values for the --certType option?
A: The accepted values for the --certType option are:
SELF_SIGNED_CERT
CA_SIGNED_CERT
PKCS12_CERT
The default value is SELF_SIGNED_CERT.
Q: Is the private key password protected by default?
A: Yes, the --privateKeyPasswordProtected option is set to true by default, indicating that the private key is password protected. You can set it to false if the private key is not password protected.
Q: Can I run a precheck before configuring TCPS?
A: Yes, you can run only the prechecks for the operation by setting the --precheckOnly option to yes. This helps to validate the environment before making changes.
Q: What happens if I provide an incorrect path for the PKCS12 wallet file?
A: If the --pkcs12WalletFilePath contains an incorrect path, the command will fail, and the TCPS configuration will not proceed.
Q: What should I do if the private key is password protected?
A: If the private key is password protected, ensure that the --privateKeyPasswordProtected option is set to true (which is the default).
Q: Can I specify my own CA-signed certificate for TCPS configuration?
A: Yes, you can specify your own CA-signed certificate by using the --serverCert and --privateKey options, and by setting the --certType to CA_SIGNED_CERT.
Q: What is an example command to configure TCPS using a self-signed certificate?
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.
--trustedCert flag to indicate trusted
certificate
--requestedCert flag to indicate requested
certificate
--serialNumber specifies the serial number of
the certificate
--executePrereqs runs the prerequisite checks and reports
the results
--resume resumes the previous run
--sessionID specifies to resume a specific session
ID
--bounceListeners flag to bounce the Grid Infrastructure
listener and scan listener
Frequently Asked Questions
Q: What is the purpose of the dbaascli grid removeTCPSCert command?
A: The dbaascli grid removeTCPSCert command is used to remove existing TCPS certificates from the Grid Infrastructure wallet in an Oracle Exadata environment.
Q: What is the prerequisite for running the dbaascli grid removeTCPSCert command?
A: The command must be run as the root user.
Q: What does the --subject option specify in the dbaascli grid removeTCPSCert command?
A: The --subject option specifies the subject of the certificate to be removed from the Grid Infrastructure wallet.
Q: What is the purpose of the --userCert flag?
A: The --userCert flag indicates that the certificate to be removed is a user certificate.
Q: When should I use the --trustedCert flag?
A: Use the --trustedCert flag when removing a trusted certificate from the Grid Infrastructure wallet.
Q: What does the --requestedCert flag do?
A: The --requestedCert flag indicates that the certificate being removed is a requested certificate.
Q: What does the --serialNumber option specify?
A: The --serialNumber option specifies the serial number of the certificate to be removed. It is useful for uniquely identifying a certificate when there are multiple certificates with the same subject.
Q: What is the purpose of the --executePrereqs option?
A: The --executePrereqs option runs prerequisite checks before removing the certificate and reports the results, ensuring that the environment is properly prepared for the operation.
Q: What does the --resume option do?
A: The --resume option resumes the removal operation if it was previously interrupted.
Q: How do I specify a session ID when resuming an interrupted operation?
A: Use the --sessionID option to specify the session ID of the interrupted operation that you want to resume.
Q: What does the --bounceListeners flag do?
A: The --bounceListeners flag is used to restart the Grid Infrastructure listener and scan listener after the TCPS certificate is removed.
Q: Can I remove a TCPS certificate without bouncing the listeners?
A: Yes, the --bounceListeners flag is optional. If you don’t specify it, the listeners will not be bounced automatically.
Q: How can I ensure that the operation will run safely?
A: You can use the --executePrereqs option to perform prerequisite checks before running the command, ensuring that everything is in order before the removal process.
Q: What should I do if I need to remove a specific user certificate by serial number?
A: Use the --subject option to specify the certificate’s subject, the --userCert flag to indicate that it is a user certificate, and the --serialNumber option to specify the certificate’s serial number.
Q: Can I remove multiple certificates at once?
A: No, the command is designed to remove a single certificate at a time based on the provided subject and other parameters.
Q: What happens if the certificate removal process is interrupted?
A: You can resume the operation using the --resume option along with the --sessionID of the interrupted process.
Q: Do I need to run the command as the root user?
A: Yes, the dbaascli grid removeTCPSCert command must be run as the root user to have the necessary privileges for removing TCPS certificates.
Q: How can I identify the certificate I want to remove?
A: You can identify the certificate by its subject, and optionally, by its serial number to ensure you're targeting the correct certificate for removal.
Q: What is an example command to remove a trusted certificate?
--pkcs12WalletFilePath specifies the absolute
path of the certificate file, which is in the pkcs12 wallet
format
--caCertChain concatenated list of certs, containing
intermediate CA's and root CA certs
--precheckOnly specifies yes to run only
the prechecks for this operation. Valid values: yes or
no.
--serverCert specifies the path of PEM certificate to use
or rotate for TCPS configuration.
--privateKey specifies the path of the private key file of
the certificate.
--certType type of the cert to be added to the Grid
Infrastructure wallet. Accepted values are:
SELF_SIGNED_CERT, CA_SIGNED_CERT, or
PKCS12_CERT. Default:
SELF_SIGNED_CERT
--privateKeyPasswordProtected specifies if the private key
is password protected or not. Valid values: true or
false. Default: true.
Frequently Asked Questions
Q: What is the purpose of the dbaascli grid rotateTCPSCert command?
A: The dbaascli grid rotateTCPSCert command is used to rotate TCPS (Transport Layer Security Protocol) certificates in the Grid Infrastructure wallet in Oracle Exadata environments.
Q: What is the prerequisite for running the dbaascli grid rotateTCPSCert command?
A: The command must be run as the root user.
Q: What does the --pkcs12WalletFilePath option specify?
A: The --pkcs12WalletFilePath option specifies the absolute path to the certificate file in the PKCS12 wallet format for the TCPS configuration.
Q: What is the purpose of the --caCertChain option?
A: The --caCertChain option specifies a concatenated list of certificates, including intermediate CA and root CA certificates, for the TCPS configuration.
Q: What does the --precheckOnly option do?
A: The --precheckOnly option allows you to run prechecks without making any actual changes. The valid values are "yes" to run only the prechecks and "no" to proceed with the rotation.
Q: How is the --serverCert option used?
A: The --serverCert option specifies the path to the PEM (Privacy Enhanced Mail) server certificate that is used or rotated for the TCPS configuration.
Q: What does the --privateKey option specify?
A: The --privateKey option specifies the path to the private key file corresponding to the server certificate used for TCPS rotation.
Q: What are the valid values for the --certType option?
A: The --certType option accepts the following values for specifying the type of certificate to be added to the Grid Infrastructure wallet:
SELF_SIGNED_CERT (default)
CA_SIGNED_CERT
PKCS12_CERT
Q: What does the --privateKeyPasswordProtected option do?
A: The --privateKeyPasswordProtected option indicates whether the private key is password-protected. Valid values are true (default) and false
Q: Can I run the dbaascli grid rotateTCPSCert command without rotating the certificates?
A: Yes, by using the --precheckOnly yes option, you can run only the prechecks without rotating the certificates.
Q: What is an example of a command to rotate a certificate using a PKCS12 wallet?
Q: What happens if I don't specify --privateKeyPasswordProtected?
A: If you don’t specify the --privateKeyPasswordProtected option, the command assumes that the private key is password-protected (default: true).
Q: Can I rotate a self-signed certificate?
A: Yes, you can rotate a self-signed certificate by using the default --certType SELF_SIGNED_CERT option or specifying it explicitly.
Q: How can I rotate a certificate without providing a private key?
A: For certain certificate types, like PKCS12, you may not need to provide a separate private key file, as it is included in the wallet. However, if a private key is required, it must be provided using the --privateKey option.
Q: What if I want to rotate a certificate in the background?
A: The dbaascli grid rotateTCPSCert command doesn’t provide an explicit option for background execution. You may run the command directly in a background session (e.g., using nohup or similar tools).
Q: What is the default certificate type if not specified?
A: The default certificate type is SELF_SIGNED_CERT.
Example 7-28 dbaascli grid
rotateTCPSCert
To rotate cert using self-signed certificate (default
option):
--executePrereqs runs prereqs for Grid
Infrastrucure upgrade
--containerUrl specifies the custom URL for
fetching Grid Infrastrucure image
--softwareOnly installs only the Grid Infrastructure
software
--targetHome specifies the path of existing
target Grid home
--revert reverts failed run
Frequently Asked Questions
Q: What is the purpose of the dbaascli grid upgrade command?
A: The dbaascli grid upgrade command is used to upgrade Oracle Grid Infrastructure from one major version to another on an Exadata Cloud@Customer virtual machine.
Q: What is the prerequisite for running the dbaascli grid upgrade command?
A: The command must be run as the root user, and you need to be connected to an Exadata Cloud@Customer virtual machine.
Q: What does the --version option specify?
A: The --version option specifies the target version of Oracle Grid Infrastructure that you want to upgrade to.
Q: What does the --resume option do?
A: The --resume option resumes a previously interrupted or failed Grid Infrastructure upgrade process.
Q: How is the --executePrereqs option used?
A: The --executePrereqs option runs only the prerequisite checks for the Grid Infrastructure upgrade without performing the actual upgrade.
Q: What is the purpose of the --containerURL option?
A: The --containerURL option specifies a custom URL to fetch the Grid Infrastructure software image for the upgrade.
Q: What does the --softwareOnly option do?
A: The --softwareOnly option installs only the Grid Infrastructure software without configuring or upgrading the Grid environment.
Q: When would you use the --targetHome option?
A: The --targetHome option specifies the path to the existing target Grid home where the upgrade will be performed.
Q: What happens if the upgrade fails?
A: If the upgrade fails, you can use the --revert option to roll back the upgrade to its previous state.
Q: Can I perform a Grid Infrastructure upgrade in stages?
A: Yes, by using the --softwareOnly option, you can first install the software and then later complete the full upgrade, allowing for staged upgrades.
Q: How do I use the dbaascli grid upgrade command to upgrade only the software?
A: Use the following syntax to upgrade only the software:
This section provides tools for updating and maintaining Oracle environments through patching and upgrades. It includes commands such as dbaascli grid patch to patch Oracle Grid Infrastructure, dbaascli dbHome patch to apply patches to Oracle homes, and dbaascli database move to move databases between homes during upgrades or patching processes. These commands help ensure systems remain secure, stable, and up-to-date.
dbaascli grid patch To patch Oracle Grid Infrastructure to the specified minor version, use the dbaascli grid patch command.
dbaascli dbHome patch To patch Oracle home from one patch level to another, use the dbaascli dbHome patch command.
dbaascli database move To move the database from one home to another, use the dbaascli database move command.
--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.
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
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
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
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.
--oracleHomeName specifies the name of Oracle
home
--targetVersion specifies the target version of
Oracle Home specified as five numeric segments separated by periods, for
example, 19.12.0.0.0.
--resume resumes the previous run
--sessionID specifies to resume a specific session
ID
--continueWithDbDowntime continues patching
with database downtime. This option can be used in environments wherein
there is only one active instance up and the patching operation can be
continued even with a downtime.
--skipUnreachableNodes skips operation on
unreachable nodes
--nodes specifies a comma-delimited list of
nodes if patching has to be performed on a subset of nodes
--executePrereqs runs prereqs
--skipDatapatch skips running
datapatch on the databases
--imageFilePath specifies the absolute path of
the image file to be used
--skipPDBs skips running the datapatch on a specified
comma-delimited list of PDBs. For example:
cdb1:pdb1,cdb2:pdb2, and so
on
--skipClosedPdbs skips running
datapatch on closed PDBs
--rollback rolls back patched Oracle
home.
--waitForCompletion specifies false to run the operation in background. Valid values : true|false
--drainTimeoutInSeconds specifies time (in seconds) to complete the resource draining while stopping the database
--skipUnreachableNodes skips operation on unreachable nodes
Frequently Asked Questions
Q: What is the dbaascli dbHome patch command used for?
A: The dbaascli dbHome patch command is used to patch Oracle home from one patch level to another.
Q: Do I need special permissions to run the dbaascli dbHome patch command?
A: Yes, you need to run the command as the root user.
Q: How do I specify the Oracle home path or name for the patch?
A: Use the --oracleHome option to specify the path of the Oracle home, or --oracleHomeName to specify the name of the Oracle home.
Q: How can I define the target version for the patch?
A: Use the --targetVersion option followed by the version number in the format 19.12.0.0.0.
Q: What does the --resume option do?
A: The --resume option allows you to resume a previous patching session.
Q: How do I specify a particular session ID when resuming a patch?
A: Use the --sessionID option to specify the session ID of the patching session you want to resume.
Q: What is the --continueWithDbDowntime option used for?
A: The --continueWithDbDowntime option allows patching to continue even if there is database downtime, useful in environments with only one active instance.
Q: How can I skip patching on unreachable nodes?
A: Use the --skipUnreachableNodes option to skip operations on nodes that are unreachable.
Q: How do I patch only specific nodes in a cluster?
A: Use the --nodes option followed by a comma-delimited list of node names to patch a subset of nodes.
Q: What is the --executePrereqs option for?
A: The --executePrereqs option runs prerequisite checks before applying the patch.
Q: How can I skip running datapatch on the databases?
A: Use the --skipDatapatch option to skip the datapatch process during patching.
Q: Can I specify a custom location for the database image?
A: Yes, use the --imageLocation option to specify a custom location for the database image.
Q: What does the --skipPDBs option do?
A: The --skipPDBs option allows you to skip running datapatch on a specified comma-delimited list of pluggable databases (PDBs).
Q: How can I skip datapatch on closed PDBs?
A: Use the --skipClosedPDBs option to skip datapatch on PDBs that are closed.
Q: What happens if I use the --rollback option?
A: The --rollback option will revert the Oracle home to its previous state before the patch was applied.
Q: How do I specify the Oracle home path for patching?
A: Use the --oracleHome option followed by the path to the Oracle home directory.
Q: How can I patch an Oracle home by its name rather than the path?
A: Use the --oracleHomeName option followed by the name of the Oracle home.
Q: How do I resume a patching operation if it was interrupted?
A: Use the --resume option along with the --sessionID option to resume a specific interrupted session.
Q: Can I continue the patching process if the database is down?
A: Yes, use the --continueWithDbDowntime option to continue patching even if the database is down.
Q: What should I do if some nodes are unreachable during the patching process?
A: Use the --skipUnreachableNodes option to bypass the unreachable nodes.
Q: How can I apply the patch to only certain nodes?
A: Specify the nodes you want to patch using the --nodes option with a comma-separated list of node names.
Q: How do I check prerequisites before applying the patch?
A: Use the --executePrereqs option to run prerequisite checks before applying the patch.
Q: What should I do if I want to avoid applying datapatch during the patching process?
A: Use the --skipDatapatch option to skip the datapatch step.
Q: How can I specify a different location for the database image used in the patching process?
A: Use the --imageLocation option to specify a custom location for the image.
Q: What if I need to skip datapatch on certain PDBs?
A: Use the --skipPDBs option to skip datapatch on a specified comma-delimited list of PDBs.
Q: Can I skip datapatch on PDBs that are not currently open?
A: Yes, use the --skipClosedPDBs option to skip datapatch on closed PDBs.
Q: What should I do if the patching fails midway?
A: You can use the --rollback option to revert to the previous state or try resuming the patching process with the --resume option.
Q: How can I check if all prerequisites are met before applying the patch?
A: Run the patch command with the --executePrereqs option to ensure all prerequisites are satisfied.
Q: What if the patching operation does not complete successfully and I need to retry?
A: Use the --resume option to retry the patching operation from where it left off. If needed, you can specify a --sessionID to resume a specific session.
Q: How can I verify if the patch was successfully applied?
A: You can verify the patching process by checking the Oracle home version using the opatch lsinventory command after the patch is completed.
Q: Can I run the patching command in a dry run mode to preview actions?
A: No, the dbaascli dbHome patch command does not have a dry-run feature. However, you can use the --executePrereqs option to run prerequisite checks before actually applying the patch.
Q: Is it possible to apply multiple patches in one run?
A: The dbaascli dbHome patch command only allows for one target version at a time. You would need to run the command separately for each patch version.
Q: How do I handle patching if the environment uses multiple Oracle homes?
A: You can specify the Oracle home you want to patch using either the --oracleHome or --oracleHomeName options, depending on whether you're specifying the path or the name of the Oracle home.
Q: Can I skip both PDB and CDB datapatching in one command?
A: Yes, you can combine the --skipPDBs and --skipDatapatch options to skip datapatching for both PDBs and the CDB in a single patch run.
Q: Can I apply a patch and rollback immediately if it causes issues?
A: Yes, after applying a patch, you can use the --rollback option to revert to the previous patch level if any issues arise.
Q: Can I patch multiple Oracle homes simultaneously?
A: No, you need to run the dbaascli dbHome patch command individually for each Oracle home.
Q: How do I track the progress of the patching operation?
A: During the patching process, the command provides output messages that show the progress. You can also check the log files for detailed information.
Q: Can I run patching in parallel on a clustered environment?
A: Patching operations can be applied to a subset of nodes using the --nodes option. However, simultaneous patching should be handled carefully, and you should ensure no overlapping sessions.
Q: How can I identify which patches are available for my Oracle home?
A: You can check the available patches via the Oracle support portal or by running the opatch lsinventory command to see the current patches applied to your Oracle home.
Q: Can I specify a timeout for draining resources when stopping the database during patching?
A: Yes, you can use the --drainTimeoutInSeconds option to specify the time in seconds for resource draining when stopping the database.
Q: What happens if the patch fails on one of the nodes in a multi-node environment?
A: You can use the --skipUnreachableNodes option to skip the failed node and continue the patching process on the remaining nodes. You can then address the issue on the failed node separately.
Q: How can I make the patching process run in the background?
A: Use the --waitForCompletion option with a value of false to allow the patching process to run in the background. This way, you don't need to wait for the process to complete interactively.
Q: Can I perform a rollback operation on a subset of nodes in a clustered environment?
A: Yes, you can use the --nodes option along with the --rollback option to roll back the patching on a specific set of nodes.
Q: What if I need to update the image location after starting the patch process?
A: The --resume option does not allow changing the image location. However, you can stop the session and start a new patch process with the updated --imageLocation.
Q: Is there a way to check which session IDs are available for resuming a patch?
A: You can check the log files or use Oracle Cloud tools to identify active or paused patching sessions and their session IDs.
Q: Can I limit the downtime during patching?
A: If you need to limit downtime, use the --continueWithDbDowntime option carefully. This allows you to proceed even when downtime is expected but requires planning for minimal service impact.
Example Use Cases
Example 1: Basic Oracle Home Patching by Oracle Home Path
--oracleHomeName specifies the name of Oracle home
--dbname specifies the name of the database
--executePrereqs runs the prerequisite checks and report the results
--resume resumes the previous run
--sessionID specifies to resume a specific session
ID
--rollback rolls the database back to previous home
--sessionID specifies to resume a specific session ID
--skipDatapatch skips running the datapatch on the databases
--skipPdbs skips running the datapatch on a specified
comma-delimited list of PDBs. For example:
pdb1,pdb2...
--skipClosedPDBs skips patching closed PDBs
--continueWithDbDowntime continues patching with
database downtime. This option can be used in environments wherein there is only
one active instance up and the patching operation can be continued even with a
downtime.
--allowParallelDBMove allows database move in parallel.
--waitForCompletion specifies false to run the operation in the background. Valid values:true|false
--nodeList specifies a comma-delimited list of nodes if operation has to be performed on a subset of nodes
Frequently Asked Questions
Q: What is the dbaascli database move command used for?
A: The dbaascli database move command is used to move a database from one Oracle home to another.
Q: What are the prerequisites for using the dbaascli database move command?
A: Before performing a move operation, ensure that all database instances associated with the database are up and running. Additionally, the command must be run as the root user.
Q: What does the --oracleHome parameter specify?
A: The --oracleHome parameter specifies the path of the Oracle home to which the database will be moved.
Q: What does the --oracleHomeName parameter specify?
A: The --oracleHomeName parameter specifies the name of the Oracle home to which the database will be moved.
Q: What is the purpose of the --dbname parameter?
A: The --dbname parameter specifies the name of the database that you want to move.
Q: What does the --executePrereqs option do?
A: The --executePrereqs option runs the prerequisite checks and reports the results.
Q: What is the --resume option used for?
A: The --resume option resumes a previously interrupted or incomplete move operation.
Q: How is --sessionID used in the command?
A: The --sessionID specifies the session ID to resume a previous run or rollback.
Q: What does the --rollback option do?
A: The --rollback option rolls the database back to its previous Oracle home.
Q: What does the --skipDatapatch option do?
A: The --skipDatapatch option skips running the datapatch on the databases during the move operation.
Q: What is the function of the --skipPDBs option?
A: The --skipPDBs option skips running the datapatch on a specified comma-delimited list of PDBs (e.g., pdb1, pdb2).
Q: What does the --skipClosedPDBs option do?
A: The --skipClosedPDBs option skips patching of closed PDBs.
Q: What does --continueWithDbDowntime mean?
A: The --continueWithDbDowntime option allows the move operation to proceed even if there is only one active instance up, allowing for downtime during the process.
Q: What is the purpose of the --allowParallelDBMove option?
A: The --allowParallelDBMove option allows the database move to be performed in parallel, potentially speeding up the process.
Q: What does --waitForCompletion specify?
A: The --waitForCompletion option specifies whether to wait for the operation to complete. Setting it to false runs the operation in the background.
Q: How do I use the --nodeList parameter?
A: The --nodeList parameter specifies a comma-delimited list of nodes on which the move operation will be performed, if it is not to be applied to all nodes.
Q: What should I do if I encounter issues with the dbaascli database move command?
A: Ensure all database instances are running and verify that you are running the command as the root user. If issues persist, consult the detailed command documentation or open a support ticket with Oracle.
Q: Can I perform a move operation if one of the database instances is down?
A: No, all associated database instances must be up and running before performing the move operation.
Q: What happens if the move operation is interrupted?
A: You can use the --resume option to continue the move operation from where it left off by using the same session or specifying the --sessionID.
Q: What does the --allowParallelDBMove option do?
A: It enables the database move to be performed in parallel, which can reduce the time it takes to complete the operation, especially on larger environments.
Q: How do I monitor the progress of a move operation that is running in the background?
A: When using --waitForCompletion false, the command does not wait for the operation to complete. You can check the status of the operation manually using appropriate Oracle logs or status commands.
Q: What is the significance of the --skipClosedPDBs option?
A: It skips patching for PDBs that are closed, reducing the operation time if there are PDBs that don’t need to be patched.
Q: Can the database move be rolled back at any time?
A: Yes, the move operation can be rolled back using the --rollback option, either by specifying the session ID or simply rolling back to the previous Oracle home.
Q: What is the role of --nodeList in a multi-node environment?
A: In a multi-node environment, you can restrict the move operation to specific nodes by providing a comma-delimited list of node names with --nodeList.
Q: Can I move the database to a new Oracle home while skipping specific nodes in a multi-node environment?
A: Yes, you can use the --nodeList option to specify which nodes to include in the move operation. Any nodes not listed will be skipped.
Q: What is the maximum number of nodes I can specify with the --nodeList parameter?
A: The --nodeList parameter allows you to specify a comma-delimited list of as many nodes as needed, limited only by your environment configuration. Ensure all nodes are valid and reachable.
Q: How do I know which PDBs are closed before using the --skipClosedPDBs option?
A: You can query the v$pdbs view to check the status of your PDBs. Any PDBs with a status of "MOUNTED" or "CLOSED" will be skipped when using --skipClosedPDBs.
Q: How do I verify if a rollback has completed successfully?
A: After running the rollback command, you can review the database logs or use the Oracle alert logs to verify that the database has been successfully rolled back to its previous Oracle home.
Q: Is there a way to force the move operation if some prerequisites fail?
A: The move command enforces prerequisite checks for system stability. You cannot bypass critical prerequisite failures. Address any issues reported by the --executePrereqs option before proceeding with the move.
Example Use Cases
Example 1: Basic Database Move by Oracle Home Path
Moves the ORCL database to the specified Oracle home, runs prerequisite checks, skips running datapatch on pdb1, and allows database downtime during the operation.
Example 16: Combination of Move in Parallel and Running in the Background
Moves the TESTDB database to the new Oracle home /u02/app/oracle/product/19.0.0/dbhome_2, while running the operation in parallel and skipping datapatch on closed PDBs.
Checks the prerequisites for moving the PRODDB database to the Oracle home located at /u02/app/oracle/product/19.0.0/dbhome_2 without actually performing the move.
Performs prerequisite checks before moving the CRMDB database to the new Oracle home, skips patching closed PDBs, and allows the operation to run in parallel for faster execution.
Example 30: Database Move with Rollback on Specific Session ID and Skipping Datapatch
Rolls back a previously executed move operation for the DEVDB database to its prior Oracle home using session ID 45678, skipping the datapatch process during the rollback.
Example 31: Moving Database with Allow Parallel Execution and Specifying Datapatch Skipping for PDBs
Q: How can I skip the catbundle run while patching Oracle Database 11.2.0.4.0?
A: To skip the catbundle run during the Oracle Database patching process, use the --skipDatapatch option with the dbaascli database move or dbaascli dbHome patch command.
Q: What are the best practices to follow during Oracle Database patching?
A: Oracle recommends performing out-of-place patching using the dbaascli database move command to minimize the patching window.
Oracle advises using the --allowParallelDBMove option to enable parallel patching, which can expedite the process.
Q: Can warnings reported during Oracle Database patch prerequisites be ignored?
A: It is advisable to address and resolve any warnings reported during the prerequisites check before proceeding with the patching process. Ignoring warnings may lead to issues during the actual patching.
Q: How can I continue with Oracle Database patching if only one database instance is up and running?
A: It is recommended to have at least two instances running to avoid database downtime. If running two instances is not possible, you can use the --continueWithDbDowntime option with the dbaascli database move or dbaascli dbHome patch command to proceed with patching despite the downtime.
Q: In a Data Guard environment, does datapatch get executed on both the primary and standby databases?
A: No, in a Data Guard environment, datapatch is executed only as part of the primary database patching process.
Q: Can Interim Software Updates (one-off patches) or individual patches be applied manually on Oracle Homes in Exadata Cloud@Customer (ExaDB-C@C) environments?
A: Yes, one-off patches or individual patches can be applied manually to Oracle Homes in ExaDB-C@C environments. However, it is recommended to use the Oracle Database Software Image option for a more streamlined and supported patching process.
Q: How do I patch multiple Oracle databases running from the same Oracle Home when each database is running on just one node?
A: Use the dbaascli dbHome patch command to patch the specified Oracle Home, which will apply the patch to all databases running from that home. It is recommended to have multiple instances running to avoid downtime. If running multiple instances is not possible, you can use the --continueWithDbDowntime option to proceed with patching despite the downtime.
This section covers the management of Pluggable Databases (PDBs) within a container database (CDB). It includes commands for creating (dbaascli pdb create), deleting (dbaascli pdb delete), and cloning PDBs (dbaascli pdb localClone, dbaascli pdb remoteClone). You can manage PDB states with commands to open, close, or bounce PDBs, and retrieve connection details (dbaascli pdb getConnectString). Additional commands support backup, recovery, and relocating PDBs, ensuring comprehensive control over PDB lifecycle and operations.
dbaascli pdb backup To backup a pluggable database (PDB), query PDB backups, and delete a PDB backup, use the dbaascli pdb backup command.
dbaascli pdb bounce To bounce a pluggable database (PDB), use the dbaascli pdb bounce command.
dbaascli pdb close To close a pluggable database (PDB), use the dbaascli pdb close command.
dbaascli pdb create To create a new pluggable database (PDB), use the dbaascli pdb create command.
dbaascli pdb delete To delete a pluggable database (PDB) run the dbaascli pdb delete command.
dbaascli pdb getConnectString To display Oracle Net connect string information for a pluggable database (PDB) run the dbaascli pdb getConnectString command.
dbaascli pdb getDetails To view details of a pluggable database (PDB), use the dbaascli pdb getDetails command.
dbaascli pdb list To view the list of pluggable databases (PDB) in a container database, use the dbaascli pdb list command.
dbaascli pdb localClone To create a new pluggable database (PDB) as a clone of an existing PDB in the same container database (CDB), use the dbaascli pdb localClone command.
dbaascli pdb open To open a pluggable database (PDB), use the dbaascli pdb open command.
dbaascli pdb recover To recover a pluggable database (PDB), use the dbaascli pdb recover command.
dbaascli pdb refresh To refresh a specified pluggable database (PDB), use the dbaascli pdb refresh command.
dbaascli pdb remoteClone To create a new pluggable database (PDB) as a clone of an existing PDB in another container database (CDB), use the dbaascli pdb remoteClone command.
dbaascli pdb relocate To relocate the specified PDB from the remote database into local database, use the dbaascli pdb relocate command.
--pdbName: PDB name.
--dbname: Oracle Database name.
--start | --delete | --status | --getBackupReport | --list--start: Begins PDB backup.
[--level1 | --archival]
[--level1: Creates a Level-1 (incremental) backup.]
[--archival: Creates an archival full backup.]
--tag: Specify backup tag.
--delete: Deletes archival backup.
--backupTag: Specify backup tag to delete.
--status--uuid <value>--getBackupReport: Returns backup report.
--json: Specify the file name for JSON output.
--tag: Specify backup tag.
--list: Returns PDB backup information.
[--json: Specify the file name for JSON output.]
Frequently Asked Questions
Q: What is the purpose of the dbaascli pdb backup command?
A: The dbaascli pdb backup command is used to create backups for a pluggable database (PDB), query backup status, generate backup reports, and delete PDB backups in an Exadata Cloud@Customer environment.
Q: What is the prerequisite for using the dbaascli pdb backup command?
A: The command must be run as the root user, and you need to be connected to an Exadata Cloud@Customer virtual machine.
Q: How do I start a PDB backup using the dbaascli pdb backup command?
A: You can start a PDB backup using the --start option. For example:
A: The --pdbName option specifies the name of the pluggable database (PDB) that you want to back up, query, or delete backups for.
Q: What is the purpose of the --dbname option?
A: The --dbname option specifies the name of the Oracle Database to which the PDB belongs.
Q: How do I specify a backup tag for a PDB backup?
A: You specify a backup tag using the --tag option when starting an archival backup or when retrieving a backup report:
--tag <backup_tag>
Q: Can I run PDB backups in JSON mode?
A: Yes, both the backup report (--getBackupReport) and backup listing (--list) options support output in JSON format. You specify a JSON file name using the --json option.
Example 7-30 Examples
To take level1 backup for a PDB pdb1 in a CDB
myTestDb:
A: The --dbname option specifies the name of the container database (CDB) that hosts the pluggable database (PDB) being bounced.
Q: What is the --pdbName option used for?
A: The --pdbName option specifies the name of the pluggable database (PDB) that you want to bounce.
Q: What is the --pdbUID option used for?
A: The --pdbUID option specifies the unique identifier (UID) of the pluggable database (PDB) that you want to bounce.
Q: How do I specify the target open mode for the PDB when bouncing it?
A: You can use the --openMode option to specify the desired open mode for the PDB after bouncing. The valid values are READ_WRITE and READ_ONLY. For example:
--pdbName specifies the name of the new PDB
that you want to create
--dbName specifies the name of the container database that
hosts the new PDB
--maxCPU optionally specifies the maximum number
of CPUs that are available to the PDB. Setting this option is effectively
the same as setting the CPU_COUNT parameter in the PDB
--maxSize optionally specifies the maximum
total size of data files and temporary files for tablespaces belonging to
the PDB. Setting this option is effectively the same as setting the
MAXSIZE PDB storage clause in the CREATE
PLUGGABLE DATABASE SQL command. You can impose a limit by
specifying an integer followed by a size unit (K,
M, G, or T), or you
can specify UNLIMITED to explicitly enforce no limit
--pdbAdminUserName specifies the new PDB admin
user name
--lockPDBAdminAccount specifies true or
false to lock the PDB admin user account. Default value
is true.
--resume resumes the previous run
--sessionID specifies to resume a specific session
ID
--executePrereqs specifies
yes to run only the prereqs for this operation. Valid
values: yes or no
--waitForCompletion specifies false to run
the operation in the background. Valid values: true or
false
--blobLocation custom directory location where the standby
blob file will be generated in a DG environment.
--standbyBlobFromPrimary specifies the
location of the standby blob file, which is prepared from the primary
database. This is required only for standby database PDB
operations.
Note
the parametersblobLocation and
standbyBlobFromPrimary are mutually exclusive.
During the PDB creation process, you are prompted to specify the
administration password for the new PDB.
Frequently Asked Questions
Q: What is the purpose of the dbaascli pdb create command?
A: The dbaascli pdb create command is used to create a new pluggable database (PDB) in a container database (CDB) in an Exadata Cloud@Customer environment.
Q: What are the prerequisites for using the dbaascli pdb create command?
A: The command must be run as the oracle user, and you must be connected to an Exadata Cloud@Customer virtual machine.
Q: What does the --pdbName option do in the dbaascli pdb create command?
A: The --pdbName option specifies the name of the new pluggable database (PDB) you want to create.
Q: What does the --dbName option do in the dbaascli pdb create command?
A: The --dbName option specifies the name of the container database (CDB) that will host the new pluggable database (PDB).
Q: Can I limit the CPU resources for the new PDB?
A: Yes, you can use the --maxCPU option to specify the maximum number of CPUs that the PDB can use. This is equivalent to setting the CPU_COUNT parameter in the PDB.
Q: How can I limit the storage size of a PDB?
A: You can use the --maxSize option to specify the maximum total size of data files and temporary files for the PDB. You can either set a size limit (in K, M, G, or T) or specify UNLIMITED for no limit.
Q: What is the --pdbAdminUserName option used for?
A: The --pdbAdminUserName option specifies the name of the admin user for the new PDB. This user will have administrative privileges within the PDB.
Q: Is it possible to lock the admin user account during PDB creation?
A: Yes, you can use the --lockPDBAdminAccount option to specify whether the PDB admin account should be locked. The default value is true (locked).
Q: What does the --resume option do in the dbaascli pdb create command?
A: The --resume option allows you to resume a previously failed PDB creation process.
Q: How do I specify a session ID for resuming a previous run?
A: You can specify a session ID using the --sessionID option to resume a specific session of the PDB creation process.
Q: What is the purpose of the --executePrereqs option?
A: The --executePrereqs option specifies whether to run only the prerequisite checks for PDB creation. You can set this option to yes or no.
Q: Can I run the PDB creation process in the background?
A: Yes, you can use the --waitForCompletion option and set it to false to run the operation in the background.
Q: What is the --standbyBlobFromPrimary option used for?
A: The --standbyBlobFromPrimary option specifies the location of the standby blob file, which is prepared from the primary database. This is required for standby database PDB operations.
Q: How will I be prompted for the PDB admin password during the creation process?
A: During the PDB creation process, you will be prompted to specify the administration password for the new PDB.
Q: Can I create a standby PDB using the dbaascli pdb create command?
A: Yes, if you are creating a standby PDB, you can use the --standbyBlobFromPrimary option to specify the location of the standby blob file from the primary database.
Q: What happens if I don't use the --maxSize option?
A: If you do not specify the --maxSize option, the PDB will not have a storage size limit unless otherwise defined by the CDB policies.
Q: What happens if I do not provide the --pdbAdminUserName option?
A: If you do not provide the --pdbAdminUserName option, the PDB will be created without a specified admin user, and you will need to manually configure the admin user after creation.
Q: Can I resume a failed PDB creation at any point in the process?
A: Yes, as long as the session has not been terminated, you can resume a failed PDB creation using the --resume and --sessionID options.
Example 7-33 dbaascli pdb create
To create a PDB from seed in a standard database in a non-Data Guard
environment:
To delete a pluggable database (PDB) run the dbaascli pdb
delete command.
Prerequisite
Run the command as the oracle user.
Syntax
dbaascli pdb delete --dbName value
{ --pdbName value | --pdbUID value }
[--executePrereqs value]
[--waitForCompletion value]
[--resume [--sessionID value]]
[--allStandbyPrepared]
[--cleanupRelocatedPDB]
Where:
--dbName specifies the name of the container
database that hosts the PDB
--pdbName specifies the name of the PDB that
you want to delete
--pdbUID specifies the UID of the PDB that you
want to delete
--executePrereqs specifies
yes to run only the prereqs for this operation. Valid
values: yes or no
--waitForCompletion specifies false to run
the operation in the background. Valid values: true or
false
--resume specifies to resume the previous
execution
--sessionID specifies to resume a
specific session ID
--allStandbyPrepared specifies to confirm that
the operation has been successfully run on all the standby databases
--cleanupRelocatedPDB - option to cleanup source database
after a PDB has been relocated.
Frequently Asked Questions
Q: What is the purpose of the dbaascli pdb delete command?
A: The dbaascli pdb delete command is used to delete a pluggable database (PDB) from a container database (CDB) in an Exadata Cloud@Customer environment.
Q: What are the prerequisites for running the dbaascli pdb delete command?
A: The command must be run as the oracle user, and you must be connected to an Exadata Cloud@Customer virtual machine.
Q: What does the --dbName option specify in the dbaascli pdb delete command?
A: The --dbName option specifies the name of the container database (CDB) that hosts the PDB you want to delete.
Q: How can I specify which PDB to delete using the dbaascli pdb delete command?
A: You can specify the PDB to delete using either the --pdbName option (specifies the PDB name) or the --pdbUID option (specifies the PDB UID).
Q: Can I run the prerequisite checks without actually deleting the PDB?
A: Yes, you can use the --executePrereqs option and set it to yes to run only the prerequisite checks for the PDB deletion operation.
Q: How can I run the PDB deletion process in the background?
A: Use the --waitForCompletion option and set it to false to run the deletion process in the background.
Q: What does the --resume option do in the dbaascli pdb delete command?
A: The --resume option allows you to resume a previously failed PDB deletion process.
Q: How do I resume a specific session for a PDB deletion?
A: You can specify a session ID using the --sessionID option to resume a specific session for the PDB deletion process.
Q: What does the --allStandbyPrepared option do?
A: The --allStandbyPrepared option is used to confirm that the deletion operation has been successfully run on all standby databases before proceeding with the primary PDB deletion.
Q: What is the purpose of the --cleanupRelocatedPDB option?
A: The --cleanupRelocatedPDB option cleans up the source database after a PDB has been relocated, ensuring no residuals are left after the relocation.
Q: Can I delete a PDB that has already been relocated?
A: Yes, you can use the --cleanupRelocatedPDB option to delete a PDB that has already been relocated to a new CDB.
Q: How do I ensure that the delete operation runs successfully on standby databases?
A: Use the --allStandbyPrepared option to confirm that the operation has run successfully on all standby databases before proceeding.
Q: What happens if the delete process fails and needs to be resumed?
A: You can resume the delete process by using the --resume option, and if needed, specify the session ID with --sessionID.
Q: What does setting --waitForCompletion to false do?
A: Setting --waitForCompletion to false allows the delete process to run in the background, letting you continue working without waiting for the operation to finish.
Example: dbaascli pdb delete
To delete a PDB from a standard database in a
non-Data Guard environment or from Standby database in Data Guard environment.
dbaascli pdb delete --dbName db721 --pdbName pdb1
To
create PDB from Primary database in Data Guard environment:
--dbname specifies the name of the container
database that hosts the PDB
--pdbname specifies the name of the PDB for
which you want to display connect string information
--pdbUID specifies the identifier of the PDB
Frequently Asked Questions
Q: What is the purpose of the dbaascli pdb getConnectString command?
A: The dbaascli pdb getConnectString command is used to display the Oracle Net connect string information for a pluggable database (PDB) in an Exadata Cloud@Customer environment.
Q: What are the prerequisites for using the dbaascli pdb getConnectString command?
A: The command must be run as the oracle user, and you must be connected to an Exadata Cloud@Customer virtual machine.
Q: How do I retrieve the connect string of a PDB by specifying its name?
A: To retrieve the connect string by specifying the PDB name, use the following syntax:
Q: What does the --dbname option do in the dbaascli pdb getConnectString command?
A: The --dbname option specifies the name of the container database (CDB) that hosts the pluggable database (PDB) for which you want to display the connect string information.
Q: What does the --pdbName option do in the dbaascli pdb getConnectString command?
A: The --pdbName option specifies the name of the pluggable database (PDB) for which you want to retrieve the Oracle Net connect string information.
Q: What is the purpose of the --pdbUID option in the dbaascli pdb getConnectString command?
A: The --pdbUID option allows you to specify the unique identifier (UID) of the pluggable database (PDB) for which you want to display the connect string.
Q: Can I use both --pdbName and --pdbUID in the same command?
A: No, you can use either --pdbName or --pdbUID, but not both in the same command.
Q: What type of information is returned by the dbaascli pdb getConnectString command?
A: The command returns the Oracle Net connect string information for the specified pluggable database (PDB).
Q: Can I retrieve the connect string for a PDB on a specific container database instance?
A: No, the connect string is for the PDB as a whole, not for a specific instance of the container database.
Q: How can I get the connect string information if I only know the PDB's unique identifier (UID)?
A: You can retrieve the connect string using the PDB's UID by running:
--dbname specifies the name of the container
database that hosts the PDB
--pdbname specifies the name of the PDB that
you want to delete
--pdbUID specifies the identifier of the PDB
Frequently Asked Questions
Q: What is the purpose of the dbaascli pdb getDetails command?
A: The dbaascli pdb getDetails command is used to view details of a pluggable database (PDB) hosted in a container database (CDB) in an Exadata Cloud@Customer environment.
Q: What are the prerequisites for running the dbaascli pdb getDetails command?
A: The command must be run as the oracle user, and you must be connected to an Exadata Cloud@Customer virtual machine.
Q: What does the --dbname option specify in the dbaascli pdb getDetails command?
A: The --dbname option specifies the name of the container database (CDB) that hosts the PDB for which you want to view details.
Q: How do you specify the PDB for which you want to view details?
A: You can specify the PDB using either the --pdbName option (to provide the PDB name) or the --pdbUID option (to provide the PDB UID).
Q: What is the difference between --pdbName and --pdbUID?
A: The --pdbName option uses the name of the PDB to fetch details, whereas the --pdbUID option uses the unique identifier (UID) of the PDB to fetch its details.
Q: Can I use both --pdbName and --pdbUID together in the dbaascli pdb getDetails command?
A: No, you can specify either the --pdbName or the --pdbUID option to get details of the PDB, but not both at the same time.
Q: What are some use cases for the dbaascli pdb getDetails command?
A: You can use the dbaascli pdb getDetails command to:
Retrieve details about a specific PDB in a CDB.
Verify the configuration of a PDB.
Check the status of a PDB within a CDB.
Q: How can I view details of a PDB based on its name?
A: To view details of a PDB based on its name, use the following syntax:
To view the list of pluggable databases (PDB) in a container database,
use the dbaascli pdb list command.
Prerequisite
Run the command as the oracle user.
Syntax
dbaascli pdb list --dbname
Where:
--dbname specifies the name of the container
database that hosts the PDB
Frequently Asked Questions
Q: What is the purpose of the dbaascli pdb list command?
A: The dbaascli pdb list command is used to view the list of pluggable databases (PDBs) in a specified container database (CDB) in an Exadata Cloud@Customer environment.
Q: What are the prerequisites for running the dbaascli pdb list command?
A: The command must be run as the oracle user, and you must be connected to an Exadata Cloud@Customer virtual machine.
Q: What does the --dbname option specify in the dbaascli pdb list command?
A: The --dbname option specifies the name of the container database (CDB) that hosts the pluggable databases (PDBs) for which you want to view the list.
Q: Can I view the list of PDBs from multiple container databases at once?
A: No, the dbaascli pdb list command allows you to list the PDBs from only one container database (CDB) at a time, specified by the --dbname option.
Q: How do I list the PDBs in a specific container database (CDB)?
A: You can list the PDBs in a specific CDB by using the following syntax:
dbaascli pdb list --dbname <CDB_Name>
Q: What information is displayed when using the dbaascli pdb list command?
A: The command returns a list of all pluggable databases (PDBs) within the specified container database (CDB). The list typically includes the names of the PDBs and possibly other details like their status.
Q: Can I filter the PDB list using additional options?
A: No, the dbaascli pdb list command does not support additional filtering options. It simply returns the complete list of PDBs within the specified CDB.
Q: What happens if the specified --dbname does not exist or is incorrect?
A: If the specified --dbname is incorrect or does not exist, the command will return an error, and no PDB list will be displayed.
Q: Can the dbaascli pdb list command be used for any Oracle database environment?
A: No, the dbaascli pdb list command is specifically designed for use in Exadata Cloud@Customer environments.
--pdbName specifies the name of the new PDB
that you want to clone
--dbName specifies the name of the database
--targetPDBName specifies the name for the
target PDB (new cloned PDB)
--powerLimit specifies the degree of
parallelism to be used for the clone operation. Valid value is between 1 and
128
--maxCPU specifies the maximum number of CPUs
to be allocated for the PDB
--maxSize specifies the maximum storage size
in GB for the new PDB
--resume resumes the previous run
--sessionID specifies to resume a specific session
ID
--executePrereqs specifies
yes to run only the prereqs for this operation. Valid
values: yes or no
--waitForCompletion specifies false to run
the operation in the background. Valid values: true or
false
--blobLocation custom directory location where the standby
blob file will be generated in a DG environment.
--standbyBlobFromPrimary specifies the location
of the standby blob file which is prepared from the primary database. This
is required only for standby database PDB operations.
Note
The parameters
--blobLocation and
--standbyBlobFromPrimary are mutually
exclusive.
--excludeUserTablespaces option to skip user table spaces,
example t1,t2,t3.
--excludePDBData specify true/yes to skip user data from
source pdb.
--pdbAdminUserName specify new PDB admin user name.
--lockPDBAdminAccount specify true or false to lock the PDB
admin user account. Default value is true.
--sourcePDBServiceConvertList specify comma separated list
of source to target service names which need to be converted. Syntax is
source_srv1:new_srv1,source_srv2:new_srv2.
The newly cloned PDB inherits administration passwords from the source
PDB.
Frequently Asked Questions
Q: What is the purpose of the dbaascli pdb localClone command?
A: The dbaascli pdb localClone command is used to create a new pluggable database (PDB) as a clone of an existing PDB in the same container database (CDB) in an Exadata Cloud@Customer environment.
Q: What are the prerequisites for running the dbaascli pdb localClone command?
A: The command must be run as the oracle user, and you must be connected to an Exadata Cloud@Customer virtual machine. Additionally, the source PDB must already exist in the specified CDB.
Q: What does the --dbName option specify in the dbaascli pdb localClone command?
A: The --dbName option specifies the name of the container database (CDB) that hosts the source PDB from which the new PDB will be cloned.
Q: What does the --pdbName option specify in the dbaascli pdb localClone command?
A: The --pdbName option specifies the name of the new PDB that you want to create as a clone of the existing PDB in the same CDB.
Q: Can I clone a PDB with a different name using the dbaascli pdb localClone command?
A: Yes, you can specify a different name for the cloned PDB using the --targetPDBName option. If this option is not provided, the cloned PDB will inherit the name of the source PDB.
Q: What does the --resume option do in the dbaascli pdb localClone command?
A: The --resume option allows you to resume a previously interrupted PDB cloning operation.
Q: How do I limit the CPU resources available to the cloned PDB?
A: You can limit the CPU resources for the cloned PDB using the --maxCPU option, which specifies the maximum number of CPUs that will be allocated to the new PDB.
Q: Can I run the PDB cloning operation in the background?
A: Yes, you can run the operation in the background by setting the --waitForCompletion option to false. If you set it to true, the operation will run in the foreground and wait for completion.
Q: What is the purpose of the --maxSize option in the dbaascli pdb localClone command?
A: The --maxSize option specifies the maximum storage size (in GB) for the newly cloned PDB. If no size is specified, the cloned PDB inherits the same storage limits as the source PDB.
Q: Can I control the parallelism of the PDB clone operation?
A: Yes, you can control the degree of parallelism for the cloning operation using the --powerLimit option. This option accepts values between 1 and 128 to define the degree of parallelism.
Q: What is the --primaryDBWalletTar option used for?
A: The --primaryDBWalletTar option specifies the location of the primary database wallet tar file. This option is only required if the cloning operation involves standby database PDB operations.
Q: Can I run only the prerequisite checks for the cloning operation?
A: Yes, you can run only the prerequisite checks by using the --executePrereqs option and setting it to yes. The valid values are yes and no.
Q: What happens if the PDB cloning operation fails or is interrupted?
A: If the cloning operation fails or is interrupted, you can resume it by using the --resume option to continue from where the operation stopped.
--pdbName specifies the name of the PDB that
you want to open
--pdbUID specifies the identifier of the PDB
--dbname specifies the name of the container
database that hosts the PDB.
--openMode specifies the target OPEN MODE of PDB
--startServices: specifies to start all or list all services
corresponding to a PDB. Accepted values are all or a
comma-delimited list of PDB services.
--waitForCompletion: specify
false to run the operation in the background. Valid
values: true|false
--setPDBRefreshModeNone: specifies to convert a refreshable
PDB to non-refreshable PDB
--skipPDBRefresh: specifies to skip refreshable PDB
refresh
--pdbAdminUserName: specifies new PDB admin user
name
Upon successful completion, the PDB is opened on all of the container
database instances.
Frequently Asked Questions
Q: What is the purpose of the dbaascli pdb open command?
A: The dbaascli pdb open command is used to open a pluggable database (PDB) in an Oracle container database (CDB) in an Exadata Cloud@Customer environment.
Q: Who can run the dbaascli pdb open command?
A: The command can be run as either the root or oracle user.
Q: What does the --pdbName option specify in the dbaascli pdb open command?
A: The --pdbName option specifies the name of the PDB that you want to open.
Q: What does the --pdbUID option specify in the dbaascli pdb open command?
A: The --pdbUID option specifies the unique identifier (UID) of the PDB that you want to open.
Q: What does the --dbname option specify in the dbaascli pdb open command?
A: The --dbname option specifies the name of the container database (CDB) that hosts the PDB.
Q: What is the purpose of the --openMode option?
A: The --openMode option specifies the mode in which the PDB will be opened. Valid values are READ_WRITE and READ_ONLY.
Q: Can I start services when opening the PDB?
A: Yes, you can use the --startServices option to either start all services associated with the PDB by specifying all or provide a comma-delimited list of specific services to start.
Q: What happens if I set the --waitForCompletion option to false?
A: If --waitForCompletion is set to false, the command will run in the background, and the user does not need to wait for the operation to complete. If set to true, the command will wait for completion before exiting.
Q: What does the --setPDBRefreshModeNone option do?
A: The --setPDBRefreshModeNone option converts a refreshable PDB (one that is regularly updated from a primary database) into a non-refreshable PDB.
Q: What is the function of the --skipPDBRefresh option?
A: The --skipPDBRefresh option allows you to skip the refresh operation when opening a refreshable PDB, preventing the PDB from syncing with the primary database at that time.
Q: What does the --pdbAdminUserName option do in the dbaascli pdb open command?
A: The --pdbAdminUserName option allows you to specify a new PDB admin username when opening the PDB.
Q: What happens if the dbaascli pdb open command is successful?
A: Upon successful completion, the specified PDB will be opened on all instances of the container database (CDB).
Q: Is it possible to run the dbaascli pdb open command for a refreshable PDB?
A: Yes, the command can be used for refreshable PDBs. The --setPDBRefreshModeNone option converts the PDB to non-refreshable, and the --skipPDBRefresh option skips the refresh operation during the opening process.
Q: What is the default open mode for a PDB if no --openMode is specified?
A: If no --openMode is specified, the PDB is typically opened in READ_WRITE mode by default.
Example 7-38 dbaascli pdb open
dbaascli pdb open --dbname cdb name --pdbName pdb name associated with the CDB
dbaascli pdb open --dbname cdb name --pdbUID con_uid of that pdb
--pdbName: PDB name.
--dbname: Oracle Database name.
--start | --status--start--untilTime | --untilSCN | --latest | --tag--untilTime: Recovers PDB until time. Input format: DD-MON-YYYY HH24:MI:SS.
--untilSCN: Recovers PDB until SCN.
--latest: Recovers PDB to last known state.
--tag: Recovers PDB to archival tag.
--status--uuid <value>
Frequently Asked Questions
Q: What is the purpose of the dbaascli pdb recover command?
A: The dbaascli pdb recover command is used to recover a pluggable database (PDB) to a previous state using backups stored in a configured backup storage destination.
Q: Who can run the dbaascli pdb recover command?
A: The command must be run as the root user.
Q: What is required before running the dbaascli pdb recover command?
A: Before running the command, the database must be configured with backup storage destination details where backups are stored.
Q: What does the --pdbName option specify in the dbaascli pdb recover command?
A: The --pdbName option specifies the name of the pluggable database (PDB) that you want to recover.
Q: What does the --dbname option specify in the dbaascli pdb recover command?
A: The --dbname option specifies the name of the container database (CDB) that hosts the PDB.
Q: What are the possible options for starting a PDB recovery using the --start option?
A: You can recover the PDB using one of the following options:
--untilTime <value>: Recovers the PDB until a specified time (format: DD-MON-YYYY HH24:MI).
--untilSCN <value>: Recovers the PDB until a specified System Change Number (SCN).
--latest: Recovers the PDB to the latest known state.
--tag <value>: Recovers the PDB to a specific archival tag.
Q: What is the format required for specifying the time in the --untilTime option?
A: The time must be in the format DD-MON-YYYY HH24:MI:SS.
Q: How can I recover a PDB to the latest state using dbaascli pdb recover?
A: To recover the PDB to the latest known state, use the --latest option:
--dbname: specifies the name of the Oracle Database
--pdbName: specifies the name of the pluggable database
--pdbUID: specifies the identifier of the pluggable
database
--waitForCompletion: specify
false to run the operation in the background. Valid values:
true|false
Frequently Asked Questions
Q: What is the purpose of the dbaascli pdb refresh command?
A: The dbaascli pdb refresh command is used to refresh a specified pluggable database (PDB) in a container database (CDB).
Q: Who can run the dbaascli pdb refresh command?
A: The command can be run by either the root or oracle user.
Q: What does the --dbname option specify in the dbaascli pdb refresh command?
A: The --dbname option specifies the name of the container database (CDB) that hosts the pluggable database (PDB) to be refreshed.
Q: What does the --pdbName option specify in the dbaascli pdb refresh command?
A: The --pdbName option specifies the name of the pluggable database (PDB) that you want to refresh.
Q: What does the --pdbUID option specify in the dbaascli pdb refresh command?
A: The --pdbUID option specifies the unique identifier (UID) of the pluggable database (PDB) that you want to refresh.
Q: What does the --waitForCompletion option do in the dbaascli pdb refresh command?
A: The --waitForCompletion option specifies whether the operation should be run in the foreground or background. If set to true, the operation will run in the foreground and wait for completion. If set to false, the operation will run in the background.
Q: How can I refresh a PDB and run the operation in the background?
A: To refresh a PDB and run the operation in the background, use the --waitForCompletion false option:
Q: Can I specify both --pdbName and --pdbUID together in the dbaascli pdb refresh command?
A: No, you must specify either --pdbName or --pdbUID, but not both, when refreshing a PDB.
Q: What happens if I don't include the --waitForCompletion option in the command?
A: If you don't specify the --waitForCompletion option, the default behavior will be to wait for the operation to complete before returning control to the user.
Q: Can I refresh a PDB while the database is running?
A: Yes, you can refresh a PDB while the database is running, as long as the command is executed by a user with appropriate privileges.
--pdbName specifies the name of the source PDB
that you want to clone
--dbname specifies the name
(DB_NAME) of the CDB that hosts the newly cloned
PDB
--sourceDBConnectionString specifies the source
database connection string in the format scan_name:scan_port/database_service_name
--targetPDBName specifies the name for the
target PDB (new cloned PDB)
--powerLimit specifies the degree of
parallelism to be used for the clone operation. Valid value is between 1 and
128
--maxCPU specifies the maximum number of CPUs
to be allocated for the PDB
--maxSize specifies the maximum storage size in
GB for the new PDB
--resume resumes the previous run
--sessionID specifies to resume a specific session
ID
--executePrereqs specifies yes
to run only the prereqs for this operation. Valid values:
yes or no
--waitForCompletion specifies
false to run the operation in the background. Valid
values: true or false
--sourcePDBExportedTDEKeyFile specifies the
source PDB exported key file. This variable is applicable to only 12.1
database.
--blobLocation specifies the custom path where
the standby blob file will be generated in a Data Guard environment
--standbyBlobFromPrimary specify the location
of the standby blob file, which is prepared from the primary database. This
is required only for standby database PDB operations
Note
The parameters
--blobLocation and
--standbyBlobFromPrimary are mutually
exclusive.
--excludeUserTablespaces option to skip user
table spaces, example
t1,t2,t3.
--excludePDBData specify
true/yes to skip user data from source
PDB.
--pdbAdminUserName specifies new PDB admin
user name
--lockPDBAdminAccount specify
true or false to lock the PDB admin
user account. Default value is true.
--sourcePDBServiceConvertList specify a
comma-delimited list of source to target service names, which need to be
converted. Syntax is source_srv1:new_srv1,
source_srv2:new_srv2.
--refreshablePDB specifies to create refreshable PDB
--refreshMode specifies refresh mode for
refreshable PDB. Valid values:
AUTO|MANUAL
--refreshIntervalInMinutes
specifies refresh interval for
refreshablePDB in minutes
--dblinkUsername specifies common user
of a remote database used for database link to connect to the remote
database
--honorCaseSensitiveUserName
indicates specified username is case sensitive
--updateDBBlockCacheSize: specifies to enable application
to set db block cache size initialization parameters to
support data copy with a different block size
When promoted, you must supply the SYS user password for the source PDB.
The newly cloned PDB inherits administration passwords from the source PDB. The
cloned PDB is named using the following format:
dbname_sourcepdbname. This command is supported only for
databases that are not in a Data Guard configuration and use Oracle Database version
12.2.0.1, or later.
Frequently Asked Questions
Q: What is the dbaascli pdb remoteClone command used for?
A: The dbaascli pdb remoteClone command is used to create a new Pluggable Database (PDB) as a clone of an existing PDB in another container database (CDB).
Q: What user should execute the dbaascli pdb remoteClone command?
A: The command should be executed as either the root or oracle user.
Q: What is required when prompted during the dbaascli pdb remoteClone operation?
A: You must supply the SYS user password for the source PDB.
Q: What does the --pdbName parameter specify?
A: The --pdbName parameter specifies the name of the source PDB that you want to clone.
Q: What does the --dbName parameter represent?
A: The --dbName parameter represents the name (DB_NAME) of the CDB that will host the newly cloned PDB.
Q: How should the --sourceDBConnectionString be formatted?
A: The --sourceDBConnectionString should be formatted as <scan_name>:<scan_port>/<database_service_name>.
Q: What is the purpose of the --targetPDBName parameter?
A: The --targetPDBName parameter specifies the name for the newly cloned PDB.
Q: What does --powerLimit control?
A: The --powerLimit parameter controls the degree of parallelism used for the cloning operation. The valid value is between 1 and 128.
Q: What does the --maxCPU parameter define?
A: The --maxCPU parameter defines the maximum number of CPUs to be allocated for the PDB cloning process.
Q: What is the function of --maxSize?
A: The --maxSize parameter specifies the maximum storage size in GB for the new PDB.
Q: What does the --resume parameter do?
A: The --resume parameter resumes the previous cloning operation.
Q: What should you provide with the --resume option?
A: You can specify a --sessionID to resume a specific session if you are resuming a previous operation.
Q: What does --executePrereqs control?
A: The --executePrereqs parameter determines if only the prerequisites for the cloning operation should be run. Valid values are yes or no.
Q: How does --waitForCompletion affect the operation?
A: The --waitForCompletion parameter specifies whether to wait for the operation to complete or run it in the background. Valid values are true or false.
Q: What is specified by the --sourcePDBExportedTDEKeyFile parameter?
A: The --sourcePDBExportedTDEKeyFile parameter specifies the exported key file from the source PDB. This parameter is applicable only for Oracle Database version 12.1.
Q: What does the --blobLocation parameter define?
A: The --blobLocation parameter specifies the custom path where the standby BLOB file will be generated in a Data Guard environment.
Q: When is --standbyBlobFromPrimary used?
A: The --standbyBlobFromPrimary parameter specifies the location of the standby BLOB file prepared from the primary database. This is required only for standby database PDB operations.
Q: Can --blobLocation and --standbyBlobFromPrimary be used together?
A: No, --blobLocation and --standbyBlobFromPrimary are mutually exclusive and cannot be used together.
Q: What does the --excludeUserTablespaces option do?
A: The --excludeUserTablespaces option allows you to skip specific user tablespaces from being cloned. For example, t1,t2,t3.
Q: What is the effect of --excludePDBData?
A: The --excludePDBData option specifies whether to skip user data from the source PDB during cloning. Valid values are true or yes.
Q: What is specified by --pdbAdminUserName?
A: The --pdbAdminUserName parameter specifies the new admin user name for the cloned PDB.
Q: What does the --lockPDBAdminAccount option control?
A: The --lockPDBAdminAccount option specifies whether to lock the PDB admin user account. The default value is true.
Q: What does --sourcePDBServiceConvertList specify?
A: The --sourcePDBServiceConvertList parameter specifies a comma-delimited list of source to target service name conversions. For example, source_srv1:new_srv1,source_srv2:new_srv2.
Q: What is the purpose of --refreshablePDB?
A: The --refreshablePDB parameter specifies whether to create a refreshable PDB.
Q: What does --refreshMode control?
A: The --refreshMode parameter controls the refresh mode for a refreshable PDB. Valid values are AUTO or MANUAL.
Q: How does --refreshIntervalInMinutes work?
A: The --refreshIntervalInMinutes parameter specifies the interval in minutes for refreshing the refreshable PDB.
Q: What is --dblinkUsername used for?
A: The --dblinkUsername parameter specifies a common user of a remote database used for the database link to connect to the remote database.
Q: What does the --honorCaseSensitiveUserName option indicate?
A: The --honorCaseSensitiveUserName option indicates that the specified username is case sensitive.
Q: What is the effect of --updateDBBlockCacheSize?
A: The --updateDBBlockCacheSize option enables the application to set the DB block cache size initialization parameters to support data copy with a different block size.
Q: What should I do if I encounter an error with the dbaascli pdb remoteClone command?
A: Review the error message for details, ensure all parameters are correctly specified, and verify that you have the necessary permissions and credentials. Additionally, check that the source and target databases meet all the requirements.
Q: What if I forget the SYS user password for the source PDB?
A: You will need to reset or recover the SYS user password for the source PDB. Without it, the cloning operation cannot be completed.
--pdbName specifies the source PDB name to
relocate
--dbName specifies the target database
name
--sourceDBConnectionString specifies the
source database connection string in the format <scan_name>:<scan_port>/<database_service_name>
--targetPDBName specifies a name for the target
PDB (new relocated PDB)
--powerLimit specifies the degree of
parallelism to be used for the relocate operation
--maxCpu specifies the maximum number of CPUs
to be allocated for the PDB
--maxSize specifies the maximum storage size
in GB for the new PDB
--resume specifies to resume the previous
execution
--sessionID specifies to resume a
specific session ID
--executePrereqs specifies yes
to run only the prereqs for this operation. Valid values:
yes|no
--sourcePDBServices specifies a list of
comma-delimited source PDB services
--sourcePDBReadOnlyServices specifies a
comma-delimited list of source PDB read-only services
--waitForCompletion specifies
false to run the operation in the background. Valid
values: true|false
--blobLocation specifies the location of a
custom directory where the standby BLOB file will be generated in a Data
Guard environment.
--standbyBlobFromPrimary specifies the
location of the standby BLOB file, which is prepared from the primary
database. This is required only for standby operations.
Note
The parameters
--blobLocation and mutually exclusive.
--upgradePDB specifies true to
upgrade the PDB as part of this operation. Valid values :
true | false.
--updateDBBlockCachesize option to enable
application to set db block cache size initialization
parameters to support data copy with different block size.
--skipOpenPDB - indicates that the PDB should
not be opened at the end of the current operation.
--completePDBRelocate - completes the PDB
relocation if done as a two-step operation.
Frequently Asked Questions
Q: What is the dbaascli pdb relocate command used for?
A: The dbaascli pdb relocate command is used to relocate a Pluggable Database (PDB) from a remote database to a local database.
Q: What user should run the dbaascli pdb relocate command?
A: The command should be run as the Oracle user.
Q: What is required when prompted during the dbaascli pdb relocate operation?
A: You must supply the SYS user password for the source database.
Q: What does the --pdbName parameter specify?
A: The --pdbName parameter specifies the name of the source PDB to be relocated.
Q: What is the purpose of the --dbName parameter?
A: The --dbName parameter specifies the target database name where the PDB will be relocated.
Q: How should the --sourceDBConnectionString be formatted?
A: The --sourceDBConnectionString should be formatted as <scan_name>:<scan_port>/<database_service_name>.
Q: What does the --targetPDBName parameter do?
A: The --targetPDBName parameter specifies a new name for the relocated PDB.
Q: What is the use of --powerLimit?
A: The --powerLimit parameter specifies the degree of parallelism to be used during the relocate operation.
Q: How does --maxCpu affect the relocation process?
A: The --maxCpu parameter specifies the maximum number of CPUs to be allocated for the PDB relocation process.
Q: What does the --maxSize parameter define?
A: The --maxSize parameter defines the maximum storage size in GB for the new PDB.
Q: What is the function of --resume?
A: The --resume parameter indicates that the relocation operation should resume from where it left off.
Q: What should I provide with the --resume option?
A: You can specify a --sessionID to resume a specific session if you are resuming a previous operation.
Q: What does the --executePrereqs parameter do?
A: The --executePrereqs parameter determines if only the prerequisites for the operation should be run. Valid values are yes or no.
Q: What is specified by the --sourcePDBServices parameter?
A: The --sourcePDBServices parameter specifies a list of comma-delimited source PDB services.
Q: What does the --sourcePDBReadOnlyServices parameter list?
A: The --sourcePDBReadOnlyServices parameter lists a comma-delimited list of source PDB read-only services.
Q: What is the effect of --waitForCompletion?
A: The --waitForCompletion parameter specifies whether to run the operation in the background. Valid values are true or false.
Q: What does the --blobLocation parameter specify?
A: The --blobLocation parameter specifies the location of a custom directory where the standby BLOB file will be generated in a Data Guard environment.
Q: When should I use --standbyBlobFromPrimary?
A: Use --standbyBlobFromPrimary to specify the location of the standby BLOB file, which is prepared from the primary database. This is required only for standby operations.
Q: Can I use --blobLocation and --standbyBlobFromPrimary together?
A: No, the --blobLocation and --standbyBlobFromPrimary parameters are mutually exclusive and cannot be used together.
Q: What does --upgradePDB do?
A: The --upgradePDB parameter specifies whether to upgrade the PDB as part of the relocation operation. Valid values are true or false.
Q: What is the purpose of --updateDBBlockCacheSize?
A: The --updateDBBlockCacheSize option allows the application to set the DB block cache size initialization parameters to support data copy with a different block size.
Q: What does the --skipOpenPDB option do?
A: The --skipOpenPDB option indicates that the PDB should not be opened at the end of the relocation operation.
Q: When should I use --completePDBRelocate?
A: Use --completePDBRelocate to complete the PDB relocation if it is done as a two-step operation.
Q: What should I do if I encounter an error while using the dbaascli pdb relocate command?
A: Check the error message for details, ensure all parameters are correctly specified, and verify that you have the necessary permissions and credentials. You might also need to review the prerequisites and configurations.
Q: What if I forget the SYS user password for the source database?
A: You will need to reset or recover the SYS user password for the source database. Without it, you cannot complete the relocation operation.
This section focuses on overseeing and managing Oracle homes within the system. It includes commands like dbaascli system getDBHomes to view details about all Oracle Database homes and dbaascli system getGridHomes to list the details of all Grid Infrastructure homes. These commands provide essential information for maintaining and troubleshooting the overall system environment.
dbaascli system getDBHomes To view information about all the Oracle homes, use the dbaascli system getDBHomes command.
dbaascli system getGridHomes To list the details of all Grid homes, use the dbaascli system getGridHomes command.
To view information about all the Oracle homes, use the dbaascli
system getDBHomes command.
Prerequisite
Run the command as the root or oracle user.
Syntax
dbaascli system getDBHomes
Frequently Asked Questions
Q: What is the dbaascli system getDBHomes command used for?
A: The dbaascli system getDBHomes command is used to view information about all the Oracle homes on a system.
Q: What user should execute the dbaascli system getDBHomes command?
A: The command should be executed as either the root or oracle user.
Q: Are there any parameters for the dbaascli system getDBHomes command?
A: No, the dbaascli system getDBHomes command does not have any parameters.
Q: What kind of information does the dbaascli system getDBHomes command provide?
A: The command provides details about all Oracle homes on the system, including their paths and other relevant information.
Q: How can I interpret the output from the dbaascli system getDBHomes command?
A: The output will list all Oracle homes with information such as the location of each Oracle home. This information can help in managing and configuring Oracle environments.
Q: What should I do if the dbaascli system getDBHomes command does not return any output?
A: Ensure that you are running the command as the root or oracle user and verify that Oracle homes are properly installed on the system. You may also want to check system permissions and configurations.
Q: What if I receive an error message while executing the dbaascli system getDBHomes command?
A: Check the error message for specific details, verify that you have the appropriate permissions, and ensure that the dbaascli tool is correctly installed and configured.
Q: Can I run dbaascli system getDBHomes on a non-Oracle system?
A: No, the dbaascli system getDBHomes command is specific to Oracle systems and requires Oracle software to be installed.
To list the details of all Grid homes, use the dbaascli system
getGridHomes command.
Prerequisite
Run the command as the root or oracle
user.
Syntax
dbaascli system getGridHomes
Frequently Asked Questions
Q: What is the dbaascli system getGridHomes command used for?
A: The dbaascli system getGridHomes command is used to list the details of all Grid homes on a system.
Q: What user should execute the dbaascli system getGridHomes command?
A: The command should be executed as either the root or oracle user.
Q: Are there any parameters for the dbaascli system getGridHomes command?
A: No, the dbaascli system getGridHomes command does not have any parameters.
Q: What kind of information does the dbaascli system getGridHomes command provide?
A: The command provides details about all Grid homes on the system, including their locations and other relevant information.
Q: How can I interpret the output from the dbaascli system getGridHomes command?
A: The output will list all Grid homes with information such as their paths and configurations. This helps in managing and configuring Oracle Grid infrastructure.
Q: What should I do if the dbaascli system getGridHomes command does not return any output?
A: Ensure you are running the command as the root or oracle user and verify that Oracle Grid homes are properly installed on the system. Check system permissions and configurations if needed.
Q: What if I receive an error message while executing the dbaascli system getGridHomes command?
A: Review the error message for specific details, ensure you have the appropriate permissions, and verify that the dbaascli tool is properly installed and configured.
Q: Can I run dbaascli system getGridHomes on a system without Oracle Grid infrastructure?
A: No, the dbaascli system getGridHomes command is specific to systems with Oracle Grid infrastructure installed. If no Grid homes are present, the command may not return any results.
This section encompasses the management of Transparent Data Encryption (TDE) for securing database data. It includes commands for handling encryption keys and keystores, such as dbaascli tde addSecondaryHsmKey to add secondary HSM keys, dbaascli tde rotateMasterKey to rotate the master key, and dbaascli tde encryptTablespacesInPDB to encrypt tablespaces within a pluggable database. You can also convert between FILE and HSM-based TDE (dbaascli tde fileToHsm, dbaascli tde hsmToFile), manage key versions, and retrieve key details with various commands. These tools ensure effective encryption management and data security.
dbaascli tde addSecondaryHsmKey To add a secondary HSM (KMS) key to the existing HSM (KMS) configuration, use the dbaascli tde addSecondaryHsmKey command.
dbaascli tde changePassword To change TDE keystore password as well as DB wallet password for the alias tde_ks_passwd, use the dbaascli tde changePassword command.
dbaascli tde enableWalletRoot To enable wallet_root spfile parameter for the existing database, use the dbaascli tde enableWalletRoot command.
dbaascli tde fileToHsm To convert FILE based TDE to HSM (KMS/OKV) based TDE, use the dbaascli tde fileToHsm command.
dbaascli tde getHsmKeys To get TDE active key details, use the dbaascli tde getHsmKeys command.
dbaascli tde getMkidForKeyVersionOCID To get Master Key ID associated with the KMS key version OCID, use the dbaascli tde getMkidForKeyVersionOCID command.
dbaascli tde getPrimaryHsmKey To get primary HSM (KMS) key from the existing HSM (KMS) configuration, use the dbaascli tde getPrimaryHsmKey command.
dbaascli tde hsmToFile To convert HSM (KMS/OKV) based TDE to FILE based TDE, use the dbaascli tde hsmToFile command.
dbaascli tde listKeys To list TDE master keys, use the dbaascli tde listKeys command.
dbaascli tde removeSecondaryHsmKey To remove secondary HSM (KMS) key from the existing HSM (KMS) configuration, use the dbaascli tde removeSecondaryHsmKey command.
dbaascli tde rotateMasterKey To rotate the master key for database encryption, use the dbaascli tde rotateMasterKey command.
dbaascli tde setKeyVersion To set the version of the primary key to be used in DB/CDB or PDB, use the dbaascli tde setKeyVersion command.
dbaascli tde setPrimaryHsmKey To change the primary HSM (KMS) key for the existing HSM (KMS) configuration, use the dbaascli tde setPrimaryHsmKey command.
dbaascli tde status To display information about the keystore for the specified database, use the dbaascli tde status command.
--secondaryKmsKeyOCID specifies the secondary KMS key to
add to the existing HSM (KMS) configuration
--dbname specifies the name of the database
--executePrereqs sexecute the prerequisites
checks and report the results.
Frequently Asked Questions
Q: What does the dbaascli tde addSecondaryHsmKey command do?
A: The dbaascli tde addSecondaryHsmKey command adds a secondary HSM (KMS) key to the existing HSM (KMS) configuration for an Exadata Cloud@Customer database.
Q: Who should run the dbaascli tde addSecondaryHsmKey command?
A: The command must be run as the root user.
Q: On which machine should I run the dbaascli tde addSecondaryHsmKey command?
A: You need to connect to an Exadata Cloud@Customer virtual machine using SSH to run this command.
Q: Where can I find more details about connecting to a virtual machine to run this command?
A: You can refer to the guide "Connecting to a Virtual Machine with SSH" for instructions on how to connect.
Q: What does the --secondaryKmsKeyOCID option specify?
A: The --secondaryKmsKeyOCID option specifies the OCID (Oracle Cloud Identifier) of the secondary KMS key to be added to the existing HSM (KMS) configuration.
Q: What does the --dbname option do?
A: The --dbname option allows you to specify the name of the database for which the secondary KMS key should be added. It is optional.
Q: What does the --precheckOnly option do?
A: The --precheckOnly option, when set to yes, runs a precheck of the operation without making any actual changes. The valid values are yes or no.
Q: Can I run the precheck only without making changes?
A: Yes, you can use the --precheckOnly yes option to run just the precheck without making changes.
Q: Can you give an example of how to run this command to add a secondary HSM key?
A: Ensure that you are running the command as the root user and that you have connected to the correct Exadata Cloud@Customer virtual machine. Also, verify the OCID of the KMS key and check if the required permissions are granted.
Q: How can I check if I have the correct OCID for the secondary KMS key?
A: You can retrieve the OCID of the KMS key from the Oracle Cloud Infrastructure console, under the Key Management Service (KMS) section.
Q: What permissions are required to add a secondary KMS key?
A: You need appropriate permissions in Oracle Cloud Infrastructure for KMS operations, including the ability to manage KMS keys for the relevant compartment.
Q: Can I use the dbaascli tde addSecondaryHsmKey command without specifying the --dbname option?
A: Yes, the --dbname option is optional. If omitted, the command applies to all databases using the existing HSM (KMS) configuration.
Q: What happens if I add a secondary KMS key?
A: The secondary KMS key will be added to the existing configuration, providing an additional layer of encryption key management redundancy.
Q: Can I remove a secondary KMS key once it is added?
A: No, once a secondary KMS key is added, it cannot be removed. You can only rotate or update keys in the future.
--prepareStandbyBlob - specify true to generate a blob file
containing the artifacts needed to perform the operation in a DG
environment.
--blobLocation - custom path where the standby blob file
will be generated in a DG environment.
--standbyBlobFromPrimary - specify the location of the
standby blob file which is prepared from the primary database. This is
required only for standby operations.
--resume - to resume the previous execution
--sessionID - to resume a specific session id.
Frequently Asked Questions
Q: What does the dbaascli tde changePassword command do?
A: The dbaascli tde changePassword command changes the Transparent Data Encryption (TDE) keystore password as well as the database wallet password for the alias tde_ks_passwd.
Q: Who should run the dbaascli tde changePassword command?
A: The command must be run as the root user.
Q: When should I use the dbaascli tde changePassword command?
A: Use this command when you need to change the TDE keystore password or the DB wallet password for an Exadata Cloud@Customer database.
Q: What does the --dbname option do?
A: The --dbname option specifies the name of the database for which you want to change the TDE keystore password.
Q: What does the --pdbName option do?
A: The --pdbName option specifies the name of the pluggable database (PDB) for which the TDE keystore password needs to be changed. This option is used for multitenant databases.
Q: Can you give an example of how to run this command for a specific database?
A: Here’s an example to change the TDE keystore password for a specific database:
dbaascli tde changePassword --dbname mydatabase
Q: How do I run the command for a specific PDB within a multitenant database?
A: You can specify the PDB name using this syntax:
Q: What are the prerequisites for running the dbaascli tde changePassword command?
A: You must run the command as the root user and have access to the Exadata Cloud@Customer virtual machine where the database is running.
Q: Do I need to stop the database to change the TDE keystore password?
A: No, the database does not need to be stopped to change the TDE keystore password.
Q: What should I do if the command fails?
A: Ensure that you are running the command as the root user and that the database name (--dbname) and PDB name (--pdbName, if applicable) are correct.
Q: What if I get an "invalid password" error when changing the TDE keystore password?
A: Make sure the new password meets your system's password complexity requirements, and that you are entering the correct old password if prompted.
Q: How do I check if the TDE keystore password has been changed successfully?
A: You can check the database logs or use the Oracle Database Vault and Key Management views to verify that the TDE keystore password change was successful.
Q: Can I change the TDE keystore password for a multitenant database and all PDBs at once?
A: No, the dbaascli tde changePassword command needs to be run for each PDB individually if you need to change the password for multiple PDBs.
Q: What happens if I forget the new TDE keystore password?
A: If the new password is forgotten, you may need to restore the keystore from a backup or follow Oracle's recovery process to reset it, depending on your setup.
Q: Can I automate the process of changing the TDE keystore password?
A: While the dbaascli tde changePassword command itself is not designed for automation, you can script it as part of your regular database maintenance procedures if needed.
Q: How often should I change the TDE keystore password?
A: Oracle recommends periodically changing your TDE keystore password based on your organization's security policies. Best practices typically involve rotating encryption keys and keystore passwords regularly.
To change the TDE password in a
non-Data Guard
environment
dbaascli tde changepassword --dbname
<dbname>
To change the TDE password in a Data Guard environment
Change the TDE password in primary
database.
dbaascli tde changepassword --dbname
<dbname> --prepareStandbyBlob true --blobLocation
<Location where blob file has to be generated>
Copy the created standby blob to standby database environment.
Change the TDE password in standby
database
dbaascli tde changepassword --dbname
<dbname> --standbyBlobFromPrimary <Location of blob generated from
primary>
--dbname specifies the name of the Oracle
Database.
--dbrestart specifies the database restart
option. Valid values are: rolling or full.
Default value: rolling
If you do not pass
the dbrestart argument, then the database restarts in a
rolling manner.
--precheckOnly runs only the precheck for this
operation. Valid values are: yes or
no
--resume to resume the previous execution
--sessionID to resume a specific session id.
Frequently Asked Questions
Q: What does the dbaascli tde enableWalletRoot command do?
A: The dbaascli tde enableWalletRoot command enables the wallet_root parameter in the spfile for an existing Oracle database on Exadata Cloud@Customer.
Q: Who should run the dbaascli tde enableWalletRoot command?
A: The command must be run as the root user.
Q: On which machine should I run the dbaascli tde enableWalletRoot command?
A: You must connect to an Exadata Cloud@Customer virtual machine using SSH to run this command.
Q: Where can I find instructions to connect to the virtual machine?
A: You can refer to the guide "Connecting to a Virtual Machine with SSH" for instructions on connecting.
Q: What does the --dbRestart option do?
A: The --dbRestart option specifies how the database should be restarted after enabling wallet_root. The valid values are:
rolling: Restarts the database in a rolling manner (default behavior).
full: Performs a full database restart.
Q: What does the --dbname option do?
A: The --dbname option allows you to specify the name of the Oracle Database for which the wallet_root parameter should be enabled.
Q: What does the --precheckOnly option do?
A: The --precheckOnly option runs a precheck of the operation without making actual changes. The valid values are yes or no.
Q: What happens if I do not specify the --dbRestart option?
A: If you do not specify the --dbRestart option, the database will restart in a rolling manner by default.
Q: Can you give an example of how to enable wallet_root for a specific database?
A: Here’s an example to enable wallet_root for a database named mydatabase:
dbaascli tde enableWalletRoot --dbname mydatabase
Q: How do I enable wallet_root and specify a full database restart?
A: You can enable wallet_root with a full database restart using the following command:
dbaascli tde enableWalletRoot --dbname mydatabase --dbRestart full
Q: How do I run the command with a precheck only?
A: To perform a precheck without making changes, use the following syntax:
Q: What are the prerequisites for running the dbaascli tde enableWalletRoot command?
A: You must run the command as the root user and be connected to the correct Exadata Cloud@Customer virtual machine.
Q: Do I need to restart the database to enable wallet_root?
A: Yes, the database will need to restart either in a rolling manner (default) or fully, depending on the option you choose.
Q: What should I do if the command fails?
A: Ensure that you are running the command as the root user, and verify that the database name (--dbname) is correct. Check for any precheck errors if you are running with --precheckOnly.
Q: What if the database fails to restart after running the command?
A: Verify that the correct restart option was used (rolling or full) and check the database logs for any errors. You may need to manually restart the database if the automatic restart fails.
Q: How can I check if wallet_root was enabled successfully?
A: You can verify the change by checking the database’s spfile or using Oracle SQL queries to confirm that the wallet_root parameter is enabled.
Q: Can I enable wallet_root without restarting the database?
A: No, the database needs to restart for the change to take effect. You can choose between a rolling restart or a full restart.
Q: What is the difference between a rolling and full database restart?
A: A rolling restart restarts the database one instance at a time, allowing the database to remain partially available during the operation. A full restart shuts down and restarts the entire database, causing a complete downtime.
Q: Can I run this command for multiple databases simultaneously?
A: You need to run the dbaascli tde enableWalletRoot command separately for each database you wish to enable wallet_root on.
Q: How does enabling wallet_root affect the existing TDE keystore configuration?
A: Enabling wallet_root updates the TDE keystore location to the new wallet root directory, making it easier to manage multiple keystores and wallets in Oracle databases.
Example 7-44 dbaascli tde
enableWalletRoot
dbaascli tde enableWalletRoot --dbname db name --dbrestart rolling|full
dbaascli tde enableWalletRoot --dbname orcl
dbaascli tde enableWalletRoot --dbname orcl--dbrestart full
--pdbName specifies the name of the PDB to
encrypt all the tablespaces.
--dbname specifies the name of the Oracle
Database.
--executePrereqs execute the prerequisites
checks and report the results.
Frequently Asked Questions
Q: What does the dbaascli tde encryptTablespacesInPDB command do?
A: The dbaascli tde encryptTablespacesInPDB command encrypts all the tablespaces in the specified pluggable database (PDB) for an Oracle Database on Exadata Cloud@Customer.
Q: Who should run the dbaascli tde encryptTablespacesInPDB command?
A: The command must be run as the root user.
Q: On which machine should I run the dbaascli tde encryptTablespacesInPDB command?
A: You need to connect to an Exadata Cloud@Customer virtual machine using SSH to run this command.
Q: Where can I find instructions for connecting to the virtual machine?
A: Refer to the guide "Connecting to a Virtual Machine with SSH" for connection instructions.
Q: What does the --pdbName option specify?
A: The --pdbName option specifies the name of the pluggable database (PDB) whose tablespaces need to be encrypted.
Q: What does the --dbname option do?
A: The --dbname option allows you to specify the name of the Oracle Database to which the PDB belongs.
Q: What does the --precheckOnly option do?
A: The --precheckOnly option runs a precheck of the encryption operation without making any actual changes. Valid values are yes or no.
Q: What does the --useSysdbaCredential option do?
A: The --useSysdbaCredential option specifies whether SYSDBA credentials should be used for the operation. Valid values are true or false.
Q: Can you give an example of how to encrypt tablespaces in a specific PDB?
A: Here’s an example to encrypt all tablespaces in a PDB named mypdb:
Q: What are the prerequisites for running the dbaascli tde encryptTablespacesInPDB command?
A: You must run the command as the root user and have access to the Exadata Cloud@Customer virtual machine.
Q: Do I need to restart the database to encrypt the tablespaces?
A: No, the command does not require a database restart. The encryption is performed while the database is online.
Q: Do I need SYSDBA credentials to encrypt tablespaces?
A: You may need SYSDBA credentials for this operation if specified using the --useSysdbaCredential option.
Q: What should I do if the command fails?
A: Ensure you are running the command as the root user, and verify that the PDB name (--pdbName) and database name (--dbname) are correct. You can also run the command with --precheckOnly yes to check for issues before running the full encryption.
Q: What should I do if encryption of the tablespaces fails?
A: Check the database logs and ensure that you have the necessary privileges and resources to perform the encryption. You may also need to verify that there is enough space to handle the encryption process.
Q: How can I check if the tablespaces in a PDB are encrypted?
A: You can query the database views related to encryption, such as V$ENCRYPTED_TABLESPACES, to verify if the tablespaces have been successfully encrypted.
Q: How do I verify if the precheck was successful?
A: If you ran the command with --precheckOnly yes, you can check the output for any warnings or errors indicating potential issues with the encryption process.
Q: Can I encrypt the tablespaces for multiple PDBs simultaneously?
A: No, you need to run the dbaascli tde encryptTablespacesInPDB command separately for each PDB.
Q: Can I partially encrypt some tablespaces in a PDB?
A: No, this command encrypts all tablespaces within the specified PDB. For partial encryption, you would need to use different database management commands.
Q: Does encrypting tablespaces impact database performance?
A: Encrypting tablespaces can have a temporary performance impact during the encryption process. However, the impact should be minimal once the encryption is complete.
Q: Can I undo the encryption of tablespaces?
A: No, once the tablespaces are encrypted, the encryption cannot be undone. You can only rotate or re-encrypt the keys as needed.
Q: What happens if the operation is interrupted during the encryption process?
A: If the operation is interrupted, you may need to rerun the command. The system will resume encryption from where it left off, and you can verify the status using database views.
--kmsKeyOCID specifies the KMS key OCID to use
for TDE. This is applicable only if KMS is selected for TDE
--dbname specifies the name of the
database
--skipPatchCheck skips validation check for
required patches if the value passed for this argument is
true. Valid values: true or
false
--executePrereqs sexecute the prerequisites
checks and report the results.
--primarySuc specify this property in the
standby database of the Data Guard environment once the command is
successfully run on the primary database
--resume specifies to resume the previous
run
--sessionID specifies to resume a specific session
ID
--revert specifies to rollback the previous
run
--sessionID specifies to rollback a specific
session ID
--waitForCompletion specify false to run the operation in
background. Valid values : true|false.
Frequently Asked Questions
Q: What is the purpose of the dbaascli tde fileToHsm command?
A: The dbaascli tde fileToHsm command is used to convert a FILE-based Transparent Data Encryption (TDE) to Hardware Security Module (HSM)-based TDE, such as KMS or OKV, in an Oracle Database Cloud Service environment.
Q: Who can run the dbaascli tde fileToHsm command?
A: The command must be run as the root user.
Q: What is the purpose of the --kmsKeyOCID parameter?
A: The --kmsKeyOCID parameter specifies the KMS key OCID that will be used for TDE encryption when transitioning from file-based to HSM-based TDE.
Q: What does the --dbname parameter do?
A: The --dbname parameter specifies the name of the database for which you are converting the TDE from file-based to HSM-based.
Q: Can I skip the patch validation check while converting TDE?
A: Yes, by using the --skipPatchCheck parameter with the value true, you can skip the validation check for required patches.
Q: What is the --executePrereqs parameter used for?
A: The --executePrereqs parameter allows you to run only the prechecks for the TDE conversion process without performing the actual conversion. Valid values are yes or no.
Q: What does the --primarySuc parameter do in a Data Guard setup?
A: The --primarySuc parameter is used in a Data Guard environment to indicate that the command has been successfully run on the primary database. It should be specified on the standby database after the primary conversion is complete.
Q: How do I resume a previous TDE conversion?
A: You can resume a previously incomplete TDE conversion by using the --resume parameter. Optionally, you can specify a specific session ID with --sessionID.
Q: How do I revert a TDE conversion?
A: To revert a previous TDE conversion, use the --revert parameter. You can also provide the specific session ID you want to revert using --sessionID.
Q: How do I specify a session ID when resuming or reverting a TDE conversion?
A: You can use the --sessionID parameter to specify the ID of the session you want to resume or revert. Example: --resume --sessionID <ID> or --revert --sessionID <ID>.
Q: What happens if I set --waitForCompletion to false?
A: If you set --waitForCompletion to false, the TDE conversion process will run in the background, and the command prompt will return immediately. If set to true, the command will wait for the process to finish before returning control to the user.
Q: What are the valid values for the --waitForCompletion parameter?
A: Valid values are true or false. Setting it to true makes the command wait until the process is complete; setting it to false runs the process in the background.
Q: Can I run dbaascli tde fileToHsm without converting the TDE immediately?
A: Yes, you can use the --executePrereqs yes parameter to perform only the prechecks for the conversion, without making any changes to the TDE.
Q: In a Data Guard environment, how do I handle the standby database after converting TDE on the primary?
A: After successfully running the conversion on the primary database, you need to specify --primarySuc when running the command on the standby database.
Q: What should I do if the TDE conversion process fails?
A: If the process fails, you can use the --resume parameter to try resuming from where it left off. If necessary, you can use the --revert parameter to roll back the changes made during the failed session.
To get TDE active key details, use the dbaascli tde
getHsmKeys command.
Prerequisite
Run the command as the root user.
Syntax
dbaascli tde getHsmKeys
[--dbname]
[--infoFile]
Where:
--dbname specifies the name of the database
--infoFile specifies the file path where the list of OCIDs
will be saved. The output is in JSON format
Frequently Asked Questions
Q: What does the dbaascli tde getHsmKeys command do?
A: The dbaascli tde getHsmKeys command retrieves details of active Transparent Data Encryption (TDE) keys from the Hardware Security Module (HSM) for a specified database.
Q: Who should run the dbaascli tde getHsmKeys command?
A: The command must be run as the root user.
Q: On which machine should I run the dbaascli tde getHsmKeys command?
A: You must connect to an Exadata Cloud@Customer virtual machine using SSH to run this command.
Q: Where can I find instructions for connecting to the virtual machine?
A: Refer to the guide "Connecting to a Virtual Machine with SSH" for instructions on connecting.
Q: What does the --dbname option do?
A: The --dbname option allows you to specify the name of the Oracle Database for which you want to retrieve TDE key details.
Q: What does the --infoFile option do?
A: The --infoFile option specifies the file path where the list of key OCIDs (Oracle Cloud Identifiers) will be saved. The output is in JSON format.
Q: Can you give an example of how to retrieve TDE key details for a specific database?
A: Here’s an example to get the TDE key details for a database named mydatabase:
dbaascli tde getHsmKeys --dbname mydatabase
Q: How do I save the TDE key details to a file?
A: You can specify a file path using the --infoFile option to save the output in JSON format:
Q: What are the prerequisites for running the dbaascli tde getHsmKeys command?
A: You must run the command as the root user and be connected to the Exadata Cloud@Customer virtual machine.
Q: Do I need SYSDBA credentials to retrieve TDE key details?
A: No, SYSDBA credentials are not required to run the dbaascli tde getHsmKeys command.
Q: In what format is the TDE key information saved when using the --infoFile option?
A: The output is saved in JSON format.
Q: What information is included in the TDE key details?
A: The details include key OCIDs and other metadata about the active encryption keys stored in the HSM for the specified database.
Q: What should I do if the command fails to retrieve the key details?
A: Ensure that you are running the command as the root user and that the database name (--dbname) is correct. Check your connection to the Exadata Cloud@Customer virtual machine.
Q: How do I check if the output file was created successfully?
A: You can check the specified file path for the output JSON file. If the file is missing, verify that the file path is correct and that you have write permissions to the directory.
Q: What should I do if the output file is empty?
A: Ensure that the database specified contains active TDE keys and that the --dbname parameter is correct. You may also need to check if there are any errors in the database logs.
Q: Can I retrieve TDE key details for multiple databases at once?
A: No, you must run the dbaascli tde getHsmKeys command separately for each database.
Q: How can I use the output file from the --infoFile option in other operations?
A: Since the output is in JSON format, you can parse the file programmatically or use it as input for other database or encryption management tasks.
Q: Can I get historical TDE key details using this command?
A: No, the command only retrieves details about the currently active keys in the HSM.
Q: How do I verify that the keys retrieved are correct?
A: You can verify the keys by cross-referencing them with the Oracle Cloud Infrastructure (OCI) console or using database views related to encryption management.
--kmsKeyVersionOCID specifies the KMS key version OCID to
set
--dbname specifies the name of the database
--waitForCompletion specify false to run
the operation in background. Valid values :
true|false.
Frequently Asked Questions
Q: What is the purpose of the dbaascli tde getMkidForKeyVersionOCID command?
A: The dbaascli tde getMkidForKeyVersionOCID command retrieves the Master Key ID (MKID) associated with a specific KMS key version OCID in Oracle Database Cloud Service environments.
Q: What are the prerequisites for running the dbaascli tde getMkidForKeyVersionOCID command?
A: You must:
Run the command as the root user.
Be connected to an Exadata Cloud@Customer virtual machine via SSH.
Q: Who can run the dbaascli tde getMkidForKeyVersionOCID command?
A: Only the root user can run this command.
Q: What does the --kmsKeyVersionOCID parameter specify?
A: The --kmsKeyVersionOCID parameter specifies the KMS key version OCID for which you want to retrieve the associated Master Key ID (MKID).
Q: What does the --dbname parameter specify?
A: The --dbname parameter specifies the name of the database for which the KMS key version OCID is being queried.
Q: Is the --dbname parameter mandatory?
A: No, the --dbname parameter is optional. If you don’t specify a database name, the command will retrieve the MKID for the default database on the system.
Q: What should I do if I don’t know the KMS key version OCID?
A: You must retrieve the KMS key version OCID from your KMS management console or service provider before using this command. Without it, the command cannot retrieve the Master Key ID (MKID).
Q: Can I run this command on a non-Exadata Cloud@Customer environment?
A: No, this command is specifically for use in an Exadata Cloud@Customer environment, and you need to connect to a virtual machine using SSH to execute it.
Q: What happens if I run the command without specifying a database name using --dbname?
A: If the --dbname parameter is not provided, the command will attempt to retrieve the MKID for the default database configured on the system.
Q: What should I do if I encounter an error while retrieving the MKID?
A: Ensure that:
You are running the command as the root user.
You are correctly connected to the Exadata Cloud@Customer virtual machine.
The KMS key version OCID you provided is valid. If the error persists, check the system logs for more details.
Q: How do I connect to the Exadata Cloud@Customer virtual machine?
A: You can connect to the virtual machine via SSH. Refer to the Exadata Cloud@Customer documentation for steps on how to securely connect.
Example 7-48 dbaascli tde
getMkidForKeyVersionOCID
To get primary HSM (KMS) key from the existing HSM (KMS) configuration,
use the dbaascli tde getPrimaryHsmKey command.
Prerequisite
Run the command as the root user.
Syntax
dbaascli tde getPrimaryHsmKey
[--dbname]
Where:
--dbname specifies the name of the database
Frequently Asked Questions
Q: What is the purpose of the dbaascli tde getPrimaryHsmKey command?
A: The dbaascli tde getPrimaryHsmKey command retrieves the primary Hardware Security Module (HSM) key from the existing HSM (KMS) configuration in an Oracle Database environment.
Q: What are the prerequisites for running the dbaascli tde getPrimaryHsmKey command?
A: You must:
Run the command as the root user.
Be connected to an Exadata Cloud@Customer virtual machine via SSH.
Q: Who can execute the dbaascli tde getPrimaryHsmKey command?
A: Only the root user can execute this command.
Q: What does the --dbname parameter specify in this command?
A: The --dbname parameter specifies the name of the database for which you want to retrieve the primary HSM key.
Q: Is the --dbname parameter mandatory?
A: No, the --dbname parameter is optional. If not provided, the command will retrieve the primary HSM key for the default database on the system.
Q: What should I do if I don’t specify a database name with --dbname?
A: If the --dbname parameter is not specified, the command will attempt to retrieve the primary HSM key for the default database configured on the system.
Q: Can I run this command on a non-Exadata Cloud@Customer environment?
A: No, this command is designed specifically for use in an Exadata Cloud@Customer environment, and you must be connected to the virtual machine using SSH to run it.
Q: How do I connect to the Exadata Cloud@Customer virtual machine to run the command?
A: You can connect to the virtual machine via SSH. Refer to the Exadata Cloud@Customer documentation for instructions on how to securely connect.
Q: What should I check if I encounter an error while retrieving the primary HSM key?
A: If you encounter an error, ensure that:
You are running the command as the root user.
You are correctly connected to the Exadata Cloud@Customer virtual machine.
The database name (if specified) is valid. If the issue persists, consult system logs or error messages for more details.
Q: Do I need to stop the database to run the dbaascli tde getPrimaryHsmKey command?
A: No, the database does not need to be stopped to run this command. You can execute it while the database is running.
Q: What is the purpose of retrieving the primary HSM key?
A: Retrieving the primary HSM key allows you to identify the current HSM key that is being used for encryption in the database’s existing HSM (KMS) configuration.
--prepareStandbyBlob specify
true to generate a blob file containing the artifacts
needed to perform the operation in a DG environment.
--blobLocation custom directory location where the standby
blob file will be generated in a DG environment.
--standbyBlobFromPrimary specify the location
of the standby blob file which is prepared from the primary database. This
is required only for standby operations. ]
--skipPatchCheck skips validation check for
required patches if the value passed for this argument is
true. Valid values: true or
false
--executePrereqs execute the prerequisites
checks and report the results.
--primarySuc specify this property in the
standby database of the Data Guard environment once the command is
successfully run on the primary database
--resume resumes the previous run
--sessionID specifies to resume a specific session
ID
--revert specifies to roll back the previous
run
--sessionID specifies to rollback a specific
session ID
--waitForCompletion specifies false to run
the operation in background. Valid values:
true|false
Frequently Asked Questions
Q: What is the purpose of the dbaascli tde hsmToFile command?
A: The dbaascli tde hsmToFile command is used to convert a Hardware Security Module (HSM)-based Transparent Data Encryption (TDE) to a file-based TDE in Oracle Database Cloud Service environments.
Q: What are the prerequisites for running the dbaascli tde hsmToFile command?
A: You must:
Run the command as the root user.
Ensure you have the necessary permissions and configurations set in the database environment.
Q: What does the --dbname parameter specify?
A: The --dbname parameter specifies the name of the database for which you are converting TDE from HSM-based to file-based.
Q: When is the --primaryDBWalletTar parameter required?
A: The --primaryDBWalletTar parameter is required only when performing the hsmToFile conversion on a standby database. It specifies the tar file of the primary database’s wallet.
Q: What is the purpose of the --skipPatchCheck parameter?
A: The --skipPatchCheck parameter allows you to skip the validation check for required patches. Set this to true to skip the check or false to enforce it.
Q: How do I run only prechecks for the conversion process without performing the actual conversion?
A: You can use the --executePrereqs parameter and set it to yes to run only the prechecks. Set it to no to perform the full conversion.
Q: What does the --primarySuc parameter do in a Data Guard environment?
A: The --primarySuc parameter is used in a Data Guard setup to indicate that the conversion has successfully run on the primary database. It should be used when running the conversion on the standby database.
Q: How can I resume a previous hsmToFile conversion?
A: You can resume a previous conversion by using the --resume parameter. Optionally, you can specify the session ID of the previous run with --sessionID.
Q: What is the purpose of the --revert parameter?
A: The --revert parameter is used to roll back a previously initiated conversion process in case of failure or if you need to undo the operation.
Q: What happens if I set --waitForCompletion to false?
A: If you set --waitForCompletion to false, the operation will run in the background, allowing you to continue other tasks. If set to true, the command will wait for the process to complete before returning control to the user.
Q: What should I do if I need to convert the TDE in a standby database in a Data Guard setup?
A: In a Data Guard setup, after converting TDE on the primary database, you must run the command on the standby database using the --primaryDBWalletTar parameter, specifying the wallet tar file from the primary database, and include --primarySuc.
Q: What should I do if I want to skip checking for required patches during the conversion?
A: You can skip the patch check by using the --skipPatchCheck parameter and setting it to true.
Q: How do I check if the system is ready for the hsmToFile conversion without making changes?
A: You can perform only the prechecks by using the --executePrereqs parameter and setting it to yes.
Q: What should I do if the conversion process is interrupted?
A: You can use the --resume parameter to restart the process from where it left off. Optionally, you can specify a particular session ID with --sessionID.
Q: What should I do if the conversion process fails?
A: If the conversion fails, you can roll back the process using the --revert parameter. Additionally, review any error messages and check system logs for more details.
Q: Can I run the dbaascli tde hsmToFile command on a non-Exadata environment?
A: This command is designed for use in Exadata Cloud@Customer environments. If you are not using Exadata, ensure that you are in a supported environment for the command to work properly.
--infoFilePath specify the absolute path of the file where
the results will be saved.
Frequently Asked Questions
Q: What is the purpose of the dbaascli tde listKeys command?
A: The dbaascli tde listKeys command is used to list all the Transparent Data Encryption (TDE) master keys for a specified database in an Oracle Database environment.
Q: What are the prerequisites for running the dbaascli tde listKeys command?
A: You must:
Run the command as the root user.
Be connected to an Exadata Cloud@Customer virtual machine using SSH.
Q: What does the --file parameter do in the dbaascli tde listKeys command?
A: The --file parameter specifies the file path where the list of TDE master keys should be saved. If this parameter is not provided, the results will be displayed directly in the terminal.
Q: What does the --dbname parameter specify?
A: The --dbname parameter specifies the name of the database for which you want to list the TDE master keys.
Q: Is the --file parameter mandatory?
A: No, the --file parameter is optional. If not provided, the list of TDE keys will be shown in the terminal output instead of being saved to a file.
Q: Is the --dbname parameter mandatory?
A: No, the --dbname parameter is optional. If not specified, the command will list the TDE master keys for the default database configured on the system.
Q: What should I do if I want to save the list of keys to a file?
A: You should provide the --file parameter along with the desired file path. For example:
dbaascli tde listKeys --file /path/to/output.txt
Q: What happens if I don’t provide a database name with --dbname?
A: If the --dbname parameter is not provided, the command will list the TDE master keys for the default database on the system.
Q: Can I use this command in environments other than Exadata Cloud@Customer?
A: This command is designed specifically for Exadata Cloud@Customer environments. Ensure you are connected to the appropriate virtual machine to run it.
Q: What should I do if the command fails to list keys?
A: Ensure that:
You are running the command as the root user.
You are connected to the Exadata Cloud@Customer virtual machine.
The database name (if specified) is correct. Check the error messages and logs for more details on the failure.
Q: Can I run the dbaascli tde listKeys command while the database is running?
A: Yes, the command can be executed while the database is running. It simply lists the TDE master keys and does not alter the state of the database.
Q: Do I need special permissions to run this command?
A: You must run this command as the root user. Without root permissions, you will not be able to execute the command.
Q: What is the purpose of listing TDE master keys?
A: Listing TDE master keys allows you to review the encryption keys being used for protecting your database’s data. It is essential for monitoring and managing encryption settings.
Q: How do I connect to the Exadata Cloud@Customer virtual machine to run the command?
A: You can connect to the virtual machine using SSH. Refer to the Exadata Cloud@Customer documentation for instructions on how to establish a secure connection.
--confirmDeletion if not specified the user will be
prompted while deleting all existing HSM(KMS) keys.
--secondaryKmsKeyOCID secondary KMS key to be
removed from existing HSM(KMS) configuration. If not specified all secondary
KMS keys will be removed.
--executePrereqs execute the prerequisites checks and
report the results.
Frequently Asked Questions
Q: What is the purpose of the dbaascli tde removeSecondaryHsmKey command?
A: The dbaascli tde removeSecondaryHsmKey command is used to remove a secondary Hardware Security Module (HSM) key from the existing HSM (KMS) configuration in an Oracle Database environment.
Q: What are the prerequisites for running the dbaascli tde removeSecondaryHsmKey command?
A: You must:
Run the command as the root user.
Be connected to an Exadata Cloud@Customer virtual machine using SSH.
Q: What does the --force parameter do in the dbaascli tde removeSecondaryHsmKey command?
A: The --force parameter allows the removal of the secondary HSM key without prompting the user for confirmation. If not specified, the command will prompt the user before deleting any keys.
Q: What does the --secondaryKmsKeyOCID parameter specify?
A: The --secondaryKmsKeyOCID parameter specifies the OCID (Oracle Cloud Identifier) of the secondary KMS key you want to remove from the existing HSM configuration.
Q: What does the --dbname parameter do?
A: The --dbname parameter specifies the name of the database for which the secondary HSM key is being removed.
Q: What is the purpose of the --precheckOnly parameter?
A: The --precheckOnly parameter, if set to yes, will only run the prechecks to validate the readiness for the removal operation without actually removing the secondary HSM key. If set to no, the full removal operation is performed.
Q: Is the --force parameter mandatory?
A: No, the --force parameter is optional. If it’s not specified, the system will prompt the user for confirmation before proceeding with the key removal.
Q: Is the --secondaryKmsKeyOCID parameter mandatory?
A: Yes, you must provide the --secondaryKmsKeyOCID to identify the specific secondary HSM key that you want to remove from the configuration.
Q: Is the --dbname parameter mandatory?
A: No, the --dbname parameter is optional. If not specified, the command will attempt to remove the secondary HSM key from the default database on the system.
Q: What should I do if I want to remove the secondary HSM key without any user prompts?
A: You should use the --force parameter to bypass the confirmation prompt and remove the secondary HSM key directly:
Q: What happens if I don’t provide a database name with --dbname?
A: If the --dbname parameter is not specified, the command will attempt to remove the secondary HSM key from the default database configured on the system.
Q: What should I check if the command fails to remove the secondary HSM key?
A: Ensure that:
You are running the command as the root user.
You are connected to the Exadata Cloud@Customer virtual machine.
The correct --secondaryKmsKeyOCID and --dbname values are provided. Check the error messages and logs for more details on the failure.
Q: What should I do if the removal operation fails partway through?
A: If the operation fails, review the error logs and try running the command with --precheckOnly to ensure the system is ready for the operation. If necessary, correct any issues before retrying.
Q: Can I run the dbaascli tde removeSecondaryHsmKey command while the database is running?
A: Yes, the command can be executed while the database is running, as it does not require the database to be stopped.
Q: What is the purpose of removing a secondary HSM key?
A: Removing a secondary HSM key is typically done when the key is no longer needed or when you want to manage the encryption keys used in your TDE (Transparent Data Encryption) configuration.
Q: How do I connect to the Exadata Cloud@Customer virtual machine to run the command?
A: You can connect to the virtual machine using SSH. Refer to the Exadata Cloud@Customer documentation for instructions on establishing a secure connection.
--dbname specifies the name of the Oracle
Database
--rotateMasterKeyOnAllPDBs specifies
true to rotate master key of all PDBs in CDB. Valid
values: true|false
--pdbName specifies the name of the PDB
--executePrereqs runs the prerequisites checks
and report the results
--resume specifes to resume the previous
execution
--sessionID specifies to resume a specific session ID
--prepareStandbyBlob specifies true to
generate a BLOB file containing the artifacts needed to perform the
operation in a Data Guard environment
--blobLocation specifies the location of the custom
directory where the standby BLOB file will be generated in a Data Guard
environment
--standbyBlobFromPrimary specifies the location
of the standby BLOB file, which is prepared from the primary database. This
is required only for standby operations.
Frequently Asked Questions
Q: What is the purpose of the dbaascli tde rotateMasterKey command?
A: The dbaascli tde rotateMasterKey command is used to rotate the master key used for Transparent Data Encryption (TDE) in an Oracle Database. This process ensures the encryption keys are updated for better security.
Q: What are the prerequisites for running the dbaascli tde rotateMasterKey command?
A: You must:
Run the command as the root user.
Ensure that the database is configured correctly for TDE.
Q: What does the --dbname parameter specify?
A: The --dbname parameter specifies the name of the Oracle Database for which you want to rotate the master encryption key.
Q: What is the purpose of the --rotateMasterKeyOnAllPDBs parameter?
A: The --rotateMasterKeyOnAllPDBs parameter specifies whether to rotate the master key for all Pluggable Databases (PDBs) in a Container Database (CDB). Valid values are true or false.
Q: What does the --pdbName parameter do?
A: The --pdbName parameter specifies the name of a particular Pluggable Database (PDB) if you want to rotate the master key for a specific PDB rather than all PDBs.
Q: What does the --executePrereqs parameter do?
A: The --executePrereqs parameter runs prerequisite checks to validate whether the environment is ready for the master key rotation without performing the actual rotation.
Q: What does the --resume parameter specify?
A: The --resume parameter is used to resume a previously started operation. You can also provide a specific session ID using --sessionID to resume a particular session.
Q: What is the purpose of the --prepareStandbyBlob parameter?
A: The --prepareStandbyBlob parameter, if set to true, generates a BLOB file containing the necessary artifacts to perform master key rotation in a Data Guard environment.
Q: What does the --blobLocation parameter do?
A: The --blobLocation parameter specifies a custom directory path where the standby BLOB file will be generated. This is applicable when --prepareStandbyBlob is set to true.
Q: What does the --standbyBlobFromPrimary parameter specify?
A: The --standbyBlobFromPrimary parameter specifies the location of the standby BLOB file that was generated from the primary database. This parameter is used when performing the master key rotation on a standby database in a Data Guard environment.
Q: Is the --rotateMasterKeyOnAllPDBs parameter mandatory?
A: No, the --rotateMasterKeyOnAllPDBs parameter is optional. If it is not specified, the master key will only be rotated for the database (or specific PDB) provided in the --dbname or --pdbName parameters.
Q: Is the --pdbName parameter required if I'm rotating keys for a CDB?
A: No, the --pdbName parameter is only required if you want to rotate the master key for a specific Pluggable Database (PDB). It is optional when rotating the key for the entire CDB.
Q: Do I need to use the --prepareStandbyBlob and --standbyBlobFromPrimary parameters for standalone databases?
A: No, these parameters are only relevant in a Data Guard environment where a standby database is involved.
Q: How can I rotate the master key for all PDBs in a CDB?
A: You should use the --rotateMasterKeyOnAllPDBs parameter set to true to rotate the master key for all PDBs in the CDB. For example:
Q: What should I do if the operation was interrupted, and I want to resume it?
A: You can use the --resume parameter to resume the previously interrupted operation. If you have a session ID, provide it with the --sessionID parameter:
Q: How can I prepare for key rotation in a Data Guard environment?
A: You should use the --prepareStandbyBlob parameter to generate a BLOB file that contains the required artifacts for rotating the master key in a standby environment:
Q: What should I check if the master key rotation fails?
A: Ensure that:
You are running the command as the root user.
The database name (--dbname) is correct.
Any prerequisite checks were run using --executePrereqs to ensure readiness. Review the error logs for more detailed information on the failure.
Q: What should I do if the operation does not complete successfully in a Data Guard environment?
A: Ensure that the BLOB file from the primary database was prepared correctly using --prepareStandbyBlob, and then use --standbyBlobFromPrimary to apply it on the standby database.
Q: Can I run the dbaascli tde rotateMasterKey command while the database is running?
A: Yes, the command can be executed while the database is running. However, it is recommended to run prerequisite checks beforehand using the --executePrereqs option.
Q: Why is rotating the master key important?
A: Rotating the master key improves database security by ensuring that the encryption keys used for data protection are periodically updated, reducing the risk of key compromise.
Q: Do I need to restart the database after rotating the master key?
A: No, restarting the database is not required after rotating the master key. The key rotation will take effect immediately without any service disruption.
--kmsKeyVersionOCID specifies the KMS key version OCID to
set.
--dbname specifies the name of the
database.
--pdbName name of the PDB to use the key version OCID.
--masterKeyID specifies the master key ID of the given key
version OCID. This is applicable to the Data Guard environment.
--standbySuc specify this property in the
primary database of the Data Guard environment once the command is
successfully run on the standby database
--executePrereqs execute the prerequisites
checks and report the results.
--waitForCompletion specify
false to run the operation in background. Valid values:
true|false
Frequently Asked Questions
Q: What is the purpose of the dbaascli tde setKeyVersion command?
A: The dbaascli tde setKeyVersion command is used to set the version of the primary encryption key that should be used for Transparent Data Encryption (TDE) in a database or Pluggable Database (PDB). This allows for the specific version of a KMS key to be assigned to the database.
Q: What are the prerequisites for using the dbaascli tde setKeyVersion command?
A: You must run the command as the root user and ensure that you are connected to an Exadata Cloud@Customer virtual machine.
Q: What does the --kmsKeyVersionOCID parameter specify?
A: The --kmsKeyVersionOCID parameter specifies the KMS key version OCID (Oracle Cloud Identifier) that you want to set for the database or PDB.
Q: What does the --dbname parameter specify?
A: The --dbname parameter specifies the name of the Oracle Database for which the key version will be set.
Q: What is the purpose of the --pdbName parameter?
A: The --pdbName parameter specifies the name of the Pluggable Database (PDB) within a Container Database (CDB) where you want to set the specific KMS key version.
Q: What is the --masterKeyID parameter used for?
A: The --masterKeyID parameter specifies the master key ID that is associated with the given KMS key version OCID. This is particularly important in a Data Guard environment.
Q: What is the role of the --standbySuc parameter?
A: The --standbySuc parameter is used in a Data Guard environment. It specifies that this property should be set on the primary database after successfully running the command on the standby database.
Q: What does the --executePrereqs parameter do?
A: The --executePrereqs parameter specifies whether to run prerequisite checks before executing the operation. Valid values are yes or no.
Q: What does the --waitForCompletion parameter control?
A: The --waitForCompletion parameter determines whether the operation will run synchronously (waiting for completion) or asynchronously (in the background). Valid values are true or false.
Q: Is the --pdbName parameter required if setting the key version for a CDB?
A: No, the --pdbName parameter is only required if you are setting the key version for a specific Pluggable Database (PDB). It is optional if you are setting the key version for the entire Container Database (CDB).
Q: Is the --masterKeyID parameter necessary for non-Data Guard environments?
A: No, the --masterKeyID parameter is typically only used in Data Guard environments. For standalone databases, this parameter is not required.
Q: How do I set the key version for a database?
A: You can set the key version for a database by running:
Q: What should I do if the key version fails to set?
A: Ensure that:
You are running the command as the root user.
The KMS key version OCID is correct.
Any prerequisite checks were run using --executePrereqs to ensure readiness. Review error logs for specific details and rerun the operation if needed.
Q: What should I check if the operation doesn't complete successfully in a Data Guard environment?
A: Ensure that the --masterKeyID parameter is correctly specified when running the command on the standby database. Once completed on the standby, the --standbySuc parameter should be used when running the command on the primary database.
Q: Can I run the dbaascli tde setKeyVersion command while the database is running?
A: Yes, the command can be executed while the database is running. However, running the prerequisite checks beforehand using --executePrereqs is recommended.
Q: Why is it important to set the correct KMS key version for a database?
A: Setting the correct KMS key version ensures that the database is using the appropriate encryption key version for TDE, which helps maintain data security and compliance with organizational policies.
Q: What happens if I use the wrong KMS key version OCID?
A: If an incorrect KMS key version OCID is used, the encryption may fail, and the database will not be able to use the incorrect key for encryption operations. You should ensure that the correct key version OCID is provided.
Q: Do I need to restart the database after setting the key version?
A: No, restarting the database is not necessary after setting the key version. The new key version will take effect immediately without requiring a restart.
--primaryKmsKeyOCID specifies the primary KMS key to
set
--dbname specifies the name of the
database
--allStandbyPrepared specify to confirm that
the operation has been successfully run on all the standby databases.
--bounceDatabase specify this flag to do
rolling database bounce for this operation
--executePrereqs execute the prerequisites
checks and report the results.
--resume to resume the previous execution
--sessionID to resume a specific session id.
Frequently Asked Questions
Q: What is the purpose of the dbaascli tde setPrimaryHsmKey command?
A: The dbaascli tde setPrimaryHsmKey command is used to change the primary HSM (Hardware Security Module) or KMS (Key Management Service) key in an existing HSM/KMS configuration for Transparent Data Encryption (TDE).
Q: What are the prerequisites for running the dbaascli tde setPrimaryHsmKey command?
A: The command must be executed as the root user, and the environment should be an Exadata Cloud@Customer virtual machine.
Q: What does the --primaryKmsKeyOCID parameter specify?
A: The --primaryKmsKeyOCID parameter specifies the OCID (Oracle Cloud Identifier) of the primary KMS key to be set for the TDE environment.
Q: What is the function of the --dbname parameter?
A: The --dbname parameter specifies the name of the Oracle Database for which the primary HSM/KMS key will be set.
Q: What does the --standbySuc parameter do?
A: The --standbySuc parameter is used in a Data Guard environment. It specifies that the command should be run on the primary database after successfully executing it on the standby database.
Q: What is the purpose of the --precheckOnly parameter?
A: The --precheckOnly parameter allows you to run only the prechecks for this operation. It validates the environment without making any actual changes. Valid values are yes or no.
Q: What does the --bounceDatabase parameter control?
A: The --bounceDatabase parameter specifies whether the database should be bounced (restarted) in a rolling manner as part of the operation. This ensures minimal downtime by restarting parts of the database one by one.
Q: How do I set the primary KMS key for my database?
A: To set the primary KMS key, run the following command:
Q: Is the --dbname parameter required for all databases?
A: Yes, you should specify the --dbname parameter to indicate the target database for which the primary KMS key should be set.
Q: Is it mandatory to use the --standbySuc parameter in a Data Guard environment?
A: Yes, the --standbySuc parameter must be used when running the command on the primary database after successfully executing it on the standby database.
Q: Can I skip the bounce operation for the database?
A: Yes, if you do not specify the --bounceDatabase parameter, the database will not be bounced (restarted) as part of the operation.
Q: What should I do if the command fails during execution?
A: If the command fails, ensure:
You are running it as the root user.
The correct --primaryKmsKeyOCID and --dbname values are provided.
The environment passes all prerequisite checks (run with --precheckOnly).
Q: What if the operation fails in a Data Guard environment?
A: Ensure that the command has been successfully executed on the standby database before running it on the primary. Check for errors in the logs and rerun the operation with correct parameters.
Q: Can I run the dbaascli tde setPrimaryHsmKey command on a live database?
A: Yes, the command can be run while the database is live. However, using the --bounceDatabase parameter will restart the database in a rolling fashion, which minimizes the impact.
Q: How do I run the command in a rolling manner to avoid complete downtime?
A: Use the --bounceDatabase parameter to perform a rolling restart of the database while changing the primary KMS key:
Q: What is the significance of changing the primary KMS key?
A: Changing the primary KMS key ensures that the database uses an updated or different encryption key for Transparent Data Encryption (TDE). This may be required for security or compliance reasons.
Q: How often should the primary KMS key be rotated or changed?
A: While there is no strict rule, organizations may rotate the primary KMS key based on security policies, such as key rotation intervals or compliance requirements.
Q: What happens if the primary KMS key is set incorrectly?
A: If the incorrect key OCID is set, database encryption operations may fail, and you may need to revert to the correct key or rectify the configuration by setting the correct KMS key OCID.
Q: Do I need to restart the database after changing the primary KMS key?
A: No, you do not need to restart the database unless you choose to use the --bounceDatabase parameter, which will automatically restart the database to apply the change.
To display information about the keystore for the specified database,
use the dbaascli tde status command.
Prerequisite
Run the command as the oracle user.
Syntax
dbaascli tde status --dbname dbname
Where:
--dbname specifies the name of the database that you want
to check.
Output from the command includes the type of keystore, and the status of
the keystore.
Frequently Asked Questions
Q: What does the dbaascli tde status command do?
A: The dbaascli tde status command displays information about the keystore for a specified database. This includes details about the type of keystore and its status.
Q: Who should run the dbaascli tde status command?
A: The command must be executed as the oracle user.
Q: Where should the dbaascli tde status command be run?
A: The command should be run on an Exadata Cloud@Customer virtual machine. You must connect to the virtual machine via SSH to run the utility.
Q: What is the function of the --dbname parameter?
A: The --dbname parameter specifies the name of the database for which the TDE keystore status will be checked.
Q: What information does the dbaascli tde status command return?
A: The output of the command includes the type of keystore (e.g., HSM-based or file-based) and the current status of the keystore, such as whether it is open, closed, or in some other state.
Q: How can I know if the keystore is open or closed using the dbaascli tde status command?
A: The status of the keystore, including whether it is open or closed, is part of the output returned by the dbaascli tde status command.
Q: How do I check the status of the TDE keystore for a specific database?
A: To check the TDE keystore status for a specific database, run:
dbaascli tde status --dbname <DB_NAME>
Q: Can I check the status of the keystore for multiple databases?
A: Yes, but you need to run the command separately for each database, specifying its name using the --dbname parameter.
Q: Can the dbaascli tde status command be run as the root user?
A: No, the command should be executed as the oracle user, not the root user.
Q: Do I need special permissions to run the dbaascli tde status command?
A: Yes, you need to have oracle user privileges and be connected to an Exadata Cloud@Customer virtual machine to run the command.
Q: What should I do if I get an error when running the dbaascli tde status command?
A: Ensure you are running the command as the oracle user, and verify that you have the necessary permissions and are connected to the correct virtual machine.
Q: How do I know what type of keystore my database is using?
A: The type of keystore, such as whether it is file-based or HSM/KMS-based, is displayed in the output of the dbaascli tde status command.
Q: What should I do if the keystore is closed?
A: If the keystore is closed, you may need to open it manually, depending on the operation you are trying to perform. The exact process will depend on the keystore type and your environment.
Q: Can I view keystore status for a CDB (Container Database) or PDB (Pluggable Database)?
A: Yes, by specifying the appropriate database name using the --dbname parameter, you can view the keystore status for both CDBs and PDBs.
Q: What does it mean if the command returns an error about database connectivity?
A: This could indicate an issue with the connection to the database or a problem with your environment. Ensure that the database is running and accessible, and verify your SSH connection to the Exadata Cloud@Customer virtual machine.
Q: What happens if the database name is incorrect?
A: If the --dbname parameter specifies an incorrect or non-existent database, the command will fail, and you’ll receive an error message indicating the problem.
Q: How do I troubleshoot if the keystore status indicates an unexpected state?
A: If the keystore status indicates an unexpected state, review the database logs for more details and check the configuration of the keystore to ensure it is properly set up.
Q: Can I automate the check of keystore status for monitoring purposes?
A: Yes, you can script the dbaascli tde status command to check keystore status periodically or integrate it into your database monitoring tools.
Q: How do I verify that Transparent Data Encryption (TDE) is correctly enabled?
A: You can verify TDE is correctly enabled by checking the status of the keystore using the dbaascli tde status command. A valid and open keystore indicates that TDE is properly configured.
The dbaascli patch db prereq and dbaascli patch db apply commands have been deprecated in dbaascli release 21.2.1.2.0, and replaced with dbaascli grid patch, dbaascli dbhome patch, and dbaascli database move commands.
dbaascli patch db
prereq and dbaascli patch db apply commands have been
deprecated in dbaascli release 21.2.1.2.0, and replaced with
dbaascli grid patch, dbaascli dbhome patch,
and dbaascli database move commands.
For more
information, see:
dbaascli grid patch
dbaascli dbhome patch
dbaascli database move
Patching Oracle Grid Infrastructure and
Oracle Databases Using dbaascli
dbaascli patch db prereq and dbaascli patch db
apply commands have been deprecated in dbaascli
release 21.2.1.2.0, and replaced with dbaascli grid patch,
dbaascli dbhome patch, and dbaascli database
move commands.
For more information, see:
dbaascli grid patch
dbaascli dbhome patch
dbaascli database move
Patching Oracle Grid Infrastructure and Oracle Databases Using
dbaascli
To display information about the keystore for the specified database,
use the dbaascli tde status command.
Prerequisite
Run the command as the oracle user.
Syntax
dbaascli tde status --dbname dbname
Where:
--dbname specifies the name of the database that you want
to check.
Output from the command includes the type of keystore, and the status of
the keystore.
Frequently Asked Questions
Q: What does the dbaascli tde status command do?
A: The dbaascli tde status command displays information about the keystore for a specified database. This includes details about the type of keystore and its status.
Q: Who should run the dbaascli tde status command?
A: The command must be executed as the oracle user.
Q: Where should the dbaascli tde status command be run?
A: The command should be run on an Exadata Cloud@Customer virtual machine. You must connect to the virtual machine via SSH to run the utility.
Q: What is the function of the --dbname parameter?
A: The --dbname parameter specifies the name of the database for which the TDE keystore status will be checked.
Q: What information does the dbaascli tde status command return?
A: The output of the command includes the type of keystore (e.g., HSM-based or file-based) and the current status of the keystore, such as whether it is open, closed, or in some other state.
Q: How can I know if the keystore is open or closed using the dbaascli tde status command?
A: The status of the keystore, including whether it is open or closed, is part of the output returned by the dbaascli tde status command.
Q: How do I check the status of the TDE keystore for a specific database?
A: To check the TDE keystore status for a specific database, run:
dbaascli tde status --dbname <DB_NAME>
Q: Can I check the status of the keystore for multiple databases?
A: Yes, but you need to run the command separately for each database, specifying its name using the --dbname parameter.
Q: Can the dbaascli tde status command be run as the root user?
A: No, the command should be executed as the oracle user, not the root user.
Q: Do I need special permissions to run the dbaascli tde status command?
A: Yes, you need to have oracle user privileges and be connected to an Exadata Cloud@Customer virtual machine to run the command.
Q: What should I do if I get an error when running the dbaascli tde status command?
A: Ensure you are running the command as the oracle user, and verify that you have the necessary permissions and are connected to the correct virtual machine.
Q: How do I know what type of keystore my database is using?
A: The type of keystore, such as whether it is file-based or HSM/KMS-based, is displayed in the output of the dbaascli tde status command.
Q: What should I do if the keystore is closed?
A: If the keystore is closed, you may need to open it manually, depending on the operation you are trying to perform. The exact process will depend on the keystore type and your environment.
Q: Can I view keystore status for a CDB (Container Database) or PDB (Pluggable Database)?
A: Yes, by specifying the appropriate database name using the --dbname parameter, you can view the keystore status for both CDBs and PDBs.
Q: What does it mean if the command returns an error about database connectivity?
A: This could indicate an issue with the connection to the database or a problem with your environment. Ensure that the database is running and accessible, and verify your SSH connection to the Exadata Cloud@Customer virtual machine.
Q: What happens if the database name is incorrect?
A: If the --dbname parameter specifies an incorrect or non-existent database, the command will fail, and you’ll receive an error message indicating the problem.
Q: How do I troubleshoot if the keystore status indicates an unexpected state?
A: If the keystore status indicates an unexpected state, review the database logs for more details and check the configuration of the keystore to ensure it is properly set up.
Q: Can I automate the check of keystore status for monitoring purposes?
A: Yes, you can script the dbaascli tde status command to check keystore status periodically or integrate it into your database monitoring tools.
Q: How do I verify that Transparent Data Encryption (TDE) is correctly enabled?
A: You can verify TDE is correctly enabled by checking the status of the keystore using the dbaascli tde status command. A valid and open keystore indicates that TDE is properly configured.