When you restart a load plan after a failure, you might not restart again from the exact point of failure, depending on where it occurred and on dependencies between load plan steps. The point of restartability is that the end result of the load plan execution is the same regardless of any load plan failure.
The following example describes one such dependency-driven requirement for re-running a step that has already completed: In a load plan with two steps, the first step truncates the table, and the second inserts records into the table, intermittently committing the records. The load plan is run and fails at the second step due to a space issue. After the issue is resolved, restarting the load plan from the second step is incorrect, because the target has some inserted rows. Restart should instead begin with the first step so that the target table is truncated again and newly inserted data does not cause any duplicates.
To maintain data integrity in the case of restart, the grain varies depending on the location in the step hierarchy of the failed step and on the Restart setting for the step in the Load Plan Manager.
Within the Steps Hierarchy in Load Plan Manager, you can view and edit the Restart setting of a step in the Restart column. The default settings for different steps in the hierarchy support data integrity in restarts:
Root steps are set to Restart From Failure if Serial and Restart from failed Children if Parallel.
Sub steps are set to Restart From Failure if Serial and Restart from failed Children if Parallel.
Scenario steps are set to Restart from Failed Step.
The following examples highlight the implications for each type of load plan step:
Serial Load Plan Step
Serial steps are represented by a horizontal icon in the Steps hierarchy in Load Plan Manager, and by default have a Restart setting of Restart from Failure. In a case where the load plan fails when running such a step to load a Dimension Group with multiple serial sub-steps loading individual dimensions, the load plan on restart, starts from the individual sub-step that failed. Any successfully completed serial sub-steps are run again.
Parallel Load Plan Step
Parallel steps are represented by a vertical icon in the Steps hierarchy in Load Plan Manager and by default have a Restart setting of Restart from Failed Children. In a typical run, a parallel step with five parallel sub-steps under it has all five sub-steps executed in parallel, subject to free sessions being available. If two of those five steps completed and then the load plan is to fail, when the load plan is restarted, all the steps that did not complete or failed are started again.
Scenario Step
At the lowest order in any load plan are the scenario steps. While the parent steps, whether serial or parallel, are used to set the dependencies, the scenario steps are those, which load the tables. A scenario step, in turn, can have one or more sub-steps, corresponding to the number of steps inside the package.
In the case of a scenario step failure during execution, consider that the scenario step might have multiple steps, all under the same session in the Operator log but identified with different step numbers: 0, 1, 2, and so on. In the case of restart, the scenario executes from the failed parent scenario step, re-running all sub-steps.
Note:
If you use the Load Plan Generator to generate a load plan, it automatically conforms to the standard. If you are manually altering a generated load plan or creating a new load plan without using Load Plan Generator, then you should ensure that you conform to the standard.