DTS NZD Processing

This chapter describes the way in which DTS supports NZD. It does not explain all the details of the NZD processing principles. Before reading further, we recommend having a good understanding of the NZD task types used for migration and NZD migration.

The NZD processing is set at the table level, either automatically by table size in the step Analyze technical settings of tables or manually per table in the step Maintain technical settings.

DTS supports two delta modes:

1. DB triggers: Collects all changes of the DML (data manipulation language) operations defined for the database trigger. The changes over the time are collected in a trigger shadow table. This table is generated by DTS when the first trigger is activated. You can manage database triggers, including browsing the trigger shadow table data, in the step Open Glue trigger management. The data collection starts after the database trigger activation.

2. BW requests: Collects delta based on the SAP BW request date and time. The delta timestamp is stored at each delta execution. The first timestamp is saved before the delta initialization. This mode is applicable for BW InfoProviders only. If other tables in the SAP BW application are processed during the uptime processing, database trigger mode must be applied.

   Important: No housekeeping activities on either BW requests or BW application logs can be executed on the system during NZD migration activities.

   NOTE The database triggers on BW tables might have a serious impact on the performance of the data load due to the high number of changes involved in one database operation. Setting up database triggers on a BW system requires expert knowledge.

NZD processing is only applicable to tables with a delta mode enabled (defined via the step Maintain technical settings) and has three phases. First two are executed in the uptime, while the last one is executed in the downtime:

1. Delta initialization: The tables are fully migrated into the target system.

2. Delta processing: The deltas of the tables, either from the trigger shadow tables or based on a BW request, are migrated into the target system.

3. Final delta processing: This phase is the same as any uptime delta, but the execution must be performed in the downtime together with migration of tables without the NZD setting.

Initially, only the step for processing delta initialization is available within the DTS activity tree, see the chapter Create Initial Load. This step performs the following actions for all NZD-enabled tables:

• Checks the consistency for delta processing

• Sets the initial load timestamp for NZD processing

• Generates the next steps in the DTS activity tree for performing further NZD-related activities. The following steps are generated:

  • A summary task called Initial load processing to initialize the delta execution, containing these steps:

    • Generate tasks for delta tables

    • Generate programs for delta tables

    • Execute and monitor delta transformation

  • Two steps for processing the next delta:

    • Execute parallel read for delta <#nnn>

    • Create delta <#nnn>: This step generates the tasks for the next delta. Here, <#nnn> = 001 after the initial load, where <#nnn> grows with the number of delta executions. Similar to the initial load, each delta captures a timestamp, and each delta generates new steps in the DTS activity tree.

      The new delta steps are the same as the steps created by the step Create initial load. The only difference is that the summary task from the steps above is named Delta <#nnn> processing instead of Initial load processing. If the delta is supposed to be the final one, i.e. the Create downtime delta option is enabled, the delta is generated in the downtime summary task within the DTS activity tree and must be performed in the downtime phase of the project execution.