RE: Postmortem on QZDASOINIT jobs

In the past I've seen similar situations at a major international bank and an aircraft manufacturer. The cause was either the client not performing a commit often enough or not closing a cursor(s) correctly. In either case disk cache continues to build.


Gary

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Charles Wilt
Sent: Thursday, August 02, 2012 10:12 PM
To: Midrange Systems Technical Discussion
Subject: Postmortem on QZDASOINIT jobs

For about 2hrs yesterday, a company I help out once and a while had disk activity up around 90% busy...

Needless to say, this dragged down the entire system even though CPU usage was only about 10%...

It seems as if the problem was from QZDASOINIT jobs servicing requests from the Extranet web site...once all the active QZDASOINIT jobs (about 13) were ended things went back to normal (ok they had to do 2 rounds of ending)

I don't see anything showing as taking longer then 45s in the SQL plan cache...

They had already ended the jobs before contacting me, so "last SQL statement" was not an option.

PM/400 is running....and they have the performance tools licensed program...

Is there anything I can look at now to maybe figure out what happened?

Is there anything I can turn on and leave running in case it happens again?

Third party tools may be an option.

Thank you,
Charles
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.