Expert SQL Server™ 2005 Integration Services

7.3. Checkpoint Files

If you're a production DBA or have been a support person at one point, it's certain that you've had a middle-of-the-night call because of an ETL failure of some sort. You probably had to go into the server while you were groggy from lack of sleep, and try to make the necessary changes to get the package working again. For example, you may have had to clean up space on the server in order for the package to complete its load. Now comes the ultimate problem: Do you re-run the entire package or just a piece of the package, and if you only ran a piece, what piece?

If you choose the wrong answer to that question, you can accidentally reload data, causing duplication or not load data at all. It's a bad spot for a DBA to be in, and is highly contingent on experience with the package that failed. This experience is great until the DBA who has the experience goes on vacation or quits, and someone else has to come up to speed quickly.

Checkpoint files are a tool in your SSIS arsenal to mitigate this problem. Essentially, these files allow you to rerun a package from the point of failure, and they save the state of the package at failure. That state file, which is XML, will contain which container or task last successfully executed, as well as other state information (such as the variable values). When you fix the problem that caused the package to fail and re-run the package, it will start at the step that failed, and skip over the successful tasks.

There are a few ...