These features of Oracle Business Intelligence Applications are related to restartability and describe some other related considerations.
Using CKM to Filter Erroneous Data
If a scenario step is failing due to bad source data, you can enable the CKM option to load the valid records and route the error records to a separate table. Examples of situations where this might be appropriate are the load of null values when they should have a value or data lengths longer than allowed target column lengths. Once the load completes, you can correct the erroneous data and have it automatically picked up in a subsequent load.
Note:
Use of CKM can slow the load considerably because every record and column might be checked before loading. For this reason, this is not an option that you want to turn on across the entire load plan.Note:
Error handling and logging of erroneous data is now automatically handled by the ETL process. See About Diagnostics Health Check.Regenerating a Scenario During a Load Plan Execution
Consider a case where a load plan is started and fails at a scenario step. You fix the issue and regenerate the scenario, then restart the load plan and might expect it to pick the new scenario, but this is not what happens. If a load plan has been started and a scenario regenerated, the regenerated scenario code is not picked up when the load plan is restarted. To force the regenerated scenario to be picked up, you have two options:
Start a new load plan run, accepting the overhead associated with restarting the load from the beginning.
Run the regenerated scenario as stand-alone outside the load plan, marking that scenario step as complete in the load plan before restarting the load plan.
See Alternate Options for Restarting Load Plans for implications of using these options.
Restarting Long Running Jobs
Consider a case where you have a scenario that takes two hours to run. The scenario fails at the insert new rows step, after loading the C$ and I$ steps. On restart, the scenario attempts to reload the C$ again. You instead want it to restart from the insert new rows steps only. This use is not supported. The restartability mechanism has been put in place in such a way that restarting a load plan is all you need to do. You do not need to clean up any data in between load plan executions, because the data is committed to the target table only after all the Knowledge Module steps are successful. If the load fails before complete success, no data is committed to that specific target table as part of the failed session.
Note:
New C$ and I$ tables are created on restart and hence data to these tables is committed in between load plan start and restart.Stale C$ and I$ Tables
On restart, new C$ and I$ tables are created, but since the previous load did not complete, these tables from the previous session are not dropped. The load plan generated using Load Plan Generator has a step at the end of the load plan executed Clean Stale Work Tables which takes a variable called ETL_DTOP_STG_OLDER_THAN_DAYS whose default value is 30 days. When this step runs, it drops any C$ and I$ tables that are older than the specified variable value.
Note:
The C$ and I$ tables are useful tables when you want to debug a failed scenario. It might not be advisable to set the ETL_DTOP_STG_OLDER_THAN_DAYS value as too small—for example, one day—as you might lose valuable information for debugging.