database Commands

Use commands with the database keyword to add, delete, move, and upgrade databases.

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.

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.

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

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

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

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.

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.

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

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

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