Long running job.....

vaibhavjadhav · New User Joined: 27 Jul 2007 Posts: 33 Location: mumbai

Hi,

In my system there is one job which does read, insert, delete and replace function on the IMS databases, there are kind of 5 databases which are used in this job. A month ago one of the database was migrated to DB2 and the job started taking long running time. I just want to know what would be the reasons behind this and how and where to check the possibilities for this issue.

Your suggestion/guidance would be much appreciated.

Note: Prior to DB2 migration, job used to take 1 hour and now it takes almost 3 to 4 hours.

Thanks
Vaibhav

Gary McDowell · Active User Joined: 15 Oct 2012 Posts: 139 Location: USA

Does your shop have any systems tools, like Freeze Frame?

vaibhavjadhav · New User Joined: 27 Jul 2007 Posts: 33 Location: mumbai

No... sorry i dont have any kind of these tools

dick scherrer · Posted: Thu Nov 07, 2013 1:45 am

Hello,

If your IMS system was reasonably well implemented, it is no surprise that the db2 replacement takes longer (and uses more resources).

This should have been observed when doing full-volume testing and dealt with before being moved into Production.

What specific performance analysis has been done to determine if everything in the run is bad or if there isw a smaller number of problem areas?

vaibhavjadhav · New User Joined: 27 Jul 2007 Posts: 33 Location: mumbai

Thanks for your reply dick scherrer....

Actually i belong to application support area and the migration was done by development team so i am not very sure about the performance analysis but now as a part of service improvement i am analyzing why does this job takes long time to run....hence i just wanna know what would be the possible reasons for this so that i can begin with my analysis in the correct direction.
Hope i am much clear in case if i am not do let me know so that i will try to provide more information.

Thanks
Vaibhav

dick scherrer · Posted: Thu Nov 07, 2013 2:03 am

Hello,

Look at the definition of the tables (and index entries) for the tables used in the poor performing processes. Review the SQL code and run EXPLAINs to see what SQL needs to do to service these quesirs.

It is most unfortunate that this is not being done in a test environment. . .

I believe you have been clear enough for generally purposes, but in order to actually diagnose/tune, you will need to deal with much lower level specifics. There is probably not a "quick fix" as i suspect there are several things that will need help.

Gary Jacek · Posted: Thu Nov 07, 2013 4:13 am

Hi Vaibhav

Have you checked to see if you have Omegamon for IMS, Omegamon for DB2, Mainview/IMS, Mainview/DB2 products which might be usedful to find out why the job runs so long now?

One step to take, is to run RUNSTATs against the new DB2 tables and then rebind the packages/plans that use these tables. The most efficient access path may have changed when full-size production data was loaded.

When you say "moved to DB2", you don't by any chance mean that the data moved to DB2 on a non-zOS platform, and your zOS DB2 is being used to obtain/update the data remotely. This would REALLY slow it down.

You may get more suggestions by posting this in the DB2 forum, but make sure you mention this is DB2 on zOS/MVS so you get answers that pertain to this platform.

Gary

vaibhavjadhav · New User Joined: 27 Jul 2007 Posts: 33 Location: mumbai

Thanks everyone for your replies, I will try to check the above mentioned points and will get back to you guys in case i still have any concern.
Thanks again...