TableName
The TableName parameter specifies the name of the DBMS table that contains restart information for the apply request. To enable restart processing, a restart table must be available for the High-speed Apply Engine to store restart information.
Attributes
This parameter has the following attributes:
Attribute | Value |
|---|---|
Section | [Restart] |
Abbreviation | None |
DBMS | Db2, Db2 LUW, Oracle |
Required? | No |
Valid values | a valid table name (nondelimited), an alias, a Db2 synonym, or an Oracle public synonym |
Default value |
|
Usage
The table that you specify must exist when you run the apply request. It must reside in the same Db2 subsystem, Db2 LUW database, or Oracle instance as the target tables. Use one of the formats shown in the following table.
If you specify an unqualified name for the restart table, be aware of the value of the BindQualifier parameter in your configuration (for more information, see BindQualifier).
Format | Description |
|---|---|
owner.tableName | To fully qualify a table name, specify the owner and table name, as follows:
|
tableName | If you specify a table name without an owner, High-speed Apply Engine uses the user ID that runs the apply request as the owner of the table. |
synonym | This can be either an unqualified Db2 synonym or an Oracle public synonym.
|
owner.synonym | You can fully qualify a synonym for a table name by specifying owner and synonym, as follows:
|
alias | For Db2, if the default name is specified or defaulted, High-speed Apply Engine uses the user ID that runs the apply request as the owner of the alias. If the table is not found, High-speed Apply Engine uses the owner of the plan as the owner of the alias. |
owner.alias | You can fully qualify an alias for a table name by specifying owner and alias, as follows:
|
By default, the High-speed Apply Engine uses a single restart table for all apply requests. (This table can be the restart table created during installation, or one that you designate.) In normal use, this practice works well. However, if you run a large number of apply requests simultaneously on the same target database, you might begin to experience resource contention for the single restart table.
If you experience resource contention, create a restart table for each apply request that runs simultaneously on the target database. This practice ensures that resource contention for the restart table will not occur.
For more information, see Creating-a-restart-table.
Related topics