How to manage SQL queries on iSeries

15 pts.
Tags:
IBM iSeries
SQL
We have users who are using SQL to perform queries on our iSeries. As such, we need a way to manage these queries so that, if a runaway, poorly written, etc. causes issues for CPU and/or DASD we can either be notified, end the job, or some other parameter. Is there such an animal? Thanks!

Software/Hardware used:
iSeries OS400

Answer Wiki

Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Discuss This Question: 4  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • CharlieBrowne
    Check the SYSTEM VALUES and options on the USRPRF
    41,380 pointsBadges:
    report
  • TomLiotta

    First choice might be settings in the QAQQINI options file for the system, and possibly setting specific copies of it for different users or jobs. This might prevent some questionable queries from ever starting. Next, you might set one or more Management Central job monitors. You could choose various metrics to trigger at thresholds to send warnings or possibly to end troubled jobs.

    How are you allowing queries to be created? What query tools are used? Are these interactive or batch? Green-screen or remote?

    Tom

    125,585 pointsBadges:
    report
  • StarTaylor
    We have a mixture of both, interactive and batch, green screen and remote. The ones that are most concerning are interactive coming in via MS Access or SQL server. 
    15 pointsBadges:
    report
  • TomLiotta

    For future note, queries that are "coming in via MS Access or SQL server" would all be batch. The confusion there could be that a user is 'interactively' working with MS Access or SQL Server and generating a remote query. But the query would be run by a batch server job in the iSeries that is remote from a Windows database.

    Tools are irrelevant for those, so we can ignore them for now.

    The QQRYTIMLMT system value is one simple control. It can be a problem not to have it set for an expected maximum, though many sites never change it from the default. It can also be a problem after it's set because it applies to all uncontrolled queries from then on. Some large future queries might be rejected unexpectedly, so you'd want to learn about control.

    The QAQQINI options file would be a first line of general control. You can enable it for particular jobs with the Change Query Attributes (CHGQRYA) CL command. (One other parameter, QRYTIMLMT(), on that command can also be relevant.) You enable the options system-wide by creating a version of the options file into the QUSRSYS library (schema) with the attribute values that you want. Option values can be set with SQL UPDATE or through iSeries Navigator.

    But exactly which attributes should be set and what values should be used will be very dependent on the specifics of your environment. We possibly can't help much in anything but describing what a given attribute could do.

    For Management Central (through iSeries Navigator), one or more "job monitors" could track different metrics and could trigger programming for notification or for remediation. These wouldn't be only for queries. Any job that exceeded your chosen thresholds would trigger a response.

    Individual user profiles can have 'Maximum storage' allowed. That's not totally helpful for queries, though, because "temporary" storage won't necessarily be included. Queries can use a lot of storage when generating temporary indexes and other objects. It's not necessarily included in the user's total storage. It's still a good value to set for users in order to limit everything that does get included.

    General limits on queries can prevent some questionable queries from ever starting. Limits on users can help in some cases where incorrect queries give excessive results. Job monitors can catch essentially anything you can think of, though some relationships might take more thought.

    Tom

    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following