Limited supportBMC provides limited support for this version of the product. As a result, BMC no longer accepts comments in this space. If you encounter problems with the product version or the space, contact BMC Support.BMC recommends upgrading to the latest version of the product. To see documentation for that version, see High-speed Apply Engine 13.1.

Configurations for specific tasks

This section provides instructions on how to define configurations for several specific uses of the High-speed Apply Engine.

Mapping source object names to target objects

If the table or column names in the input file differ from those in the target database, you can use this procedure to help you configure the apply request to map the source object names to the target objects.

The following figure shows the relationships described in this procedure.

GUID-BA5C03BA-7EE9-4A58-A37D-B3BD406ED7E3-low.png

Before you edit the configuration, you should determine which source and target object names will be mapped in the configuration. The target object names that you specify must exist when you run an apply request that requires them. For more information about the parameters in this procedure, see ObjectMap parameters.

Important

You can use wildcard patterns to specify groups of objects. For more information, see Using-wildcards-to-map-object-names.

To map a source table to a target table

  1. Create or edit a configuration file as described in Creating or editing a configuration file.
  2. Add the [ObjectMap] section name to the configuration file.

  3. Specify a SourceTable parameter in the [ObjectMap] section, as follows:

    SourceTable=tableName

    A source table name is a table name specified in the input file. This table can reside on a different Db2 subsystem, Db2 LUW database, or Oracle instance than the target table. High-speed Apply Engine does not validate the existence of the source table. The name must conform to the conventions that are described in Object-names-in-configuration-files.

  4. Specify a TargetTable parameter, as follows:

    TargetTable=tableName

    The target table name you specify must be the target for the changes that would otherwise be applied to the source table that you specified in Step 3. The target table must reside on the same subsystem or server as High-speed Apply Engine. The name must conform to the conventions that are described in Object-names-in-configuration-files.

  5. If the column names differ between the source and target table, specify a SourceColumn and TargetColumn parameter for each column that needs to be mapped. (If the columns are the same for both tables, you can proceed to Step 6.)

    SourceColumn=source01
    TargetColumn=target01
    SourceColumn=source02
    TargetColumn=target02

    The column name parameters must follow the corresponding TargetTable parameter. Each SourceColumn parameter must be followed by a TargetColumn parameter. The target column names must exist when you run the apply request.

  6. Repeat steps 3,4 and 5 until you have mapped all object names that are required for the apply request.
  7. Save the configuration file.When you run an apply request that refers to the configuration file, High-speed Apply Engine maps the object names in the input file according to the parameters in the [ObjectMap] section.

If you receive error messages about the object names specified in the [ObjectMap] section, check the configuration file for the following common problems:

  • Verify that the [ObjectMap] parameters are in the correct order.
  • Verify that the target objects that are specified by the TargetTable and TargetColumn parameters exist in the Db2 subsystem, Db2 LUW database, or Oracle instance where you ran the apply request. 

Creating logical partitions for target tables

Use this procedure to create logical partitions for a target table to change the workload distribution for an apply request.


GUID-2DD796EB-8110-4D15-B664-F17EA0D41A7D-low.png

Before you begin

To define logical partitions, you must know the column name and value that represent the upper limit of each partition. For a Db2 mainframe target, you can also use a limit key value to define the partition.

The order of the parameters in the [ObjectPartition] section is significant. The steps in this procedure describe the required order. For more information, see Positional-requirements-for-ObjectPartition-parameters.

If you create logical partitions for a table that is physically partitioned, High-speed Apply Engine ignores the physical partitions and uses the logical partitions for workload distribution.

High-speed Apply Engine can create partition keys from the columns and values that you specify within the partition definition. The partition key length has the following limitations:

  • For Oracle and Db2 LUW targets, the partition key is truncated after 256 bytes. Specify unique key values within the first 256 bytes of the partition definition.
  • For Db2 mainframe targets, the partition key is truncated after 255 bytes. Specify unique key values within the first 255 bytes of the partition definition.

To define logical partitions for apply processing

  1. Create or edit a configuration file as described in Creating or editing a configuration file.
  2. Add the [ObjectPartition] section name to the configuration file.
  3.  Specify the table that you want to partition by using the TableName parameter.The table that you specify must exist on the target Db2 subsystem, Db2 LUW database, or Oracle instance.
  4.  Specify a Column parameter for a column to be used in the partition definition.

  5.  (optional) For Db2 mainframe targets, specify an Order parameter for the column, if necessary.This parameter is optional. You can specify either ascending (ASC) or descending (DESC) order for the corresponding column. The Order parameter must immediately follow its associated Column parameter.

    If you do not include an Order parameter for a column, the default sort order is ascending.

  6. Repeat Step 3 and Step 4 for each column that you want to use in the partition definition.
  7. Define the upper limits for a partition as follows:
    1. Specify a Partition parameter.The Partition parameter indicates the start of a partition definition. You must specify this parameter at least one time in the [ObjectPartition] section, but you do not need to specify a value for it. If you do specify a value, it appears in the informational messages for the apply request.
    2. Specify the upper limit for the partition with a Value parameter (or with a LimitKey parameter) for each of the Column parameters you defined in Step 4.
      • The Value parameter represents the upper limit of the partition for the associated column. You must specify the Value parameters in the same order as the Column parameters. If the order is incorrect, High-speed Apply Engine cannot process the apply request.
      • If your target is a Db2 table on a mainframe and you have one or more limit-key values that represent a partition point, you can specify the LimitKey parameter as the upper limit of the partition. The LimitKey parameter and the Value parameter are mutually exclusive. For more information, see LimitKey.
      • Repeat this step to create additional partitions for the table you specified in Step 3. The values for the partition definitions must be defined in ascending order. The values for each succeeding partition must be greater than the values of the previous partition.
  8. Repeat this procedure for each target table that you want to process with logical partitions.

If you receive error messages about the object names specified in the [ObjectPartition] section, check the configuration file for the following common problems:

  • Verify that the [ObjectPartition] parameters are in the correct order.
  • Verify that the column names and values for the partition definitions are valid values, and that the partition definitions appear in ascending order in the configuration.

Related topic

Defining-configurations


 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*