You can resynchronize source and target objects for a subtask that is part of a running database ingestion and replication combined initial and incremental load job. The subtask must be in a state other than Queued or Starting.
Resynchronization loads the latest changes from the source table to the target to make sure the source and target are consistent. Usually, the target table contents is truncated before the current source data is applied. However, for data lake targets, a T (truncate) operation is replicated instead of actually truncating the target contents.
For example, you might want to resynchronize the target with the source if initial load or incremental load processing failed or if you want to start the job over again from a specific restart point.
1Drill down on the database ingestion and replication job that you want to resynchronize from one of the following monitoring interfaces:
- My Jobs page that's accessed from the navigation bar of the Home page
- All Jobs page in the Monitor service
- All Jobs tab on the Data Ingestion and Replication page in Operational Insights
The job must be in the Up and Running state and be for a combined initial and incremental load operation.
2Click the Object Detail tab.
3In the subtask row for the source and target objects that you want to resynchronize, click the Actions menu and select Resync. The resync operation resynchronizes the target table with the latest source table definition, including any DDL changes.
Note: For the Actions menu and Resync option to be available, the subtask must be in a state other than Queued or Starting.
If you are resynchronizing a subtask for a database ingestion and replication combined load job that has a Db2 for i, Db2 for LUW Log-based CDC, Oracle, SAP HANA, or SQL Server source, use one of the following resync options instead of the Resync option:
- Resync (refresh) - Use this option to resynchronize the target table with the latest source table definition, including any DDL changes that schema drift ignored. After the target table is refreshed, the target table structure matches the current source table structure. This option mimics the behavior of the Resync option.
- Resync (retain) - Use this option to resynchronize the same columns that have been processed for CDC, retaining the current structure of the source and target tables. No checks for changes in the source or target table definitions are performed. If source DDL changes affected the source table structure, those changes are not processed.
For SAP HANA Trigger-based CDC source tables, the default is Resync (refresh).
Notes:
•If the source table contains many rows, the resynchronization might take a long time to perform.
•If the source table schema does not match the target table schema, the ingestion subtask drops the target table and creates a new table that matches the source schema. Regardless of whether the target tables are re-created, the subtask truncates the target tables and then reloads source data to the tables.
•When you resync a database ingestion and replication subtask with a Snowflake target and use Audit apply mode, you can retain the audit information. Data Ingestion and Replication re-creates the target table and renames the existing table that contains the audit information using an appended timestamp in the format <target_table_name>_<current_UTC_timestamp>. If you want the audit information in the new target table, you need to load it, for example, with a join operation. If adding the timestamp to the existing table name causes the name to exceed the maximum number of characters, the subtask fails with an error. If you enable schema drift and a schema drift change, such as Add Column, occurs, the new column will be in the re-created target table but not in the renamed table. To enable this behavior, set the backupTargetTableBeforeResync custom property to true on the Target page of the task wizard.
If you resync a combined load job that has existing audit information, the following considerations apply:
- Storing the existing table with the audit information on the target consumes extra database storage.
- To obtain a unified view of audit information, you need to join the multiple versions of the target tables.