liveBook · Manning

Rerunnable process

As explained in 100 SQL Server Mistakes and How to Avoid Them

A rerunnable process is a process that can be executed again after partial failure without code changes or unintended duplicate results.

A rerunnable process can execute again after partial failure without code changes, data duplication, or loss of business-level consistency. section 12.5

Design an ETL process around three conditions:

  • Retain the original source data, or make it available again through a configurable API or cached transactional data. section 12.5
  • Parameterize dates instead of hardcoding expressions such as WHERE DataDate = GETDATE(). section 12.5
  • Merge results into target tables rather than relying on INSERT statements that can create duplicate business keys across multiple transactions. section 12.5

The overnight ETL failure

An ETL process starts at 1 a.m., runs for five hours, and populates staging and star-schema tables through several transactions. If it fails after a 2 a.m. backup, rerunning an INSERT-based process can create new identity rows with duplicate business keys, even though each transaction remains valid. section 12.5

How 100 SQL Server Mistakes and How to Avoid Them covers it

How deep it goes
Explains source replay, date parameters, and merge-based loading, then traces duplication risk across multiple transactions.
Examples
Uses flat files, configurable APIs, cached transactional data, parameterized dates, and an overnight star-schema ETL scenario.
What you can do after
Build it from scratch by retaining sources, parameterizing dates, and merging results into target tables.
How it connects
Connects rerunnable processes with ETL, data retention, staging tables, transactions, identity columns, and business keys.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of 100 SQL Server Mistakes and How to Avoid Them. The section links point to the parts of the book it draws on.