Controlling Concurrent Execution of Scenarios and Load Plans FAQS

1. What is concurrent execution of scenarios and load plans?

• Concurrent execution refers to multiple instances of the same scenario or load plan running at the same time. This can happen across multiple agents or ODI Studio sessions, potentially leading to issues like data conflicts, corruption, or overwriting.

2. Why is controlling concurrent execution important?

• It is crucial to prevent multiple instances of a scenario or load plan from running simultaneously, especially when the job involves writing data. Concurrent execution could result in inconsistent data, data corruption, or overwriting of data if not controlled.

3. How does ODI identify a scenario or load plan?

• ODI identifies a scenario or load plan based on its internal ID, not its name or version. This means that even if the scenario or load plan is regenerated or modified, it is still treated as the same entity if the internal ID remains unchanged. If a scenario is deleted and recreated, it will be treated as a different scenario because the internal ID will change.

4. What is the default behavior for concurrent execution?

• By default, ODI does not restrict concurrent execution. This means two or more instances of the same scenario or load plan can run at the same time without any control, which could lead to conflicts or data integrity issues.

5. How can I control concurrent execution in ODI?

• You can control concurrent execution using the Concurrent Execution Control options in ODI. These options ensure that only one instance of a scenario or load plan runs at a time, preventing multiple instances from executing simultaneously.

6. Can concurrent execution occur across different agents or ODI Studio sessions?

• Yes, concurrent execution applies across all agents, including both remote agents and internal agents, as well as across different ODI Studio sessions. This means the issue can arise even if the instances are running on separate machines or environments.

7. What happens if I have a scenario with the same name and version but a different internal ID?

• A scenario with the same name and version but a different internal ID will be treated as a new scenario by ODI. The internal ID uniquely identifies the scenario, so regenerating or modifying a scenario while keeping the same name and version results in a different scenario.

8. How do I prevent multiple instances of the same scenario or load plan from running simultaneously?

• To prevent this, you can enable the Concurrent Execution Control options in the load plan or scenario configuration. This ensures that if one instance is already running, others will be blocked from starting until the first instance finishes.

9. Can I configure concurrent execution control for specific scenarios or load plans only?

• Yes, you can configure concurrent execution control on a per-scenario or per-load plan basis. This gives you the flexibility to control which specific scenarios or load plans should be restricted from running concurrently.

10. What issues can arise if concurrent execution is not controlled?

• If concurrent execution is not controlled, the following issues can arise:
• Data corruption: Simultaneous writes to the same data source can lead to inconsistent or incorrect data.
• Overwrites: Multiple instances may overwrite data, leading to loss of important information.
• Inconsistent results: Running the same scenario in parallel might cause unpredictable outcomes, especially if the scenario involves calculations or data transformations that depend on previous steps.

Here are some frequently asked questions (FAQs) related to Concurrent Execution Control for scenarios and load plans:

1. What happens when I enable Concurrent Execution Control?

• Enabling Concurrent Execution Control ensures that only one instance of a scenario or load plan runs at a time. It prevents multiple instances from executing simultaneously, helping to avoid conflicts, data corruption, or overwriting, especially when the job involves data writing.

2. What happens if I disable Concurrent Execution Control?

• Disabling Concurrent Execution Control allows multiple instances of the same scenario or load plan to run concurrently, potentially leading to issues such as data corruption or inconsistent results, particularly if multiple jobs are writing data to the same location.

3. What is the effect of changing Concurrent Execution Control settings while jobs are running?

• When switching from disabled to enabled: Existing running and queued jobs are treated as executing jobs and are not affected by the new setting. New job submissions will follow the new Concurrent Execution Control settings.
• When switching from enabled to disabled: Jobs already in the waiting state or those restarted later will carry the original Concurrent Execution Control setting values. However, new jobs submitted after disabling may run ahead of waiting jobs, potentially delaying them.

4. Can I change Concurrent Execution Control settings during job execution?

• Yes, you can change the Concurrent Execution Control settings at any time, but changes will only affect newly submitted jobs. Running jobs or jobs already queued will follow the rules that were in place at the time of their submission.

5. What happens to jobs that are in the waiting state when I disable Concurrent Execution Control?

• Jobs that are in the waiting state when Concurrent Execution Control is disabled will still be processed based on the original settings. However, once the setting is disabled, new jobs may execute before these waiting jobs, potentially causing delays.

6. What impact does disabling Concurrent Execution Control have on already waiting jobs?

• When Concurrent Execution Control is disabled, jobs already in the waiting state may be delayed. The system could find and process jobs that were submitted before the setting was disabled and treat them as executing jobs, which might lead to a waiting job being delayed.

7. Can jobs run concurrently after disabling Concurrent Execution Control?

• Yes, if Concurrent Execution Control is disabled, new jobs can run concurrently. This is true even if other jobs are already waiting or running, which could result in simultaneous execution of multiple jobs that would otherwise be restricted.

8. What happens when I restart a job after disabling Concurrent Execution Control?

• If a job is restarted after you disable Concurrent Execution Control, it will follow the settings in place at the time of the restart, which means it might not be controlled and could run concurrently with other jobs.

9. Will newly submitted jobs run ahead of waiting jobs if I disable Concurrent Execution Control?

• Yes, if you disable Concurrent Execution Control, new jobs may be executed before jobs that are in the waiting state. This can cause some waiting jobs to be delayed as they will be processed after the newly submitted ones.

10. How can I prevent multiple instances of the same scenario from running concurrently?

• To avoid concurrent execution of the same scenario, you should enable Concurrent Execution Control for the scenario or load plan. This ensures that only one instance runs at a time, preventing issues with data integrity and execution conflicts.

Here are some frequently asked questions (FAQs) regarding limiting concurrent execution of scenarios and load plans in ODI:

1. What does "Limit Concurrent Executions" do?

• Limit Concurrent Executions ensures that only one instance of a scenario or load plan can run at a time. If this option is enabled, multiple instances cannot run simultaneously, and the system will enforce the chosen Violation Behavior if an instance is already running.

2. What happens if I disable the "Limit Concurrent Executions" option?

• If the Limit Concurrent Executions option is disabled (unchecked), there is no restriction on concurrent execution. This means multiple instances of the same scenario or load plan can run at the same time without any control, which could potentially lead to data conflicts or other issues.

3. What are the possible Violation Behaviors when "Limit Concurrent Executions" is enabled?

• Raise Execution Error: If an instance of the scenario or load plan is already running, attempting to execute another instance will result in an execution error. The session will end with an error message indicating which session caused the issue.
• Wait to Execute: If an instance is already running, any new job submissions will be placed in a waiting status and will be executed when the current running instance finishes. The system will periodically check (poll) the status and update the waiting sessions.

4. What is the "Wait Polling Interval"?

• The Wait Polling Interval defines how frequently the system checks if the running instance has finished and whether it can execute the waiting jobs. You must specify a polling interval if you choose the Wait to Execute option.
• If not specified, the default interval for the executing agent will be used. In ODI 12.1.3, the default polling interval is 30 seconds.

5. What happens if I don’t set a Wait Polling Interval?

• If you don’t specify a Wait Polling Interval, the system will use the default interval set for the executing agent (e.g., 30 seconds in ODI 12.1.3). This interval defines how often the system checks if the running instance is complete.

6. Can I limit concurrent execution for specific scenarios or load plans?

• Yes, you can limit concurrent execution on a per-scenario or per-load plan basis. Each scenario or load plan can have its own Concurrent Execution Control settings, allowing you to apply different rules as needed.

7. How does the system handle queued jobs when "Limit Concurrent Executions" is enabled?

• When Limit Concurrent Executions is enabled and an instance is already running, any new submissions will be placed in the queued or waiting state. These jobs will wait until the running instance finishes, and then they will be executed in the order they were submitted.

8. What happens if I select "Wait to Execute" and there are multiple waiting jobs?

• If you select Wait to Execute and there are multiple jobs in the waiting state, the system will poll periodically to check if the running instance has completed. Once the running job finishes, the next waiting job will begin execution. All jobs will be executed in the order they were submitted.

9. What happens if I select "Raise Execution Error" and try to run a scenario while another instance is running?

• If you select Raise Execution Error and try to run a scenario while another instance is running, the new job will fail with an execution error message. The error message will identify the currently running session that caused the conflict.

10. How do I save the changes to the Concurrent Execution Control settings?

• After you make the desired changes to the Concurrent Execution Control settings, you need to click Save to apply those changes and save them for the scenario or load plan.