Job execution blocked (freeze) : no error, no warning!

Hi,

[EDIT]Excuse me to insist, but our production system is completely down.[/EDIT] :hb:

Do you know why a Job, which worked fine until yesterday night, doesn’t work anymore? It stops suddenly without start again!! I made no change on it … :crazy_face:

It seems to me my SQL source could be the reason. It’s the only element of my Job that I haven’t not mastered. See print-screen “2010-05-05_160535.png” in attachment.

[EDIT]This Job duration is normally 15 minutes! (2nd attachment). :cry:[/EDIT]

Gôm
2010-05-05_160535.png
2010-05-05_161243.png

copy the SQL used in the SQL Transform and execute that SQL Statement from other SQL Query tool of that database and see if its hanging or returning the data

check if there are any locks in the tables used in the SQL transform, since all the transforms are in ready state looks like something is blocking the source tables


manoj_d (BOB member since 2009-01-02)

Thank you! :+1:

The Database where I tried to launch my SQL query was instable.

Well … someone reboot this Database server and my problem disappear … :roll_eyes:

Thanks again. :wink:

Gôm

I only use the SQL statement approach as a large resort as it robs Data Services of any possibility to control or monitor its execution.

Is it really required to use custom SQL? Perhaps if you share more, we could think of ways to avoid this problem.

Because if it happened now, it will happen again - a regular SQL query shouldn’t cause a database to crash, unless that version of the database is buggy. (Like the recent Teradata 13 problems).


ErikR :new_zealand: (BOB member since 2007-01-10)

I’m agree with you, of course I dislike use a SQL statement, but this is not me who has developed the Job. :mrgreen:

We have … unfortunately … a lot of Jobs where there is a SQL statement. :?

Apparently the reason is the complexity of SQL query conditions. I know it could be possible to do the same with BODI components, but … no time!

At least I know what I should do next time … contact directly the DBA to audit its database :!: :roll_eyes:

Gôm