(*) IBM DB2 for z/os DB2 Version 10 Kapitel DBA (11_DB2V10_dba.pptx) (*) ist eingetragenes Warenzeichen der IBM International Business Machines Inc. 1
DB2 10 for z/os Im Einsatz, wo andere längst aufgeben... 2
Connectivity & Administration Routines DDF Verfügbarkeit Monitoring & Controlling connections und threads auf der Server-Seite JDBC Type 2 Driver Performance Verbesserungen High Performance DBAT Einsatz von RELEASE(DEALLOCATE) in Java Anwendungen Support des 64-bit ODBC Driver DRDA Unterstützung der Unicode Kodierung in system code pages DB2-unterstützte stored procedures 3
DDF Verfügbarkeit 4
DB2-unterstützte stored procedures - ATS 5
DB2-unterstützte stored procedures - ATS The administrative task scheduler has an SQL interface that currently consists of the following DB2- supplied stored procedures: SYSPROC.ADMIN_TASK_ADD Diese stored procedure fügt eine task zur task list des ATS hinzu und läuft in einem WLM-zugehörigen STP address space. Sie nutzt das RRSAF( Resource Recovery Services attachment facility ) zum connect auf DB2. Die STP nimmt die Task-Information und ergänzt sie um task name und einem return code. SYSPROC.ADMIN_TASK_REMOVE The ADMIN_TASK_REMOVE stored procedure removes a task from the task list of the administrative task scheduler. If the task is currently running, it continues to execute until completion, and the task is not removed from the task list. If other tasks depend on the execution of the task that is to be removed, the task is not removed from the task list of the administrative task scheduler. SYSPROC.ADMIN_TASK_CANCEL The ADMIN_TASK_CANCEL stored procedure attempts to stop the execution of a task that is currently running. SYSPROC.ADMIN_TASK_UPDATE The ADMIN_TASK_UPDATE stored procedure updates the schedule of a task that is in the task list for the administrative task scheduler. If the task that you want to update is running, the changes go into effect after the current execution finishes. 6
DB2-unterstützte stored procedures The following stored procedures were a late addition to DB2 9: SYSPROC.ADMIN_INFO_SMS ADMIN_INFO_SMS provides a DB2 interface to SMS for storage space alerts. The ADMIN_INFO_SMS stored procedure returns space information about copy pools and their storage groups and volumes. SYSPROC.ADMIN_INFO_SYSPARM The ADMIN_INFO_SYSPARM stored procedure returns the system parameters, application defaults module, and IRLM parameters of a connected DB2 subsystem, or member of its data sharing group. SYSPROC.ADMIN_INFO_SYSLOG ADMIN_INFO_SYSLOG is a new stored procedure that returns the system log entries. Filters, such as search string, system name, begin and end date, begin and end time, and max entries, are supplied that can limit the system log entries that are returned. SYSPROC.ADMIN_INFO_SQL ADMIN_INFO_SQL procedure collects DDL, statistics, and column statistics providing information to help identifying query performance. This procedure is meant to be used by DB2 provided programs and tools. The procedure is invoked by the DSNADMSB program, which has functions equivalent to PLI8 for DB2 optimization problems diagnosis. ADMIN_INFO_SQL is included in DB2 10 and retrofitted into DB2 9 with APAR PM11941. Two DB2 10 APARs apply: PM25635 and PM24808. ADMIN_INFO_SQL has several input and output parameter. In addition, a result set is returned containing several scripts with all the data that was collected, such as DDL, statistics, and other data. The result set can be returned to the caller or written to data sets on the host. 7
DB2 statistics routines DB2 10 delivers the following stored procedures that are used to monitor and execute RUNSTATS autonomically: SYSPROC.ADMIN_UTL_MONITOR SYSPROC.ADMIN_UTL_MONITOR is a stored procedure that provides functions that enable analysis of database statistics. These functions include alerts for out-of-date, missing, or conflicting statistics, summary reports, and detailed table-level reports that describe generated RUNSTATS statements SYSPROC.ADMIN_UTL_EXECUTE ADMIN_UTL_EXECUTE is a stored procedure that solves alerts stored in the SYSIBM.SYSAUTOALERTS catalog table within the maintenance windows that are defined by the SYSIBM.SYSAUTOTIMEWINDOWS catalog table. SYSPROC.ADMIN_UTL_MODIFY ADMIN_UTL_MODIFY is a stored procedure that maintains the SYSIBM.SYSAUTORUNS_HIST and SYSIBM.SYSAUTOALERTS catalog tables. The ADMIN_UTL_MODIFY stored procedure removes all entries in the SYSIBM.SYSAUTORUNS_HIST table that are older than a configurable threshold and removes all entries in the SYSIBM.SYSAUTOALERTS table that are older than the configured threshold and are in COMPLETE state. The following stored procedures are configured (DSNTIJRT), and your authorization ID has CALL privileges for each: ADMIN_COMMAND_DB2 ADMIN_INFO_SSID ADMIN_TASK_ADD ADMIN_TASK_UPDATE 8
DB2 statistics routines The following stored procedures are configured (DSNTIJRT), and your authorization ID has CALL privileges for each (cntn d): ADMIN_UTL_EXECUTE ADMIN_UTL_MODIFY ADMIN_UTL_MONITOR ADMIN_UTL_SCHEDULE ADMIN_UTL_SORT DSNUTILU DSNWZP The following user-defined functions are configured (DSNTIJRT), and your authorization ID has call privileges for each: ADMIN_TASK_LIST() ADMIN_TASK_STATUS() Your authorization ID has privileges to select and modify data in the following catalog tables: SYSIBM.SYSAUTOALERTS SYSIBM.SYSAUTORUNS_HIST SYSIBM.SYSAUTOTIMEWINDOWS SYSIBM.SYSTABLES_PROFILES Your authorization ID has privileges to read data in the following catalog tables: SYSIBM.SYSTABLESPACESTATS SYSIBM.SYSTABLESPACE SYSIBM.SYSDATABASE SYSIBM.SYSTABLES 9
DB2 statistics routines Your authorization ID has privileges to read data in the following catalog tables(cntn d): SYSIBM.SYSTABLESPACESTATS SYSIBM.SYSTABLESPACE SYSIBM.SYSDATABASE SYSIBM.SYSTABLES SYSIBM.SYSINDEXES SYSIBM.SYSKEYS SYSIBM.SYSCOLUMNS SYSIBM.SYSCOLDIST SYSIBM.SYSDUMMY1 SYSIBM.UTILITY_OBJECTS 10
DB2 UTS Universal table space Starting with DB2 9 for z/os new-function mode (NFM), you can combine the benefits of segmented space management with partitioned table space organization using universal table spaces (UTS): either partition-by-growth (PBG) table spaces or range-partitioned table spaces (also know as partition-byrange (PBR) table spaces). The combined advantages are as follows: A segmented space-map page has more information about free space than a partitioned space-map page. Mass delete performance is improved because mass delete in a segmented table space organization tends to be faster than in other types of table space organizations. All or most of the segments of a table are ready for immediate reuse after the table is dropped or mass deleted. Partitioning allows for supporting of large table spaces and parallelism of accesses. Also all table spaces, including UTS, are created in reordered row format by default, unless the DSNZPARM SPRMRRF is set to DISABLE. The MEMBER CLUSTER option, introduced for partitioned table spaces in data sharing environments, is supported by UTS with DB2 10. 11
DB2 UTS Universal table space The DB2 catalog table SYSIBM.SYSTABLESPACE identifies table spaces by the following values in the TYPE column: blank The table space was created without the LOB or CLUSTER options L The table space can be greater than 64 gigabytes R UTS range-partitioned UTS P Implicit UTS table space created for XML columns O LOB table space G UTS partitioned-by-growth table space The use of UTS in DB2 9 In DB2 9, UTS was required for the following items: XML table spaces, but the base table can be segmented, partitioned, or UTSn CLONE support The use of UTS in DB2 10 In DB2 10, UTS is required if you want to use any of the following features: Hashing access. XML versioning function. 12
DB2 UTS Universal table space Use of ALTER online schema enhancements. Several schema changes are available for UTS with the new pending changes technique that are not available to the other structures of table spaces, as described in Chapter 4. Availability of the DB2 10 for z/os Technical Overview, SG24-7892. Inline LOBs. Access currently committed data. Insert index I/O parallelism. This requires either UTS or a classic partitioned table space but does not work with segmented table spaces. How to convert to UTS With DB2 9, you cannot convert a table space to UTS without a drop and re-create. DB2 10 largely simplifies changes to table space structure and attributes. The ALTER supported table space type shows conversions, which are as follows: Convert index partitioned table space to table partitioned. Convert classic table partitioned table space to a range-partitioned table space adding SEGSIZE. Convert simple table space with one table to a partition-by-growth table space. Convert segmented table space with one table to a partition-by-growth table space. Convert a partition-by-growth table space to hash table space. Convert a range-partitioned table space to hash table space. 13
Universal table space New default table space at CREATE time DB2 UTS In DB2 10, when creating a new table space, segmented table spaces are no longer the default. Partition-by-growth universal table spaces are the new default. If you want to create a range partitioned UTS, set values for NUMPARTS and SEGSIZE. If you want to create a classic partitioned table space, you need to specify SEGSIZE 0 on CREATE TABLESPACE. You can also set the new default partition SEGSIZE DSNZPARM DPSEGSZ=0 in the DSN6SYSP macro (the default is 32). If you want to create a segmented table space, do not specify MAXPARTITIONS and NUMPARTS, and whatever the DPSEGSZ value, you get a segmented table space with 4 KB SEGSIZE. MEMBER CLUSTER option available for UTS When you INSERT a row, DB2 typically tries to place data in the clustering sequence as defined by the implicit clustering index (the first index created) or the explicit clustering index. This can cause hot spots in data page ranges and high update activity in the corresponding space map page or pages. These updates must be serialized among all members in a data sharing environment, which can adversely affect INSERT/UPDATE performance in data sharing. 14
DB2 UTS Universal table space DB2 10 in new-function mode removes this restriction. MEMBER CLUSTER is supported by both partition-by-growth and range-partitioned UTS and it can be created as shown: To create a MEMBER CLUSTER partition-by-range UTS, use these statements: CREATE TABLESPACE MySpace IN MyDB MEMBER CLUSTER MUNPARTS 3; To create a MEMBER CLUSTER partition-by-growth UTS, use these statements: CREATE TABLESPACE MySpace in MyDB MEMBER CLUSTER MAXPARTITIONS 10; You can also implement MEMBER CLUSTER using an ALTER, without having to drop and recreate the table space. Because the need to use MEMBER CLUSTER can change over time, DB2 10 also provides the capability to both enable and disable MEMBER CLUSTER for universal table spaces: ALTER TABLESPACE MyDB.MySpace... MEMBER CLUSTER YES/NO 15
DB2 UTS Summary for universal table spaces In DB2 10, you can convert to universal table spaces (UTS) using ALTER and REORG. After the table space is converted to UTS, you can also change many other attributes, such as page size, or take advantage of new functions that require UTS. Thus, to be able to alter these other attributes, create all new table spaces as UTS, and as time and resources permit, convert the existing table spaces to UTS. The INSERT performance of the UTS is close to the classic partition table space and better than the classic segmented. MEMBER CLUSTER shows some benefits in data sharing. In the case of UTS sequential insert with row level locking in data sharing, the use of the MEMBER CLUSTER option can be more beneficial. In summary, in DB2 10 with UTS, and MEMBER CLUSTER support, you can get performance generally equivalent to classic partitioned table spaces and better than segmented. 16
High performance DBATs DDF Prior to DB2 10, the RELEASE option of BIND PACKAGE is not honored in distributed applications. Packages are always de-allocated at commit, mainly to allow more availability for functions such as DDL, utilities, and BIND packages, which can be impacted if the packages were released only at the application end. The performance analysis of inactive connection processing reported that a large CPU cost occurred in package allocation and de-allocation. A CPU reduction can occur when pooling database access threads (DBAT) and then associating a pooled DBAT with a connection1. DB2 10 includes the following enhancements: CPU reduction of inactive connection processing. An easy method to switch between RELEASE (COMMIT) and RELEASE (DEALLOCATE) BIND options for existing distributed applications without having to rebind, so that activities such as running DDL and utilities, can happen without an outage. DB2 10 DRDA DBATs are allowed to run accessing data under the BIND RELEASE option of the package. If a package that is associated with a distributed application is bound with RELEASE (DEALLOCATE), the copy of the package is allocated to the DBAT up until the DBAT is terminated. The DBATs hold package allocation locks even while they are not being used for client unit-of-work processing. 17
High performance DBATs DDF However, to minimize the number of different packages that can possibly be allocated by any one DBAT, distributed data facility (DDF) does not pool the DBAT and disassociates it from its connection after the unit-of-work is ended. After the unit-of-work is ended, DDF cuts an accounting record and deletes the WLM enclave, as done for inactive connection processing. Thus, the client application that requested the connection holds onto its DBAT, and only the packages that are required to run the application accumulate allocation locks against the DBAT. If one package among many is bound with RELEASE(DEALLOCATE), then the DBAT becomes a high performance DBAT, provided that it meets the requirements. Also, similar to inactive connection processing, the DBAT is terminated after 200 (not user changeable) units-of-work are processed by the DBAT. The connection at this point is made inactive. On the next request to start a unit-of-work by the connection, a new DBAT is created or a pooled DBAT is assigned to process the unit-of-work. Normal idle thread time-out detection is applied to these DBATs. If the DBAT is in flight processing a unit-of-work and if it has not received the next message from a client, DDF cancels the DBAT after the IDTHTOIN2 value has expired. However, if the DBAT is sitting idle, having completed a unit-of-work for the connection, and if it has not received a request from the client, then the DBAT is terminated (not cancelled) after POOLINAC3 time expires. 18
DDF High performance DBATs 1 There are two modes of running distributed threads: active, in which every connection is a database access thread (DBAT) even when waiting for new client transactions up until it is disconnected, and inactive, in which DBATs are pooled and handed out to connections as needed. 2 The IDTHTOIN subsystem parameter (IDLE THREAD TIMEOUT field) controls the amount of time, in seconds, that an active server thread is to be allowed to remain idle. 3 The POOLINAC subsystem parameter (POOL THREAD TIMEOUT field) specifies the approximate time, in seconds, that a database access thread (DBAT) can remain idle in the pool before it is terminated. The honoring of package bind options for distributed application threads is available only under the following conditions: KEEPDYNAMIC YES is not enabled. CURSOR WITH HOLD is not enabled. CMTSTAT is set to INACTIVE. Because RELEASE(DEALLOCATE) for distributed applications avoids pooling of DBATs, you might need to increase the MAXDBAT subsystem parameter to avoid queuing of distributed requests. The DB2 10 for z/os storage relief below the bar makes this requirement addressable. High performance DBATs and RELEASE(DEALLOCATE) do not relax the need to identify and fix bad behaving distributed applications. 19
DB2 Logging Verbesserungen Da die Maschinen immer schneller werden und DB2 immer mehr Arbeit erledigen kann, ist die latch class 19 contention in Frage gestellt. Dieser Zustand gilt vor allem für Systeme, mit hohen LOG Raten, wie Applikationen mit hoher INSERT Last. DB2 10 reduziertb die logging delays über folgende Verbesserungen (verfügbar im CM): (1) Long term page fix log buffers : DB2 10 page fixed die LOG Buffer permanent im Speicherin memory. Beim DB2 Start, werden alle Buffers wie in OUTBUFF angegeben page fixed. Das Feld OUTPUT BUFFER im Panel DSNTIPL ermöglicht die Angabe der Größe des output buffers für active log data sets. Die maximale Größe dieses Buiffers beträgt 400,000 KB, der default liegt bei 4,000 KB (4 MB) und die minimale Größe bei 400 KB. Generall ist der default für gute Performance NICHT GEEIGNET. Die Erhöhung des Wertes für OUTBUFF in DB2 10 verbessert die log read Performance. Beispiel: ROLLBACK und RECOVER mit der neuen Option BACKOUT kann davon profitieren, dass mehr Daten in den Buffers gefunden werden. COPY mit der Option CONSISTENT sollte ebenfalls davon profitieren (2) LOG I/O Verbesserungen Die aktuelle DASD Technik schreibt I/Os auf neue Bereiche des DASD cache und nicht mehr auf die Platte direkt. Es gibt also keine Möglichkeit mehr, dass log pages beim erneuten Schreiben zerstört werden. DB2 10 schreibt also einfach alle vier Pages auf log 1 und log 2 parallel. Demzufolge schreibt DB2 10 diese Pages in zwei I/Os und wartet die Dauer eines I/O ab welcher auch immer länger dauert. DB2 10 profitiert dabe von der non-volatile cache Architektur des I/O Subsystem. DB2 schreibt die Page asynchron auf beide active log data sets. In diesem Beispiel verkettet DB2 das Schreiben für Page 10 mit den write requests für die Pages 11, 12 und 13. So reduziert DB2 10 die Zahl der Log I/Os. (3) Reduzieren der Log latch contention 20
DB2 10 for z/os Im Einsatz, wo andere längst aufgeben... 21