Table of Contents

Search

  1. Preface
  2. Understanding Pipeline Partitioning
  3. Partition Points
  4. Partition Types
  5. Pushdown Optimization
  6. Pushdown Optimization and Transformations
  7. Real-time Processing
  8. Commit Points
  9. Row Error Logging
  10. Workflow Recovery
  11. Stopping and Aborting
  12. Concurrent Workflows
  13. Grid Processing
  14. Load Balancer
  15. Workflow Variables
  16. Parameters and Variables in Sessions
  17. Parameter Files
  18. FastExport
  19. External Loading
  20. FTP
  21. Session Caches
  22. Incremental Aggregation
  23. Session Log Interface
  24. Understanding Buffer Memory
  25. High Precision Data

Advanced Workflow Guide

Advanced Workflow Guide

Target Recovery Tables

Target Recovery Tables

When the Integration Service runs a session that has a resume recovery strategy, it writes to recovery tables on the target database system. When the Integration Service recovers the session, it uses information in the recovery tables to determine where to begin loading data to target tables.
If you want the Integration Service to create the recovery tables, grant table creation privilege to the database user name configured in the target database connection. If you do not want the Integration Service to create the recovery tables, create the recovery tables manually.
The Integration Service creates the following recovery tables in the target database:
  • PM_RECOVERY.
    Contains target load information for the session run. The Integration Service removes the information from this table after each successful session and initializes the information at the beginning of subsequent sessions.
  • PM_TGT_RUN_ID.
    Contains information the Integration Service uses to identify each target on the database. The information remains in the table between session runs. If you manually create this table, you must create a row and enter a value other than zero for LAST_TGT_RUN_ID to ensure that the session recovers successfully.
  • PM_REC_STATE.
    Contains information the Integration Service uses to determine if it needs to write messages to the target table during recovery for a real-time session.
If you edit or drop the recovery tables before you recover a session, the Integration Service cannot recover the session. If you disable recovery, the Integration Service does not remove the recovery tables from the target database. You must manually remove the recovery tables.
The following table describes the format of PM_RECOVERY:
Column Name
Datatype
REP_GID
VARCHAR(240)
WFLOW_ID
INTEGER
WFLOW_RUN_ID
INTEGER
WFLOW_RUN_INS_NAME
VARCHAR(240)
SUBJ_ID
INTEGER
TASK_INST_ID
INTEGER
TGT_INST_ID
INTEGER
PARTITION_ID
INTEGER
TGT_RUN_ID
INTEGER
RECOVERY_VER
INTEGER
CHECK_POINT
INTEGER
ROW_COUNT
INTEGER
The following table describes the format of PM_TGT_RUN_ID:
Column Name
Datatype
LAST_TGT_RUN_ID
INTEGER
The following table describes the format of PM_REC_STATE:
Column Name
Datatype
OWNER_TYPE_ID
INTEGER
REP_GID
VARCHAR(240)
FOLDER_ID
INTEGER
WFLOW_ID
INTEGER
WFLOW_RUN_INS_NAME
VARCHAR(240)
WLET_ID
INTEGER
TASK_INST_ID
INTEGER
WID_INST_ID
INTEGER
GROUP_ID
INTEGER
PART_ID
INTEGER
PLUGIN_ID
INTEGER
APPL_ID
VARCHAR(38)
SEQ_NUM
INTEGER
VERSION
INTEGER
CHKP_NUM
INTEGER
STATE_DATA
VARCHAR(1024)
Oracle uses the NUMBER datatype instead of the INTEGER datatype.
When concurrent recovery sessions write to the same target database, the Integration Service may encounter a deadlock on PM_RECOVERY. To retry writing to PM_RECOVERY on deadlock, you can configure the Session Retry on Deadlock option to retry the deadlock for the session.

0 COMMENTS

We’d like to hear from you!