Note: There is an updated version of this article, which applies to the next generation of TimeXtender.
Execution packages have two ways of handling errors: fail and retry. The default value is to fail when encountering an error. This ensures the integrity of data in your BI environment. However, data sources may be periodically locked by updates, backups, etc. In this case, failure may occur if the load collides with one of these processes.
In the event the data source is temporarily unavailable, the failure doesn't represent a problem that needs to be fixed - instead, the desired behavior is to simply wait a while and try again. Retry steps is designed to provide this functionality.
When enabled, the retry step option has three values that can be configured. These values are Retries, Retries per Step, and Retry delay in minutes, as shown here:
Retry delay in minutes simply defines the time the package will wait between an execution failure and the next retry. Retries and Retries per Step define exactly how the execution package will handle its retry attempts.
Retries defines the total number of retries the package will attempt, and Retries per Step defines how many attempts will be made on a given execution step. An execution step is a basic execution task, which can include an SSIS transfer, executing a pre- or post-step, or a running data cleansing script.
It's important to note that the Retries value can effectively override Retries per Step. This is because running down either counter will cause the package to fail.
For instance, if you set Retries per Step to 3 and Retries to 1, the execution package will run one retry when the step fails the first time. If the step fails a second time, the execution package will check the remaining retries for the step (2), and the remaining retries for the entire package (0), note the zero value, and fail the package.
For most packages, the number of Retries should equal to the number of steps you want to retry in a given load times the number of retries per step.
If you want to allow up to four steps to fail, and to retry each step twice, then Retries per step should equal 2 and the Retries value should be 2 retries * 4 steps = 8.
If you want one step to get retried up to three times, then Retries per Step must be 3, and Retries should be equal to 3 retries * 1 step = 3. Note that this could also result in three steps being retried one time each. This is a limitation of the current implementation of the Retry functionality.