we have same jobs on two diffrent prodution environment.All jobs are same there is no diffrence on jobs.
in one production with 50K data job has finishedsuccessfully..aprox..15 mints
In other production with 50K data job has taking nearly 1 hr.evry thing is same on both env jobs.
Please help me on this....where we can tune
performance tuning on dastage jobs
Moderators: chulett, rschirm, roy
Hi ravipuli,
it is almost impossible to give an answer to your question. You say that both jobs and both environments are (at least as far as you can see) identical in terms of hardware. Hopefully you've also got approximately the same workload on both servers while running the job in question (there is no traffic-jam on the slow server).
Are you using identical data-sources? If I interpret your text correctly, the job only moves 50.000 records and takes 15 (!) minutes for that, at best. Which would seem to me to be an awful lot, unless the job contains overwhelmingly complex SQL-statements...
it is almost impossible to give an answer to your question. You say that both jobs and both environments are (at least as far as you can see) identical in terms of hardware. Hopefully you've also got approximately the same workload on both servers while running the job in question (there is no traffic-jam on the slow server).
Are you using identical data-sources? If I interpret your text correctly, the job only moves 50.000 records and takes 15 (!) minutes for that, at best. Which would seem to me to be an awful lot, unless the job contains overwhelmingly complex SQL-statements...
"It is not the lucky ones are grateful.
There are the grateful those are happy." Francis Bacon
There are the grateful those are happy." Francis Bacon
What does the job do? Read from a database or write to a database?
Understand that the typical slow part in a job is IO. That could be writing to your disk or writing to a database.
to test out some stuff, make a copy of the job and replace the target database with a copy stage.
recompile and run.
Now you have eliminated the target DB from the equation. Does your job still under perform on your prod environment? If it is still very slow... then it's not your DB interaction. (but honestly... it's most likely a DB interaction slowness when you are talking mins vs hours). Point is... start breaking down your job into it's logical sections and narrow down the possibilities.
Understand that the typical slow part in a job is IO. That could be writing to your disk or writing to a database.
to test out some stuff, make a copy of the job and replace the target database with a copy stage.
recompile and run.
Now you have eliminated the target DB from the equation. Does your job still under perform on your prod environment? If it is still very slow... then it's not your DB interaction. (but honestly... it's most likely a DB interaction slowness when you are talking mins vs hours). Point is... start breaking down your job into it's logical sections and narrow down the possibilities.
thank you..very much to all
Got some resolutions from DBA.We need to work on SQL queerys.Need to filter the data more and need to create an index some coulmns.....thanks to all
ravikumar