Create or modify a synchronization request - connect_cdc_mimix_share - Latest

CREATE

Establish a new synchronization request in a previously defined distribution.

ALTER

Modify a previously established synchronization request. Specify the distribution and/or path group for this request.

PATHGROUP

Specify the path group (if any) to use for this request.

SCHEDULE...

Set synchronization request times:

• Start

• Stop

• Duration

• Pattern of repetition every n hours minutes, seconds, days, or months.

• CONTINUE specifies that the scheduled synchronization request should continue the replication phase.

CONNECT

Specify a username for a server connection.

Copy:

Indicates that the following are copy parameters:

ON_ERROR, COMMIT, ISOLATION, LOCKING, ORDERED_RETRIEVAL and APPLY.

On_error

Determines what to do if recoverable errors are encountered:

• TERMINATE

Terminate the request. This is the default option.

• SKIP_RECORD

Copy Retriever/Applier goes on to the next record.

If the request’s Target apply mode is Delete on target, refresh, and deletion of the table data fails, the copy phase is skipped for the table.

• NEXT_TABLE

• Copy Retriever/Applier goes on to the next table in the request.

Commit

Determine the number of rows to copy per commit(the default value is 100 rows per commit):

• EACH_TABLE

All rows for each table. Each table is committed as a unit.

• ALL_TABLES

All rows for all tables. The entire request is committed as a unit.

• EVERY n RECORDS

Every specified number of rows.

Isolation

Determine the transaction isolation level on the source. The higher the isolation level you use, the more consistent the results are that Copy produces. For details on transaction isolation levels, see your SQL manual. Not all SQL DBMSs provide all four isolation levels. Check what levels are available for your DBMS.

• READ_UNCOMMITTED–Processing is the fastest, but the extracted copy may include uncommitted changes from running transactions.

Note: DB2 provides this isolation level only when a table has a Type 2 index. If your source table does not have a Type 2 index and you specify READ_UNCOMMITTED, you will get READ_COMMITTED functionality instead.

• READ_COMMITED–Extracts only committed changes, but the rows in the extracted copy can be updated by other concurrent transactions.

• REPEATABLE_READ–Extracts only committed changes, and ensures that the rows being extracted cannot be updated during the extraction.

New rows that satisfy a search condition of the extraction may be added by other concurrent transactions. However, your extract transaction will not include those rows.

• SERIALIZABLE–Provides serial ordering of concurrent transactions to produce consistent results.

Locking

Determine whether a source table is locked for the entire request or only while this single table is being copied:

• BY_TABLE–Access and lock, one at a time, all source tables specified in the TABLES list for copying, and commits on the source after processing each table, thus unlocking the table.

• BY_REQUEST–Access and lock, one at a time, all source tables specified in the TABLES list for copying, and commits on the source and unlocks the tables after the entire request is processed. This is the default.

Ordered_Retrieval

Specify whether the order of retrieval is important.

Apply

Determine how to apply rows to the receiving table:

• DELETE–Complete replacement of the target records. Old records on the target are deleted, then new records from the source are inserted. Any duplicate rows are treated as an error.

If your request has multiple tables, the Copy Applier completes its work in two passes: In the first pass, all the deletions from all the tables involved are completed. In the second pass, all the sending table rows are inserted.

In the first pass, the selected tables are processed from the bottom to the top in their copy request display order. In the second pass, the tables are processed in top-to-bottom order.

Important: If you select this mode, all the rows in the target table will be deleted, even if you defined specific rows to copy based on a gate condition specified in the CREATE TABLE MAPPING statement. If this is not what you want, select a different mode, or manually delete the rows on the target and then run the Copy request.

• APPEND–The target data is assumed to be correct. Only new source records are inserted. Duplicate rows are ignored and processing continues.

• REFRESH–The source data is assumed to be correct. Duplicate rows are deleted and the source rows inserted.

• MERGE–The target data is assumed to be correct, but the source data overwrites it where there is a difference, in order to merge the source and the target tables. Inserts are changed to updates on duplicate rows. This mode may be used to merge columns, creating a “materialized join” table.

Replication:

Indicates that the following are replication parameters:

ON_ERROR, INTEGRITY, PROTECTED_RESOLUTION, UNPROTECTED_RESOLUTION, DESCRIPTION.

On_error

Specify error handling: continue, ignore, or shutdown.

Protected_Resolution

Specify automatic or manual full collision resolution by shadow. table.

Unprotected_Resolution

Specify unprotected collision resolution:

• insert, update, or delete

• none, target_correct, or source_correct

Description

User-defined text.