DSXchange

Many of us might have heard complains from users that Their jobs are running extremely slow in production and how do we make it finish,Since this is production so we can't make any changes to the job but Yes we start looking around other things like CPU,Memory,Network,Job design,DB locks etc...
I do face this issue continuously and trying to make a checklist on what all need to be checked and tweaked.

So I am trying to compile opinions from the experts,Please throw some light on Slow running jobs and It will definitely help me and others as well.

Any best practices documents,write-ups,little notes,one-liners on this topic will be highly appreciated.

Cheers
Etler

All our DEV and QA servers are configured the same way from the infrastructure perspective.

Same systems, same CPUs, Memory, same network switches, same disks, same SANs etc.

So whenever we encounter a difference in performance between one environment and another, in our case, most of the time the problems occurs at the database end, specifically the tables are not analyzed or the statistics are old making the optimizer choose a longer access path. Or someone forgot to turn off the nologgin option on staging tables sabotaging the direct path access...stuff like that....

have you used any transformer Stage .Problem is if any transformer stage used in job it wil take more time do compiling because of transformer stage need to C++ compiler.

Sampath wrote:have you used any transformer Stage .Problem is if any transformer stage used in job it wil take more time do compiling because of transformer stage need to C++ compiler.

Transformer is likely to be faster at run time than alternatives such as Filter or Switch exactly because it's compiled.