apply.buffer_size_for_split_records
Specifies the maximum size of the buffer, in bytes, that the Applier uses to store data for a long-running transaction or for a table that is queued for apply processing in Merge Apply mode. When this buffer size limit is exceeded, the Applier flushes data from the buffer to a temporary spill file and then writes any additional change data to the spill file. The Applier creates a buffer for each long-running transaction or for each table that is queued for apply processing in Merge Apply mode.
Default value: 1048576 bytes
apply.conflict_resolution_json_offset
If you use the apply.conflict_resolution_pretty_json parameter, specifies the indentation level for the JSON log files. Data Replication uses the specified number of spaces to indent JSON elements.
apply.conflict_resolution_pretty_json
Indicates whether to use the indented format for the JSON log file to which the Applier writes information about detected conflicts. You specify a path to this log file on the
Runtime Settings
tab >
General
view. Options are:
0
. Use a single-line format for the JSON log files. Use this option to reduce the size of the log files.
1
. Use an indented format for the JSON log files. The indentation level is determined by the apply.conflict_resolution_json_offset parameter.
apply.force_log_table_suffix_for_audit
For configurations that include multiple targets, indicates whether the Applier alters the SQL apply statements for secondary targets that use Audit Apply mode to append the audit log suffix to the table names on those targets. The audit log suffix is specified in the
Log table suffix for merge apply
field on the
Runtime Settings
tab >
Calculated Columns
view and usually used for Merge Apply. Options are:
0
. Do not append the audit log suffix to the table names on the secondary targets that use Audit Apply mode. With this option, the names of the audit log tables on the secondary targets match the names of the regular target tables on the primary target. This option is typically used for configurations that replicate data from one primary target to multiple secondary targets in different databases.
1
. Append the audit log suffix to the table names on the secondary targets that use Audit Apply mode. With this option, the audit log table names on the secondary targets are composed of the primary target table names followed by the audit log suffix. This option is used in special situations where you need to use the audit log suffix to distinguish the audit log tables on secondary targets that use Audit Apply mode.
You can use Audit Apply mode for a secondary target to add audit log tables in the primary target database that use the same schema as the regular target tables in the same database. In this case, if you use Merge Apply mode for the primary target, the audit log tables for Merge Apply mode must have a different schema. Specify a schema that includes audit log tables for Merge Apply mode in the
Log table schema for merge apply
field on the
Runtime Settings
tab >
Calculated Columns
view.
apply.libpq_client_encoding
For Greenplum
and Vertica
targets, specifies the original source character encoding for data that Data Replication applies using the libpq library in Audit Apply and Merge Apply modes. InitialSync also uses this setting to specify original source character encoding for data that it loads using the libpq library. This parameter is equivalent to setting the PGCLIENTENCODING environment variable. For example, if the Oracle source system character set is WE8ISO8859P1, set this parameter to LATIN1. For more information about available character sets for a target, see your target database documentation.
apply.libpq_custom_connection_string
For Greenplum
, Vertica
,
and PostgreSQL
targets, specifies a custom connection string for the libpq library. This parameter overrides the automatically generated libpq connection string, which has the following format:
host=
target_host_name
port=
target_port
user=
target_user
password=
target_password
dbname=
target_database_name
apply.load_sessions_per_load_pass
Specifies the number of target tables that the Applier can load concurrently. By default, Data Replication uses this parameter only for Netezza
, Vertica,
and Teradata targets. To use this parameter for other target types, set the apply.loader_multiple_load_passes parameter to 1.
If you use the value of -1 for this parameter, the Applier determines the number of tables that it can load to the target concurrently based on the target database type. The Applier uses the following criteria:
For Netezza, the number of tables equals the number of Applier threads. Maximum is 20 tables.
For Vertica, the number of tables equals the number of Applier threads multiplied by 4. Maximum is 20 tables.
For other target types, the number of tables equals the number of Applier threads. No maximum limit applies.
To change this value for Netezza targets, Informatica recommends that you clear the
Create output as pipes instead of files
option on the
Runtime Settings
tab >
General
view. If this option is selected, each Applier thread can load only a single audit log table at a time.
apply.loader_multiple_load_passes
Indicates whether the number of target tables that the Applier loads concurrently is limited. Options are:
0
. The Applier loads data to all of the target tables concurrently. No limit on the number of tables is in effect.
1
. The Applier loads data to a limited number of target tables concurrently. The number of tables is limited by the apply.load_sessions_per_load_pass runtime parameter.
Default value: 0. However, for Netezza
, Vertica,
and Teradata targets, Data Replication always uses the parameter value of 1 because the number of concurrent loader tasks on these targets is limited. For Apache Kafka targets, Data Replication always uses the parameter value of 0.
apply.loader_tx_map_size_rollback_key
Specifies the number of slots in a hash structure that is used to process rollback-to-savepoint records during each apply cycle. Increase this value if rollback-to-savepoint operations are common and process a lot of records.
apply.loader_tx_map_size_tx
Specifies the number of slots in a hash structure that is used to hold committed transactions during each apply cycle. For better performance, set this value to one-tenth of the number of opened or closed transactions in each apply cycle.
apply.merge.double_precision
The Applier rounds 8-byte floating-point numbers, such as DOUBLE and 8-byte FLOAT values, from the source before loading them to Merge Apply targets. This parameter specifies the number of digits after the decimal point that the Applier preserves in the 8-byte floating-point numbers that are applied to the target.
apply.merge.float_precision
The Applier rounds 4-byte floating-point numbers, such as 4-byte FLOAT and REAL values, from the source before loading them to Merge Apply targets. This parameter specifies the number of digits after the decimal point that the Applier preserves in the 4-byte floating-point numbers that are applied to the target.
apply.performance_degradation_warning_percentage
Specifies the percentage degradation of the average SQL statement processing time that must occur before Data Replication logs a warning. You can specify the intervals at which Data Replication calculates the average SQL statement processing times in the apply.print_statistics_interval and initial.print_statistics_interval parameters.
Data Replication does not log a performance degradation warning if the average SQL statement processing time is less than the value that is specified by the apply.performance_degradation_warning_threshold parameter.
apply.performance_degradation_warning_step
Specifies the number of performance readings that must indicate degradation of the average SQL statement processing time before Data Replication logs a warning. You can specify the intervals at which Data Replication calculates the average SQL statement processing times in the apply.print_statistics_interval and initial.print_statistics_interval parameters.
Data Replication does not log a performance degradation warning if the average SQL statement processing time is less than the value that is specified by the apply.performance_degradation_warning_threshold parameter.
apply.performance_degradation_warning_threshold
apply.post_apply_script_enabled
Indicates whether the Applier runs post-apply SQL statements or stored procedure calls after each apply cycle on a target. Post-apply processing is supported for configurations that have Greenplum, Netezza, Oracle,
Vertica,
or Teradata targets and that use Audit Apply or Merge Apply mode. You must specify the post-apply SQL statements or stored procedure calls in the
%DBSYNC_HOME%/uiconf/afterapply.xsl
file. Options are:
0
. Disable post-apply processing.
1
. Enable post-apply processing.
apply.print_statistics_interval
For configurations with targets that use ODBC drivers, specifies the number of seconds that must elapse before Data Replication updates the number of processed rows in the Applier output log. If you specify 0, Data Replication does not include the number of processed rows in the Applier output log.
Default value: 300 seconds
apply.process_intermediate_size_per_job
Specifies the maximum total size of all intermediate files, in megabytes, that Data Replication processes during a single apply cycle. Data Replication always processes entire intermediate files. Data Replication never splits an intermediate file to avoid exceeding the maximum total size that is specified in this parameter. You control the maximum size of a single intermediate file by setting the
Maximum size of each intermediate file
option on the
Runtime Settings
tab >
General
view.
Each apply cycle ends with a single commit by default except in certain situations when you use Applier multi-threaded processing. For more information, see
Commit Processing and Target Constraints with Applier Multi-Threaded Processing. If you specify smaller values for this parameter, Data Replication apply processing reduces the transaction size and increases the commit frequency on the target. If you specify 0, Data Replication processes all available intermediate files within a single apply cycle.
Data Replication always processes at least one intermediate file during a single apply cycle, even if the intermediate file size exceeds the maximum total size that is specified in this parameter.
apply.realtime_clean_metadata_every_n_cycles
For continuous replication, specifies the number of apply microcycles that the Applier runs before it removes information about the processed intermediate files from the Applier SQLite database. This parameter is for use only by Informatica Global Customer Support. Do not modify it.
Default value: 1000 microcycles
apply.recovery_enabled
Indicates whether to enable recovery based on information in the recovery table for apply processing. Options are:
0
. Disable recovery based on information in the recovery table. When you save a new configuration in the Data Replication Console, this parameter is transparently set to 0 if you clicked
No
in the
Enter Recovery Table Name and Schema
dialog box to not create a recovery table with the specified name.
1
. Enable recovery based on information in the recovery table. When you save a new configuration in the Data Replication Console, this parameter is transparently set to 1 if you clicked
Yes
in the
Enter Recovery Table Name and Schema
dialog box to create a recovery table. Ensure that the apply.recovery_table parameter specifies the schema and table name of the recovery table.
For database target types other than
Cloudera,
Flat File,
Hortonworks,
and Kafka, Informatica recommends that you enter 1 to enable recovery for apply processing. For
Cloudera,
Flat File,
Hortonworks,
and Kafka targets that do not use a recovery table, enter 0.
Default value: 0 for the
Cloudera,
Flat File,
Hortonworks,
and Kafka targets, 1 for other targets.
apply.recovery_table
Specifies the schema and table name of the recovery table on the primary target. Only target types other than
Cloudera,
Flat File,
Hortonworks,
and Kafka use recovery tables. For the recovery table to be used, ensure that the apply.recovery_enabled parameter is set to 1.
In the Data Replication Console, when you save a new configuration, the Console prompts you to specify the schema and table name of the recovery table. You can accept the default values or override them. The default schema is the database user, and the default table name is IDR_RECOVERY. If you click
Yes
, this parameter is populated with the full recovery table name. The Applier uses this parameter value to create the recovery table. If you click
No
, the recovery table is not created and the apply.recovery_enabled parameter is set to 0. If you want to use a recovery table later, you can create it in one of the following ways:
Manually create the table by using the DDL in
DDL Statements for Manually Creating Recovery Tables. Then enter the schema and table name of the table that you created in this parameter and set the apply.recovery_enabled parameter to 1, before saving the configuration again.
In the Data Replication Console, set the apply.recovery_enabled runtime parameter to 1 and save the configuration again. The Console prompts you for the schema and table name. After you specify these names and click
Yes
, the Console enters the full
schema.table_name
value in this parameter. When you start the Applier later, it will create the recovery table.
To specify recovery tables for secondary targets in a configuration that has multiple targets, use the
Recovery table name
field on the
Routing
tab >
Override Apply
subtab.
Default value: IDR_RECOVERY
apply.script_engine_enabled
Indicates whether the Tcl Script Engine executes the following Tcl scripts that are located in the
DataReplication_installation
/support/Tcl directory during apply processing:
Execute dbs_main_start.tcl when the Applier task starts.
Execute dbs_main_end.tcl when the Applier task ends.
Execute dbs_cycle_start.tcl when an apply cycle starts.
Execute dbs_cycle_end.tcl when an apply cycle ends.
0
. Do not execute these Tcl scripts during apply processing.
1
. Execute these Tcl scripts during apply processing.
apply.skip_if_pk_not_defined
Indicates whether the Applier is forced to end with an error if it encounters an Update or Delete record that does not contain undo values for all of the primary key columns. Options are:
0
. The Applier ends with an error.
1
. In SQL Apply and Merge Apply modes, the Applier skips any Update or Delete record that does not include undo values for all of the primary key columns and continues apply processing. This setting can result in data inconsistencies.
In Audit Apply mode, the Applier applies these records to the target instead of skipping them.
apply.skip_oracle_piecewise_operations
Indicates whether the Applier skips Oracle piecewise operations.
Data Replication supports Oracle piecewise operations only for Oracle targets in Audit Apply mode if apply.direct_load_for_audit_tables is set to 0 and in SQL Apply mode. This parameter determines the Applier behavior when processing change records that contain piecewise operations in the following cases:
For target databases other than Oracle.
For Oracle targets in Merge Apply mode.
For Oracle targets in Audit Apply mode if apply.direct_load_for_audit_tables is set to 1.
0
. Do not skip Oracle piecewise operations. If piecewise operations occur, the Applier ends with an error.
1
. Skip Oracle piecewise operations.
apply.sql_statement_text_id_cache_optimization_enabled
For source tables mapped in SQL Apply mode, controls whether the Applier caches the SQL statements that it generates for applying data to target tables in memory. Enable caching of these SQL statements to improve Applier performance. Options are:
0
. Do not cache the SQL statements for applying data to the target tables.
1
. Cache the SQL statements for applying data to the target tables.
apply.threshold_time_for_open_transaction
Specifies the number of minutes that a transaction must be open before the Applier logs a warning message about the open transaction. The Applier compares this threshold time to the time the transaction has been open, which is calculated as the difference between the time of the last record from the open transaction and the time of the last processed record from any transaction.
Default value: 60 minutes
apply.trace_db_execution
For Oracle targets, indicates whether to use Oracle SQL tracing. This tracing is enabled using SQL event 10046 with trace levels 1, 4, 8, or 12. Options are:
0
. Do not use SQL tracing.
1
. Use standard SQL trace level 1. Provides statistics for parse, execute, fetch, commit and rollback database calls.
4
. Use SQL trace level 4. This option displays level 1 information and additional information about bind variables.
8
. Use SQL trace level 8. This option displays level 1 information and additional information about wait time.
12
. Use SQL trace level 12. This option enables trace levels 4 and 8 simultaneously.
apply.verbose_ddl
Indicates whether to include the DDL statements that the Applier uses to apply source DDL changes to the target in the Applier output. The Applier translates the source DDL statements to DDL statements that the target database can process. You can include these translated DDL statements in the Applier output to determine the specific DDL statements that the Applier used to apply structural changes on the target. Options are:
0
. Do not include the SQL statements for the target that correspond to source DDL changes in the Applier output.
1
. Include the SQL statements for the target in the Applier output.
apply.verbose_level
Specifies the level of verbose output for the Applier process. Larger values provide more detailed output. The specific output information depends on the Applier type. Valid values are 0 to 4.
apply.verbose_process_long_running_txns
Indicates whether the Applier logs messages that are related to processing memory buffers and temporary spill files for change data that belongs to long-running open transactions. Options are:
0
. Do not include the messages that are related to processing memory buffers and temporary spill files for long-running transactions in the Applier output.
1
. Include the messages that are related to processing memory buffers and temporary spill files for long-running transactions in the Applier output.
Default value: 1
apply.verbose_print_every_n_records
Determines the frequency at which Data Replication updates progress when the Applier task is running. When the specified number of records are reached, Data Replication updates progress information.
Default value: 1000000 records
apply.verbose_process_queued_tables
Indicates whether the Applier logs messages that are related to processing memory buffers and temporary spill files for queued source tables. The Applier cannot apply change data from these tables during the current apply cycle because of target loader limitations. Options are:
0
. Do not include the messages that are related to processing memory buffers and temporary spill files for queued tables in the Applier output.
1
. Include the messages that are related to processing memory buffers and temporary spill files for queued tables in the Applier output.
Default value: 0
apply.verify_modified_row_count
Indicates whether Data Replication verifies that the number of rows that the Applier expected to process for Inserts, Updates, and Deletes during the apply cycle matches the actual count of rows for these SQL changes that were applied. Options are:
0
. Do not verify that the expected row count matches the actual row count.
1
. Verify that the expected row count matches the actual row count.
A row count mismatch might occur in the following situations:
Data Replication replicates a row for an Insert operation, but an Insert row was already written to the target.
Data Replication replicates a row for a Delete or Update operation, but no rows match the WHERE condition that is used when applying changes to the target.
With this setting, the apply cycle is rolled back and a new apply cycle begins with row-by-row processing. Data Replication prints the SQL statements and bind variable values with the mismatched row count to the log. The Applier then reports the mismatch and either stops or continues depending on the apply.verify_modified_row_count_abort_on_mismatch parameter setting.
This type of verification works only for SQL Apply table mappings. It does not work for Audit Apply or Merge Apply mappings.
apply.verify_modified_row_count_abort_on_mismatch
If you set the apply.verify_modified_row_count parameter to 1, use this parameter to control whether the Applier task stops or continues when a mismatch occurs between the expected count of Insert, Update, and Delete rows and the actual row count. Options are:
0
. Report an error and continue apply processing.
1
. Stop apply processing.
data_direct_optimize_prepare
Specifies the value for the OptimizePrepare (OP) attribute in the connection string that is generated for the DataDirect ODBC drivers. The OptimizePrepare attribute determines whether the driver creates stored procedures on the database server for calls to the ODBC SQLPrepare function. Options are:
0
. Create stored procedures for each call to the SQLPrepare function. This setting might degrade performance when processing SQL statements that do not contain parameters.
1
. Create stored procedures only if the SQL statement includes parameters. If the SQL statement does not include parameters, the driver caches the SQL statement and runs it directly when calling the SQLExecute function.
2
. Do not create stored procedures. The driver caches the SQL statement and runs it directly in the SQLExecute function. The driver reports syntax errors during the call to the function or when the SQLExecute function runs.
3
. Do not create stored procedures. The driver caches the SQL statement and runs it directly in the SQLExecute function. However, the driver reports syntax errors during the call to the function or when the SQLPrepare function runs.
extract.log_wait_cycle_time
Specifies the number of seconds that the Extractor waits during a cycle for archived log files from each Oracle RAC to appear before starting a new cycle.
extract.log_wait_cycles
Specifies the number of cycles that the Extractor runs while waiting for Oracle RAC archived logs before it exits with an error message.
extract.log_wait_print_warning_cycles
Specifies the number of cycles that the Extractor runs while waiting for Oracle RAC archived logs before it prints a warning message that reports its wait status.
extract.process_old_logs
For
Microsoft SQL Server
and Oracle sources, indicates whether the Extractor reads all available transaction logs. Options are:
0
. Start reading the logs from the Start Point value and skip any older logs. The default Start Point value is calculated by the Data Replication Console. You can override the default Start Point value to customize Extractor processing.
1
. Ignore the Start Point value and process all available log files.
extract.rawdevice_offset
On Linux and AIX operating systems only, if you use raw devices to store data for an Oracle source database, controls the offset from the beginning of the raw device storage at which the Oracle Extractor begins reading data. The offset is expressed in bytes. The default offset depends on the operating system type. Valid values are the integers 0 through 2147483647. Data Replication interprets any negative integer value for this parameter as the default value.
Default value: -1. On Linux, the default value causes the offset to be 0 bytes. On AIX, the default value causes the offset to be 4096 bytes.
extract.show_throughput
For Oracle sources, the Extractor shows the amount of the redo logs in bytes that is processed per time unit. Options are:
0
. Show the amount of redo logs processed per time unit.
1
. Do not show the amount of redo logs processed per time unit.
extract.stop_on_parsing_error
Determines the Extractor behavior when the Extractor cannot parse a transaction record in the log. Options are:
0
. Skip an inconsistent log record and continue processing. The Extractor logs a message for each skipped record and ends successfully if no other errors occur.
1
. Log an error and stop processing the transaction log.
When a parsing error occurs, the Oracle Extractor also creates a binary file with the transaction record and a .LOG file in the
DataReplication_installation
/dump subdirectory.
extract.throughput_window
The number of measurements that Data Replication uses to calculate Extractor throughput. Throughput is reported in an Extractor message in the output log. Valid values are positive integers, beginning with 1.
extract.verbose_level
Specifies the level of verbose output for the Extractor process. Larger values provide more detailed output. The specific output information depends on the Extractor type. Valid values are 0 to 4.
global.encrypt_algorithm
Specifies the encryption algorithm that Data Replication uses to encrypt the intermediate files. This setting is also configurable in the Data Replication Console on the
Runtime Settings
tab >
General
view. In the Encryption Algorithm box, options in the
Type
list correspond to the options for this parameter. Options are:
0
. Do not encrypt the intermediate files.
1
. Use the Triple DES algorithm.
2
. Use the AES algorithm with 128-bit key.
3
. Use the AES algorithm with 192-bit key.
4
. Use the AES algorithm with 256-bit key.
global.fallback_connection
When an attempt to connect to an Oracle source or target fails, indicates whether the Extractor and Applier rebuild the ODBC connection string and try to connect to the source or target again. Options are:
0
. If an attempt to connect to an Oracle source or target fails, the replication tasks do not try to connect to the source or target again. The tasks end with an error.
1
. If an attempt to connect to an Oracle source or target fails, the replication tasks rebuild the ODBC connection string and try to connect to the source or target again. The replication tasks rebuild the connection string as follows:
If the replication configuration does not specify a custom ODBC connection string for the source or target, the replication tasks rebuild the ODBC connection string for the second connection attempt by switching between the Oracle SID and SERVICE_NAME values.
By default, the Extractor and Applier use the SERVICE_NAME value to build the ODBC connection string for the first connection attempt. If you select the
Use SID instead of SERVICE_NAME
option on the
Source Database
or
Target Database
tab, the Extractor or Applier task uses the Oracle SID to build the ODBC connection string for the first connection attempt. If the first connection attempt fails, the Extractor or Applier task switches to the other value and builds the ODBC connection string based on this value for the second connection attempt.
If the replication configuration specifies a custom ODBC connection string for the source or target, the replication tasks build the ODBC connection string for the second connection attempt based on the connection settings or database connection that you specify on the
Source Database
or
Target Database
tab.
global.file_open_timeout
Specifies the number of seconds that a Data Replication component retries opening a file after the first open attempt fails. If this timeout period elapses without the file being opened, the component ends with an error message. This parameter affects only Data Replication components that run on Linux.
Valid values are 1 to 2147483647.
global.fix_invalid_db_characters
For Amazon Redshift, Greenplum, and Teradata targets, indicates whether to fix UTF-8 encoded characters in character data that the targets cannot process correctly during InitialSync and Applier processing.
The UTF-8 encoded characters are valid but the targets do not support them.
0
. Do not fix UTF-8 encoded symbols in the character data that the target cannot process correctly. The InitialSync and Applier tasks might fail.
1
. Replace each byte of UTF-8 encoded symbols in character data that the target cannot process correctly with the character that is specified in global.invalid_character_replacement parameter.
global.fix_invalid_encoding_characters
For
Amazon Redshift, Greenplum, Netezza, Teradata, and Vertica
targets, indicates whether to fix invalid UTF-8 byte sequences in character data during InitialSync and Applier processing. Options are:
0
. Do not fix invalid UTF-8 byte sequences. The InitialSync and Applier tasks might fail.
1
. If the global.icu_enabled parameter is set to 1 or the source data contains UTF-16 characters, replace invalid UTF-8 byte sequences with the character that is specified in the global.invalid_character_replacement parameter. If the global.icu_enabled parameter is set to 0 or the source data contains only UTF-8 characters, replace each byte of the invalid UTF-8 byte sequences with the character that is specified in the global.invalid_character_replacement parameter.
global.handle_os_signals
For Applier, Extractor, and InitialSync tasks that run on Linux or UNIX, indicates which error log files these tasks generate in the
DataReplication_installation
directory when they end abnormally. Options are:
1
. Generate a dbsync_crash.log file.
2
. Generate a core file and dbsync_crash.log file.
Change this value only at the request of Informatica Global Customer Support.
global.icu_enabled
For configurations that have a DB2 for Linux, UNIX, and Windows, Microsoft SQL Server, or Oracle source and an Amazon Redshift, Greenplum, Netezza,
Vertica,
or Teradata target, indicates whether the Applier and InitialSync convert character data from the source database encoding to the target database encoding. Options are:
0
. Do not convert the source character data to the target database encoding. Use this setting if the source and target databases use incompatible character sets and the source character data includes only Latin characters.
If the source character data includes non-Latin characters and the source and target databases use incompatible character sets, Data Replication ends with an error regardless of the global.icu_enabled setting.
1
. Convert the source character data to the target database encoding.
The Data Replication Console sets this parameter to 1 for new configurations.
global.insert_buffer_size
Specifies the maximum number of DML operations that the Applier and InitialSync accumulate in the internal buffer prior to flushing the buffer contents to the target. Each buffer stores operations of a single type.
If you use the default value of 0, the Applier and InitialSync determine the appropriate number of operations that can be buffered for the target type. The Applier and InitialSync use one of the following maximums:
1 operation for
MySQL
and
PostgreSQL
targets.
100 operations for Teradata targets.
200 operations for
DB2 for Linux, UNIX, and Windows,
Greenplum, Microsoft SQL Server, Netezza,
Vertica,
and Oracle targets.
If a replication configuration includes mapped LOB columns, Data Replication always uses the parameter value of 1.
For
MySQL
and
PostgreSQL
targets, enter a value other than the default value only at the request of Informatica Global Customer Support.
Set this parameter to 1 to ensure correct Applier processing in the following cases:
You configure Data Replication to continue Applier processing when specific database errors occur.
In other cases, use the default value of 0 for optimal Applier performance. If you set this parameter to 1 or any other low non-zero value, Applier performance might be degraded.
global.invalid_character_replacement
Specifies the ASCII character that replaces UTF-8 encoded characters during InitialSync and Applier processing in the following situations:
If you set the global.fix_invalid _db_characters parameter to 1 for Greenplum and Teradata targets, replaces UTF-8 encoded characters that the targets cannot process correctly.
If you set the global.fix_invalid_encoding_characters parameter to 1 for Amazon Redshift, Greenplum, Netezza, Teradata, and Vertica targets, replaces invalid UTF-8 byte sequences.
Default value: ? (question mark)
global.lob_truncation_size
Determines the maximum size of a source LOB value, in bytes, that the Applier and InitialSync replicate to the target. If the size of a LOB value exceeds this limit, the data is truncated to the specified maximum size.
If you use the default value of 0, the Applier and InitialSync truncate the source LOB data to 16 KB for Merge Apply targets and to 16 MB for other targets.
Netezza supports row sizes up to 64 KB when the data is loaded with Netezza high-performance loaders.
The Extractor does not extract more than 50 MB from source LOB columns. Consequently, the maximum supported LOB size for change data capture is 50 MB, regardless of this parameter setting.
If a target database uses a multibyte encoding, the Applier might truncate the last character from a character LOB column, causing an incomplete byte sequence. The Applier cannot apply the incomplete byte sequence.
To avoid this problem on Amazon Redshift, Greenplum, Netezza, Teradata, and Vertica targets, set the global.fix_invalid_db_characters and global.fix_invalid_encoding_characters runtime parameters to 1. The Applier then replaces each byte of the invalid UTF-8 byte sequence or the entire sequence with the character that is specified in the global.invalid_character_replacement parameter.
global.max_output_log_size
Specifies the maximum size of a log file, in megabytes, to which an Extractor, Applier, or InitialSync task logs messages. When this log size limit is exceeded, the Data Replication task creates a new log file.
If the time period in the global.time_for_output_log_rotation parameter elapses before this log size limit is exceeded, the Data Replication task creates a new log file.
global.number_of_historical_metadata_records_kept
The maximum number of records that represent processed intermediate files in the Applier SQLite database. When the number of intermediate file records in the Applier SQLite database exceeds this value, the Applier deletes records for the earliest intermediate files.
Default value: 40000 records.
global.nz_pg_empty_strings_as_null
For Greenplum
, Vertica,
PostgreSQL,
and Netezza targets, indicates whether the Applier and InitialSync load empty strings and LOBs from the source as null values on the target. Options are:
0
. Load empty strings and LOBs from the source as empty strings on the target.
1
. Load empty strings and LOBs from the source as null values on the target.
global.print_runtime_settings
Indicates whether the InitialSync, Extractor, and Applier tasks log a list of the runtime parameters for which you specified a non-default value to the execution logs each time the tasks start. Options are:
0
. Do not log the list of parameters with non-default values.
1
. Log the list of parameters with non-default values.
global.print_timestamps
Indicates whether to append date and time to the logged messages that provide debug information. Options are:
0
. Do not append the date and time.
1
. Append the date and time.
global.show_transaction_locking
Indicates whether the Applier and InitialSync tasks retrieve information about database locking sessions that other applications establish. Options are:
0
. The Applier and InitialSync tasks do not provide information about database locking sessions and silently wait until the sessions release the row lock to continue processing.
1
. If the Applier or InitialSync task cannot load data into a locked target row, the task retrieves information about the database locking sessions and includes this information in the processing statistics. The Applier updates processing statistics at 5-minute intervals by default. InitialSync updates processing statistics at 10-second intervals by default. To change the default interval for the Applier or InitialSync task, use the apply.print_statistics_interval or initial.print_statistics_interval runtime parameter.
global.time_for_output_log_rotation
Specifies the maximum number of hours that an Extractor, Applier, or InitialSync task can write messages to its task execution log. When this time period elapses, the task creates a new log file.
If the size of a log file exceeds the global.max_output_log_size parameter value before this time period elapses, the Data Replication task creates a new log file.
global.unicode_normalization
Indicates whether Data Replication converts source Unicode character data to Normalization Form C (NFC) format by using the International Components for Unicode (ICU) library. Valid values are:
0
. Do not normalize Unicode character data.
1
. Normalize Unicode character data. Use this option for Netezza targets if the source character data includes decomposed characters.
If you set this parameter to 1 and the source character set matches the target character set, Data Replication converts the source data to UTF-16 for Unicode normalization. Then, the normalized Unicode character data is converted back to the source format.
initial.check_empty_tables
Indicates whether InitialSync checks mapped target tables to determine if they are empty before loading data. Options are:
0
. Do not check if the target tables are empty. InitialSync loads data to all of the mapped tables on the target.
1
. Check if the target tables are empty. If InitialSync detects that one or more tables are not empty, it skips these tables and continues to load data to other tables. If InitialSync successfully loads data to all of the empty target tables, it ends without error.
2
. Check if the target tables are empty. If InitialSync detects that one or more target tables are not empty, it skips these tables and continues to load data to other tables. After InitialSync processes all of the target tables, it returns error code 57.
For configurations with multiple sources and a single target, set this parameter to 0 to materialize the target from all of the sources.
For Oracle sources, disable the DBLinks option.
initial.enforce_odbc_load
Indicates whether InitialSync uses a native database load utility or the appropriate ODBC driver to load data to the target. Options are:
0
. Use a native database load utility to load data to the target, if a load utility is available for the target type.
1
. Use the appropriate ODBC driver or the Oracle Call Interface (OCI) library to load data to the target. If you defined Tcl or SQL expressions that the target native load utility does not support, select this option so that InitialSync can properly process the expressions.
InitialSync does not support the use of ODBC drivers for loading
Vertica and
Netezza targets.
initial.lob_prefetch_threshold
For source tables that contain LOB columns, determines the number of rows that InitialSync gets in a single fetch. Large values provide better InitialSync performance but require a lot of memory to allocate prefetched rows. Use the following formula to estimate the allocated memory size:
allocated_memory_size
=
row_size
*
number_of_rows
If you use the default value of 0, InitialSync gets the following number of rows in a single fetch:
1000 rows for Oracle sources
1 row for DB2 for Linux, UNIX, and Windows
, Microsoft SQL Server
sources
For source tables that do not contain LOB columns, use the initial.select_buffer_size runtime parameter.
initial.named_transactions
For
DB2,
Microsoft SQL Server and Oracle targets, controls whether InitialSync uses a specific transaction or application name for the transactions that load data to targets during bidirectional or cascade replication. The transaction or application name can be the default name of DbSyncTransaction or an override name that you specify in the TX_NAME command line parameter. Options are:
0
. InitialSync does not use a specific transaction or application name for the transactions that insert data into targets.
1
. InitialSync uses one of the following transaction or application names:
For Microsoft SQL Server and Oracle targets, the default transaction name of DbSyncTransaction.
For DB2 targets, the default application name of DbSyncTransaction.
For any of these target types, an override transaction or application name that you specify with the
TX_NAME
command line parameter.
initial.pipe_directory
Specifies the path and directory where pipes (*nix) are created when InitialSync runs. On Windows, you cannot specify this directory because pipes are created as
\\.\pipe\PipeName
. Informatica recommends that you specify this parameter for DB2 for Linux, UNIX, and Windows sources.
Default value: The Applier output directory
initial.pipe_wait_time
For
DB2,
Greenplum
, PostgreSQL
, Vertica
and Netezza targets, specifies the number of seconds that InitialSync waits for the database native load utility to connect to the pipe that InitialSync opens for loading data to the target.
Increase this parameter value if you get the following error:
Write to pipe timed out
write_size
from
bytes_to_write
by thread
thread_name
to the file
file_name
Default value: 20 seconds on Linux and UNIX, 5 seconds on Windows
initial.print_statistics_interval
For configurations with targets that use ODBC drivers, specifies the number of seconds that must elapse before Data Replication updates InitialSync processing statistics in the InitialSync output log. The statistics include the number of processed rows, the total number of rows to be processed, and the estimated time for processing to complete. If you specify 0, Data Replication does not include this information in the InitialSync output log.
Default value: 10 seconds
initial.rows_to_commit
Specifies the maximum number of Insert rows that a single InitialSync thread can commit on the target. Use this parameter to avoid large transactions that might degrade load performance. If you use the ODBC drivers to connect to targets, this parameter applies to all target database types. If you use the target native load utilities, this parameter applies to the following target types:
Greenplum
Microsoft SQL Server
PostgreSQL
Vertica
Default value: 2147483647 rows
initial.script_engine_enabled
Indicates whether to enable or disable Tcl scripts and SQL expressions during InitialSync synchronization of source and target tables. Options are:
0
. Disable Tcl scripts and SQL expressions during InitialSync synchronization. The InitialSync task does not include target columns that are mapped to virtual columns with Tcl scripts or SQL expressions in the Insert statements for loading data.
1
. Enable Tcl scripts and SQL expressions during InitialSync synchronization.
initial.select_buffer_size
Specifies the buffer size, in rows, that InitialSync uses for selecting data from source tables that do not contain mapped LOB columns. For source tables that contain mapped LOB columns, use the
initial.lob_prefetch_threshold
runtime parameter.
If you use the default value of 0, InitialSync uses one of the following buffer sizes:
100 rows for
Microsoft SQL Server and
Oracle sources
100 rows for DB2 sources on Windows
1 row for DB2 sources on Linux and UNIX
Values greater than 200 might enhance InitialSync performance but cause higher memory consumption.
initial.verbose_level
For Oracle sources, if you use InitialSync subtask threads, specifies the verbosity level for IniitalSync output. Options are:
0
. Provides standard InitialSync output.
1
. Provides additional output for each subtask thread.
For sources other than Oracle, use the default value of 0.
initialsync.abort_on_failed_table
Indicates whether the InitialSync task ends abnormally if an error occurs during initial synchronization of source and target tables. Options are:
0
. InitialSync skips processing the target table when an error occurs but continues processing the other tables.
1
. InitialSync ends with an error and does not synchronize the remaining tables.
initialsync.progress_print_step
Specifies the number of rows that the Extractor, Applier, or InitialSync component must process before Data Replication updates the progress information that is displayed when you start the Extractor or InitialSync component from the Data Replication Console.
pgloader.exceptions_path
Specifies the location of the log file that contains exceptions for a failed data load operation during an InitialSync or Applier job.
Default value: The Applier output directory
pgloader.reject_max
Specifies the maximum number of rows that can fail to be loaded before the Applier or InitialSync task fails.
pgloader.reject_data_path
Specifies the location of the file that contains the data that failed to be loaded during an InitialSync or Applier task.
Default value: The Applier output directory
