× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Martin

Have you tried using iSeries Nav Database for this issue?

I would start a DB monitor, in iSeries Nav, run the job, then end the DB
monitor.  Right click on the monitor then take 'List Explainable
statements' click on the processing time column to show the longest
running statement.    Highlight that option then take the options to run
Visual Explain.  Once there you can use this tool to advise if any
indexes need building and it will also show the most expensive
row/processing stages.

HTH 

Regards

Andy Youens | Senior IBM Consultant | formaserve systems ltd
Tel: 01908 609500 | Mob: 07770 380276 | http://www.formaserve.co.uk

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Bath, Martin
Sent: 27 April 2006 08:02
To: 'midrange-l@xxxxxxxxxxxx'
Subject: SQL performance problem on one job only

Hi guys

Anyone help me with this before I scream, please?
I have one 3rd Party job that contains 30 embedded SQL commands that
runs ok
for a while (runtime between 10 secs and 3 minutes in batch) and then,
inexplicably, runs for over an hour without ever finishing.

So far, I've
1) Checked DBMON for missing logicals. Created some but this seem to
make it
worse.
2) Checked for damaged logicals. Replaced them all anyway
3) Recompiled program.
4) Converted program from OPM to ILE and recompiled it.
5) Created copy of program for just that (BPCS) environment.
6) Triple checked all PTFs / Cumpacks / Feng Shui
7) Checked with supplier / internet.  "The job is functioning as
designed"
8) Archived data  (it's a General ledger job)
9) Amended QAQINI (or whatever it's called) settings. 
10) Removed some logicals that weren't in other environments - no
effect.
11) Checked PRTSQLINF - learnt nothing from this.
12) Swore a lot

I have found references to problems with progs over 16mb in size and
this
prog is over 16mb.
Currently the only workaround that works is to have it a scheduled job
to
recompile it every two hours. My gut feeling is that the fact that this
workaround seems to work proves that the 16mb issue is the crux of the
problem.  It's not the only prog above 16mb but it does appear to be the
only one with the problem.

BTW This is on a 720 running V5R2.

I've run out of solutions other that rewrite the prog.

Regards

Martin Bath
Global IT Group
Invensys Controls 
Tel:      +44 (0) 1752 724388
Mobile: +44 (0) 7736 017318
Fax :    +44 (0) 1752 732455
 **** PLEASE NOTE NEW EMAIL ADDRESS  ****
Email : martin.bath@xxxxxxxxxxxxxxxxxxxx
***********************************************************

CONFIDENTIALITY NOTICE
This e-mail and any attachments are confidential and also may be
privileged.
If you are not the named recipient, or have otherwise received this
communication in error, please delete it from your inbox, notify the
sender
immediately, and do not disclose its contents to any other person, use
them
for any purpose, or store or copy them in any medium. Thank you for your
cooperation.






As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.