Analytics Software

Refer http://docs.oracle.com/cd/E28271_01/integrate.1111/e12643/running_executions.htm

Stale sessions are sessions that are incorrectly left in a running state after an agent or repository crash.

The Agent that started a session automatically detects when this session becomes stale and changes it to Error status. You can manually request specific Agents to clean stale sessions in Operator Navigator or Topology Navigator.

To clean stale sessions manually:

Do one of the following:
From the Operator Navigator toolbar menu, select Clean Stale Sessions.
In Topology Navigator, from the Physical Architecture accordion, select an Agent, right-click and select Clean Stale Sessions.
The Clean Stale Sessions Dialog opens
In the Clean Stale Sessions Dialog specify the criteria for cleaning stale sessions:
From the list, select the Agents that will clean their stale sessions.
Select Clean all Agents if you want all Agents to clean their stale sessions.
From the list, select the Work Repositories you want to clean.
Select Clean all Work Repositories if you want to clean stale sessions in all Work Repositories.
Click Clean to start the cleaning process.

Bhabani
http://dwteam.in

hi,
but why am i getting these stale sessions .
after cleaning stale sessions also i m getting the same error.
error appears normally while loading huge volume of data (around 20 millions).
so in the load data step in the interface scenario , after running for a while , it shows the error.
i want the scenario to be executed fully without any issues.

Are your Agent connections to the work repos timing out? Is there any correlation between the duration of the failed steps in operator?

I had a bug where a jython procedure was inserting millions of rows into the application database in a tight loop. The master and work repositories and the application database were all on the same machine/server. The ODI Agent declared running scenarios as stale, due, I think, to timeouts when trying to access the work repository. I killed the bad jython procedure and the problem went away.

today i converted the ODI interface and deployed the same as a PL/sql procedure . then i made a ODI procedure just to call the database procedure.
for example :
begin
procedure_test; ------------- procedure deployed on database -------------
end;

when i ran the ODI procedure scenario , it again went into a stale session after some time .
But when i checked the sql procedure was successfully executed and the data got inserted into the table. i'm not getting y still it gave stale session. is it happening because of ODI connection timeout parameter ???
i have observed that error is more common when data volume is large .

please share your views and solution.

ODI creates and keeps open the master and work repository connection for each session execution. These connections are used by ODI agent/runtime to write logs, statistics and read session data for executions. It seems in your case these connections are getting timedout because of which odi agent gets exception and aborts session execution. Since the repository connection is closed it cannot even update the session status in repository and thus making that session a stale session, a session which is marked running in repository but is not executed by an agent. Agent cleanup such stale sessions as part of its operations on predefined triggers and changes its status to Error.

Increasing the connection timeout interval should address your problem.

hi ,
okay i'll try by increasing the timeout.
is this happening beacuse we have a single agent for nearly 30-40 scenarios which are triggered at different times during the day ?
would creating a new agent and using loadbalancing solve the issue ?

No. Number of scenarios in Agent does not cause this. This is caused by the timeout on repository connection while the execution is busy in performing other task. So load balancing too would not make any difference.