Speaking as a developer. A few years back we used to pass all new (or
troublesome) queries through "Visual Explain". We LOVED it. It dramatically
improved our ability to tune queries before we implemented them.
Then our internal "software police" took Visual Explain away from us and made
us use the "supported" product, i.e. "IBM Data Studio". What a horribly
complicated piece of equipment to use for a simple job. This made even
attempting to get a simple explain an exercise in frustration. Developers
across the board stopped tuning their queries.
And now they will take Data Studio away from us when we don't use it frequently
enough because "licenses are expensive and we can see that you are not using
the product".
If Visual Explain had a licensed/paid option our company would buy it and give
us access to it. Big corporations are extremely averse to using any
unsupported software, no matter how reliable the vendor is or how "free". They
fear it will get incorporated into a production system and that there will
subsequently be an "Oh Dark Thirty" production incident and there will be no
vendor support available.
IBM - Are you listening? Provide a paid option with support for Visual Explain
and corporate customers will buy it.
Sigh ...
... Rant over.
____________________________
Walter (Bill) Bass
Senior Applications Development Consultant
Optum Tech App Srvcs Grp
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Farley, Peter x23353
Sent: Friday, January 09, 2015 11:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How Does Your Shop Limit Testing in the Production LPAR
Simple - don't run it against the production database - that's what
test/development LPAR's and test/development DB2's are for. And if you don't
have a test/development environment set up, then someone isn't doing their job.
Though I agree a better solution would be a "query time estimator" function
that told you ahead of time how long your new query might take, based on
whether the WHEN criteria fields are indexes or not, how many criteria you
asked for, how complex the JOIN's are, etc., and then gave you the option to
proceed or to go back and change the query first. DBA's may have such tools
available to them, but I'm not aware of any that "normal" users can access.
ISPF SPUFI screens allow a query to be limited to some reasonable number of
results to limit execution time. Limit your results to the first 100 or so
while you debug/tune. If it's going to be a monster anyway, arrange for
off-schedule test time (weekends or holidays, for instance) when you won't hurt
the business.
HTH
Peter
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Ted MacNEIL
Sent: Friday, January 09, 2015 9:58 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: How Does Your Shop Limit Testing in the Production LPAR
I'm one of those types.
The governor pretty well guarantees a re-submission.
Which means twice the resources (or more) spent to do nothing!
How can they debug/tune something if we don't let complete?
-
-teD
-
Original Message
From: Shane Ginnane
Sent: Friday, January 9, 2015 07:10
To: IBM-MAIN@LISTSERV.UA.EDU
Reply To: IBM Mainframe Discussion List
Subject: Re: How Does Your Shop Limit Testing in the Production LPAR
On Fri, 9 Jan 2015 05:27:47 -0600, Scott Chapman wrote:
> Enabling DB2's governor is a good idea as well.
Have others found DBAs are averse to contemplating the governor ?.
Shane ...
--
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity
to which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
