--
In this post we will look at ODI session restarts. Basically, how ODI behaves when you restart a session and different restart options for Load Plans.
We will consider three cases:
Case 1) Restarting a Scenario with no sub-scenarios -
I have here is a "LOAD_ALL" package which is executing three steps (interfaces using IKM SQL Control Append). I have dropped the target table so that JOBS_LOAD interface fails.
Executing the ODI package
ODI generated a session number 99045 and the interface JOBS_LOAD failed at task "Truncate target table".
ODI stores all the task (commands in your KM or procedure)execution details in the work repository table SNP_SESS_TASK_LOG
After fixing the error and restarting the session 99045. ODI restarts the session from the failed task which is the "Truncate target table" for interface JOBS_LOAD. If the interface had failed while executing the "Insert new rows" task then ODI would have restarted it from the same task.
In cases where there are no sub-scenarios inside an scenario , ODI will restart from the failed task rather than the failed step.
If you create a scenario for an ODI object(like Interface,Procedure) , restarting the failed scenario will result in same behavior.
Case 2) Restarting a Scenario with sub-scenarios -
Created a scenario for each of the three interfaces and added them in a package LOAD_ALL_SCEN.
Again before executing the package , i will drop the table to fail the interface JOBS_LOAD.
Executing the scenario for the package
ODI created session for each scenario. The Parent session 101045 (scenario for package LOAD_ALL_SCEN ) spawns a new session (102045,103045) for each sub-scenario (interfaces). The session 103045 failed (scenario for JOBS_LOAD interface).
Fixed the error and restarted the parent session 101045.
The parent session starts from the failed step. It does not starts from the failed task.. In this case it created a new session 104045 for the JOBS_LOAD scenario.
Note: Sessions can be restarted at the failed sub-scenario(step). This should be avoided because they execute the current failed step and stop. Restarts should be done at top most parent session.
View of the SNP_SESS_TASK_LOG -
Case 3) Restarting Load Plans -
To explain the restart concept , we will take an example of simple load plans with no exception handling ( If anything fails load plans fails ).
Load plans provides different restart options. Executing a load plan creates a session.
Load plans consists of steps (Serial,Parallel,Case,When,Else). Steps can have sub-steps and scenarios. The scenarios are the lowest entity in the Load Plan.
The first step is always a Serial step. In the example above its named as the ROOT_STEP.
If a scenario under a step fails then the step itself fails.
Restart options at the Step level of Load Plans
1) Restart from failure -
If the load plan is restarted then the scenario which failed will be the place where restart will initiate.
Look at the restart options at Scenario level.
2) Restart all children -
This will re-excute(new sessions) all the successfully executed scenarios, the scenario which failed will be
restarted as per the restart option set at the scenario level.
Restart options at the Scenario level of Load Plans
Note: The "Step" discussed here is this section is a step within an ODI Package which is executed as a scenario.
1) Restart from new Session -
The failed scenario will be re-executed with a new session.
If the scenario has sub-scenarios as steps, a new session will be launched again for each scenario.
2) Restart from failed Step -
If the failed scenario executes other scenarios (sub-scenarios) as steps then a new session will be launched
for failed sub-scenario as discussed in "Case 2".
If there is no sub-scenario as step then restart will start from the failed step.
3) Restart from failed Task -
If the failed scenario has sub-scenario as steps then a new session will be launched for failed sub-scenario.
If there is no sub-scenario as step then restart will start from the failed task as discussed in "Case 1" above.
Load plans provide additional benefits of restart which are not provided by packages.
A good practice is always create scenarios for each and every object.
--
In this post we will look at ODI session restarts. Basically, how ODI behaves when you restart a session and different restart options for Load Plans.
We will consider three cases:
Case 1) Restarting a Scenario with no sub-scenarios -
I have here is a "LOAD_ALL" package which is executing three steps (interfaces using IKM SQL Control Append). I have dropped the target table so that JOBS_LOAD interface fails.
ODI generated a session number 99045 and the interface JOBS_LOAD failed at task "Truncate target table".
ODI stores all the task (commands in your KM or procedure)execution details in the work repository table SNP_SESS_TASK_LOG
After fixing the error and restarting the session 99045. ODI restarts the session from the failed task which is the "Truncate target table" for interface JOBS_LOAD. If the interface had failed while executing the "Insert new rows" task then ODI would have restarted it from the same task.
In cases where there are no sub-scenarios inside an scenario , ODI will restart from the failed task rather than the failed step.
If you create a scenario for an ODI object(like Interface,Procedure) , restarting the failed scenario will result in same behavior.
Case 2) Restarting a Scenario with sub-scenarios -
Created a scenario for each of the three interfaces and added them in a package LOAD_ALL_SCEN.
Again before executing the package , i will drop the table to fail the interface JOBS_LOAD.
Executing the scenario for the package
Fixed the error and restarted the parent session 101045.
Note: Sessions can be restarted at the failed sub-scenario(step). This should be avoided because they execute the current failed step and stop. Restarts should be done at top most parent session.
View of the SNP_SESS_TASK_LOG -
Case 3) Restarting Load Plans -
To explain the restart concept , we will take an example of simple load plans with no exception handling ( If anything fails load plans fails ).
Load plans consists of steps (Serial,Parallel,Case,When,Else). Steps can have sub-steps and scenarios. The scenarios are the lowest entity in the Load Plan.
The first step is always a Serial step. In the example above its named as the ROOT_STEP.
If a scenario under a step fails then the step itself fails.
Restart options at the Step level of Load Plans
1) Restart from failure -
If the load plan is restarted then the scenario which failed will be the place where restart will initiate.
Look at the restart options at Scenario level.
2) Restart all children -
This will re-excute(new sessions) all the successfully executed scenarios, the scenario which failed will be
restarted as per the restart option set at the scenario level.
Restart options at the Scenario level of Load Plans
Note: The "Step" discussed here is this section is a step within an ODI Package which is executed as a scenario.
1) Restart from new Session -
The failed scenario will be re-executed with a new session.
If the scenario has sub-scenarios as steps, a new session will be launched again for each scenario.
2) Restart from failed Step -
If the failed scenario executes other scenarios (sub-scenarios) as steps then a new session will be launched
for failed sub-scenario as discussed in "Case 2".
If there is no sub-scenario as step then restart will start from the failed step.
3) Restart from failed Task -
If the failed scenario has sub-scenario as steps then a new session will be launched for failed sub-scenario.
If there is no sub-scenario as step then restart will start from the failed task as discussed in "Case 1" above.
Load plans provide additional benefits of restart which are not provided by packages.
A good practice is always create scenarios for each and every object.
--
Suraj,
ReplyDeleteYou mention «A good practice is always create scenarios for each and every object.»
With «each and every object» do you mean all interfaces and such? What about packages where you have logic (loops, IFs, variables, etc) that condition the invocation of some interfaces?
Thanks,
PMGuerra
Hi PMGuerra,
ReplyDeleteWith "each and every object" I meant - interfaces , procedures or packages used within a package.
For packages involving variables,loops,etc the decision to generate scenarios for variables should depend upon the business logic. From case to case it can be different, for example if you want to evaluate\set\declare a variable then scenario for that variable cannot be used. Generally if your variable is of refresh type and refreshing the variable on restart doesn't affect the processing then you can use the scenario for that variable , in other cases you can use the variable as it is.
Scenarios also provide you the additional advantage of running a step across different agents.
Regards,
Suraj
How do you rigorously test a load plan?
ReplyDeleteHow to kill ODI sessions which are running long hours?
ReplyDelete