ZPARMS101: What Everyone Should Know About ZPARMs

1

ZPARMS101: What Everyone Should Know About ZPARMs

Suresh SaneDST Systems Inc.

Heart of America DB2 Users GroupJune 13, 2005

Platform: z/OS

Abstract

As a DBA or a developer, you don’t care about ZPARMS – they fall in the domain of the DB2 SYSPROG, right? Not so! The defaults or the choices made for you may not be optimal. Several parameters (some “hidden”!) impact how you develop, manage and tune your applications. In this introductory presentation, we will discuss specific parameters are of interest to you – their meaning, the choices and their impact on you.

2

International DB2 Users Group

2About the Instructor

♦ Co-author of two IBM Redbooks♦ “Squeezing the Most Out of Dynamic SQL with DB2 for

z/OS and OS/390” - SG24-6418, May 2002♦ DB2 for z/OS Stored Procedures: Through the CALL and

Beyond” - SG24-7083, March 2004♦ Educational seminars at IDUG 2004 North America and IDUG

2004 Toronto Symposium on Dynamic SQL♦ Numerous IDUG North America presentations since 1996♦ IDUG Solutions Journal article – Winter 2000♦ Numerous DB2 courses at various locations♦ Special interest in SQL and DB2 performance issues♦ IBM Certified Solutions Expert for both platforms for

Application Development and Database Administration

Suresh Sane

Suresh Sane works as a Database Architect at DST Systems in Kansas City, MO. He provides strategic direction for deployment of database technology at DST and has overall responsibility for the DB2 curriculum for about 1,200 technical associates.

Contact Information:

[email protected]

Suresh SaneDST Systems Inc1055 BroadwayKansas City, MO 64105USA

(816) 435-3803

3


3About DST SystemsDST is a leading provider of computersoftware solutions and services.

FinancialServices

OutputSolutions

CustomerManagement

♦ Mutual Fund shareholder recordkeeping♦ Corporate Securities & Processing♦ Automated Work Distributor

76M accounts

28M accounts

85K workstations

♦ Literature distribution 2.1B packages annually

♦ Software, billing, outputfor cable, telephone,satellite and utilities

40% of US cable households

Highlightshttp://www.dstsystems.com

If you have ever invested in a mutual fund, have had a prescription filled, or are a cable or satellite television subscriber, you may have already had dealings with our company.

DST Systems, Inc. is a publicly traded company (NYSE: DST) with headquarters in Kansas City, MO. Founded in 1969, it employs about 12,000 associates domestically and internationally.

The three operating segments - Financial Services, Output Solutions and Customer Management - are further enhanced by DST’s advanced technology and e-commerce solutions.

4


4

Agenda

1. ZPARMS – An Introduction 2. Managing Threads3. Application Development 4. Dynamic SQL5. Performance and Optimization 6. Locking 7. Distributed Processing 8. Stored Procedures/User Defined Functions

Presentation Outline:

•Managing threads•Max users•Max remote active and connected•Max TSO connect•Max batch connect

•Application development•Updates to partitioning key•Date/Time format

•Dynamic SQL•Rules•Local and global caching•Thread storage•Resource Limit Facility (RLF)

•Performance and Optimization•Index access•VARCHAR index padding•Parallelism•Optimization Hints•Star Joins

•Locking•Timeouts and deadlocks•Locks per user & table•Long-running reader

•Distributed processing•Active and Inactive threads•Idle thread and pool thread timeout

•Stored procedures/UDFs•Number of TCBs•Max abends•Timeouts•Number of open cursors and stored procedures

5


5

1. ZPARMS – An Introduction

In this section, we discuss what ZPARMs are, how they are maintained and how you can view the current settings.

6


6

Purpose

♦ ZPARMs are system-level parameters whose values describe the operating characteristics of the DB2 subsystem.

♦ They contain data only (not logic).♦ They are set via a series of panels when installing or migrating to a

new version of DB2.♦ Some are set outside of such a process (“hidden” or “opaque”) –

this topic is beyond the scope of this presentation.♦ They are contained in 7 macros.♦ They are externalized in prefix.DSNMACS.

The seven macros are:1. DSN6ARVP – archive2. DSN6ENV – environment3. DSN6FAC – DDF4. DSN6GRP – group (data sharing)5. DSN6LOGP – logging6. DSN6SPRM –DBM17. DSN6SYSP – misc system

7


7

Maintenance♦ As of V7, you do not need to cycle DB2 system after a ZPARM change.♦ Changing, assembling and linking the modules is still needed.♦ Use SET SYSPARM command to reload the new module.♦ V8 introduces several additional parameters that can be changed online

(total of 123 out of 200+).♦ Some parameters cannot be changed.

• Example: CMTSTAT♦ Some parameters take effect later.

• Example: NUMLKTS or any RLF parms♦ Most parameters take effect immediately.

• Example: MAXKEEPD♦ Some parameters affect application behavior – dangerous to change!

• Example: PARTKEYU

8


8Browsing ZPARMs

The easiest method of searching for different ZPARMs and their current settings is to use Visual Explain (a free product from IBM that uses DB2 Connect). It invokes the stored procedure DSWZP which must be installed. Visual Explain provides a great deal of flexibility by allowing you to search by keywords or by various groupings.

9


9

2. Managing Threads

In this section, we discuss parameters that deal with DB2 threads of various types and how their settings affect the performance of your applications.

10


10

Controlling the Number of Threads

♦ Max Users (CTHREAD)• Max number of allied threads. Count each of the following items

as a separate user: Each TSO userEach batch job (DSN or Utility)Each IMS region that can access DB2Each active CICS transaction that can access DB2Each utility (uses one additional thread per subtask)Each CAF or RRSAF connection

• The sum of this and Max Remote Active is the total # of threads,which cannot exceed 2,000. When more connections are attempted, they are queued.

• Utilities can use more than 1 thread due to parallelism.

Module & Parameter Name: DSN6SYSP CTHREADAcceptable Values: 1 to 2,000Default: 200

11


11

Controlling the Number of Threads♦ Max Remote Active (MAXDBAT)

• Number of database access threads (DBATs) that can be active concurrently.

• The sum of this and Max Users is the total # of threads, which cannot exceed 2,000. When more connections are attempted, the resulting action depends on the value of zparm DDF THREADS:

If you specify ACTIVE, the allocation request is queued, waiting for an active thread to terminateIf you specify INACTIVE, the allocation request is queued, waiting for an empty slot to create a new thread

• Setting this to 0 restricts all DDF activity. It also causes Max Remote Connected (see next slide) to be set to zero.

Module & Parameter Name: DSN6SYSP MAXDBATAcceptable Values: 0 to 1,999Default: 200

12


12

Controlling the Number of Threads

♦ Max remote connected (CONDBAT)• Specifies the maximum number of concurrent remote

connections. • This value must be greater than or equal to Max Remote Active. • If Max Remote Active is set to zero, Max Remote Connected will

also be set to zero. • When a request to allocate a new connection to DB2 is received,

and Max Remote Connected has been reached or Max Remote Connected is zero, the connection request is rejected.

Module & Parameter Name: DSN6SYSP CONDBATAcceptable Values: 0 to 150,000Default: 10,000

13


13

Controlling the Number of Threads♦ Max TSO Connect (IDFORE)

• Specify the maximum number of users that can be identified to DB2 from TSO foreground at the same time. Count each of the following items as a separate user:

¨ Each TSO foreground user that is executing a DSN command ¨ Each TSO foreground user that is connected to DB2 through the

CAF or RRSAF. (Includes DB2 QMF users who are running in TSO foreground or user-written CAF or RRSAF applications running in TSO foreground)

• When the number of TSO users who are attempting to access DB2 exceeds the number specified, excess connection requests are rejected.

• No DB2 subsystem parameter controls the maximum concurrent connections for IMS and CICS. You can control those limits by using IMS and CICS facilities.

Module & Parameter Name: DSN6SYSP IDFOREAcceptable Values: 1 to 2,000Default: 50

14


14

Controlling the Number of Threads♦ Max Batch Connect (IDBACK)

• Specifies the maximum number of concurrent connections that are identified to DB2 from batch. Count each of the following items as a separate connection:

¨ Each DB2 utility ¨ Each batch job that uses DB2 QMF ¨ Each batch job that uses the DSN command processor ¨ Each task that is connected to DB2 through the call attachment

facility, which runs in batch. Among others, this can include: Batch jobs that use DB2 QMF TCP/IP FTP connections

¨ Each RRSAF connection. • Batch job requests to access DB2 that exceed this limit are

rejected.

Module & Parameter Name: DSN6SYSP IDBACKAcceptable Values: 1 to 2,000Default: 50

15


15

3. Application Development

In this section, we discuss parameters that impact application development and focus on partitioning and formats.

16


16

Controlling Updates to Partitioning Key♦ Specify whether values in columns that participate in

partitioning keys can be updated (PARTKEYU).

LOCK?

Module & Parameter Name: DSN6SPRM PARTKEYUAcceptable Values: YES, NO, or SAMEDefault: YES

Note that this is an application issue – not a performance issue. Prior to V8, all intermediate partitions would be locked during the update causing a severe degradation in concurrency. This is no longer the case.

17


17Controlling Updates to Partitioning Key

♦ The acceptable values are: • YES - Values in columns that participate in partitioning keys can be updated. This is

the default. • NO - Values in columns that participate in partitioning keys cannot be updated. • SAME - Values in columns that participate in partitioning keys can be updated if and

only if the update leaves the row in the same partition.

♦ Recommendation: Specifying NO or SAME will not improve concurrency. DB2 does not take exclusive control of the objects to perform the update. This should be decided by the application.

♦ How do you enforce standards if you choose SAME? (run time error)

Also be aware that while you may have control over how such updates are handled for in-house SQL, some vendor packages (e.g. PeopleSoft) issue such updates routinely and there may be no way to control these.

18


18

Specifying Date & Time Format♦ Specify format for DATE, TIME and TIMESTAMP columns

(DSNHDECP DATE and TIME)♦ Acceptable values are:

• ISO: yyyy-mm-dd and hh.mm.ss• USA: mm/dd/yyyy and hh:mm AM/PM or hh AM/PM• EUR: dd.mm.yyyy and hh.mm.ss• JIS: yyyy-mm-dd and hh:mm:ss• LOCAL: your choice

Module & Parameter Name: DSNHDECP DATE and TIMEAcceptable Values: ISO, USA, EUR, JIS, LOCALDefault: ISO

SQL that relies on the specific positions (e.g. char 1 to 4 contains YYYY) will be affected if any change is made.

For this reason, a good practice is to promote the use of scalar functions (e.g. DATE(COL1, USA)) consistently. If you develop generic software that runs across a variety of client installations, this practice is even more important.

19


19

4. Dynamic SQL

In this section, we discuss parameters that affect the behavior and performance of dynamic SQL. We also discuss how to govern the execution of dynamic SQL.

20


20Controlling Defaults for Dynamic SQL (DYNRULS)

♦ Specify whether DB2 should use the application programming defaults that are specified on this panel or use the values of the DB2 precompiler options for dynamic SQL statements that are bound byusing DYNAMICRULES bind, define, or invoke behavior.

♦ Specify YES to use the application programming defaults for these fields regardless of the DYNAMICRULES option: • DECIMAL POINT IS • STRING DELIMITER • SQL STRING DELIMITER • MIXED DATA • DECIMAL ARITHMETIC

♦ Specify NO to use the DB2 precompiler values for dynamic SQL statements in plans or packages bound using the DYNAMICRULES bind, define, or invoke behavior.

Module & Parameter Name: DSNHDECP DYNRULSAcceptable Values: YES or NODefault: YES

This is a question of control vs flexibility. Do you want to have full control over such parameters (e.g. decimal point or mixed data), or do you want to delegate this to each application when it is pre-compiled? In general, a more centralized approach (DYNRULS=YES, the default) provides control at the expense of some flexibility. (I do not think the flexibility is justified.)

21


21

No CachingIntroducing Local and Global Caching

PREPARE S

EXECUTE S

EXECUTE S

Program A

PREPARE S

EXECUTE S

COMMIT

EXECUTE S

PREPARE S

EXECUTE S

Program B

Prepared statement S

Thread A

Thread B



SQLCODE=0

SQLCODE=0

Full Prepare

SQLCODE=0

SQLCODE=0

Full Prepare

SQLCODE=0

Full Prepare

SQLCODE=0

SQLCODE= -514 or -518

SQLCODE=0

SQLCODE=0

Invalidating prepared statements

No sharing of statements across threads (each must do full prepare before using).Within a thread, a statement is invalidated after a commit and must be prepared again.

SQLCODE -514 (SQLSTATE 26501) for a cursor SQLCODE -518 (SQLSTATE 07003) for a non-cursor

-514 THE CURSOR cursor-name IS NOT IN A PREPARED STATE

-518 THE EXECUTE STATEMENT DOES NOT IDENTIFY A VALID PREPARED STATEMENT

22


22

Local CachingIntroducing Local and Global Caching

PREPARE S

EXECUTE S

EXECUTE S

Program A

PREPARE S

EXECUTE S

COMMIT

EXECUTE S

Program B


Thread A

Thread B



SQLCODE=0

SQLCODE=0

Full Prepare

SQLCODE=0

SQLCODE=0

Full Prepare

SQLCODE=0

Full Prepare(Implicit)SQLCODE=0

SQLCODE=0

Invalidating prepared statements – Statement text preserved

The only real benefit of local caching is the ability to issue an EXECUTE without issuing a PREPARE. DB2 will take care of this for you – you still pay the price.

•Cache allocated in storage of each thread in DBM1 address space.•Controlled by KEEPDYNAMIC bind option.•A thread can issue a prepare once and use it across commits.•After COMMIT, implicit PREPARE by DB2.•Application must be able to recognize that EXECUTE can get errors that normally occur during PREPARE.•For DRDA clients, KEEPDYNAMIC(YES) causes early close of cursor.

23


23

Global CachingIntroducing Local and Global Caching

PREPARE S

EXECUTE S

EXECUTE S

Program A

PREPARE S

EXECUTE S

COMMIT

EXECUTE S

PREPARE S

EXECUTE S

Program B


Thread A

Thread B



SQLCODE=0

SQLCODE=0

SQLCODE=0

SQLCODE=0

SQLCODE= -514 or -518

SQLCODE=0

Invalidating prepared statements

EDM Pool

SKDSS

Full Prepare

SQLCODE=0

Short Prepare

SQLCODE=0

Short Prepare

SQLCODE=0

The main benefit of global caching comes from the ability to reuse a statement that has been prepared by another thread.

•Cache within EDM pool of DBM1 address space.•Activated by CACHEDYN=YES ZPARM.•Can be in dataspace via ZPARM EDMDSPAC.•Skeleton copy of prepared statement in cache.•Unless local caching is active, directly issuing an EXECUTE is not possible – must issue PREPARE first.

24


24

Full CachingIntroducing Local and Global Caching

PREPARE S

EXECUTE S

EXECUTE S

Program A

PREPARE S

EXECUTE S

COMMIT

EXECUTE S

Program B


Thread A

Thread B


SQLCODE=0

SQLCODE=0

SQLCODE=0

SQLCODE=0

SQLCODE=0

No effect on prepared statements

EDM Pool

SKDSS

Full Prepare

SQLCODE=0

Short Prepare

SQLCODE=0

Avoided Prepare

Full caching combines two benefits: the ability to issue an EXECUTE without PREPARE – small impact) and the ability reuse the statement prepared by another thread (big impact).

•Activated by KEEPDYNAMIC(YES) bind parameter and ZPARM MAXKEEPD > 0 and ZPARM CACHEDYN=YES.•No need to issue a PREPARE after a COMMIT.•Local cache uses FIFO algorithm.•Global cache uses LRU algorithm.

25


25

25

Dynamic Statement Caching Summary

CACHEDYN NO YESK

EEPD

YNA

MIC

NO

YES

No skeletons cached in EDMPOnly full preparesNo prepared statements keptacross commits (note 1)

No statement strings kept across commits (note 3)

No skeletons cached in EDMPOnly full preparesNo prepared statements kept across commits (note 1)Stmt strings kept across

commits – implicit prepares

Skeletons cached in EDMP1st prepare full; others short(note 2)No prepared statements

across commits (note 1)No statement strings kept

across commits (note 3)

Skeletons cached in EDMP 1st prepare full; others short(note 2)Prepared stmts across

commits – avoided prepares (note 4)Stmt strings kept across

commits – implicit prepares

The differences show up as:•Is skeleton cached?•What is the type of PREPARE?•Is the prepared statement kept across a COMMIT?•Is the statement string kept across a COMMIT?

Note 1: unless a cursor WITH HOLD is openNote 2: unless invalidated or flushed out due to LRUNote 3: SQLCODES –514 or –518 resultNote 4: assuming MAXKEEPD > 0

26


26

Controlling Local Caching (MAXKEEPD)

♦ Specify the total number of prepared, dynamic SQL statements that can be saved past a commit point by applications that run with the KEEPDYNAMIC(YES) bind option.

♦ System-wide limit. ♦ Does not limit the size of the dynamic cache itself. ♦ When many applications bound with KEEPDYNAMIC(YES) run in a

system that has the dynamic statement cache active, can use a considerable amount of storage in the DBM1 address space. This parameter limits the total number of prepared statements held by these applications past a commit point.

♦ If exceeded, DB2 honors the KEEPDYNAMIC(YES) behavior, but "implicit" prepares might be necessary.

Module & Parameter Name: DSN6SPRM MAXKEEPDAcceptable Values: 0 to 65,535Default: 5000

Note that the statements are maintained in the local cache using the FIFO (first-in-first-out) algorithm. This means that a frequently used statement may need an implicit prepare if MAXKEEPD is reached often. In contrast, global caching uses the more sophisticated LRU (least-recently-used) algorithm.

27


27Controlling Global Caching (CACHEDYN)♦ Specify whether to cache prepared dynamic SQL statements for later

use by eligible application processes. These prepared statements are cached in the EDM dynamic statement cache

♦ If you specify YES, you must specify YES for USE PROTECTION on panel DSNTIPP.

Module & Parameter Name: DSN6SPRM CACHEDYNAcceptable Values: YES, NODefault: YES

The ability to re-use a cached statement is dependent on the authorization id. This id is available only when USE PROTECTION is set to YES. Without it, DB2 disables all authorization checking and all access is granted to public.

28


28Controlling Thread Storage (CONTSTOR)

♦ Specify whether DB2 is to periodically "contract" each thread's working storage area.

♦ Storage that a thread acquires is normally allocated to that thread until de-allocation.

♦ If YES is specified for this parameter, DB2 examines threads at commit points and periodically returns to the operating system storage that is no longer in use.

♦ For best performance, specify NO for this parameter. For subsystems that have many long-running threads and that are constrained on storage in the DBM1 address space, specifying YES can reduce thetotal amount of storage that is used in the DBM1 address space.

Module & Parameter Name: DSN6SPRM CONTSTORAcceptable Values: YES, NODefault: NO

This is a trade-off between the amount of working storage used and how often it should be re-claimed.

29


29

Controlling Thread Storage (MINSTOR)

♦ Specify whether DB2 is to use storage management algorithms thatminimize the amount of working storage consumed by individual threads.

♦ For best performance, specify NO for this parameter. For subsystems that have many long-running threads and are constrained on storage in the DBM1 address space, specifying YES can reduce the total amount of storage that is used in the DBM1 address space.

Module & Parameter Name: DSN6SPRM MINSTORAcceptable Values: YES, NODefault: NO

This is a trade-off between the amount of working storage used and the time (CPU cost) spent in optimizing it.

30


30

Controlling Thread Storage (EDMBFIT)

♦ Specify how free space is to be utilized for large EDM pools (greater than 40 MB).

♦ Specify NO to optimize for performance. ♦ YES optimizes for better storage utilization. ♦ In the trade-off between performance and space utilization, space is

normally more critical for smaller EDM pools, and performance is more critical for larger EDM pools.

Module & Parameter Name: DSN6SPRM EDMBFITAcceptable Values: YES, NODefault: NO

As before, this is a trade-off between amount of free space used and the time spent in the optimization process.

31


31

Controlling Resource Limit Facility (RLF)♦ Parameter defaults to control the RLF at installation time ♦ Strongly recommend that some limit be in place (even if high) at all

times♦ RLF

• Auto start (Yes or No)♦ RLFAUTH

• Auth ID♦ RLFTBL

• Table suffix (DSNRLSTnn)♦ RLFERR

• Default action for local connections (NOLIMIT, NORUN, nn)♦ RLFERRD

• Same for remote connectionsNote – the limits are only the defaults – you can limit each combination of plan/package and user.

Module & Parameter Name: DSN6SYSP RLFAcceptable Values: YES, NODefault: NO

Module & Parameter Name: DSN6SYSP RLFAUTHAcceptable Values: 1-6 charactersDefault: SYSIBM

Module & Parameter Name: DSN6SYSP RLFTBLAcceptable Values: any 2 charactersDefault: 01

Module & Parameter Name: DSN6SYSP RLFERRAcceptable Values: NOLIMIT, NORUN, 1 to 5,000,000Default: NOLIMIT

Module & Parameter Name: DSN6FAC RLFERRDAcceptable Values: NOLIMIT, NORUN, 1 to 5,000,000Default: NOLIMIT

32


32

5. Performance and Optimization

This section focuses on performance and optimization of your applications.

33


33

Favoring Index Access (NPGTHRSH)

♦ Specifies when index access should be favored.♦ When set to:

• -1: DB2 favors matching index access to all tables• 0: Default, no special processing for any tables• n: When NPAGES < n, (and not = -1), favor matching index

access♦ Matching index access can be more expensive than tablespace scan

or non-matching indexes access – specify a low number (e.g. 10)♦ VOLATILE parameter (V8) on CREATE/ALTER TABLESPACE

provides a better granularity♦ VOLATILE may also provide better concurrency (but favors primary

key which may not be good always)

Module & Parameter Name: DSN6SPRM NPGTHRSHAcceptable Values: -1, 0 or a positive number (not clear what the max allowable is)Default: 0

Updating the catalog tables with an artificial value for CARDF, using NPGTHRSH or specifying VOLATILE at the tablespace level are three methods of achieving the same result. You should consider using the one that meets your business needs. For example, if a vendor package (e.g. PeopleSoft) creates various temporary tables over which you have no control, using NPGTHRSH may provide the best external means of influencing the access path. On the other hand, if you control the table DDL, using VOLATILE will likely provide the granularity you need.

34


34

Controlling Index Padding (PADIX)

♦ Specify whether new indexes should be padded by default. ♦ YES indicates that a new index will be padded unless the NOT

PADDED option is specified on the CREATE INDEX statement. ♦ The default value, NO, indicates that a new index will not be padded

unless the PADDED option is specified on the CREATE INDEX statement.

♦ This parameter only affects indexes that have at least one varying length column.

Module & Parameter Name: DSN6SPRM PADIXAcceptable Values: NO, YESDefault: NO

This parameter deals with new indexes that contain at least one VARCHAR column. This should be consistent with your strategy of whether or not you want to deploy padded indexes (see next two slides).

35


35

VARCHAR from Index (RETVLCFK)

♦ Specify whether the VARCHAR column is to be retrieved from a padded index. The data sharing scope of this parameter is GROUP.

♦ If you choose NO, DB2 must go to the data page to retrieve data because index-only access of varying-length column data in padded indexes is not possible. With a setting of NO, data is retrieved with no padding.

♦ If you choose YES, better performance results because index-only access of varying-length column data is enabled for padded indexes . The data that is retrieved from the index is padded with blanks to the maximum length of the column.

Module & Parameter Name: DSN6SPRM RETVLCFKAcceptable Values: NO or YESDefault: NO

See next slide for recommendations.

36


36

VARCHAR from Index

♦ Important: Applications must be able to handle the padded blanks. If your application is sensitive to these blanks, keep the default value of NO or consider using non-padded indexes. You must rebind plans and packages to enable the change.

♦ Recommendation: Accept the default value and use padded indexes. Use NOT PADDED indexes if you want the index to use less space, to allow index-only retrieval with variable characters, and do not want the incompatible retrieval of the full column width.

Note that:•All applications must be able to tolerate padded blanks.•A rebind is required for this option to take effect.

37


37

Exploiting Parallelism ♦ Max Degree (PARAMDEG)

• Specify the max degree of parallelism for a parallel group. Default of 0 means DB2 chooses max based on system configuration (e.g. # of partitions, size of bufferpools etc).

♦ Default Degree (CDSSRDEF)• Specify the default for the CURRENT DEGREE special register

when no degree is explicitly set using the SQL statement SET CURRENT DEGREE.

♦ If you are using nearly all of your CPU, I/O, or storage resources, parallelism is more likely to cause degradation of performance. Use parallelism only where it is most likely to provide benefits.

Module & Parameter Name: DSN6SPRM PARAMDEGAcceptable Values: 0 to 254Default: 0

Module & Parameter Name: DSN6SPRM CDSSRDEFAcceptable Values: 1, ANYDefault: 1

38


38

Deploying Optimization Hints

BIND

Package

REBIND NewPackage

SQL withQUERYNO

PLAN_TABLE Edit & add OPTHINT

There are various reasons for trying to influence the access path of an SQL statement including:

•Fallback (e.g. good access path on Friday but weekend activity created a horrible access path)•Unstable access path (e.g. switches between good and bad)•Fixes (e.g. access path A is clearly superior, but optimizer always picks access path B).

39


39Deploying Optimization Hints (OPTHINTS)♦ Specify that you intend to pass information to DB2 that might influence

the access path selected for certain queries. The information is passed in the form of rows in the PLAN_TABLE.

♦ Programmers add QUERYNO to SQL.♦ Bind program with EXPLAIN(YES).♦ Update PLAN_TABLE to add a OPTHINT (e.g. “myhint”).♦ To return to previous (hopefully good) access path, rebind with

OPTHINT(‘myhint’).♦ Verify hint was honored: sqlcode = +394 and HINT_USED = ‘myhint’.

Module & Parameter Name: DSN6SPRM OPTHINTSAcceptable Values: NO or YESDefault: NO

40


40

Exploiting STAR Joins

Dealer Trans

Dealer

Month

Fund Sponsor

Social Code

Tran Type

A typical star schema with a large “fact table” (dealer trans) containing many millions of rows and five “dimension tables” (dealer, month, etc.) consisting of only a few rows. All joins are between the fact table and one of the dimension tables and most predicates are on the dimension tables. (Snow-flake topology is ignored in this discussion.)

41


41

Exploiting STAR Joins♦ STARJOIN: Specify whether star join processing is enabled. A value of

1 indicates that the fact table will be the largest table in a star join query that does not have fact/dimension ratio checking. A value of 2 to 32768 indicates that DB2 should use the ratio of the star join table and the largest dimension table.

♦ SJMXPOOL: Specify the maximum size, in MB, of the virtual memory pool for star join queries. If you specify zero, DB2 does not allocate a memory pool for star join queries, even if star join queries are enabled. If you specify a value between 1 and 1024, DB2 creates a dedicated memory pool up to the specified size for star join queries.

♦ Choose a value that avoids system paging which can slow down theentire system throughput.

Module & Parameter Name: DSN6SPRM STARTJOINAcceptable Values: DISABLE, ENABLE, 1 to 32,768Default: DISABLE

Module & Parameter Name: DSN6SPRM SJMXPOOLAcceptable Values: 0 to 1024Default: 20

42


42

6. Locking

This section deals with locking and concurrency issues.

43


43

Managing Timeouts and Deadlocks

Program Y attempts to getpage 1 also, but cannot and is

the victim of a timeout.

Table A

Page 1

Program YProgram X

A timeout occurs when program Y waits for a resource held by program X for a period longer than the timeout interval. A larger timeout interval, or program X committing more often, could eliminate the timeout.

44


44

Managing Timeouts and Deadlocks

Table BTable A

Page 1 Page 1

Program YProgram X

IRLM detects andresolves a deadlock

condition.

A deadlock (this case involves 2 programs but could be 2 or more programs), where each is waiting on a resource held by the other. In this case, none of the programs can proceed no matter how long they wait.

45


45Managing Timeouts and Deadlocks (IRLMRWT)

♦ Specify the number of seconds before a timeout is detected.♦ Timeout means that a lock request has waited for a resource (or for

claims on a resource for a particular claim class to be released) longer than the number of seconds specified on this option.

♦ The value that is specified for this option must be a multiple of the DEADLOCK TIME on installation panel DSNTIPJ because IRLM uses its deadlock timer to initiate time-out detection and deadlock detection.

♦ This value is rarely the actual time. For data sharing, the actual timeout period is longer than the time-out value.

Module & Parameter Name: DSN6SPRM IRLMRWTAcceptable Values: 1 to 3,600Default: 60

46


46Managing Utility Timeouts and Deadlocks (UTIMOUT)

♦ Specify the number of resource timeout values (a value that applies to all other threads) that a utility or utility command is to wait for a lock or for all claims on a resource of a particular claim class to be released.

♦ This option allows utilities to wait longer than SQL applications to access a resource.

Module & Parameter Name: DSN6SPRM UTIMOUTAcceptable Values: 1 to 254Default: 6

47


47Managing Timeouts and Deadlocks (DEADLOCK TIME/DEADLOCK CYCLE)

♦ Specify the time, in seconds or milliseconds, of the local deadlock detection cycle.

♦ DB2 interprets values between 1 and 5 as seconds and values between 100 and 5000 as milliseconds.

♦ Depending on the value that you enter, IRLM might substitute a smaller maximum value.

♦ A deadlock is a situation where two or more requesters are waiting for resources that are held by another requester. Deadlock detection is the procedure by which a deadlock and its participants are identified.

♦ An additional parameter (DEADLOCK CYCLE) specifies the number ofcycles that must expire before IRLM checks for global locking (used only in Data Sharing).

Module & Parameter Name: Edit the IRLM start procedure –parameter

DEADLOKAcceptable Values: 1 to 5, or 100 to 5,000Default: 1

Module & Parameter Name: Edit the IRLM start procedure –parameter

DEADLOK CYCLEAcceptable Values: 1 Default: 1

(I have found no evidence to suggest that DEADLOK CYCLE can be anything other than 1.)

48


48

Controlling Locks per User (NUMLKUS)

♦ Specify the default value for the maximum number of page, row, or LOB locks that a single application can hold simultaneously in a single table or table space before lock escalation occurs. The maximum number of locks includes locks on data pages, index pages, sub pages, and rows that the program acquires when it accesses tablespaces.

♦ Do not specify 0 or a very large value unless it is specifically required to run an application.

♦ Consider the design of your applications. Long-running applications, particularly those that perform row-level locking, have few or infrequent commit points, or use repeatable-read isolation may use substantial amounts of lock storage. You should perform frequent commits to release locks.

Module & Parameter Name: DSN6SPRM NUMLKUSAcceptable Values: 0 to 104,857,600Default: 10,000

Note that when you change the LOCKSIZE for a tablespace from PAGE to ROW, the number of locks held increases substantially. You will need to take this in to account when setting the value for this parameter.

49


49

Controlling Locks by Table (NUMLKTS) ♦ Specify the default value for the maximum number of page, row, or

LOB locks that a single application can hold simultaneously in a single table or tablespace before lock escalation occurs. You can enter the value in bytes, or use the abbreviations K for kilobytes and M for megabytes. The value that you specify for this field must be less than the value specified for LOCKS PER USER (except when LOCKS PER USER is set to 0).

♦ This value becomes the default value (SYSTEM) for the LOCKMAX clause of the SQL statements CREATE TABLESPACE and ALTER TABLESPACE. A value of 0 indicates that there is no limit to thenumber of page and row locks that a program can acquire.

♦ Do not set the value to 0, because it can cause the IRLM to experience storage shortages.

Module & Parameter Name: DSN6SPRM NUMLKTSAcceptable Values: 0 to 104,857,600Default: 1,000

50


50Detecting a Long-running Reader (LRDRTHLD) ♦ Specify the number of minutes that a read claim can be held by an

agent before DB2 issues a warning message to report it as a long-running reader.

♦ If you specify a value of 0, DB2 will not report long-running readers.♦ Default = 0 (i.e. do not report).♦ Recommendation: Specify a reasonable number (e.g. 15 minutes).

Module & Parameter Name: DSN6SPRM LRDRTHLDAcceptable Values: 0 to 1439 minutesDefault: 0

51


51

7. Distributed Processing

An important set of parameters to manage carefully is the area of distributed processing. This is especially important in a client-server environment.

52


52

♦ A generic term that describes a process to reuse and share resources♦ Provides a boost in performance of distributed access♦ Without connection pooling, need dedicated concurrently connected

DB2 clients♦ Implemented in various ways:

WebsphereODBC and JDBC driversThread pooling within DB2 z/OS via management of DBATsDB2 Connect

• Agent and connection reuse• Connection concentrator – reduces physical connections and

agents needed

52

What is Connection Pooling?

Connection pooling allows you to “do more with less”.

53


53

53

TCP/IPTCP/IP

DB2 Connect

DB2 z/OS

Connections Coordinator Agents

DDF DBM1

ConnectionsActiveInactive

ClientWorkstations

ActivePool

DBATs

Connection Pooling Architecture

Connection pooling provided by DB2 Connect servers is completely independent of the application, machine and user. Connections from multiple clients and application servers, each with a different user ID can all reuse connections from each other.

54


54Managing Active/Inactive Distributed Threads (CMTSTAT)

♦ Specify whether to make a thread active or inactive after it successfully commits or rolls back and holds no cursors. A thread can become inactive only if it holds no cursors, has no temporary tables defined, and executes no statements from the dynamic statement cache.

♦ If you specify ACTIVE, the thread remains active. This provides the best performance but consumes system resources. If your installation must support a large number of connections, specifyINACTIVE.

Module & Parameter Name: DSN6FAC CMTSTATAcceptable Values: ACTIVE, INACTIVEDefault: INACTIVE

In general, specify ACTIVE only if you can afford to do so. In most cases, you cannot.

55


55Managing Active/Inactive Distributed Threads (MAXTYPE1) ♦ Specify the number of inactive DBATs that DB2 is to allow. This limit

is defined because a large number of inactive DBATs might adversely affect system performance. Inactive DBATs are used forprivate protocol. DRDA uses inactive connections.

♦ A value of 0 indicates that inactive DBATs are not allowed. If athread meets the requirement of an inactive DBATs, and MAX INACTIVE DBAT is 0, the thread remains active.

♦ A value greater than 0 indicates that inactive DBATs are allowed, but they are limited to the specified number. When a thread meets the requirement of an inactive DBAT, and MAX INACTIVE DBAT is reached, the remote connection is terminated.

♦ If you want to allow inactive DBATs, set this value to the maximum number of concurrent connections that you want to allow to go inactive that access another remote location with three-part names.

♦ A value that is equal to the value in the MAX REMOTE CONNECTED field from panel DSNTIPE allows all remote threads to become type 1 inactive threads.

Module & Parameter Name: DSN6FAC MAXTYPE1Acceptable Values: 0 to MAX REMOTE CONNECTED

(CONDBAT)Default: 0

56


56Managing Idle Thread Timeout (IDTHTOIN) ♦ Specify the approximate time, in seconds, that an active server

thread should be allowed to remain idle before it is canceled. The thread is canceled after the timeout value expires; its locks and cursors are released. Inactive and in-doubt threads are not subject to timeout. The value that you specify for DDF THREADS determines whether a thread can become inactive, and thus not subject to timeout.

♦ Threads are checked every two minutes to see if they have exceeded the timeout value. If the timeout value is less than two minutes, the thread might not be canceled if it has been inactive for more than the timeout value but less than two minutes.

♦ Specifying 0 disables timeout processing. If timeout processing is disabled, idle server threads remain in the system and continue to hold their resources, if any.

Module & Parameter Name: DSN6FAC IDTHTOINAcceptable Values: 0 to 9,999Default: 120

57


57Managing Pool Thread Timeout (POOLINAC)♦ Specify the approximate time, in seconds, that a database access

thread (DBAT) can remain idle in the pool before it is terminated. A database access thread in the pool counts as an active thread against MAX REMOTE ACTIVE and can hold locks, but does not have any cursors.

♦ Threads are checked every three minutes to see if they have exceeded the timeout value. If the timeout value is less than three minutes, the thread might not be cancelled if it has been inactive for more than the timeout value but less than three minutes.

♦ Specifying 0 causes a DBAT to terminate rather than go into the pool if the pool has a sufficient number of threads to process the number of inactive DBATs (type 2 inactive threads) that currently exist.

Module & Parameter Name: DSN6FAC POOLINACAcceptable Values: 0 to 9,999Default: 120

58


58

8. Stored Procedures/User Defined Functions

Stored procedures and user defined functions (UDFs) are the focus of this last section.

59


59

Managing Number of TCBs

♦ Specify how many SQL CALL statements or invocations of user-defined functions can be processed concurrently in one address space.

♦ The larger the value, the more stored procedures and user-defined functions you can run concurrently in one address space.

♦ This value is dependent on the USS MAXPROCUSER value. ♦ If this value is set above the USS MAXPROCUSER value, you may

exceed the maximum number of processes for the user.

Module & Parameter Name: NoneAcceptable Values: 1 to 100Default: 8

This parameter is simply the default. With the ability to set the number of TCBs in the WLM environment, this is meaningful only when you do not specify a value. I strongly suggest that this be controlled when defining the WLM environment. Several factors, including the language, play a part in the correct setting.

60


60

Tolerating Abends (STORMXAB)

♦ Specify the number of times a stored procedure or an invocation of a user-defined function is allowed to terminate abnormally, after whichSQL CALL statements for the stored procedure or user-defined function are rejected.

♦ The default of 0 means that the first abend of a stored procedure or user defined function causes SQL CALLs to that procedure or function to be rejected.

♦ For production systems, you should accept the default.

Module & Parameter Name: DSN6SYSP STORMXABAcceptable Values: 0 to 255Default: 0

The issue is this: When a stored procedure or user defined function abends, is it a rare occurrence that can be analyzed later without affecting any subsequent executions, or is it a symptom of something catastrophic thereby allowing any further executions will likely result in an abend (and a dump) as well? If the reason was transitory in nature (e.g. a timeout or deadlock), you want to allow all subsequent executions. If it was caused by an installation issue (e.g. parameter mismatch), you want to stop all subsequent executions while you analyze the cause.

Overall, I recommend a value of zero (default) in a production environment and a reasonable but small (e.g. 100) value in a test environment.

61


61

Managing Timeouts (STORTIME)

♦ Specify the number of seconds before DB2 is to stop waiting for an SQL CALL or invocation of a user-defined function to be assigned to one of the task control blocks (TCBs) in a DB2 stored proceduresaddress space. If the time interval expires, the SQL statement fails.

♦ The default is a reasonable waiting time for most sites. Choose a higher value if your system has long queues. Choose a lower value if you want to minimize the waiting time for end-user requests.

♦ The NOLIMIT value means that DB2 waits indefinitely for the SQL request to complete, while the thread is active.

♦ Do not select the NOLIMIT value. If the stored procedure addressspace is down for some reason or the user-defined function does not complete, your SQL request hangs until the request is satisfied or the thread is canceled.

Module & Parameter Name: DSN6SUSP STORTIMEAcceptable Values: 5 to 1,800 Default: 180

62


62Controlling Number of Open Cursors (MAX_NUM_CUR)

♦ Specify the maximum number of cursors, including allocated cursors, that are open at a given DB2 site per thread. The RDS will keep a total of currently open cursors. If an application attempts to open a thread after the maximum is reached, the statement will fail.

♦ In a data sharing group, this parameter has member scope.

Module & Parameter Name: DSN6SPRM MAX_NUM_CURAcceptable Values: 0 to 99,999Default: 500

63


63Controlling Number of Stored Procedures (MAX_ST_PROC)

♦ Specify the maximum number of stored procedures per thread. If an application attempts to call a stored procedure after the maximum is reached, the statement will fail.

♦ In a data sharing group, this parameter has member scope.

Module & Parameter Name: DSN6SPRM MAX_ST_PROCAcceptable Values: 0 to 99,999Default: 2,000

64


64

Summary

1. ZPARMS – An Introduction 2. Managing Threads3. Application Development 4. Dynamic SQL5. Performance and Optimization 6. Locking 7. Distributed Processing 8. Stored Procedures/User Defined Functions

References:

1. Willie Favero – “The Good, the Bad and the Really Ugly: DSNZPARM” –IDUG NA 2004

2. Susan Lawson, “DB2 for z/OS Version 8 Certification Guide”3. IBM Redbook SG24-6418, “Squeezing the Most of Dynamic SQL with DB2 for

z/OS and OS/390” – May 2002

65


65ZPARMS101: What Everyone Should Know About ZPARMs

Thank You!

Special thanks to Kathy Chelton, who was formerly with DST Systems. Kathy has been the lead DB2 instructor at DST and we have researched, developed and taught many courses together. Kathy has reviewed my work for almost a decade and, while I am not happy when the draft comes back bloodied with all the red marks, I know the end result is a better product. I am indebted to her for all her help throughout the years.

66

66

ZPARMS101: What Everyone Should Know About ZPARMSSession: B2

Suresh SaneDST Systems Inc.

[email protected]

Thank You!

Suresh SaneDST Systems Inc.1055 BroadwayKansas City, MO 64105(816) 435-3803email: [email protected]

Documents

ZPARMS101: What Everyone Should Know About ZPARMs