View
4.381
Download
13
Category
Preview:
DESCRIPTION
Citation preview
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:
sssane@dstsytems.com
Suresh SaneDST Systems Inc1055 BroadwayKansas City, MO 64105USA
(816) 435-3803
3
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
15
3. Application Development
In this section, we discuss parameters that impact application development and focus on partitioning and formats.
16
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
Prepared statement S
Prepared statement S
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
International DB2 Users Group
22
Local CachingIntroducing Local and Global Caching
PREPARE S
EXECUTE S
EXECUTE S
Program A
PREPARE S
EXECUTE S
COMMIT
EXECUTE S
Program B
Prepared statement S
Thread A
Thread B
Prepared statement S
Prepared statement S
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
International DB2 Users Group
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
Prepared statement S
Thread A
Thread B
Prepared statement S
Prepared statement S
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
International DB2 Users Group
24
Full CachingIntroducing Local and Global Caching
PREPARE S
EXECUTE S
EXECUTE S
Program A
PREPARE S
EXECUTE S
COMMIT
EXECUTE S
Program B
Prepared statement S
Thread A
Thread B
Prepared statement S
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
32
5. Performance and Optimization
This section focuses on performance and optimization of your applications.
33
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
42
6. Locking
This section deals with locking and concurrency issues.
43
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
58
8. Stored Procedures/User Defined Functions
Stored procedures and user defined functions (UDFs) are the focus of this last section.
59
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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
International DB2 Users Group
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.
sssane@dstsystems.com
Thank You!
Suresh SaneDST Systems Inc.1055 BroadwayKansas City, MO 64105(816) 435-3803email: sssane@dstsystems.com
Recommended