Controlling resource usage

When system resources are shared among transactions, user queries, web requests, distributed application requests, and batch programs, you need to control how those resources are used, separate data, and set priorities carefully.

About this task

You might choose to emphasize resource use, performance, concurrency, or data security. Many of the things you currently do to improve response time or reduce processor consumption for a single DB2® subsystem also apply in the data sharing environment.

Procedure

  1. Choose the controls that best match your goals. For example, you might want to:
    • Minimize resource usage
    • Maximize throughput
    • Maximize response time
    • Ensure a certain level of service to some users
    • Avoid conflicts between users
    Consequently, Your goal might be to favor a certain class of users or to achieve the best overall system performance.
  2. Use the appropriate facilities to tune the performance of your system:
    Option Description
    Prioritizing resources z/OS® workload management (WLM) controls the execution of DB2 work based on the priorities that you set.

    In CICS® environments without the Open Transaction Environment (OTE) function, DB2 work and application work is performed in different tasks. DB2 work is managed at the subtask level. With CICS OTE, DB2 work and application work can be performed in the same task. You can manage the DB2 subtasks through various settings in the CICS resource definition online (RDO). Without OTE, some overhead is incurred for each task switch. Therefore, depending on the SQL activity, CICS OTE can improve performance significantly because of the reduction of needing to switch tasks.

    In other environments such as batch and TSO, which typically have a single task requesting DB2 services, the task-level processor dispatching priority is irrelevant. Access to processor and I/O resources for synchronous portions of the request is governed solely by WLM.

    Limiting resources for each job You use the TIME parameter of a job or step to control the total amount of processor resources used for a job, instead of the amount used by a single query. Because most of resource usage occurs within the standard job structure, you can control processor usage at the job level.
    Related information:
    Limiting resources for TSO sessions You can control the amount of resources used for an entire TSO session. Time limits can apply to either TSO sessions or to batch jobs. Your z/OS system programmer can provide a time parameter on the logon procedure or on a job statement in the logon pre-prompt exit. This time limit applies to the session, rather than for an individual query or a single program. If you want to control the amount of resources used for an entire TSO session, rather than the amount used by a single query, use this control.
    Limiting resources for IMS™ and CICS Various IMS and CICS controls (such as the PROCLIM keyword of the TRANSACT macro in IMS).
    Limiting resources for stored procedures Use the ASUTIME column of SYSIBM.SYSROUTINES catalog table and the MAX ABEND COUNT field on installation panel DSNTIPX.
    Reducing locking contention Use DB2 locking parameters, DISPLAY DATABASE LOCKS, lock trace data, database design
    Limiting the execution time of dynamic statements Use the DB2 resource limit facility (governor).
    Controlling use of parallelism DB2 resource limit facility, SET CURRENT DEGREE statement
    Controlling the use of system resources by threads and connections Use profile tables and certain DB2 subsystem parameters.
    Evaluating long-term resource usage Use accounting trace data, Tivoli® OMEGAMON® XE for DB2 Performance Expert on z/OS reports.
    Predicting resource consumption Use EXPLAIN table data, Visual Explain, and the predictive governing capability of the resource limit facility.