database Commands

rhpctl add database

Creates a database using a specific working copy.

Syntax

rhpctl add database -workingcopy workingcopy_name 
  { -gimr | -dbname unique_db_name {-node node_list | 
         -serverpool pool_name [-pqpool pool_name | 
         -newpqpool pool_name -pqcardinality cardinality] | 
         -newpool pool_name -cardinality cardinality [-pqpool pool_name | 
         -newpqpool pool_name -pqcardinality cardinality]} 
         [-dbtype {RACONENODE | RAC | SINGLE}] 
         [-dbtemplate file_path | image_name:relative_file_path]
         [-cdb] [-pdbname pdb_prefix [-numberOfPDBs pdb_count]]
         [{-sudouser user_name -sudopath sudo_binary_path | 
          -root | -cred cred_name | 
          -auth plugin_name [-arg1 name1:value1...]}] 
          [-targetnode node_name]
          [-ignoreprereq] 
          [-fixup]} 
  [-datafileDestination datafileDestination_path] 
  [-useractiondata user_action_data] 
  [-eval] [-schedule {timer_value | NOW}]

Parameters

Table A-9 rhpctl add database Command Parameters

Parameter	Description
`-workingcopy workingcopy_name`	Specify the name of an existing working copy for the database that you want to add.
`-gimr`	Perform the operations required for a Grid Infrastructure Management Repository (GIMR) database
`-dbname unique_db_name`	Specify the unique name of the database (`DB_UNIQUE_NAME` without `DB_DOMAIN`) that you are adding.
`-datafileDestination datafileDestination_path`	Specify the data file destination location or the name of the Oracle Automatic Storage Management (Oracle ASM) disk group. Note: You cannot specify a disk group for Oracle Database versions before Oracle Database 11g release 2 (11.2).
`-node node_list`	Specify a node or comma-delimited list of several nodes on which to create the database.
`-serverpool server_pool_name`	Specify the name of an existing server pool.
`-pqpool server_pool_name`	Specify the name of an existing server pool. Note: This parameter is only applicable in an Oracle Flex Cluster environment and refers to server pools (either already defined, as in this case, or to be created when you use the `-newpqpool` parameter) running on non-Hub Nodes.
`-newpqpool server_pool_name`	Optionally, you can create a new server pool to be used for parallel queries. Specify a name for the new server pool. Note: This parameter is only applicable in an Oracle Flex Cluster environment because it refers to server pools running on non-Hub Nodes.
`-pqcardinality cardinality`	If you create a new server pool, then you must specify a cardinality value for the server pool. Note: This parameter is only applicable in an Oracle Flex Cluster environment.
`-newpool server_pool_name`	Optionally, you can create a new server pool. Specify a name for the new server pool.
`-cardinality cardinality`	If you create a new server pool, then you must specify a cardinality value for the server pool.
`-dbtype {RACONENODE \| RAC \| SINGLE}`	Specify whether the database is Oracle RAC One Node, Oracle RAC, or a nonclustered database.
`-dbtemplate file_path \| image_name:relative_file_path`	Specify the absolute file path to a database template or the relative path to the image home directory on a Fleet Patching and Provisioning Server.
`-cdb`	Optionally, use this parameter to create a database as a container database.
`-pdbname pdb_prefix`	If you are creating one or more pluggable databases, then specify a pluggable database name prefix.
`-numberOfPDBs pdb_count`	Specify the number of pluggable databases you want to create.
`-sudouser user_name -sudopath sudo_binary_path \| -root \| -cred cred_name \| -auth plugin_name [-arg1 name1:value1...]`	If you choose to use the `-targetnode` parameter, then you must choose either `sudo` or `root` to access the remote node. If you choose `sudo`, then you must specify a user name to run super-user operations, and a path to the location of the `sudo` binary. Optionally, you can choose to specify a credential name to associate the user and password credentials to access a remote node. Alternative to `–sudouser`, `–root`, or `–cred`, you can use `–auth` to specify an authentication plugin to access a remote node.
`-targetnode node_name`	Optionally, you can specify the name of a node in a remote cluster that has no Oracle Fleet Patching and Provisioning Client.
`–ignoreprereq`	Ignore prerequisites.
`–fixup`	Execute a fixup script. This option is valid for Oracle Grid Infrastructure and database provisioning.
`-useractiondata user_action_data`	Optionally, you can pass a value to the `useractiondata` parameter of the user action script.
`-schedule {timer_value \| NOW}`	Optionally, you can use this parameter to schedule a time to run this operation, in ISO-8601 format, as in the following example: `2018-07-25T19:13:17+05` If `NOW` is specified or the option is omitted, then the job is scheduled immediately.
`–eval`	Optionally, you can use this parameter to evaluate the impact of this command on the system without actually running the command.

Usage Notes

If you choose to use the -schedule parameter, then you must run this command on the Fleet Patching and Provisioning Server.

Authentication plugins enable the easy addition of authentication methods without changes in command line interfaces (CLIs). For information about authentication options, refer to Authentication Options for Oracle Fleet Patching and Provisioning Operations.

Examples

To create a database on a working copy named prodhome:

$ rhpctl add database -workingcopy prodhome -dbname proddb -datafileDestination /acfs/proddata -serverpool prodpool1 -dbtype RAC

Note:

You can create multiple databases on a working copy.

Parent topic: database Commands

rhpctl addnode database

Adds instances to an administrator-managed Oracle RAC database.

Syntax

rhpctl addnode database -workingcopy workingcopy_name 
  -dbname unique_db_name -node node_list
   [-root | -cred cred_name | -sudouser sudo_user_name
    -sudopath sudo_binary_location | 
    -auth plugin_name [-arg1 name1:value1 [-arg2 name2:value2 ...]]]
   [-useractiondata user_action_data] [-eval] [-schedule timer_value]

Parameters

Table A-10 rhpctl addnode database Command Parameters

Parameter	Description
`-workingcopy workingcopy_name`	Specify the name of a working copy.
`-dbname unique_db_name`	Specify the unique name of the database (`DB_UNIQUE_NAME` without `DB_DOMAIN`) that you are adding.
`-node node_list`	Specify a node or comma-delimited list of several nodes on which to create the database.
`-root \| -cred cred_name \| -sudouser sudo_user_name -sudopath sudo_binary_location \| -auth plugin_name plugin_args`	If you choose to use the `-targetnode` parameter, then you must choose either `root`, a credential name, `sudo`, or an authentication plugin to access the remote node. Choose `-root` to perform super user operations as `root`. Alternatively, you can choose either to specify a credential name to associate the user name and password credentials to access a remote node, to perform super user operations as a `sudo` user by specifying a `sudo` user name and the path to the `sudo` binary, or to use an authentication plugin to access the remote node.
`-useractiondata user_action_data`	Optionally, you can pass a value to the `useractiondata` parameter of the user action script.
`–eval`	Optionally, you can use this parameter to evaluate the impact of this command on the system without actually running the command.
`-schedule timer_value`	Optionally, you can use this parameter to schedule a time to run this operation, in ISO-8601 format, as in the following example: `2018-07-25T19:13:17+05`

Usage Notes

If the specified working copy is not installed on the nodes in the node list, then you must first run rhpctl addnode workingcopy.
If the working copy is on a Fleet Patching and Provisioning Client or on the Fleet Patching and Provisioning Server, then credentials are not required. This is true whether you run the command on the Server or the Client. Credentials are required when you run the command on the Server and the working copy is on a target that is not a Fleet Patching and Provisioning Client.
If you choose to use the -schedule parameter, then you must run this command on the Fleet Patching and Provisioning Server.

Parent topic: database Commands

rhpctl addpdb database

Adds a pluggable database to an existing container database on a working copy.

After you create a working copy of a gold image and provision that working copy to a target, and create a database as a multitenant container database, you can add a pluggable database to the container database on the working copy.

Syntax

rhpctl addpdb database -workingcopy workingcopy_name -cdbname cdb_name
  -pdbname new_pdb_name [-pdbDatafileDestination pdb_datafile_destination_path]
  [-root | -cred cred_name | -auth plugin_name [-arg1 name1:value1...]
   | -sudouser user_name -sudopath sudo_binary_path] [-targetnode node_name]
  [-useractiondata user_action_data] [-schedule timer_value]

Parameters

Table A-11 rhpctl addpdb database Command Parameters

Parameter	Description
`-workingcopy workingcopy_name`	Specify the name of an existing working copy for the pluggable database that you want to add.
`-cdbname cdb_name`	Specify the name of the multitenant container database to which you want to add the pluggable database.
`-pdbname new_pdb_name`	Specify a name for the pluggable database you are adding.
`-pdbDatafileDestination pdb_datafile_destination`	Optionally, you can specify the path to the data file destination location for the pluggable database.
`-root \| -cred cred_name \| -auth plugin_name [-arg1 name1:value1...] \| -sudouser user_name -sudopath sudo_binary_path`	If you choose to use the `-targetnode` parameter, then you must choose either `sudo` or `root` to access the remote node. If you choose `sudo`, then you must specify a user name to run super-user operations, and a path to the location of the `sudo` binary. Optionally, you can choose to specify a credential name to associate the user and password credentials to access a remote node. Alternative to `–sudouser`, `–root`, or `–cred`, you can use `–auth` to specify an authentication plugin to access a remote node.
`-targetnode node_name`	Optionally, you can specify the name of a node in the cluster on which you want to run this operation.
`-useractiondata user_action_data`	Optionally, you can pass a value to the `useractiondata` parameter of the user action script.
`-schedule timer_value`	Optionally, you can use this parameter to schedule a time to run this operation, in ISO-8601 format, as in the following example: `2018-07-25T19:13:17+05`

Usage Notes

The working copy can be on Fleet Patching and Provisioning Server, a Fleet Patching and Provisioning Client, or a non-Fleet Patching and Provisioning Client target.

Example

The following example creates a pluggable database called pdb183 on a container database called raccdb183 on a working copy called wc_db183:

$ rhpctl addpdb database -workingcopy wc_db183 -cdbname raccdb183 -pdbname pdb183

Parent topic: database Commands

rhpctl deletepdb database

Deletes a pluggable database to an existing container database on a working copy.

Syntax

rhpctl deletepdb database -workingcopy workingcopy_name -cdbname cdb_name
  -pdbname pdb_name
  [-root | -cred cred_name | -auth plugin_name [-arg1 name1:value1...]
   | -sudouser user_name -sudopath sudo_binary_path] [-targetnode node_name]
  [-useractiondata user_action_data] [-schedule timer_value]

Parameters

Table A-12 rhpctl deletepdb database Command Parameters

Parameter	Description
`-workingcopy workingcopy_name`	Specify the name of an existing working copy for the pluggable database that you want to delete.
`-cdbname cdb_name`	Specify the name of the multitenant container database from which you want to delete the pluggable database.
`-pdbname pdb_name`	Specify the name of the pluggable database you want to delete.
`-root \| -cred cred_name \| -auth plugin_name [-arg1 name1:value1...] \| -sudouser user_name -sudopath sudo_binary_path`	If you choose to use the `-targetnode` parameter, then you must choose either `sudo` or `root` to access the remote node. If you choose `sudo`, then you must specify a user name to run super-user operations, and a path to the location of the `sudo` binary. Optionally, you can choose to specify a credential name to associate the user and password credentials to access a remote node. Alternative to `–sudouser`, `–root`, or `–cred`, you can use `–auth` to specify an authentication plugin to access a remote node.
`-targetnode node_name`	Optionally, you can specify the name of a node in the cluster on which you want to run this operation.
`-useractiondata user_action_data`	Optionally, you can pass a value to the `useractiondata` parameter of the user action script.
`-schedule timer_value`	Optionally, you can use this parameter to schedule a time to run this operation, in ISO-8601 format, as in the following example: `2018-07-25T19:13:17+05`

Usage Notes

The working copy can be on Fleet Patching and Provisioning Server, a Fleet Patching and Provisioning Client, or a non-Fleet Patching and Provisioning Client target.

Examples

The following example deletes a pluggable database called pdb183 from a container database called raccdb183 on a working copy called wc_db183:

$ rhpctl deletepdb database -workingcopy wc_db183 -cdbname raccdb183 -pdbname pdb183

Parent topic: database Commands

rhpctl delete database

Deletes a database that was created on a working copy.

Note:

If the database is hosted on a working copy that is on the Oracle Fleet Patching and Provisioning Server or on an Oracle Fleet Patching and Provisioning Client, then credentials are not required. This is true whether you run the command on the Server or the Client. Credentials are required when you run the command on the Server and the working copy is on a target that is not an Oracle Fleet Patching and Provisioning Client.

Syntax

rhpctl delete database –workingcopy workingcopy_name -dbname unique_db_name
  {-sudouser sudo_user_name -sudopath sudo_binary_path | 
    -root | -cred cred_name | 
    -auth plugin_name [-arg1 name1:value1...]} 
  [-targetnode node_name]
  [-useractiondata user_action_data]
  [-schedule {timer_value | NOW}]

Parameters

Table A-13 rhpctl delete database Command Parameters

Parameter	Description
`-workingcopy workingcopy_name`	Specify a name for the working copy for the database that you want to delete.
`-dbname unique_db_name`	Specify the unique name of the database (`DB_UNIQUE_NAME`without `DB_DOMAIN`) that you are deleting.
`-sudouser user_name -sudopath sudo_binary_path \| -root \| -cred cred_name \| -auth plugin_name [-arg1 name1:value1...]`	If you choose to use the `-targetnode` parameter, then you must choose either `sudo` or `root` to access the remote node. If you choose `sudo`, then you must specify a user name to run super-user operations, and a path to the location of the `sudo` binary. Optionally, you can choose to specify a credential name to associate the user and password credentials to access a remote node. Alternative to `–sudouser`, `–root`, or `–cred`, you can use `–auth` to specify an authentication plugin to access a remote node.
`-targetnode node_name`	Optionally, you can specify the name of a node in a remote cluster that has no Oracle Fleet Patching and Provisioning Client.
`-useractiondata user_action_data`	Optionally, you can pass a value to the `useractiondata` parameter of the user action script.
`-schedule {timer_value \| NOW}`	Optionally, you can use this parameter to schedule a time to run this operation, in ISO-8601 format, as in the following example: `2018-07-25T19:13:17+05` If `NOW` is specified, then the job is scheduled immediately.

Parent topic: database Commands

rhpctl deletenode database

Deletes an instance, which contracts an administrator-managed Oracle RAC database.

Syntax

rhpctl deletenode database -workingcopy working_copy_name -dbname unique_db_name
 -node node_list {-root | -sudouser sudo_username -sudopath sudo_binary_path 
  | -cred cred_name | -auth plugin_name [-arg1 name1:value1...]} [-force]
 [-failover] [-drain_timeout timeout] [-stopoption stop_option]
 [-useractiondata user_action_data] [-schedule timer_value] [-eval]

Parameters

Table A-14 rhpctl deletenode database Command Parameters

Parameter	Description
`-workingcopy working_copy_name`	Specify the name of a working copy.
`-dbname unique_db_name`	Specify the unique name of the database (`DB_UNIQUE_NAME` without `DB_DOMAIN`) that you are deleting.
`-node node_list`	Specify a node or comma-delimited list of several nodes from which to delete the database instance.
`-root \| -sudouser sudo_username -sudopath sudo_binary_path \| -cred cred_name \| -auth plugin_name [-arg1 name1:value1...]`	Choose either `sudo` or `root` to access the remote nodes. If you choose `sudo`, then you must specify a user name to run super-user operations, and a path to the location of the `sudo` binary. Optionally, you can choose to specify a credential name to associate the user and password credentials to access a remote node. Alternative to `–sudouser`, `–root`, or `–cred`, you can use `–auth` to specify an authentication plugin to access a remote node.
`-force`	Use `-force` to remove the instance after forcibly stopping the instance.
`-failover`	Optionally, you can use this parameter to attempt to have services running on the instance that want to delete fail over to another instance.
`-drain_timeout timeout`	Optionally, you can use `-drain_timeout` to specify the time, in seconds, allowed for resource draining to be completed. Accepted values are an empty string (""), 0, or any positive integer. The default value is an empty string, which means that this parameter is not set. If it is set to 0, then draining occurs, immediately. The draining period is intended for planned maintenance operations. During the draining period, all current client requests are processed, but new requests are not accepted.
`-stopoption stop_option`	Optionally, you can specify a stop option for the database. Options include: `ABORT`, `IMMEDIATE`, `NORMAL`, `TRANSACTIONAL`, and `TRANSACTIONAL_LOCAL`.
`-useractiondata user_action_data`	Optionally, you can pass a value to the `useractiondata` parameter of the user action script.
`-schedule timer_value`	Optionally, you can use this parameter to schedule a time to run this operation, in ISO-8601 format, as in the following example: `2018-07-25T19:13:17+05`
`–eval`	Optionally, you can use this parameter to evaluate the impact of this command on the system without actually running the command.

Usage Notes

If the working copy is on a Fleet Patching and Provisioning Client or on the Fleet Patching and Provisioning Server, then credentials are not required. This is true whether you run the command on the Server or the Client. Credentials are required when you run the command on the Server and the working copy is on a target that is not a Fleet Patching and Provisioning Client.
If you choose to use the -schedule parameter, then you must run this command on the Fleet Patching and Provisioning Server.

Parent topic: database Commands

rhpctl move database

Moves one or more databases from a source working copy or any Oracle Database home to a patched working copy.

Syntax

rhpctl move database -patchedwc workingcopy_name 
   {{-sourcewc workingcopy_name |
     -sourcehome Oracle_home_path [-oraclebase Oracle_base_path]
   [-client cluster_name]}
   [-dbname db_name_list | -excludedblist db_name_list]
   [-nonrolling [-skipprereq] | -forcerolling | -batches list_of_batches | -smartmove [-saf availability] [-separate]] 
   [-eval]
   [-ignoremissingpatches patch_name1 [,patch_name2...]]
   [-ignorewcpatches] [-keepplacement]
   [-disconnect [-noreplay]] [-drain_timeout time] [-stopoption stop_option]
   [-nodatapatch] [-targetnode node_name] [-notify [-cc user_list]] |
    -continue [-skip] | -revert | -abort}
   [-root | -cred cred_name | -sudouser sudo_user_name
     -sudopath sudo_binary_location | 
     -auth plugin_name [-arg1 name1:value1 [-arg2 name2:value2 ...]]]
    [schedule {timer_value| NOW}] 
    [-useractiondata user_action_data]
   [-dbsinparallel <number_of_instances>] [-raconetimeout <timeout>]

Parameters

Table A-15 rhpctl move database Command Parameters

Parameter	Description
`-patchedwc workingcopy_name`	Specify the name of the working copy to where you want to move the database.
`-sourcewc workingcopy_name`	Specify the name of the working copy from which the database is to be moved.
`-sourcehome Oracle_home_path`	Alternatively, you can specify the source Oracle home path.
`-oraclebase Oracle_base_path`	Specify the ORACLE_BASE path for provisioning the Oracle database home (required only for `ORACLEDBSOFTWARE` image type).
`-client cluster_name`	Specify the name of the client cluster.
`-dbname db_name_list`	Specify the unique names of the databases (`DB_UNIQUE_NAME` without `DB_DOMAIN`) that you want to move to the patched working copy. Note: If you are moving a non-clustered (single-instance) database, then, for the value of the `-dbname` parameter, you must specify the SID of the database instead of the database name.
`-excludedblist db_name_list`	Alternative to using the `-dbname` parameter, you can use the `-excludedblist` parameter to patch all databases except specific databases.
`-nonrolling [-skipprereq]` \| `-forcerolling \| -batches list_of_batches` \| `-smartmove [-saf availability] [–separate]`	Optionally, you can choose one of the three following methods to move a database: Use the `-nonrolling` parameter to move the database in a non-rolling mode. By default, databases move in a rolling mode. Use the `–skipprereq` option to skip the prerequisite checks and start the database in upgrade mode for patching. Use the `–forcerolling` parameter to force the Oracle home to move in rolling mode. Use the `-batches` parameter to specify a comma-delimited list of batches of nodes (where each batch is a comma-delimited list of node names enclosed in parentheses) enclosed in double quotation marks (`""`) in the format: `"(nA,nB,...),(...,nY,nZ)"`. Alternatively, use the `-smartmove` parameter. Use the `-saf availability` parameter to specify a service availability factor, which is the minimum percentage of instances on which a service must remain running during the move. Use the `-separate` parameter to process batches separately. When you use this parameter, the `move` command returns after each batch. The move operation for the first batch must specify the source home and other parameters that apply to all batches (such as `-nonrolling` and `-keepplacement`). Control subsequent batches using the `-continue`, `-skip`, and `-abort` parameters.
`–eval`	Use the `–eval` parameter to print auto-generated batches of nodes and sequence of moves without actually performing the move operation.
`-ignoremissingpatches patch_name1 [,patch_name2...]`	Perform the move and/or upgrade even though the specified patches, which are present in the source path or working copy, may be missing from the destination path or working copy.
`-ignorewcpatches`	Optionally, you can use this parameter to ignore if a patched working copy is missing some patches which are present in the source path or working copy.
`-keepplacement`	Use this parameter to ensure that services of administrator-managed Oracle RAC or Oracle RAC One Node databases are running on the same instances before and after the move operation.
`-disconnect [-noreplay]`	Optionally, use the `-disconnect` parameter to disconnect all sessions before stopping or relocating services. If you choose to use `-disconnect`, then you can choose to use the `-noreplay` parameter to disable session replay during disconnection.
`-drain_timeout timeout`	Specify the time, in seconds, allowed for resource draining to be completed. Accepted values are an empty string (""), 0, or any positive integer. The default value is an empty string, which means that this parameter is not set. If it is set to 0, then draining occurs, immediately. The draining period is intended for planned maintenance operations. During the draining period, all current client requests are processed, but new requests are not accepted.
`-stopoption stop_option`	Optionally, you can specify a stop option for the database. Options include: `ABORT`, `IMMEDIATE`, `NORMAL`, `TRANSACTIONAL`, and `TRANSACTIONAL_LOCAL`.
`–nodatapatch`	Use this parameter to indicate not to run `datapatch` for databases you are moving.
`-targetnode node_name`	Optionally, you can specify the name of a node in a remote cluster that has no Fleet Patching and Provisioning Client.
`-notify [-cc user_list]`	Optionally, you can supply a list of users to whom email notifications of the move will be sent, in addition to the owner of the working copy.
`-continue [-skip]`	If a batch-mode `rhpctl move database` command fails at any point, then, after correcting the cause of the error, you can rerun the command with the `-continue` parameter to attempt to patch the failed batch. If you want to skip the failed batch and continue with the next batch, use the `-continue` and `-skip` parameters together. If you attempt to skip over the last batch, then the move operation is terminated.
`—revert`	If a batch-mode or non-batch-mode `rhpctl move database` command fails, then you can rerun the command with the `-revert` parameter to undo the changes that have been made, and return the configuration to its initial state.
`—abort`	If a batch-mode or non-batch-mode `rhpctl move database` command fails, then you can rerun the command with the `-abort` parameter to terminate the patching process and leave the cluster in its current state.
`-root` \| `-cred cred_name` \| `-sudouser sudo_user_name -sudopath sudo_binary_location` \| `-auth plugin_name plugin_args`	If you choose to use the `-targetnode` parameter, then you must choose either `root`, a credential name, `sudo`, or an authentication plugin to access the remote node. Choose `-root` to perform super user operations as `root`. Alternatively, you can choose either to specify a credential name to associate the user name and password credentials to access a remote node, to perform super user operations as a `sudo` user by specifying a `sudo` user name and the path to the `sudo` binary, or to use an authentication plugin to access the remote node.
`-useractiondata user_action_data`	Optionally, you can pass a value to the `useractiondata` parameter of the user action script.
`-schedule {timer_value \| NOW}`	Optionally, you can use this parameter to schedule a time to run this operation, in ISO-8601 format. For example: `2018-07-25T19:13:17+05` If `NOW` is specified, then the job is scheduled immediately.
`-dbsinparallel number_of_instances`	Number of database instances that can be started in parallel on a given node.
`-raconetimeout timeout`	RAC One Node database relocation timeout in minutes.

Usage Notes

You can obtain context sensitive help for specific use cases for the rhpctl move database command, as follows:

$ rhpctl move database -help [EXISTING_PATCHEDWC | NEW_PATCHEDWC | SRCHOME
  | SINGLEINSTANCEDB | ROLLING | NONROLLING | BATCHES | SMARTMOVE]

If you choose to use the -schedule parameter, then you must run this command on the Fleet Patching and Provisioning Server.

Examples

To move all the databases running from one working copy to another in a rolling fashion:

$ rhpctl move database -sourcewc prodHomeV1 -patchedwc prodHomeV2 -client prodcluster

In the preceding example, the patched working copy, prodHomeV2, must exist.

To move all databases running on a non-managed Oracle home at /u01/app/product/12.1.0/dbhome to a working copy named myDB12Home1:

$ rhpctl move database -sourcehome /u01/app/product/12.1.0/dbhome -oraclebase /u01/app/product/12.1.0/obase -patchedwc myDB12Home1

To move a database named SampleDB from a working copy named myDB12Home1 to a working copy named myDB12Home1patched (any other databases running on myDB12Home1 are not affected by this move):

$ rhpctl move database –sourcewc myDB12Home1 –patchedwc myDB12Home1patched –dbname SampleDB

To move all databases running on a working copy named myDB12Home1 to a working copy named myDB12Home1patched:

$ rhpctl move database –sourcewc myDB12Home1 –patchedwc myDB12Home1patched

To move a non-clustered (single-instance) database with a SID of SID101 running on a patched working copy named myDB12Home1patched:

$ rhpctl move database -patchedwc myDB12Home1patched -sourcehome
/u01/app/oracle/product/12.2.0/db_1 -targetnode vm02 -dbname SIDl01
-sudouser oracle -sudopath /usr/bin/sudo

The preceding examples are the basic form of the command. You can also move groups of databases in batches. The batch operations also support management of session connections and recovery options.

Parent topic: database Commands

rhpctl movepdb database

Moves one or more pluggable databases from a source, single-instance container database, to a destination, single-instance container database.

The source and destination single-instance container databases can be running in a provisioned database working copy. The working copy can be on the Fleet Patching and Provisioning Server, a Fleet Patching and Provisioning Client, or a non-Fleet Patching and Provisioning Client target, which is a target without a Fleet Patching and Provisioning Client configured and running. The destination single-instance container database can be at a higher patch level, which facilitates patching of a pluggable database to a higher patch level.

Syntax

rhpctl movepdb database -sourcecdb source_cdb_name -destcdb destination_cdb_name
    {-pdbname pdb_name_list | -excludepdblist pdb_name_list}
    [-root | -cred cred_name | -sudouser sudo_user_name
     -sudopath sudo_binary_location | 
     -auth plugin_name [-arg1 name1:value1
     [-arg2 name2:value2 ...]]] [-client client_name | -targetnode node_name]
    [-useractiondata user_action_data] [-schedule timer_value]

Parameters

Table A-16 rhpctl movepdb database Command Parameters

Parameter	Description
`-sourcecdb source_cdb_name`	Specify the name of the Oracle Multitenant container database from which you want to move the pluggable database.
`-destcdb destination_cdb_name`	Specify the name of the multitenant container database to which you want to move the pluggable database.
`-pdbname pdb_name_list`	Specify a comma-separated list of names of pluggable databases that you want to move.
`-excludepdblist pdb_name_list`	Specify a list of pluggable databases that you want to excluded from the move operation.
`-root \| -cred cred_name \| -sudouser sudo_user_name -sudopath sudo_binary_location \| -auth plugin_name plugin_args`	If you choose to use the `-targetnode` parameter, then you must choose either `root`, a credential name, `sudo`, or an authentication plugin to access the remote node. Choose `-root` to perform super user operations as `root`. Alternatively, you can choose either to specify a credential name to associate the user name and password credentials to access a remote node, to perform super user operations as a `sudo` user by specifying a `sudo` user name and the path to the `sudo` binary, or to use an authentication plugin to access the remote node.
`-client client_name \| -targetnode node_name`	Optionally, you can specify either the name of the client cluster or the node on which the operation is to be run.
`-useractiondata user_action_data`	Optionally, you can pass a value to the `useractiondata` parameter of the user action script.
`-schedule timer_value \| NOW`	Optionally, you can use this parameter to schedule a time to run this operation, in ISO-8601 format, as in the following example: `2019-01-07T19:13:17+05` You can also specify `NOW` to schedule the operation, immediately.

Usage Notes

You can only use this command if both the source and destination single-instance container databases are on the same node.

Examples

To move a pluggable database from a source single-instance container database to a destination single-instance container database:

rhpctl movepdb database -sourcecdb srccdb -pdbname pdb1,pdb2,pdb3 -destcdb dstcdb

Parent topic: database Commands

rhpctl upgrade database

Upgrades a database to the version of the destination working copy.

Syntax

rhpctl upgrade database [-sourcewc source_workingcopy_name | -sourcehome oracle_home_path
   [-oraclebase Oracle_base_path] [{-client cluster_name | -targetnode node_name}]]
  [-root | -cred cred_name | -sudouser sudo_username -sudopath path_to_sudo_binary
   | -auth plugin_name [-arg1 name1:value1 [-arg2 name2:value2 ...]]]
  -destwc destination_workingcopy_name [-image image_name [-path where_path]]
  -dbname unique_db_name [-useractiondata user_action_data] [-eval [-preupg]
  [-schedule timer_value]

Parameters

Table A-17 rhpctl upgrade database Command Parameters

Parameter	Description
`-sourcewc source_workingcopy_name`	Specify the name of the source working copy from which you want to upgrade the database.
`-sourcehome oracle_home_path`	Alternative to specifying the name of the source working copy, you can specify the path to the source Oracle home.
`-oraclebase oraclebase_path`	If you use the `-sourcehome` parameter, then you can, optionally, specify a different `ORACLE_BASE` from the source Home.
`-client cluster_name \| -targetnode node_name`	Specify either the name of the client cluster or the name of a node in a remote cluster with no Fleet Patching and Provisioning Client on which to provision a working copy.
`-root \| -cred cred_name \| -sudouser sudo_user_name -sudopath sudo_binary_location \| -auth plugin_name plugin_args`	If you choose to use the `-targetnode` parameter, then you must choose either `root`, a credential name, `sudo`, or an authentication plugin to access the remote node. Choose `-root` to perform super user operations as `root`. Alternatively, you can choose either to specify a credential name to associate the user name and password credentials to access a remote node, to perform super user operations as a `sudo` user by specifying a `sudo` user name and the path to the `sudo` binary, or to use an authentication plugin to access the remote node.
`-destwc destination_workingcopy_name [-image image_name [-path where_path]]`	Specify the name of the destination working copy to which the database is to be upgraded. If the destination working copy does not exist, then specify the gold image from which to create it, and optionally, the path to where to provision the working copy.
`-dbname unique_db_name`	Specify the name of the database you are upgrading.
`-useractiondata user_action_data`	Optionally, you can pass a value to the `useractiondata` parameter of the user action script.
`–eval`	Optionally, you can use this parameter to evaluate the impact of this command on the system without actually running the command.
`-schedule timer_value`	Optionally, you can use this parameter to schedule a time to run this operation, in ISO-8601 format, as in the following example: `2018-07-25T19:13:17+05`

Usage Notes

If you choose to use the -schedule parameter, then you must run this command on the Fleet Patching and Provisioning Server.

Example

The following example upgrades a database, testy, from Oracle Database 11g, which is on working copy db112mbc143 to Oracle Database 12c, which is on working copy db12102mbc143, both of which reside on the remote node bposvr141:

$ rhpctl upgrade database -dbname testy -sourcewc db112mbcl43 -destwc db12102mbcl43 -root -targetnode bposvr141

Parent topic: database Commands

rhpctl zdtupgrade database

Enables zero downtime database upgrade for Oracle RAC and Oracle RAC One Node databases.

Syntax

rhpctl zdtupgrade database -dbname unique_db_name -destwc destination_workingcopy_name
   [-sourcewc source_workingcopy_name | -sourcehome oracle_home_path]
   -ggsrcwc golden_gate_source_workingcopy_name
   -ggdstwc golden_gate_dest_workingcopy_name
   [-clonedatadg diskgroup_name [-cloneredodg diskgroup_name]
       [-clonerecodg diskgroup_name]]
  [clonedatafs acfs_mountpoint [-cloneredofs acfs_mountpont]
       [-clonerecofs acfs_mountpoint]]
   [-rmanlocation backup_location]
   [-targetnode node_name
    {-root | -cred cred_name | -sudouser sudo_user_name
     -sudopath sudo_binary_location | 
     -auth plugin_name [-arg1 name1:value1 [-arg2 name2:value2 ...]]}]
   [-eval]
   [-ignoreprereq]
   [-useractiondata user_action_data]
   [-dbuaargs dbua_arguments

Parameters

Table A-18 rhpctl zdtupgrade database Command Parameters

Parameter	Description
`-dbname unique_db_name`	Specify the unique name of the database that you want to upgrade.
`-destwc destination_workingcopy_name`	Specify the name of the destination working copy to which the database is to be upgraded.
`-sourcewc source_workingcopy_name`	Optionally, you can specify the name of the source working copy from which you want to upgrade the database.
`-sourcehome oracle_home_path`	Alternative to specifying the name of the source working copy, you can specify the path to the source Oracle home.
`-ggsrcwc golden_gate_source_workingcopy_name`	Specify the name of the Oracle GoldenGate source working copy.
`-ggdstwc golden_gate_dest_workingcopy_name`	Specify the name of the Oracle GoldenGate destination working copy.
`-clonedatadg diskgroup_name`	Optionally, you can specify the name of an Oracle ASM disk group to use as a data file location for the cloned database.
`-cloneredodg diskgroup_name`	Optionally, you can specify the name of an Oracle ASM disk group to use as a redo log location for the clones database.
`-clonerecodg diskgroup_name`	Optionally, you can specify the name of an Oracle ASM disk group to use as a recovery area for the cloned database.
`clonedatafs acfs_mountpoint`	(Optional) You can specify the mount point of an Oracle Automatic Storage Management Cluster File System (Oracle ACFS) to use as a data file location for the cloned database.
`-cloneredofs acfs_mountpoint`	(Optional) You can specify the mount point of an Oracle ACFS file system to use as redo log location for the clone database.
`-clonerecofs acfs_mountpoint`	(Optional) You can specify the mount point of an Oracle ACFS file system to use as recovery area for the clone database.
`-rmanlocation backup_location`	Optionally, you can specify the source RMAN backup location.
`-targetnode node_name`	Optionally, you can specify the name of a node in a remote cluster with no Fleet Patching and Provisioning Client on which to provision a working copy.
`-root \| -cred cred_name \| -sudouser sudo_user_name -sudopath sudo_binary_location \| -auth plugin_name plugin_args`	If you choose to use the `-targetnode` parameter, then you must choose either `root`, a credential name, `sudo`, or an authentication plugin to access the remote node. Choose `-root` to perform super user operations as `root`. Alternatively, you can choose either to specify a credential name to associate the user name and password credentials to access a remote node, to perform super user operations as a `sudo` user by specifying a `sudo` user name and the path to the `sudo` binary, or to use an authentication plugin to access the remote node.
`eval`	(Optional) You can specify `eval` to evaluate the Zero Downtime Upgrade operation to see if it can succeed, but does not perform the operation.
`-ignoreprereq`	(Optional) You can use this parameter to instruct the `zdtupgrade database` command to ignore system prerequisites during the upgrade.
`-useractiondata user_action_data`	Optionally, you can use this parameter to specify a value to be passed to the useractiondata parameter of a useraction script
`-dbuaargs`	(Optional) If you do not specify the AutoUpgrade Utility for the upgrade with the `-autoupg` parameter, so that Database Upgrade Assistant (DBUA) is used for the upgrade, then you can specify arguments to pass to DBUA. If you specify `-autoupg`, then this argument is not available. For example, if the user account with which you are running Zero Downtime Upgrade If your account does not have SYSDBA privileges, or you do not have operating system authentication set up, then you can use the following syntax to connect, where `mydb` is your Oracle Database SID, `username` is a user name with SYSDBA privileges, and `password` is that user name’s password: `-sysDBAUserName - username -sysDBAPassword - password`

Parent topic: database Commands