Some system parameters adjust the way IBM InfoSphere CDC applies rows, column data, and error handling.
convert_not_nullable_column
Use this system parameter to control how IBM InfoSphere CDC behaves when it applies a null value to a non-nullable column. When set to true (default value), the null value will be replaced with a default value (based on the data type of the column) and IBM InfoSphere CDC will generate a warning in the event log. When set to false, IBM InfoSphere CDC applies the null value directly to the non-nullable column which will result in an error and cause a shutdown of IBM InfoSphere CDC on the target database.
Set this parameter to one of the following:
▪true—Null value will be replaced with default value for non-nullable column, and a warning event will be logged.
▪false—Null data will be applied as-is to non-nullable column and database will usually return an error code.
Applies to: Source and Target
Default setting: True
global_max_batch_size
Use this system parameter to specify the maximum number of rows that IBM InfoSphere CDC can place in an array and apply to the target database during refresh or mirroring. IBM InfoSphere CDC collects rows and places them in an array (in memory) while receiving table-level operations from the source system. IBM InfoSphere CDC applies the rows from the array when there is a change to a different table, when there is a new table-level operation, or when the maximum number of rows in an array has been reached.
You can use this parameter during mirroring only if mirror_end_on_error is true and mirror_expected_errors_list is empty. Use only during a refresh if refresh_end_on_error is true and refresh_expected_errors_list is empty. Before IBM InfoSphere CDC places rows into an array, it allocates memory for the maximum number of rows you specify and multiplies this integer by the maximum length of a row. If the maximum number of rows is too large, then IBM InfoSphere CDC cannot allocate enough memory and will shut down. Management Console references this area to present replication latency information.
Applies to: Target
Default setting: 25 rows
Maximum setting: 2147483647 rows
Minimum setting: 1 row
mirror_end_on_error
Use this system parameter to indicate if you want to end mirroring after an apply error occurs on the target database.
Set this parameter to one of the following:
▪true—End mirroring after an apply error on the target database.
▪false—Do not end mirroring after an apply error on the target database.
Applies to: Target
Default setting: true
refresh_end_on_error
Use this system parameter to indicate if you want to end a refresh after an apply error occurs.
Set this parameter to one of the following:
▪true—End a refresh after an apply error occurs.
▪false—Do not end a refresh after an apply error occurs.
Applies to: Target
Default setting: true
refresh_with_referential_integrity
Use this system parameter to indicate whether or not you want the data removed from all the target tables being refreshed before repopulating any of them. This is most useful when there are referential integrity constraints on the tables being refreshed.
Set this parameter to one of the following:
▪true—Indicates that IBM InfoSphere CDC will first remove all data in reverse of the specified refresh order. When specifying the refresh order, in general parent tables should appear before the referenced child tables.
▪false—Indicates that IBM InfoSphere CDC will not first remove all data from your tables and will refresh the tables in the specified order.
Applies to: Source
Default setting: false
solid_fast_refresh_apply_pipes
Use this system parameter to improve the performance of fast refreshes. The fast refresh feature reduces the amount of time needed to replicate a large amount of data from the backend data server to the solidDB® frontend.
Set this parameter to match the number of processors (cores) in your system.
Applies to: Target
Default setting: 2
solid_fast_refresh_on
Use this system parameter to control the fast refresh feature. The fast refresh feature reduces the amount of time needed to replicate a large amount of data from the backend data server to the solidDB® frontend.