You can restart failed load plans using these alternate methods.
Using Mark as Complete
In most cases the load plan restart method described earlier in this section is the recommended approach. This approach ensures data integrity and leaves no scope for manual error. However, at times you might want to run a load plan step manually. For example, if a step is inserting duplicate records which are causing failure, rerunning the step still inserts duplicates. In such a case, you might need to manually correct the data outside of the load plan and then skip that step when you restart the load plan. For this kind of situation, you can use the Mark as Complete option.
When you mark a load plan step as complete, it ensures that when the load plan is restarted, the marked step is not executed. It is then the responsibility of the person making this setting to ensure that the load for that step is carried out outside the load plan.
To mark a step as complete, right-click the step and select Mark As Complete. You can do this at the scenario step or at any step higher than that.
Marking a step complete at a higher level in the step hierarchy means that none of the child steps under that parent step are executed upon load plan restart, even if they are otherwise eligible. For this reason, you should treat marking a step as complete as an advanced task and must mark a step complete with a full understanding of its impact. There is no single recommendation that pertains in all cases. Hence, you should make the setting carefully and on a case-by-case basis.
Running a Scenario Standalone
When you are monitoring a load plan, you might not completely know how to fix a scenario step failure, but you might want to use the Mark as Complete option for the failed scenario step instead of waiting for complete resolution. This prevents a step failure from precluding an entire load plan completing, while allowing you to inform the ETL team about the failed scenario step and work on a resolution. The ETL team might then fix the scenario and want to run it standalone outside the load plan to complete the load.
As in marking a step as complete, you should treat running a scenario standalone as an advanced task and you must bear these guidelines in mind:
A scenario run outside of a load plan by itself invokes the Table Maintenance process. This can happen, depending on the setting, truncate the table before the load.
To understand this, consider that when a scenario is run inside a load plan table maintenance tasks are carried out as explicit steps (the parent step name can be either Initialize or Finalize). The scenario by itself does not invoke the Table Maintenance process when run from within the load plan. Rather, this is controlled by the EXECUTION_ID variable, which is set to the load plan instance ID. If this variable has a value greater than 0 when a scenario is run, the Table Maintenance process is not invoked. This is the case when a scenario is run from within a load plan with an instance ID. However, if this variable does not have a value greater than 0, then the scenario invokes the Table Maintenance process. This is the case when a scenario is run outside the load plan. If you set a value for the EXECUTION_ID when invoking the scenario from outside a load plan, the table maintenance steps are not executed.
A scenario step can have many variable values set, either dynamically in the case of a refresh variable or explicitly by overriding its value at that scenario step in the load plan. When running a scenario outside the load plan, all the scenario variables must have only their default values. For this reason, you should set the variables appropriately before executing a scenario from outside the load plan. You can check the variable values that are present in the load plan by looking at the Operator log, provided the log level was set to 6 when the load plan ran. Configuration Manager uses Oracle Diagnostic Logging. See Managing Log Files and Diagnostic Data in Oracle Fusion Middleware Administrator's Guide.