Comments on: QZDASOINIT JOBS using large cpu

By: TomLiotta

TomLiotta — Thu, 07 Mar 2013 12:05:49 +0000

It’s not clear what problem you need to solve. If it’s just the access plan, the message already tells you how to fix it. If it’s high CPU, please give details that would help know if the CPU utilization is unreasonable. E.g., what queries are run? What are the related database statistics and definitions? What are the system resources? How have work management settings been tuned for these queries? — Tom

By: Haaiderali

Haaiderali — Thu, 07 Mar 2013 10:58:37 +0000

Currently we have many QZDASOINIT jobs connecting to our iSeries System for Data Extraction using COGNOS Impromtu. ideally 8 to 10 connections from different windows servers run throughout the day taking the total CPU Utilisation of iSeries to 80 to 90 Percent. Upon investigation we identified a message stating “Access plan not updated.” in the Joblog.
***********************************************************
Message ID . . . . . . : SQL7917 Severity . . . . . . . : 00 Message type . . . . . : Information Date sent . . . . . . : 07/03/13 Time sent . . . . . . : 16:09:39 Message . . . . : Access plan not updated. Cause . . . . . : The query optimizer rebuilt the access plan for this statement, but the program could not be updated. Another job may be running the program. The program cannot be updated with the new access plan until a job can obtain an exclusive lock on the program. The exclusive lock cannot be obtained if another job is running the program, if the job does not have proper authority to the program, or if the program is currently being saved. The query will still run, but access plan rebuilds will continue to occur until the program is updated. Recovery . . . : See previous messages from the query optimizer to determine why the access plan has been rebuilt. To ensure that the program gets updated with the new access plan, run the program when no other active jobs are using it.
***********************************************************
Please suggest a way out to resolve the issue .. Thanks in advance
Server : iSeries 570 Power6
O/S Version : V6R1M0

By: TomLiotta

TomLiotta — Thu, 07 Feb 2013 19:09:08 +0000

And also, your definition of “a lot of CPU” should be supplied. — Tom

By: TomLiotta

TomLiotta — Thu, 07 Feb 2013 19:07:26 +0000

Now that the app is identified, is the reason for high CPU also identified? Database updates by themselves shouldn’t use excessive CPU, and an app should only be using one or two QZDASOINIT jobs. If many jobs show high CPU, it might simply be that your prestart jobs or your subsystems need to be configured for environment. — Tom

By: 100282

100282 — Thu, 07 Feb 2013 14:27:14 +0000

We checked the job logs and found that the jobs are originating from an application and because of requests for DB updates they were consuming lot of CPU. After figuring out the application, we had requested users not to use that application for a day during that time and those jobs were normal. CPU was stable. Thanks for your help.

By: TomLiotta

TomLiotta — Wed, 06 Feb 2013 21:06:03 +0000

First, can you clarify if it’s “the QZDASOINIT jobs” rather than “a QZDASOINIT job”?

Then, please elaborate on “everyday approx the same duration of time”. Does that mean that QZDASOINIT jobs suddenly start using excessive CPU at some point in a day, and then after a similar interval each day they go back to using normal resources. But it doesn’t start at the same time of day, so it’s unlikely to be scheduled.

Tom

By: CharlieBrowne

CharlieBrowne — Wed, 06 Feb 2013 16:15:27 +0000

Have you checked the JOBLOG from those programs and the activity in QHST durint that time frame?