My Job behaving very peculiar

suresh.narasimha · Post by **suresh.narasimha** » Fri Dec 08, 2006 12:46 am

Hi,

Today i aborted a job and compiled it to re-run.

Surprisingly after compiling the job started running with Zero rows per second and some 50000 rows being processed.

I'm able to compile again and again but not able to run.

Please help why this is so and what could be the solution for this..

Regards,

I_Server_Whale · Post by **I_Server_Whale** » Fri Dec 08, 2006 1:17 am

1. What does the job do?

2. What are the stages that were used in the job?

3. How did you design the job?

4. Does it give out any warnings or error messages?

Always, more info about your job will help.

Whale.

Sreedhar · Post by **Sreedhar** » Fri Dec 08, 2006 1:34 am

This sort of behaviors is observed quite a number of times, one of the reason that would result in the peculiar behavior is, when you abort the job from the director, it my not have been terminated, the process must be still running at the background on the unix server.

So is the reason that it is getting complied but not able to run the job as the instance of the jobs is already under execution.

The solution to this should be, catch the PID of the job and Kill it explicitly on the unix server (but be careful in using the Kill command on the unix box and make sure that you catch the right PID, ) seek help from your Unix Admin if possible.

Please do let us know your observations...

caltog · Post by **caltog** » Fri Dec 08, 2006 1:36 am

What about the LOG ? Do you have any warning messages (from the DB ? ) ?

What do you mean by not able to run it again ?

suresh.narasimha · Post by **suresh.narasimha** » Fri Dec 08, 2006 2:33 am

HI Sridhar and All,

Problem is now resolved. Might be you are correct. This situation lasted for 5 mins and after that i was able to run my job.

Thanks for all replies.
Suresh N

ray.wurlod · Post by **ray.wurlod** » Fri Dec 08, 2006 3:41 pm

Rows/sec, as I have often asseverated, is meaningless. 0 is reported if the run finishes in less than 0.5 sec, because the time is rounded to whole seconds, and divide by zero errors are avoided.

Heck, if you want good statistics, all you have to do is wind back the system clock while the job is running - elapsed time is calculated by subtraction of start time from end time. This will also boost rows/sec. Have I mentioned how meaningless rows/sec is as a metric?