1. Command Line Interface
  2. Verb Reference
  3. EM CLI Verbs
  4. configure_db_ha
  5. configure_db_ha -configureBackupToRA

configure_db_ha -configureBackupToRA

configure_db_ha -configureBackupToRA

This form of the command configures one or more databases for protection by one or more Recovery Appliance(s). The command schedules an Enterprise Manager deployment procedure that processes multiple databases and configures each to send backups to a designated Recovery Appliance. In addition, the command also enables redo transport to the Recovery Appliance(s) either from individual databases or from within a Data Guard broker configuration. The procedure steps include configuring a database backup wallet, installing the Recovery Appliance Backup Module in the database Oracle homes (if necessary), and configuration of all required backup and redo settings in the database and in Enterprise Manager. Before running this command, the specified databases must already be enrolled with the Recovery Appliance as protected databases (as performed by the Recovery Appliance administrator via the emcli manage_ra -addProtectedDatabase command or the Enterprise Manager Recovery Appliance management console).

The -backup_config parameter controls the type of databases that will be processed and how they will be configured for backup and redo transport. If this parameter is specified with a value of NO_DG, only databases that are not in a Data Guard configuration will be configured. If the parameter is specified with a value of ALL_DG, CUSTOM_DG, GOLD, or GOLD_WITH_REP only databases in a Data Guard broker configuration will be configured to send backups to one or more Recovery Appliances (either the same Recovery Appliance for all databases or different Recovery Appliances designated for different databases), and the Recovery Appliance(s) will subsequently be added as members of the Data Guard broker configuration and redo transport will be enabled to the Recovery Appliance(s).

The command can also be used to change the existing configuration of one or more databases, either for the same Recovery Appliance or for a different Recovery Appliance than the one currently configured. The procedure works identically in the initial configuration and reconfiguration cases, except that in the latter case any existing protected database configuration is overwritten with the new settings.

Wallet Handling

Configuration of the Recovery Appliance virtual private catalog credentials in an Oracle wallet is a requirement for a database to send backups and redo to a Recovery Appliance. Since this configuration must coexist with other database features that use the wallet, it must either be integrated into an existing wallet if present or a new wallet must be created in the proper location. The database initialization parameter WALLET_ROOT specifies the location of a root directory tree containing sub-directories for all component wallets (TDE, EUS, SERVER_SEPS...) used by the database and is supported for backup wallets starting with database versions greater than or equal to 19.17. External clients like RMAN or SQLPLUS cannot use the WALLET_ROOT initialization parameter and rely on the WALLET_LOCATION parameter specified in the SQLNET.ORA file. Since the WALLET_LOCATION parameter in SQLNET.ORA is used by some existing features to locate the wallet, the location of SQLNET.ORA must also be determined.

  • The location of SQLNET.ORA for each database will be determined as follows:
    1. Use the value of the TNS_ADMIN environment variable set via the database SRVCTL utility, if it is set.
    2. Otherwise, use the value of TNS_ADMIN in the environment of the Enterprise Manager Agent that is monitoring the database, if it is set.
    3. Otherwise, if the database Oracle home is a read-only Oracle home, use ORACLE_BASE_HOME/network/admin.
    4. Otherwise, use ORACLE_HOME/network/admin.
  • Having determined the value of WALLET_ROOT and WALLET_LOCATION in the SQLNET.ORA file, the configuration procedure follows the sequence of steps below to create or update the backup wallet with the Recovery Appliance virtual private catalog user credentials and/or trusted certificates.:
    1. Create/update the wallet in the SERVER_SEPS sub-directory under the WALLET_ROOT directory, if WALLET_ROOT is set.
    2. Create/update the wallet in the WALLET_LOCATION directory specified in SQLNET.ORA, if WALLET_LOCATION is set. Note that if both WALLET_ROOT and WALLET_LOCATION are set, the wallet will be created/updated in both places so that existing features that use the wallet are not adversely impacted.
    3. Otherwise, update the default wallet in ORACLE_BASE/admin/$ORACLE_UNQNAME/wallet, if it exists. The WALLET_LOCATION parameter in SQLNET.ORA will not be changed unless specifically requested by passing in the force_update_wallet_loc argument.
    4. Otherwise, if the user passes in the WALLET_LOCATION argument to the command, create/update the wallet in the location specified. If WALLET_LOCATION is set to USE_RECOMMENDED, the location defaults to $ORACLE_BASE/admin/$ORACLE_UNQNAME/wallet if the environment variables are already set or are being set.
    5. Otherwise, if the database Oracle home is a read-only Oracle home, create/update the wallet in ORACLE_BASE_HOME/dbs/zdlra.
    6. Otherwise, create/update the wallet in ORACLE_HOME/dbs/zdlra.
  • In cases 4, 5, and 6, if the set_wallet_root flag is specified, the WALLET_ROOT parameter will be set to the associated value and the wallet will be created in the SERVER_SEPS sub directory under this location. WALLET_LOCATION in SQLNET.ORA will be set only if specifically requested by passing the force_update_wallet_loc argument. However, if the set_wallet_root parameter is not specified, the wallet will be created in the directory location specified and the WALLET_LOCATION in SQLNET.ORA will always be updated to the associated value by default.

    If the database version is between 19.17 and 23, the algorithm also looks to see if ENCRYPTION_WALLET_LOCATION is set in SQLNET.ORA and conforms with the WALLET_ROOT directory naming semantics - it ends with TDE. If it does, the wallet is created/updated in a SERVER_SEPS peer directory of the ENCRYPTION_WALLET_LOCATION. WALLET_ROOT is set to the parent directory and WALLET_LOCATION in SQLNET.ORA is updated.

    If WALLET_ROOT and/or WALLET_LOCATION cannot be set for any reason, the following will occur:

    • The Set Redo Transport User step of the configuration procedure will fail with an error indicating that the required WALLET_LOCATION setting is not present.
    • All other steps of the procedure will proceed.
    • The databases will be configured to only send backups to the Recovery Appliance(s) and redo transport will not be enabled.
    • If the databases being processed are in a Data Guard configuration, the Recovery Appliance(s) will not be added to the Data Guard broker configuration.
    • The status of the procedure will be reported as Completed with Errors.

Format

emcli configure_db_ha -configureBackupToRA
        (            (-target_name="<database or group target name>" -target_type="oracle_database|rac_database|composite")
            | -input_file="<full path name of input file>"
        )
        -backup_config="NO_DG|ALL_DG|CUSTOM_DG|GOLD|GOLD_WITH_REP"
        [-protocol=TCPS|TCP]

        [-ra_target_name="<Recovery Appliance target name>"]
        [-ra_vpc_username="<Recovery Appliance virtual private catalog username>"]
        [-ra_override_conn_desc="<Recovery Appliance database override connect descriptor>"]

        [-br_continuity
           -alternate_ra_target_name="<Alternate Recovery Appliance target name>"
           [-ra_local_vpc_username="<Recovery Appliance local virtual private catalog username>"]
           [-alternate_ra_override_conn_desc="<Alternate Recovery Appliance database override connect descriptor>"]
           [-br_continuity_override_conn_desc="<Backup and Recovery Continuity override connect descriptor for the Recovery Appliances>"]
        ]   

        [-db_cred="<database target named credential>"]
        [-db_host_cred="<database host target named credential>"]

        [-download_backup_module] 
        [-force_install_backup_module]
        [-backup_module_directory="<full pathname where backup module will be installed on database hosts>"]

        [-wallet_location=USE_RECOMMENDED|"<full pathname of backup wallet location>"]
        [-wallet_cred="<named credential containing wallet credentials for a password-protected wallet>"]
        [-tde_wallet_cred="<named credential used to access a password protected Transparent Data Encryption wallet>"] 
        -force_update_wallet_loc] 
        [-force_crs_setenv]
        [-set_wallet_root] 

        [-ship_redo=YES|NO] 
        [-redo_transport_user_cred="<named credential for the redo transport user password>"]
        [ -ship_redo_from_standby]


        [-skip_controlfile_autobackup]
        [-update_snapshot_controlfile_loc]
        [-parallelism=<# of channels to set in database RMAN settings for Recovery Appliance backups>]

        [-force_restart_db] 
        [-db_restart_permitted] 
        [-skip_configured_dbs]
        [-force_serial_execution]
        
        [-schedule=
            { 
                start_time:yyyy/MM/dd HH:mm; 
                tz:{java timezone ID}; 
                frequency:interval/weekly/monthly/yearly; 
                repeat:#m|#h|#d|#w; 
                months:#,#,...; 
                days:#,#,...; 
                end_time:yyyy/MM/dd HH:mm; 
            }
        ]

Options

For each parameter, it is noted whether the argument is required (either on the command line or in the input file), what the default is if it's not required, and whether it can be specified for individual targets in an input file (i.e., whether the parameter can be set on a per-database or per-group basis when the command is run against multiple databases and/or groups). Required arguments can be specified either on the command line or in an input file. When an input file is used, command line argument values globally apply to all targets listed in the input file, while per-target parameter values specified in the input file override the corresponding command line argument values.

The following conventions are used for the attribute values in the argument descriptions:

  • Required: Whether the argument is required on either the command line or in an input file, and if so under what conditions.
  • Default: For optional arguments, whether there is a default value.
  • Scope:
    • Command Line Only: The argument can be specified only on the command line, not in an input file, and will apply globally to all database targets involved in the command.
    • Input File Only: The argument can be specified only in the input file, at a per-target level.
    • Both: The argument can be specified on either the command line, in the input file, or both. If specified in both places, the value in the input file will override the corresponding command line argument value.
backup_config="NO_DG|ALL_DG|CUSTOM_DG|GOLD|GOLD_WITH_REP"

Specifies the databases that will be configured by this command. A single invocation of the command can operate only on a set of databases that are either Data Guard databases (i.e., primary or standby databases in a Data Guard configuration) or non-Data Guard databases (i.e., not primary or standby databases and not members of a Data Guard configuration). If the set of databases to be configured include a combination of Data Guard and non-Data Guard databases, the command should be invoked twice: once for the Data Guard databases and once for the non-Data Guard databases.

  • Required: Yes
  • Scope: Command Line Only
  • NO_DG:
    • Only non-Data Guard databases will be configured to send backups and redo to the Recovery Appliance(s) specified.
  • ALL_DG:

    Only the primary databases in one or more Data Guard configurations can be specified as a target (on the command line or in an input file). The Recovery Appliance(s) specified for the database(s) will be integrated into the Data Guard configuration via the following steps:

    1. All existing Recovery Appliances in the Data Guard broker configuration will be removed and any REDO_ROUTES if set, are altered accordingly.
    2. All the databases in a Data Guard configuration will be configured to send backups to the Recovery Appliance specified for the primary database (backups can later be scheduled from any of the databases).
    3. The specified Recovery Appliance will be added as a member of the Data Guard broker configuration.
    4. If there are no redo routes currently defined for a Data Guard configuration, the redo transport will be enabled from the primary database to the Recovery Appliance. Although all databases in the Data Guard configuration will have the basic settings required to send redo, redo transport will only be enabled from the primary database. If redo routes are currently defined for a Data Guard configuration, the Recovery Appliances will be added to the broker configuration but will not receive redo from any member. After the initial configuration performed by this command, the redo transport settings within the Data Guard configuration can be changed via the Edit Properties page in Data Guard Administration using Enterprise Manager or directly using Data Guard broker commands.
    Restrictions:
    • If multiple databases in a Data Guard configuration are specified as targets, only the settings specified for primary database will be considered for all the members of the Data Guard configuration.
    • If a group target is specified on the command line or in the input file in conjunction with this option, only Data Guard configurations that have their Primary database as a member of the specified group will be considered.
    • Preferred database credentials and preferred database host credentials must be present for all databases. If this is not available for all databases in a Data Guard configuration, the configuration procedure will fail and report an error for all databases in this configuration.
  • CUSTOM_DG:

    One or more of the databases in one or more Data Guard configurations - the primary database and some/all standby databases - can be specified as targets in an input file. Each database can be designated to send backups to the same or different Recovery Appliances. The specified Recovery Appliance(s) will be integrated into the Data Guard configuration via the following steps:

    • All existing Recovery Appliances in the Data Guard broker configuration will be removed and any REDO_ROUTES if set, are altered accordingly.
    • Each specified database will be configured to send backups to its designated Recovery Appliance. Databases in a Data Guard configuration not explicitly specified as targets will not be configured for backup and any existing backup configuration for these databases will be reset/cleared.
    • The specified Recovery Appliance(s) will be added as members of the associated Data Guard broker configuration.
    • If there are no redo routes currently defined for a Data Guard configuration, redo transport will be enabled from the primary database to all Recovery Appliances. If redo routes are currently defined for a Data Guard configuration, the Recovery Appliances will be added to the broker configuration but will not receive redo from any member. After the initial configuration performed by this command, the redo transport settings within the Data Guard configuration can be changed via the Edit Properties page in Data Guard Administration using Enterprise Manager or directly using Data Guard broker commands.
    • Regardless of which databases in a Data Guard configuration are specified, the redo transport user setting will be changed on the primary database to accommodate the integrated Recovery Appliance(s), and that setting (along with the primary database password file) will be propagated to all standby databases.
    Restrictions:
    • If a group target is specified on the command line, only targets that are actually part of that group will be configured. The primary database in a Data Guard configuration must be included in the group.
    • An individual group can only be targeted to send backups to a single Recovery Appliance. If the primary and standby databases need to send backups to different Recovery Appliances, they must be members of different groups and these groups should be specified in an input file. The primary database must be a member of one of the groups specified in the input file.
  • GOLD (This option is available if the Zero Data Loss Recovery Appliance Management Pack is enabled):

    The Data Guard configuration must contain only one standby database and both the primary and the standby database must be specified as targets in the input file. The Recovery Appliance specified for the standby database must be different from the one specified for the primary database. The specified Recovery Appliances will be integrated into the Data Guard configuration via the following steps:

    • All existing Recovery Appliances in the Data Guard broker configuration will be removed and any REDO_ROUTES if set, are altered accordingly.
    • Each database will be configured to send backups to its designated Recovery Appliance.
    • Both Recovery Appliances will be added as members of the associated Data Guard broker configuration.
    • Redo routes will be set for both the primary and standby database to ship redo to their respective Recovery Appliances.
  • GOLD_WITH_REP (This option is available if the Zero Data Loss Recovery Appliance Management Pack is enabled):

    The Data Guard configuration must contain only one standby database and both the primary and the standby database must be specified as targets in the input file. The Recovery Appliance specified for the standby database must be different from the one specified for the primary database. Both Recovery Appliances must be in a Backup Anywhere Replication configuration and the databases must be part of a replicating protection policy. The specified Recovery Appliances will be integrated into the Data Guard configuration via the following steps:

    • All existing Recovery Appliances in the Data Guard broker configuration will be removed and any REDO_ROUTES if set, are altered accordingly.
    • Each database will be configured to send backups to its designated Recovery Appliance.
    • Both Recovery Appliances will be added as members of the associated Data Guard broker configuration.
    • If the ship_redo_from_standby option is specified, redo routes will be set so that only the standby database will ship redo to its Recovery Appliance.
    • If the ship_redo_from_standby option is not specified, redo routes will be set so that the primary database will ship redo to its Recovery Appliance.
  • target_name="<database or group target name>"

    Enterprise Manager target name of a single-instance database or cluster database that will be configured as a protected database, or else a group for which all member databases will be configured. (Multiple databases can be configured either by specifying a group target or by using the input_file option below.)

    • Required: Yes
    • Scope: Both
  • target_type="oracle_database|rac_database|composite"

    Target type corresponding to the target specified by -target_name. Allowed target types are single-instance database (oracle_database), cluster database (rac_database), or group (composite).

    • Required: Yes
    • Scope: Both
  • input_file="target_list:<full pathname of input file>"

    A file containing information for multiple databases and/or group targets. This is an alternative to the -target_name parameter that can be used when there are multiple databases to be configured with one or more Recovery Appliances. The entries in the file mirror the command-line parameters.

    • Required:
      • Command Line: Yes, unless -target_name is specified. (Either -target_name or -input_file must be specified.)
      • Input File: Not applicable.
    • Scope: Command Line Only

    The format of this file is as follows:

    • target_name and target_type are required for each database or group.
    • The following parameters are optional (conditionally if noted, otherwise entirely). They can be specified for some or all of the targets. If an option is not specified for a particular target, values specified on the command line for that option will be used for that target. If an option is present in both the input file and command line, the input file value overrides the command-line value.
      • ra_target_name (optional only if corresponding command line argument is specified and backup_config is not GOLD or GOLD_WITH_REP)
      • ra_vpc_username (optional only if corresponding command line argument is specified and backup_config is not GOLD or GOLD_WITH_REP)
      • ra_override_conn_desc
      • br_continuity
      • ra_local_vpc_username (can be specified only with the br_continuity flag)
      • br_continuity_override_conn_desc (can be specified only with the br_continuity flag)
      • db_cred
      • db_host_cred
      • force_install_backup_module
      • backup_module_directory
      • wallet_location
      • force_update_wallet_loc
      • set_wallet_root
      • wallet_cred
      • tde_wallet_cred
      • ship_redo
      • skip_controlfile_autobackup
      • update_snapshot_controlfile_loc
      • force_restart_db
      • db_restart_permitted
      • alternate_ra.0.target_name (can be specified only with the br_continuity flag; only one alternate Recovery Appliance can be specified for one target)
      • alternate_ra.0.ra_override_conn_desc (can be specified only with the br_continuity flag; only one alternate Recovery Appliance can be specified for one target)

    • Input file format, showing optional parameters specified across four databases:

      target.0.target_name="<database #1 target name or group target name>"
target.0.target_type=<oracle_database|rac_database|composite>
target.0.db_cred="<database named credential for database #1 or common credential for all databases in group target>"
target.0.db_host_cred="<database host named credential for database #1>"
target.0.ra_target_name="<target name of Recovery Appliance for which database #1 is to be configured (or multiple databases if target_name is group)>"
target.0.ra_vpc_username="<Recovery Appliance virtual private catalog username for database #1>"
target.0.force_install_backup_module
target.0.wallet_location=USE_RECOMMENDED
target.0.ship_redo=YES
target.1.target_name="<database #2 target name or group target name>"
target.1.target_type=<oracle_database|rac_database|composite>
target.1.db_cred="<database named credential for database #2>"
target.1.db_host_cred=<database host named credential for database #2>
target.1.ra_target_name="<target name of Recovery Appliance for which database #2 is to be configured (or multiple databases if target_name is group)>"
target.1.ra_vpc_username="<Recovery Appliance virtual private catalog user common to both Recovery Appliances, same password on both Recovery Appliances>"
target.1.skip_controlfile_autobackup
target.1.force_restart_db
target1.db_restart_permitted
target.1.br_continuity
target.1.db_restart_permitted
target.1.wallet_location="<full pathname of backup wallet location for database #2>"
target.1.wallet_cred="<named credential containing wallet credentials for a password-protected backup wallet for database #2>"
target.1.alternate_ra.0.target_name="<Alternate Recovery Appliance target name for database #2>"
target.1.alternate_ra.0.ra_override_conn_desc="<Alternate Recovery Appliance override connect descriptor for database #2>"
target.2.target_name=<database #3 target name or group target name>"
target.2.target_type=<oracle_database|rac_database|composite>
target.2.db_cred="<database named credential for database #3>"
target.2.db_host_cred=<database host named credential for database #3>
target.2.ra_target_name="<target name of Recovery Appliance for which database #3 is to be configured (or multiple databases if target_name is group)>"
target.2.ra_vpc_username="<Recovery Appliance virtual private catalog username for database #3>"
target.2.redo_transport_user_cred=\"<named credential for the redo transport user password #3>
target.2.tde_wallet_cred=\"<named credential used to access a password protected Transparent Data Encryption wallet for database #3>
target.2.update_snapshot_controlfile_loc
target.3.target_name="<database #4 target name or group target name>"
target.3.target_type=<oracle_database|rac_database|composite>
target.3.db_cred="<database named credential for database #4>"
target.3.db_host_cred=<database host named credential for database #4>
target.3.ra_target_name="<target name of Recovery Appliance for which database #4 is to be configured (or multiple databases if target_name is group)>"
target.3.ra_vpc_username="<Recovery Appliance virtual private catalog user common to both Recovery Appliances, same password on both Recovery Appliances>"
target.3.br_continuity
target.3.ra_local_vpc_username="<Optional Recovery Appliance virtual private catalog user valid for both Recovery Appliances with different passwords on both Recovery Appliances>"
target.3.alternate_ra.0.target_name="<Alternate Recovery Appliance target name for database #4>"
target.3.ra_override_conn_desc="<Recovery Appliance override connect descriptor for database #4>"
target.3.br_continuity_override_conn_desc="<Recovery Appliance backup and recovery continuity override connect descriptor for database #4>"
target.3.alternate_ra.0.ra_override_conn_desc="<Alternate Recovery Appliance override connect descriptor for database #4>"
  • ra_target_name="<Recovery Appliance target name>"

    The target name of the Recovery Appliance that the specified databases will be configured to send backups to. If specified along with the br_continuity flag, this will be used as the preferred Recovery Appliance to send backups and redo to.

    • Required: Yes
    • Scope: Both
  • ra_vpc_username="<Recovery Appliance virtual private catalog username>"

    The name of the Recovery Appliance database virtual private catalog user that will be used to send backups to and ship redo to the Recovery Appliance for all specified databases. This must be a virtual private catalog user, not the Recovery Appliance administrator user. If specified along with the br_continuity flag, this must be a common virtual private catalog user for both the preferred and alternate Recovery Appliances and must have the same password on both appliances. If this is specified along with the br_continuity and ra_local_vpc_username is also provided, this virtual private catalog user will only be used in the initial RMAN connection to determine which Recovery Appliance will be used for backups and redo. The user specified by ra_local_vpc_username will be used for sending the actual backups and redo.

    • Required: Yes
    • Scope: Both
  • ra_override_conn_desc="<Recovery Appliance database override connect descriptor>"

    A TNS connect descriptor for the Recovery Appliance that will be used by the database to send backups and redo to the Recovery Appliance. If specified, this connect descriptor overrides the default Enterprise Manager connect descriptor for the Recovery Appliance target. The value can be a full connect descriptor, an Easy Connect string, or a TNS alias. If specified along with br_continuity, this connect descriptor will be used for connections to the preferred Recovery Appliance.

    • Required: No
    • Default: Use the default Enterprise Manger connect descriptor for the Recovery Appliance target.
    • Scope: Both
  • br_continuity (This option is available if the Zero Data Loss Recovery Appliance Management Pack is enabled)

    Option to enable backup and recovery continuity. Use this option to configure the database(s) such that backups and redo are sent to an alternate Recovery Appliance when the preferred Recovery Appliance is unavailable. The database(s) must be enrolled with both Recovery Appliances in a replicating protection policy. This option is supported with NO_DG, GOLD and GOLD_WITH_REP backup configuration options.

    • Required: No
    • Default: Use single Recovery Appliance to send backups and redo.
    • Scope: Command Line Only
  • alternate_ra_target_name="<alternate Recovery Appliance target name>"

    The target name of the alternate Recovery Appliance that the databases will be configured to send backups and redo to when the preferred Recovery Appliance is unavailable. This option is valid only when specified along with the br_continuity option.

    • Required: Yes, if br_continuity flag is specified.
    • Scope: Both
  • ra_local_vpc_username="<Recovery Appliance local virtual private catalog username>"

    The name of the Recovery Appliance database virtual private catalog user that will be used to send backups and redo to the Recovery Appliance(s) for all specified databases if the br_continuity option is specified. This must be a virtual private catalog user, not the Recovery Appliance administrator user. This user could have different passwords across the Recovery Appliances. This option is valid only when specified along with the br_continuity option.

    • Required: No
    • Default: Use common virtual private catalog user to send backups and ship redo to.
    • Scope: Both
  • alternate_ra_override_conn_desc="<alternate Recovery Appliance override connect descriptor>"

    A TNS connect descriptor for the alternate Recovery Appliance that will be used by the database while sending backups and redo. If specified, this connect descriptor overrides the default Enterprise Manager connect descriptor for the alternate Recovery Appliance target. The value can be a full connect descriptor, an EZCONNECT descriptor, or a TNS alias. This is valid only when specified with the br_continuity option.

    • Required: No
    • Default: Use the default Enterprise Manger connect descriptor for the alternate Recovery Appliance target.
    • Scope: Both
  • br_continuity_override_conn_desc="<Backup and Recovery Continuity override connect descriptor for the Recovery Appliance>"

    A TNS connect descriptor which will be used to determine which Recovery Appliance will be used for backups in this Backup And Recovery Continuity configuration. If specified, this descriptor overrides the default Backup and Recovery Continuity descriptor constructed by Enterprise Manager. The value can be a full connect descriptor or a TNS alias. An EZCONNECT descriptor cannot be specified. This option is valid only when specified along with the br_continuity option.

    • Required: No
    • Default: Use the default Enterprise Manger Recovery Appliance backup and recovery continuity connect descriptor.
    • Scope: Both
  • db_cred="<database target named credential>"

    The name of an existing Enterprise Manager database named credential for a SYSDBA or SYSBACKUP role user that can be used to connect to all the specified target databases. If this argument is not specified, preferred credentials will be used. If multiple databases are specified in an input file, this should be a global named credential.

    • Required: No
    • Default: Preferred database credentials for database target type.
    • Scope: Both
  • db_host_cred="<database target host named credential>"

    The name of an existing Enterprise Manager database host named credential that can be used to run operating system commands on the specified target database hosts. The credential should be for a user that has write permission for all Oracle homes. If this argument is not specified, preferred credentials will be used. If multiple database hosts are specified in an input file, this should be a global named credential.

    • Required: No
    • Default: Preferred host credentials for database target type.
    • Scope: Both
  • download_backup_module

    Download the latest version of the Recovery Appliance backup module for all supported operating systems from the Oracle Cloud and upload them to the Enterprise Manager software library during the deployment procedure, so that they will then be available for deployment and installation for all databases being processed later in the procedure.

    • Required: No
    • Default: Do not download new backup module versions.
    • Scope: Both

    The following conditions apply to this argument:

    • If it is desired to install the latest available backup module version on all databases, this argument should be specified in conjunction with -force_install_backup_module.

    • This argument should not be specified if it is desired to maintain strict control of the backup module version on all databases. In that case, the desired backup module versions can be obtained and uploaded manually to the software library using the emcli configure_db_ha -uploadBackupModule command.
    • If this argument is specified but Enterprise Manager does not have external internet connectivity, backup module download will be skipped.
  • force_install_backup_module

    Force installation of the version of the Recovery Appliance backup module stored in the Enterprise Manager software library into the Oracle homes of the specified target databases, regardless of whether there is an existing backup module installed in the Oracle homes. This will overwrite any existing backup module, so this option should be selected only if it is known that the backup module version in the software library is the version desired to be installed on all the specified target databases. If this argument is not specified, the backup module will be installed only if there is no existing backup module installed in the Oracle home and there is a backup module version uploaded to the software library.

    • Required: No
    • Default: Do not install the backup module.
    • Scope: Both
  • backup_module_directory="<full pathname where backup module will be installed on database hosts>"

    The directory where the backup module will be installed on the database hosts. The directory must exist on all hosts.

    • Required: No
    • Default: ORACLE_HOME/lib
    • Scope: Both
  • wallet_location=USE_RECOMMENDED|"<full pathname of backup wallet location>"

    The location of an existing wallet that will be configured as the backup wallet, or if a wallet doesn't exist, the location where a new backup wallet will be created.

    • Required: No
    • Default: Create/Update wallet at location calculated by wallet handling algorithm described above.
    • Scope: Both

    Even if this flag is specified, the wallet location for creating/updating the wallet will be determined using the wallet handling algorithm described above. This parameter will only be considered if required based on the wallet handling algorithm described above.

  • force_crs_setenv

    Set the values of the required environment variables in the database Cluster Ready Services (CRS) settings via the SRVCTL command. This parameter should be specified if a wallet location using these variables is being configured (per the above wallet handling description) and these variables are not already set in CRS. If this parameter is not specified, backup and other RMAN operations may fail if the required environment variables are not set via the SRVCTL command in the CRS. This operation also needs database restart, so specifying db_restart_permitted parameter is recommended. If a restart is not permitted, CRS environment variables will be updated but will remain inactive until the next database restart.

    • Required: No
    • Default: Do not set the environment variables.
    • Scope: Both
  • force_update_wallet_loc

    Set the WALLET_LOCATION parameter in SQLNET.ORA to the location determined by the wallet handling algorithm described above.

    • Required: No
    • Default: Do not forcibly update WALLET_LOCATION in SQLNET.ORA.
    • Scope: Both

    The following conditions apply to this argument:

    • This argument should be specified if it is desired to change WALLET_LOCATION to the location specified by the -wallet_location argument. (In the absence of this argument, WALLET_LOCATION will be set only under the conditions described above in the description for the -wallet_location argument.)

    • This option should be used with caution, as it should be verified that the new wallet location will not perturb other database features that may be using an existing wallet.

  • set_wallet_root

    Set WALLET_ROOT initialization parameter to the value determined by the wallet handling algorithm described earlier.

    • Required: No
    • Default: Do not forcibly update WALLET_ROOT initialization parameter.
    • Scope: Both
  • wallet_cred="<named credential containing wallet credentials for a password-protected wallet>"

    Named credential used to create a new password-protected wallet or to update an existing password-protected wallet with the Recovery Appliance virtual private catalog user credentials used to connect to the Recovery Appliance

    • Required: No
    • Default: Create auto-login, non-password-protected wallet or assume existing wallet is not password-protected.
    • Scope: Both
  • -redo_transport_user_cred="<named credential for the redo transport user password>"

    The redo transport user will be created if it does not already exist when the -backup_config is specified for a Data Guard configuration.

    • Required: No
    • Default: The redo transport user will be created using a random password that is generated based on the password for the user specified by db_cred.
    • Scope: Both
  • tde_wallet_cred="<named credential used to access a password protected Transparent Data Encryption wallet>"

    Named credential used to access a password-protected Transparent Data Encryption wallet being used by the database.

    • Required: No
    • Default: Database restart will proceed under the assumption that the database is not Transparent Data Encryption enabled or that the Transparent Data Encryption wallet is an auto-login wallet.
    • Scope: Both
  • ship_redo=YES|NO

    Enable or disable real time redo transport from all specified databases to their respective Recovery Appliances. This argument is only valid when specified with -backup_config=NO_DG. If NO is specified and redo transport is currently enabled for any databases being configured, it will be disabled for those databases.

    • Required: No
    • Default: Do not alter the current redo transport settings.
    • Scope: Both
  • skip_controlfile_autobackup

    Do not enable RMAN control file autobackup for the databases. (Control file autobackup is recommended to be enabled when backing up to Recovery Appliance. If control file autobackup is already enabled for any databases, that setting is not altered.)

    • Required: No
    • Default: Enable controlfile autobackup.
    • Scope: Both
  • update_snapshot_controlfile_loc

    Configure the database snapshot control file location to the Fast Recovery Area if it is set, or else the same location as the database control file.

    • Required: No
    • Default: Do not alter the snapshot control file location.
    • Scope: Both
  • parallelism=<# of SBT channels to set in database RMAN settings for Recovery Appliance backups>

    Configure RMAN settings for all databases with the specified number of SBT channels for Recovery Appliance backups. This will result in the specified number of backup pieces being processed in parallel by each backup.

    • Required: No
    • Default: Do not alter the channel settings in the database RMAN settings.
    • Scope: Both
  • force_restart_db

    Restart database(s) after the configuration process, regardless of whether it was required by the configuration steps actually performed. A rolling restart will be performed for Real Application Cluster (RAC) databases. This argument should be used only for individual databases in cases where it is known those databases need to be restarted. Specifying this argument for a recurring procedure will cause all the databases to which it is applied to be restarted in every execution.

    • Required: No
    • Default: If this option is not specified, a rolling restart will be automatically performed only if a configuration operation was performed that requires a restart and db_restart_permitted flag is specified.
    • Scope: Both
  • db_restart_permitted

    Allow the configuration procedure to restart the database if deemed necessary. If force_restart_db flag is specified, the database will always be restarted, whether this parameter is specified or not.

    • Required: No
    • Default: Do not restart the databases even if any configuration operations performed require the database to be restarted.
    • Scope: Both
  • skip_configured_dbs

    While processing the databases in the deployment procedure, skip databases that were already configured as protected databases with their respective Recovery Appliances. All such skipped databases will be listed in the deployment procedure Initialization step output. This option is only applicable for group targets. If this option is specified when scheduling a recurring configuration procedure against one or more group targets, databases that were already configured are not needlessly reconfigured in subsequent procedure executions. In this scenario, each recurring execution of the procedure will process only databases that have joined the group since the last execution.

    • Required: No
    • Default: Process all databases in groups.
    • Scope: Command Line Only
  • force_serial_execution

    Run the Enterprise Manager configuration deployment procedure in serial mode, processing one database at a time.

    • Required: No
    • Default: Process all databases in parallel.
    • Scope: Command Line Only
  • protocol

    Database backups to the Recovery Appliance will be configured to occur using the specified protocol.

    • Required: No
    • Default: TCPS, if the Recovery Appliance if configured in either the TLS-only mode or dual mode. If not, TCP.
    • Scope: Both
  • ship_redo_from_standby

    This argument is only valid with backup_config=GOLD_WITH_REP. If specified, the redo routes will be set such that the standby database is the one that ships redo to its Recovery Appliance.

    • Required: No
    • Default: Redo routes will be set such that the primary database ships redo to its Recovery Appliance.
    • Scope: Command Line Only
  • schedule

    Schedule the deployment procedure. If this argument is not provided, the procedure will run immediately.

    • Required: No
    • Default: Schedule procedure for immediate execution.
    • Scope: Command Line Only

    Sub-arguments:

    • start_time - Time when the procedure has to start execution.
      • Format should be "yyyy/MM/dd HH:mm"
    • tz - The timezone ID (optional)
    • frequency - Valid values are once/interval/weekly/monthly/yearly. (optional)
      • If frequency is set to interval then repeat has to be specified.
      • If frequency is set to weekly or monthly, days has to specified.
      • If frequency is set to yearly, both days and months have to specified.
    • repeat - Frequency with which the procedure has to be repeated. (Required only if frequency is set to interval)
    • days - Comma separated list of days. (Required only if frequency is weekly, monthly, or yearly)
      • If frequency is weekly, then valid range is 1 to 7
      • If frequency is monthly or yearly, then valid range is 1 to 30
    • months - Comma separated list of months. (Required only if frequency is yearly)
      • Valid range is 1 to 12.
    • end_time - End time for procedure executions. (optional)
      • If it is not specified, procedure will run indefinitely.
      • Format should be "yyyy/MM/dd HH:mm"

Examples

Example 1

Configure one non-Data Guard single-instance database to send backups to and ship redo to a Recovery Appliance. Use named database and host credentials.

      emcli configure_db_ha -configureBackuptoRA -backup_config=NO_DG -ra_target_name="Chicago
      ZDLRA" -ra_vpc_username="rauser1" -target_name="Finance" -target_type="oracle_database"
      -db_cred="DB_USER" -db_host_cred="DB_HOST_USER" -ship_redo=YES
Example 2

Configure one non-Data Guard cluster database to send backups to a Recovery Appliance without transport redo, download and force installation of the backup module in the Oracle home of each cluster database instance. Use preferred database and host credentials.

	emcli configure_db_ha -configureBackuptoRA -backup_config=NO_DG ra_target_name="Chicago
      ZDLRA" -ra_vpc_username="rauser1" -target_name="Finance" -target_type="rac_database"
      -download_backup_module -force_install_backup_module
Example 3

Configure one non-Data Guard database to be in a Backup and Recovery Continuity configuration - to send backups and redo to a Recovery Appliance and if that Recovery Appliance was unavailable, to failover and send backups and redo to an alternate Recovery Appliance. Use a common virtual private catalog user account to send backups and ship redo. Use named database and host credentials.

emcli configure_db_ha -configureBackuptoRA
        -backup_config=NO_DG -ra_target_name="Chicago ZDLRA" -ra_vpc_username="common_rauser 
        -target_name=Finance  -target_type="rac_database" -db_cred="DB_USER"
        -db_host_cred="DB_HOST_USER" -ship_redo=YES -br_continuity
        -alternate_ra_target_name="Bombay ZDLRA"
Example 4

Configure one non-Data Guard database to be in a Backup and Recovery Continuity configuration - to send backups and redo to a Recovery Appliance and if that Recovery Appliance was unavailable, to failover and send backups and redo to an alternate Recovery Appliance. Use a common virtual private catalog user with same password across Recovery Appliances to determine the Recovery Appliance to be used and use another local virtual private catalog user (which can have different passwords across Recovery Appliances) to register database, send backups and ship redo to Recovery Appliances. Use named database and host credentials.

emcli configure_db_ha
          -configureBackuptoRA -backup_config=NO_DG -ra_target_name="Chicago ZDLRA"
          -ra_vpc_username="common_rauser" -ra_local_vpc_username="local_rauser"
          -target_name="Finance" -target_type="rac_database" -db_cred="DB_USER"
          -db_host_cred="DB_HOST_USER" -ship_redo=YES
          -br_continuity -alternate_ra_target_name="Bombay ZDLRA"
Example 5

Configure one non-Data Guard database to be in a Backup and Recovery Continuity configuration - to send backups and redo to a Recovery Appliance and if that Recovery Appliance was unavailable, to failover and send backups and redo to an alternate Recovery Appliance. Use a custom user provided Backup And Recovery Continuity Override Connect Descriptor to determine the Recovery Appliance to be used for backups and redo. Use named database and host credentials.

emcli configure_db_ha
          -configureBackuptoRA -backup_config=NO_DG  -ra_target_name="Chicago ZDLRA"
          -ra_vpc_username="common_rauser" -target_name="Finance" -target_type="rac_database"
          -db_cred="DB_USER" -db_host_cred="DB_HOST_USER" -ship_redo=YES -br_continuity
          -alternate_ra_target_name="Bombay ZDLRA"
          -br_continuity_override_conn_desc="My_RA_BR"
Example 6

Configure multiple non-Data Guard databases specified in an input file to send backups to and ship redo to a Recovery Appliance and force the installation of the backup module in the Oracle home of each database. Use named database and database host credentials.

	emcli configure_db_ha -configureBackuptoRA -backup_config=NO_DG -ra_target_name="Chicago
      ZDLRA" -ra_vpc_username="rauser1" -input_file="target_list:/tmp/dblist"  -db_cred="DB_USER" 
      -db_host_cred="DB_HOST_USER" -ship_redo=YES -force_install_backup_module
Example 7

Configure multiple Data Guard databases specified in an input file to send backups to a Recovery Appliance and force the installation of the backup module in the Oracle home of each database. Use named database and database host credentials. The primary database in the Data Guard configuration must be specified in the input file.

	emcli configure_db_ha -configureBackuptoRA -backup_config=CUSTOM_DG
      -ra_target_name="Chicago ZDLRA" -ra_vpc_username="rauser1" -input_file="target_list:/tmp/dblist"
      -db_cred="DB_USER" -db_host_cred="DB_HOST_USER" -force_install_backup_module
Example 8

Configure multiple non-Data Guard databases specified in a input file to send backups to and ship redo to a Recovery Appliance, but do not force the installation of the backup module. Use global named database and host credentials. Schedule the operation for a future time.

	emcli configure_db_ha -configureBackuptoRA -backup_config=NO_DG -ra_target_name="Chicago
      ZDLRA" -ra_vpc_username="rauser1" -input_file="target_list:/tmp/dblist" -db_cred="DB_USER"
      -db_host_cred="DB_HOST_USER" -ship_redo=YES -schedule="start_time:2020/10/28 18:31;tz:PST;"
Example 9

Configure database members of a group target to send backups and redo to a Recovery Appliance. Use preferred credentials for all databases. Schedule the procedure to execute on a daily recurring schedule, and do not process any databases in the group that were already enrolled during previous executions of the procedure (i.e., only databases that have joined the group since the last procedure execution are processed). The first invocation of the command will work on all non-Data Guard databases in the group while the second invocation will work on all Data Guard databases in the group. The primary database in the Data Guard configuration must be a part of the group.

	emcli configure_db_ha -configureBackuptoRA -backup_config=NO_DG -ra_target_name="Chicago
      ZDLRA" -ra_vpc_username="rauser1" -target_name="Backup_Group" -target_type=composite
      -ship_redo=YES -skip_configured_dbs -schedule="start_time:2020/10/10 01:00;tz:PST;frequency:interval;repeat:1d"
	emcli configure_db_ha -configureBackuptoRA -backup_config=CUSTOM_DG
      -ra_target_name="Chicago ZDLRA" -ra_vpc_username="rauser1" -target_name="Backup_Group"
      -target_type=composite  -skip_configured_dbs -schedule="start_time:2020/10/10 04:00;tz:PST;frequency:interval;repeat:1d"
Example 10

Configure multiple non-Data Guard databases with multiple Recovery Appliances using an input file. Provide command line values for database credentials applicable to all databases, and specify that the latest backup module should be downloaded to the software library. Provide per-database values in the input file for backup module install, redo transport, wallet location, and snapshot control file settings.

	emcli configure_db_ha -configureBackuptoRA -backup_config=NO_DG -input_file="target_list:/tmp/dblist"
      -db_cred="DB_USER" -download_backup_module

The input file used in this example specifies three databases, two associated with one Recovery Appliance and one associated with a different Recovery Appliance. None of the databases are in a Data Guard configuration. The options vary across the databases as follows:

  • FinanceDB
    • ZDLRA: Montreal ZDLRA
    • VPC user: rauser1
    • Redo transport: Enable.
    • Backup module: Install.
    • Wallet: Use recommended location, force update of WALLET_LOCATION in SQLNET.ORA.
    • Snapshot control file: Set to shared location.
    • Parallel backup channels: 2
  • SalesDB
    • ZDLRA: Montreal ZDLRA
    • VPC user: rauser2
    • Redo transport: Disable.
    • Backup module: Do not install.
    • Wallet: Use default wallet if databases already configured with default wallet, otherwise set to ZDLRA default location; do not force WALLET_LOCATION update.
  • MarketingDB
    • ZDLRA: Boston ZDLRA
    • VPC user: rauser1
    • Redo transport: Keep existing settings.
    • Backup module: Install.
    • Wallet: Use custom location, force update of WALLET_LOCATION in SQLNET.ORA.
    • Parallel backup channels: 4

The input file is as follows:

target.0.ra_target_name="Montreal ZDLRA"
target.0.ra_vpc_username="rauser1"
target.0.target_name="FinanceDB"
target.0.target_type="rac_database"
target.0.force_install_backup_module
target.0.ship_redo=YES
target.0.wallet_location=USE_RECOMMENDED
target.0.force_update_wallet_loc
target.0.update_snapshot_controlfile_loc
target.0.parallelism=2
target.0.protocol=TCPS
target.1.ra_target_name="Montreal ZDLRA"
target.1.ra_vpc_username="rauser2"
target.1.target_name="SalesDB"
target.1.target_type="oracle_database"
target.1.ship_redo=NO
target.1.protocol=TCPS
target.2.ra_target_name="Boston ZDLRA"
target.2.ra_vpc_username="rauser1"
target.2.target_name="MarketingDB"
target.2.target_type="rac_database"
target.2.force_install_backup_module
target.2.wallet_location="/prod/db/wallet/$ORACLE_UNQNAME"
target.2.force_update_wallet_loc
target.2.parallelism=4
Example 11

Configure all databases in one Data Guard configuration to send backups to a Recovery Appliance by specifying the primary database in this Data Guard configuration. Download and force installation of the backup module in the Oracle home of each database instance. Use preferred database and host credentials.

	emcli configure_db_ha -configureBackupToRA -backup_config="ALL_DG"
      -ra_target_name="Chicago ZDLRA" -ra_vpc_username="rauser1"
      -target_name="OrclPrimary" -target_type="oracle_database" -download_backup_module
      -force_install_backup_module
Example 12

Configure multiple groups of Data Guard databases with multiple Recovery Appliances using an input file that contains multiple group targets. Schedule the procedure to execute on a daily recurring schedule, and do not process any databases in the groups that were already enrolled during previous executions of the procedure (i.e., only databases that have joined the groups since the last procedure execution are processed). Provide command line values specifying that the latest backup module should be installed for all databases. Provide per-database values in the input file for database credentials, redo transport, wallet location, and snapshot control file settings.

	emcli configure_db_ha -configureBackupToRA -backup_config="CUSTOM_DG"
      -input_file="target_list:/tmp/dblist" -skip_configured_dbs -download_backup_module -force_install_backup_module
      -schedule="start_time:2020/10/10 01:00;tz:PST;frequency:interval;repeat:1d"

Multiple Data Guard configuration databases are involved in the groups specfied in this input list. Group membership for these Data Guard databases is shown below. Data Guard databases in groups G1, G2 and G3 will be configured when this command is run with the input file shown. Data Guard databases that are standalone or in a group not included in the input file are not configured. DGConfiguration4 databases are all ignored since the primary database in this configuration is not present in one of the groups specified in the input file.

  • DGConfiguration1
    • Primary DB: ORCL12 - Group G1
    • Standby DB: ORCL12Stby - Group G2
    • Standby DB: ORCLStby2 - Group G3
    • Standby DB: ORCLStby3 - standalone
  • DGConfiguration2
    • Primary DB: DB19 - Group G1
    • Standby DB: DB19Stby - Group G1
    • Standby DB: DB19Stby2 - Group G2
  • DGConfiguration3
    • Primary DB: DBx - Group G2
    • Standby DB: DBxStby - Group G1
    • Standby DB: DBxStby2 - Group G3
    • Standby DB: DBxStby3 - Group G4
  • DGConfiguration4
    • Primary DB: DB18 - Group G4
    • Standby DB: DB19Stby - Group G1
    • Standby DB: DB19Stby2 - Group G2

The input file used in this example specifies three groups, each associated with a different Recovery Appliance. Each group is also associated with a specific set of parameter values. The options vary across the groups as follows:

  • Group G1
    • ZDLRA: Montreal ZDLRA
    • VPC user: rauser1
    • Wallet: Use recommended location, force update of WALLET_LOCATION in SQLNET.ORA.
    • Snapshot control file: Set to shared location.
    • Parallel backup channels: 2
  • Group G2
    • ZDLRA: Boston ZDLRA
    • VPC user: rauser1
  • Group G3
    • ZDLRA: Barcelona ZDLRA
    • VPC user: rauser2
    • Wallet Use recommended location

The input file is as follows:

target.0.ra_target_name="Montreal ZDLRA"
target.0.ra_vpc_username="rauser1"
target.0.target_name="G1"
target.0.target_type="composite"
target.0.db_cred="DB_SYSDBA_MONTREAL"
target.0.db_host_cred="HOST_MONTREAL"
target.0.wallet_location=USE_RECOMMENDED
target.0.force_update_wallet_loc
target.0.update_snapshot_controlfile_loc
target.0.parallelism=2
target.1.ra_target_name="Boston ZDLRA"
target.1.ra_vpc_username="rauser1"
target.1.target_name="G2"
target.1.target_type="composite"
target.1.db_cred="DB_SYSDBA_BOSTON"
target.1.db_host_cred="HOST_BOSTON"
target.2.ra_target_name="Barcelona ZDLRA"
target.2.ra_vpc_username="rauser2"
target.2.target_name="G3"
target.2.target_type="composite"
target.2.db_cred="DB_SYSDBA_BARCELONA"
target.2.db_host_cred="HOST_BARCELONA"
target.2.wallet_location=USE_RECOMMENDED
Example 13
Configure all databases in one Data Guard configuration to send backups to a Recovery Appliance by specifying the primary database in this Data Guard configuration. Download and force installation of the backup module in the Oracle home of each database instance. Use preferred database and host credentials. The redo transport user will be created using password from the named credential RTU_CREDS.
emcli configure_db_ha -configureBackupToRA 
-backup_config="ALL _DG"
-ra_target_name="Chicago ZDLRA" 
-ra_vpc_username="rauser1" 
-target_name="OrclPrimary"
-target_type="oracle_database" 
-download_backup_module 
-force_install_backup_module
-redo_transport_user_cred="RTU_CREDS"
Example 14

Configure multiple Data Guard configurations having exactly one standby database along with primary database to send backups and ship redo to corresponding set of Recovery Appliances in either GOLD or GOLD_WITH_REP configurations, specifying the databases in the input file.

  • For GOLD configuration:
    emcli configure_db_ha -configureBackupToRA -backup_config="GOLD" -input_file="target_list:/tmp/dblist"
  • For GOLD_WITH_REP configuration: 
    emcli configure_db_ha -configureBackupToRA -backup_config="GOLD_WITH_REP" -input_file="target_list:/tmp/dblist"
  • For GOLD_WITH_REP configuration with standby database shipping redo to corresponding Recovery Appliance instead of primary database: 
    emcli configure_db_ha -configureBackupToRA -backup_config="GOLD_WITH_REP" -input_file="target_list:/tmp/dblist" -ship_redo_from_standby

Multiple Data Guard configuration databases involved are as follows: 

DGConfiguration1
Primary DB: ORCL12 - Recovery Appliance RA_1
Standby DB: ORCL12Stby - Recovery Appliance RA_2
DGConfiguration2
Primary DB: DB19 - Recovery Appliance RAx
Standby DB: DB19Stby - Recovery Appliance RAy

The input file (remains same) for all three cases is as follows:

target.0.ra_target_name="RA_1"
target.0.ra_vpc_username="rauser1"
target.0.target_name="ORCL12"
target.0.target_type="oracle_database"
target.0.db_cred="DB_SYSDBA"
target.0.db_host_cred="HOST_1"
target.1.ra_target_name="RA_2"
target.1.ra_vpc_username="rauser1"
target.1.target_name="ORCL12Stby"
target.1.target_type="oracle_database"
target.1.db_cred="DB_SYSDBA"
target.1.db_host_cred="HOST_2"
target.2.ra_target_name="RAx"
target.2.ra_vpc_username="ra_vpc1"
target.2.target_name="DB19"
target.2.target_type="rac_database"
target.2.db_cred="DB_SD"
target.2.db_host_cred="HOST_xy"
target.3.ra_target_name="RAy"
target.3.ra_vpc_username="ra_vpc1"
target.3.target_name="DB19Stby"
target.3.target_type=rac_database"
target.3.db_cred="DB_Cred"
target.3.db_host_cred="HOST_ab"
Example 15

Configure multiple Data Guard configurations having exactly one standby database along with primary database to send backups and ship redo to corresponding set of Recovery Appliances in either GOLD or GOLD_WITH_REP configurations, specifying the databases in the input file while also specifying an alternate Recovery Appliance corresponding to each Recovery Appliance.

  • For GOLD configuration:
    emcli configure_db_ha -configureBackupToRA -backup_config="GOLD" -input_file="target_list:/tmp/dblist" -br_continuity
  • For GOLD_WITH_REP configuration: 
    emcli configure_db_ha -configureBackupToRA -backup_config="GOLD_WITH_REP" -input_file="target_list:/tmp/dblist"  -br_continuity
  • For GOLD_WITH_REP configuration with standby database shipping redo to corresponding Recovery Appliance instead of primary database: 
    emcli configure_db_ha -configureBackupToRA -backup_config="GOLD_WITH_REP" -input_file=\"target_list:/tmp/dblist\" -ship_redo_from_standby  -br_continuity

Multiple Data Guard configuration databases involved are as follows: 

DGConfiguration1
Primary DB: ORCL12 - Recovery Appliance RA_1a and alternate Recovery Appliance RA_1b
Standby DB: ORCL12Stby - Recovery Appliance RA_2a and alternate Recovery Appliance RA_2b
DGConfiguration2
Primary DB: DB19 - Recovery Appliance RAx1 and alternate Recovery Appliance RA_x2
Standby DB: DB19Stby - Recovery Appliance RAy1 and alternate Recovery Appliance RA_y2

The input file (remains same) for all three cases is as follows:

target.0.ra_target_name="RA_1a"
target.0.alternate_ra.0.target_name="RA_1b"
target.0.ra_vpc_username="rauser1"
target.0.target_name="ORCL12"
target.0.target_type="oracle_database"
target.0.db_cred="DB_SYSDBA"
target.0.db_host_cred="HOST_1"
target.1.ra_target_name="RA_2a"
target.1.ra_vpc_username="rauser1"
target.1.target_name="ORCL12Stby"
target.1.target_type="oracle_database"
target.1.alternate_ra.0.target_name="RA_2b"
target.1.db_cred="DB_SYSDBA"
target.1.db_host_cred="HOST_2"
target.2.ra_target_name="RAx1"
target.2.ra_vpc_username="ra_vpc1"
target.2.target_name="DB19"
target.2.target_type="rac_database"
target.2.db_cred="DB_SD"
target.2.db_host_cred="HOST_xy"
target.2.alternate_ra.0.target_name="RA_x2"
target.3.ra_target_name="RAy1"
target.3.alternate_ra.0.target_name="RA_y2"
target.3.ra_vpc_username="ra_vpc1"
target.3.target_name="DB19Stby"
target.3.target_type="rac_database"
target.3.db_cred="DB_Cred"
target.3.db_host_cred="HOST_ab"