(*) IBM DB2 for z/os DB2 Version 9 - Zusammenfassung (DB2_V9_SUMMARYnews.ppt) (*) ist eingetragenes Warenzeichen der IBM International Business Machines Inc. 1
Vergangenheit, DB2 V9 und Zukunft 2
Alle Applikationstypen profitieren von der neuen DB2 Version 9 3
Inkompatibilitäten zwischen DB2 V8 und der neuen DB2 Version 9 Applications Commands Storage SQL Changes to PL/I applications with no DECLARE VARIABLE statements. A host variable must be a varying-length string variable that is preceded by a colon. A PL/I string cannot be preceded by a colon. Changes to -DISPLAY THREAD output length. In V9, the -DISPLAY THREAD command output displays the number of lines per member that is specified in the LIMIT keyword. The default value of LIMIT is 512 lines of output per type specified, per member. Changes to the format of the BSDS. In V9, the BSDS must be in the format that supports up to 10,000 data sets per copy for archive logs and 93 data sets per copy for active logs. Any unconverted BSDSs are converted in job DSNTIJUZ. BSDSs that you have already converted are unaffected. The work file database is the only temporary database. In DB2 V9, the work file database is the only temporary database. The TEMP database is no longer used by DB2. Work file table spaces are now created on DB2-managed storage during installation. In V9, the installation process creates work file table spaces on DB2-managed storage. The default storage group is SYSDEFLT. You can specify a different. Changes in BIND PACKAGE and BIND PLAN defaults. The default value for bind option CURRENTDATA is changed from YES to NO. This applies to the BIND PLAN and the BIND PACKAGE subcommands, as well as the CREATE TRIGGER for trigger packages, and the CREATE PROCEDURE and the ALTER PROCEDURE ADD VERSION SQL statements for SQL PL procedure packages. Specifying NO for CURRENTDATA is the best option for performance. This change does not affect the REBIND subcommand. The default value for bind option ISOLATION is changed from RR to CS. This applies to the BIND PLAN and the remote BIND PACKAGE subcommands. For the BIND PACKAGE subcommand, the current default (plan value) stays. The default change does not apply to implicitly-built CTs (for example, DISTSERV CTs) or for the REBIND subcommand. 4
Inkompatibilitäten zwischen DB2 V8 und der neuen DB2 Version 9 SQL Changes in BIND PACKAGE and BIND PLAN defaults. Although you can specify DBPROTOCOL(PRIVATE) for the DBPROTOCOL parameter of the BIND option, DB2 issues a new warning message, DSNT226I. Plans and packages bound on DB2 Version 3 and before. If you have plans and packages that were bound on DB2 Version 3 and before and you specified YES or COEXIST in the AUTO BIND field of panel DSNTIPO, DB2 V9 autobinds these packages. If you specified NO in the AUTO BIND field of panel DSNTIPO, DB2 V9 returns SQLCODE -908, SQLSTATE 23510 for each attempt to use such a package or plan until it is rebound. Column names and labels in SQLDA SQLNAME field for statements involving UNION Changed behavior for ORDER BY clause in SELECT statement. If you order a query by a qualified column where the column name is the same as the AS NAME of the column in the select list, DB2 issues an error. Changed behavior of the INSERT statement with the OVERRIDING USER VALUES clause When the INSERT statement is specified with the OVERRIDING USER VALUES clause, the value for the insert operation is ignored for columns that are defined with the GENERATED BY DEFAULT attribute. DESCRIBE no longer returns LONG type values. When you execute a DESCRIBE statement against a column with a LONG VARCHAR or LONG VARGRAPHIC data type, the DESCRIBE statement returns the values as VARCHAR or VARGRAPHIC data type. DB2 enforces the restrictions about where a host variable array can be specified The host-variable-array variable is the meta-variable for host variable arrays. The host-variablearray variable is included only in the syntax for multi-row FETCH, multi-row INSERT, multirow MERGE, and EXECUTE in support of a dynamic multi-row INSERT or MERGE statement. In V9, if a host variable array is referenced in an unsupported context, DB2 issues an error. 5
Inkompatibilitäten zwischen DB2 V8 und der neuen DB2 Version 9 SQL Utilities DEBUGSESSION system privilege required for continued debugging of SQL procedures. After you migrate to new-function mode, users that debug external SQL procedures need the DEBUGSESSION system privilege. Changes to the result length of the DECRYPT function. The result length of the DECRYPT function is shortened to 8 bytes less than the length of the input value. If the result expands because of a difference between input and result CCSIDs, you must cast the encrypted data to a larger VARCHAR value before the DECRYPT function is run. Changes to DSN1LOGP. In V9, when you invoke DSN1LOGP with an RBA or LRSN range and the lower or higher bounds are not found in the available log files, DB2 issues a warning message to let you know that not all of the expected information can be formatted in the available logs and returns return code 4. Changes to the REORG utility. The REORG utility has been updated to reduce the amount of virtual storage that is used to build dictionaries. Because the REORG utility needs less virtual storage, the 254 partition restriction for reorganizing compressed table spaces has been removed. REORG or LOAD REPLACE utility automatically converts table spaces to reordered row format. In V9, the REORG or LOAD REPLACE utility automatically converts table spaces to reordered row format (RRF). You might need to rewrite the VALIDPROC or EDITPROC so that it correctly interprets rows that are in RRF. Changes to the REORG SHRLEVEL CHANGE utility. In V9, you do not need to run REORG INDEX SHRLEVEL CHANGE on all NPI data sets after you run REORG TABLESPACE PART x SHRLEVEL CHANGE because the NPI data sets are rebuilt by the REORG TABLESPACE PART. During a REORG TABLESPACE PART SHRLEVEL CHANGE, applications that access partitions other than the ones being reorganized might now encounter time outs if they access NPI data sets during the last iteration of the LOG phase or during the SWITCH phase. Adjust the values of the DRAIN_WAIT and MAXRO parameters to minimize application time outs. 6
Inkompatibilitäten zwischen DB2 V8 und der neuen DB2 Version 9 Utilities COLTYPE column in SYSIBM.SYSCOLUMNS and SYSIBM.SYSCOLUMNS_HIST for LONG column types. When new tables are created with LONG VARCHAR or LONG VARGRAPHIC columns, the COLTYPE values in SYSIBM.SYSCOLUMNS and SYSIBM.SYSCOLUMNS_HIST contain VARCHAR or VARGRAPHIC. DB2 returns all DSNWZP output in the same format as DB2 parameters. In Version 9, DB2 returns all DSNWZP output in the same format as DB2 parameters. Modify programs that call DSNWZP if they compensate for the format differences. DB2 enforces the restriction that row IDs are not compatible with character strings when they are used with a set operator. In V9, DB2 enforces the restriction that row IDs are not compatible with string types when they are used with a set operator (UNION, INTERSECT, or EXCEPT). The GROUP ATTACH process is randomized. In V9, the GROUP ATTACH process is randomized so that all members that are defined in a data sharing group and running on a z/os image have an equal chance of getting the attach from a starting application if the application specifies a GROUP ATTACH name instead of an individual subsystem name. You can no longer explicitly create a database name as DSNxxxxx. After you migrate to compatibility mode, if you explicitly create a database name with eight characters that begins with DSN and is followed by exactly five digits, DB2 issues an SQLCODE -20074 (SQLSTATE 42939). SDSNLOAD must be a PDSE. The DB2 SDSNLOAD data set that contains most of the DB2 executable code must now be allocated (via the DSNALLOC job) as a PDSE data set. In DB2 V8, you had the option to convert this data set to a PDSE. If you did not take the opportunity during your DB2 V8 migration to convert this data se to a PDSE, you must now do so. Note, however, that SMP/E must know which type of data set it is managing. It will compress a PDS, but not compress a PDSE. If you change the data set organization, you must also update the SMP/E definition. 7
DB2 Version 9 packageing 8
DB2 Version 9 Zusatz-Pakete 9
DB2 V9 - Voraussetzungen Hardware Jeder Prozessor der z/architektur unterstützt zseries z800, z890, z900, z990, IBM System z9 109 Funktionsabhängig o DRDA Data Stream Encryption optional mit Cryptographic Hardware o Encryption und Decryption benötigt Cryptographic Hardware Software z/os V1.7 Base Services im 64 Bit Modus DB2 V8 NFM IRLM V2.2 z/os Unicode Services 10
DB2 Version X (Ausblick) DB2 X Planung 20xx 2007 DB2 X 2004 DB2V9 2001 DB2V8 DB2V7 Themen Reliability, Availability, Serviceability Performance, Scalability Security, Productivity Application Development SQL, XML, SOA 11
DB2 Version X (Ausblick) DB2 X Planung Historisches Ziel: <5 % version-to-version Performanceeinbusse Zielsetzung: 10%-20% Performancesteigerung mit DB2 X Durchschnittliche CPU Einsparungen/Beschleunigungen in % - version to version 12
13
DB2 Version 9 weitere Informationen DB2 9 for z/os Home page: http://www-306.ibm.com/software/data/db2/zos/db2zosv91.html Optimization Service Center for DB2 for z/os: http://www-306.ibm.com/software/data/db2/zos/downloads/osc.html DB2 Tools Home page http://www-306.ibm.com/software/data/db2imstools/ Redbook DB2 9 for z/os Technical Overview http://www.redbooks.ibm.com/redpieces/abstracts/sg247330.html Securing DB2 and Implementing MLS on z/os Trusted Context and Roles http://www.redbooks.ibm.com/redpieces/abstracts/sg246480.html 14