db2® for z/os version 8 sql enhancements overview colorado

© 2002 IBM CorporationDB2 for z/OS Version 8 Overview

IBM Software Group | DB2 Data Management Software

IBM Software Group

© 2002 IBM Corporation

DB2® for z/OS Version 8

SQL Enhancements Overview

Colorado DB2 User group for z/OS

Kevin Harrison

Certified IT Architect

IBM Data Management Software-West Region

Technical Support DB2 for z/OS



Breaking the limits

–Virtual Storage 2 GB 231 to 264

–Table name sizes 18 to 128

–VIEW & ALIAS names 18 to 128

–Column name sizes 18 to 30

–Partitions 254 to 4096

�A node becomes B,C,D, or E

�Defaults to Selective Partition Locking

–SQL statement length 32K to 2 MB

–Index key size 255 to 2000

–Character Literals 255 to 32704

–Hex literal digits 255 to 32704

–Predicates 255 to 32704

Limits: DB2 for z/OS



Breaking the limits ...

–Tables in a join 15 to 225

–Current optimization 8 to 128

–CURRENT PACKAGESET 18 to 128

–CURRENT PATH 254 to 2048

–CURRENT SQLID 8 to 128

Limits: DB2 for z/OS



–Common Table Expression & Recursion

–Multi-row INSERT & FETCH

–GET DIAGNOSTICS

–INSERT within SELECT

–IDENTITY Column enhancements

–SEQUENCES

–DYNAMIC SCROLLABLE CURSORS

–CURRENT PACKAGE PATH

–SCALAR FULLSELECT

–MATERIALIZED QUERY TABLES

–UNICODE SQL, MULTIPLE CCSIDs

–XML Publishing

–...

SQL and DB2 Family



Common Table Expressions



Recursive SQL



Recursive SQL- Initialization

SELECT



Recursive SQL - First Iteration



Recursive SQL - Second Iteration



Recursive SQL - Main SELECT



Controlling Depth of Recursion - 1



Recursive SQL - Recommendations

• Desk-check recursive SQL statement

• Test recursive SQL against small test

tables

• Use controls to limit recursion



�New third form of insert

–INSERT via VALUES is used to insert a single row into the table or view using values

provided or referenced

–INSERT via SELECT is used to insert one or more rows into table or view using values

from other tables or views

–INSERT via FOR "n" ROWS form is used to insert multiple rows into table or view using

values provided in host variable array

�FOR "n" ROWS

–For static, it is valid to specify FOR "n" ROWS on the INSERT statement

(for dynamic INSERT, specify FOR "n" ROWS on the EXECUTE statement)

–Maximum value of n is 32767

–Input provided with host variable array -- each array represents cells for multiple rows of a

single column

�VALUES clause allows specification of multiple rows of data

–Host variable arrays used to provide values for a column on INSERT

–Example: VALUES (:hva1, :hva2)

Multi-row insert



Multi-row INSERT

�Inserts multiple rows on one API call

�Can be ATOMIC or NOT ATOMIC

�Can be static or dynamic SQL

�Significant performance boost

INSERT INTO T1 FOR :hv ROWS

VALUES( :ARRAY1, :ARRAY2) ATOMIC;



Multi-row FETCH�Returns multiple rows on one API crossing

�"wide" cursor with locks on multiple rows

�Supports scrollable and non-scrollable, static and

dynamic SQL

�Significant performance boost

�DSNTEP4 = DSNTEP2 + MRF

DECLARE C1 CURSOR

WITH ROWSET POSITIONING

FOR SELECT COL1, COL2 FROM T1;

OPEN C1;

FETCH FROM C1

FOR :hv ROWS INTO :ARRAY1, :ARRAY2;



Positioned UPDATE/DELETEof Multi-row FETCH

�Allows positioned UPDATE or DELETE to be used on

a "wide" cursor

UPDATE T1 SET COL1='ABC'

FOR CURSOR C1

FOR ROW :hv OF ROWSET



FETCH Examples

EXAMPLE 1:

Fetch the previous rowset and have the cursor positioned on that rowset

EXEC SQL

FETCH PRIOR ROWSET FROM C1 FOR 3 ROWS INTO...

-- OR --

EXEC SQL

FETCH ROWSET

STARTING AT RELATIVE -3 FROM C1 FOR 3 ROWS INTO...

EXAMPLE 2:

Fetch 3 rows starting with row 20 regardless of the current position of the cursor

EXEC SQL

FETCH ROWSET STARTING AT ABSOLUTE 20

FROM C1 FOR 3 ROWS INTO...



Host Variable Arrays

• A host variable array is an array in which each element of the array contains a value for the same column; column-wise binding

• Can only be referenced in multi-row FETCH and INSERT

• Host variable arrays are supported in

– COBOL

– PL/I

– C and C++

• Assembler support is limited to cases where USING DESCRIPTOR is allowed.

• In general, arrays may not be arrays of structures



ATOMIC/NOT ATOMIC CONTINUE ON

SQLEXCEPTIONATOMIC (default)

• If the insert for any row fails, all changes made to database by that INSERT statement are undone

NOT ATOMIC CONTINUE ON SQLEXCEPTION

• Inserts are processed independently

• If errors occur during execution of INSERT, processing continues

• Diagnostics are available for each failed row through GET DIAGNOSTICS

• SQLCODE indicates if:– All failed

• SQLSTATE 22530, SQLCODE -254

– All were successful, but warnings• SQLSTATE 01659, SQLCODE +252

– At least one failed• - SQLSTATE 22529, SQLCODE -253



Some Considerations

FETCH FIRST clause

– Does not affect which rows are inserted

– All of the rows from the INSERT statement will be inserted

into the target object

– The result table will only contain those rows for which the

FETCH FIRST clause satisfies

DECLARE CURSOR

– The cursor is always read-only

OPEN CURSOR

– SQLERRD3 is set to reflect the effects of the INSERT

statement (number of rows inserted)



GET DIAGNOSTICS

�Returns SQL error information

ƒfor overall statement

ƒfor each condition (when multiple errors occur)

�Supports SQL error message tokens greater than 70

bytes (SQLCA limitation)

INSERT INTO T1 FOR 5 ROWS VALUES(:ARRAY);

GET DIAGNOSTICS :ERR_COUNT = NUMBER;

DO II = 1 TO ERR_COUNT;

GET DIAGNOSTICS FOR CONDITION :II

:RC = RETURNED_SQLSTATE;

END;



GET DIAGNOSTICS Example �To determine how many rows were updated in an UPDATE statement

– GET DIAGNOSTICS :rcount = ROW_COUNT;

�To handle multiple SQL errors during a NOT ATOMIC multi-row insert

–GET DIAGNOSTICS :numerrors = NUMBER;

–Then code a loop to execute the following for the number of errors

�GET DIAGNOSTICS CONDITION :i :retstate = RETURNED_SQLSTATE

�To see all diagnostic information for a SQL statement

–GET DIAGNOSTICS :diags = ALL STATEMENT

–Sample output in :diags

�Number=1; Returned_SQLSTATE=02000;

DB2_RETURNED_SQLCODE=+100;

�Would continue for all applicable items and for all conditions

�Items are delimited by semicolons



INSERT within SELECT Statement

What is it? .....

• Users can automatically retrieve column values inserted

in tables by DB2 during Insert such as:

– Identity columns, sequence values

– User-defined defaults, expressions

– Columns modified by BEFORE INSERT triggers ROWIDs

– INSERT with return or SELECT from INSERT

Benefits .....

• Enhances usability and power of SQL

• Cuts down on network cost in application programs

• Cuts down on procedural logic in stored procedures



INSERT within SELECT Syntax Changes



INSERT within SELECT Examples



INSERT within SELECT - Ordering Example



Trigger Example



EXPLAIN output

Example:

SELECT EMPNO INTO :HV1

FROM FINAL TABLE

(INSERT INTO EMPLOYEE (NAME, SALARY,LEVEL)

VALUES('The New Guy', 50000.00, 'Staff'));

QBLOCK_T

YPE

QBLOCKNO PLANNO ACCESSTYPE TABLE_TYPE

SELECT 1 1 V B

INSERT 2 0

–New Information Stored in Plan Table

–ACCESSTYPE -- V indicates that buffers will be used for singleton INSERT VALUES clause for INSERT within SELECT

–TABLE_TYPE -- B indicates buffers will be used



Identity Column Improvements

�ALTER support for Identity Columns

ƒGENERATED ALWAYS | BY DEFAULT

ƒRESTART WITH value

ƒINCREMENT BY

ƒMINVALUE

ƒMAXVALUE

ƒCYCLE | NO CYCLE

ƒCACHE | NO CACHE

ƒORDER | NO ORDER



Sequences

�Useful for porting Oracle applications

�New SQL support:

ƒCREATE SEQUENCE

ƒALTER SEQUENCE

–RESTART WITH value

–INCREMENT BY

–MINVALUE

–MAXVALUE

–CYCLE/NO CYCLE

–CACHE/NO CACHE

ƒGRANT/REVOKE privileges for the sequence object

ƒNEXT VALUE FOR EXPRESSION

ƒPREVIOUS VALUE FOR EXPRESSION



Sequence Object Solution

• Avoid the concurrency and performance problems when applications generate their own sequence numbers (hotspots)

• DB2 sequences allow multiple transactions to concurrently increment sequence number and guarantee each number will be unique

• Sequence can be accessed and incremented by many users without waiting– DB2 does not wait for a transaction that has incremented a sequence to

commit before allowing the sequence to be incremented again by another transaction

• Failure of one DB2 member in group will never prevent access (R/W) to sequence from surviving members– No retained locks to prevent access to sequence



Comparing Identity Columns and Sequences



SQL to Support Sequence Objects

• CREATE SEQUENCE– Creates a sequence at the application server

– Can be embedded in application program or used interactively

• ALTER SEQUENCE

• Can be used to change INCREMENT BY, MIN VALUE, MAXVALUE, CACHE,– CYCLE and to RESTART WITH different sequence

– Only future values affected and only after COMMIT of ALTER

– Cannot alter data type of sequence

– Unused cache values may be lost

• DROP SEQUENCE

• COMMENT ON SEQUENCE

• GRANT/REVOKE ON SEQUENCE

• NEXT VALUE FOR and PREVIOUS VALUE FOR



Sequence Objects - CREATE Statement



Sequence Objects – Usage -1



Sequence Objects – Usage -2



Dynamic scrollable cursors

�What is it? .....

–Dynamic scrollable cursor:

� Scrolls directly on base table (TS scan, IX scan & DPSI)

� No result table materialized at any time

� Immediate visibility of committed updates, inserts, deletes

� Positioned updates and deletes allowed when possible

� Avoid sort by using backward index scan for ORDER BY

� Defaults to single row fetch, so DDF applications should use:

�multi-row FETCH

�positioned update/delete for multi-row FETCH

�Benefits .....

–Enhances usability and power of SQL

–Facilitates portability

–Conforms to SQL standards

–Performance improved by sort elimination

–Elimination of work file (temporary table)



Declare Cursor - New Attributes• SENSITIVE DYNAMIC

– Specifies that size of result table is not fixed at OPEN cursor time

– Cursor has complete visibility to changes• All committed inserts, updates, deletes by other application processes

• All positioned updates and deletes within cursor

• All inserts, updates, deletes by same application processes, but outside cursor

– FETCH executed against base table since no temporary result table created

• ASENSITIVE

– DB2 determines sensitivity of cursor

– If read-only...• Cursor is INSENSITIVE if SELECT statement does not allow it to be SENSITIVE

(UNION, UNION ALL, FOR FETCH ONLY, FOR READ ONLY)

• It behaves as an insensitive cursor

– If not read-only, SENSITIVE DYNAMIC is used for maximum sensitivity

– Mainly for Client applications that do not care whether or not the server supports the sensitivity or scrollability



Dynamic Scrollable Cursors Considerations

• Dynamic scrollable cursors are supported with stored procedures

• Scalar functions and arithmetic expressions in SELECT list are reevaluated at every FETCH

• Column functions (AVG, MIN, MAX, etc.) are calculated once at cursor open

– Functions may not be meaningful because size of result table can change

• Use of non-deterministic function (built-in or UDF) in WHERE clause of SELECT statement or statement name of scrollable cursor can cause misleading results

– Result of function can vary from one fetch to subsequent fetch of same row

• Cursors requiring use of a workfile cannot be declared SENSITIVE DYNAMIC

• Changes to tables referenced in subqueries are not reflected

• Parallelism is not supported with dynamic scrollable cursors



DRDA Considerations

• DB2 Linux, UNIX, and Windows V8.1 clients support

dynamic scrollable cursors with FP4

– Only via the ODBC interface

– Only when calling DB2 for z/OS V8

• Dynamic scrollable cursors do not support the DRDA limited

block fetch protocol

– To achieve blocking, use multi-row fetch operations. This is

currently

– supported between:

• DB2 for z/OS V8 systems

• DB2 ODBC distributed clients using dynamic scrollable cursors and

• DB2 for z/OS V8



Static scrollable cursors -- Version 7 review

FETCH CURSOR...

Cursors can be scrolled

–backwards

–forwards

–to an absolute position

–to a position relative to the

current cursor

–before/after position

Result table in TEMP DB

Rows refreshed on demand



Sensitive and insensitive cursors -- V7 review

DECLARE C1 INSENSITIVE

SCROLL..

...

FETCH INSENSITIVE...

TEMP TABLE

BASE TABLE

ƒRead only cursor

ƒNot aware of updates or

deletes in base table

PROGRAM

DECLARE C1 SENSITIVE

STATIC SCROLL..

...

FETCH INSENSITIVE...

ƒUpdatable cursor

ƒAware of own updates or

deletes within cursor

ƒOther changes to base

table not visible to cursor

ƒAll inserts not recognized

TEMP TABLE

BASE TABLE

PROGRAM

DECLARE C1 SENSITIVE

STATIC SCROLL..

...

FETCH SENSITIVE...

ƒUpdatable cursor

ƒAware of own updates and

deletes within cursor

ƒsees all committed

updates and deletes

ƒAll inserts not recognized

TEMP TABLE

BASE TABLE

PROGRAM

Order by, table join and aggregate functions will force READ ONLY



Implications on FETCH

� INSENSITIVE not allowed with FETCH statement (SQLCODE -244) if

–The associated cursor is declared as SENSITIVE DYNAMIC SCROLL

–The cursor is declared ASENSITIVE and DB2 chooses the maximum

allowable sensitivity of SENSITIVE DYNAMIC SCROLL

�There are no "holes" as there is no temporary result table

–Special case: If FETCH CURRENT or FETCH RELATIVE +0 requested but row

on which cursor is positioned was deleted or updated so that it no longer

meets selection criteria (SQLCODE +231)

–For example, can occur with ISOLATION(CS) and CURRENTDATA(NO)

�Inserts by the application itself are immediately visible -- inserts by others

are visible after commit

�Order is always maintained

–If current row is updated, the cursor is positioned before the next row of the

original location and there is no current row



�At OPEN CURSOR, cursor is positioned before first row

�After FETCH, fetched row becomes current row and cursor

positioned on current row

�When FETCH reaches end of file, cursor positioned after

last row if scroll number positive and before first row if

scroll number negative

�Ability to scroll backwards and forwards through result set

which is ever changing

–Note that scroll quantity counts new inserts and has no way of

counting deleted rows

–Usage example: airline reservation or credit card processing

Cursor position and scrolling



Locking with dynamic scrollable cursors

�ISO CS recommended for maximum concurrency

–RR and RS severely restrict update of table by other users, therefore

defeating purpose of SENSITIVE DYNAMIC

�Lock is held on current row as base table is always

accessed directly

�As before, if ISO UR is on BIND option and SELECT

statement contains FOR UPDATE OF, ISO promoted to

CS

�As normal, if cursor defined WITH HOLD, locks will be

held until first commit after close of cursor unless

DSNZPARM SPRMRCHL = NO, in which case locks

held for held cursors released at COMMIT



Updating via scrollable cursors

�Optimistic locking is used by static scrollable cursors

–Static scrollable cursors hold no locks on base tables

after OPEN CURSOR

–Check at update time whether the row has not changed

�Optimistic locking is not used by dynamic scrollable

cursors

–Locks against the underlying table while fetching,

similar to non-scrollable cursors

�Positioned UPDATE and DELETE always allowed if

cursor not read-only and the page or row lock was

acquired successfully



COBOL Example 1: Declare a CURSOR C1 and fetch 10 rows using a multi-row

FETCH statement

01 OUTPUT-VARS.

05 NAME OCCURS 10 TIMES.

49 NAME-LEN PIC S9(4) USAGE COMP.

49 NAME-TEXT PIC X(40).

05 SERIAL-NUMBER PIC S9(9) USAGE COMP OCCURS 10 TIMES.

01 IND-VARS.

10 INDSTRUC1 PIC S9(4) USAGE COMP OCCURS 10 TIMES.

10 INDSTRUC2 PIC S9(4) USAGE COMP OCCURS 10 TIMES.

PROCEDURE DIVISION.

EXEC SQL

DECLARE C1 CURSOR WITH ROWSET POSITIONING FOR

SELECT NAME, SERIAL# FROM EMPLOYEE

END-EXEC.

EXEC SQL

OPEN C1 END-EXEC.

EXEC SQL

FETCH FIRST ROWSET FROM C1 FOR 10 ROWS

INTO :NAME:INDSTRUC1,:SERIAL-NUMBER:INDSTRUC2

END-EXEC.



Determining rowset size�If FOR n ROWS is NOT specified and cursor is declared for rowset

positioning..

�Size of rowset will be the same as the previous rowset fetch as long as

–It was the previous fetch for this cursor

–Or the previous fetch was a FETCH BEFORE or FETCH AFTER and the fetch before that was

a rowset fetch

�Else rowset is 1

FETCH FIRST ROWSET FOR 5 ROWS Returns 5 rows

FETCH NEXT ROWSET Returns the next 5 rows

FETCH NEXT Returns a single row

FETCH NEXT ROWSET Returns a single row

FETCH NEXT ROWSET FOR 3 ROWS Returns 3 rows

FETCH BEFORE Returns 0 rows

FETCH NEXT ROWSET Returns 3 rows



Fetching beyond the result set

�If you try to fetch beyond the result set you will receive end

of data condition

–i.e., When there are only 5 rows left in result table and you

request FETCH NEXT ROWSET FOR 10 ROWS, 5 rows will

be returned with an SQLCODE +100

�This includes where FETCH FIRST n ROWS ONLY has been

specified



Cursor positioning: rowset positioned fetches

CUST_NO CUST_TYP CUST_NAME

1 P Ian

2 P Mark

3 P John

4 P Karen

5 P Sarah

6 M Florence

7 M Dylan

8 M Bert

9 M Jo

10 R Karen

11 R Gary

12 R Bill

13 R Geoff

14 R Julia

15 R Sally

FETCH FIRST ROWSET

FOR 3 ROWS

FETCH NEXT ROWSET

FETCH ROWSET STARTING

AT ABSOLUTE 8

FOR 3 ROWS

Result table

Note: cursor is positioned on

ALL rows in current rowset



Locking and isolation levels

�Cursor will be positioned on all rows in current rowset

�Locks will be held on all rows in rowset depending on isolation

level and whether a result table has been materialized

�Affects whether you refetch the same rows when issuing a

FETCH CURRENT to refetch current rowset



Considerations using static scrollable cursors

�When scrolling between rowsets:

–With insensitive fetches, updates by the application itself could

cause changes and holes

–With sensitive fetches, updates by other applications could cause

changes and holes

–For example, FETCH PRIOR ROWSET may return update or

delete holes in place of rows that were fetched before

�Row contents can change between fetches



�Starting point and contents of rowsets will change when scrolling back

and forth

�Note that just after fetching the CURRENT ROWSET, other applications

can insert rows in between the rows being returned as part of the rowset

–Refetching current rowset would return different rows, unless

ISOLATION(RR)

�FETCH PRIOR ROWSET will return the previous n rows that qualify from

the start of the current cursor position

–Therefore n rows will be returned as long as start of rowset is not reached

Considerations with dynamic scrollable cursors



Considerations for positioned update/delete

�It is possible for another application process to update or

delete a row in the base table of the SELECT statement so that

the specified row of the cursor no longer has a corresponding

row in the base table

–If the cursor is non-scrollable, this could happen if the cursor is

ISOLATION(CS) CURRENTDATA(NO) and lock avoidance

succeeds

–If the cursor is static scrollable, this could happen, since the result

set is materialized into a temporary table and all underlying locks are

released (unless ISOLATION(RR) or ISOLATION(RS)

–If the cursor is dynamic scrollable, this could happen if the cursor is

ISOLATION(CS) CURRENTDATA(NO) and lock avoidance

succeeds.



Cursor Type Result Table Visibility of

Own Changes

Visibility of

Others'

Changes

Updatability

(*)

Non-scrollable

(SQL contains a

join, sort, etc.)

Fixed, work file No No No

Non-scrollable No work file, base

table access

Yes Yes Yes

INSENSITIVE

SCROLL

Fixed, declared

temp table

No No No

SENSITIVE

STATIC SCROLL

Fixed, declared

temp table

Yes

(INSERTs not

allowed)

Yes

(Not INSERTs)

Yes

SENSITIVE

DYNAMIC

SCROLL

No declared temp

table, base table

access

Yes Yes YesNew

Cursor type comparison

* A cursor can become read-only if the SELECT statement references more

than

one table, contains a GROUP BY, etc. (read-only by SQL)



CURRENT PACKAGE PATH

�Important for SQLJ and DDF apps

–Less need for SET CURRENT PACKAGESET

–Less network traffic for multiple PKLIST values

–Easier to switch to/from JDBC and SQLJ

–Better handling of nested stored procedure

packages

� Allows application to specify search list of package

schemas (similar to PKLIST)

SET CURRENT PACKAGE PATH =

ALPHA,

BETA,

PROD



CURRENT PACKAGE PATH special register

� What is it? .....

–CURRENT PACKAGE PATH special register:

�Used for package collection resolution

�Means for application to specify a list of package collections to DB server

(similar to PKLIST)

�DB server (rather than application requester) can search through list and

find first package that exists with specified package name

�Control for applications that do not run under a DB2 plan

�Benefits .....

–Reduce network traffic and improve CPU/elapsed time for application

using DRDA from a z/OS requester

–Allows nested procedure, user-defined function to be implemented

without concern for invoker's runtime environment and allows

multiple collections to be specified

–Easier to switch to / from JDBC and SQLJ



Package Resolution today

�Given that multiple collections can be used for

packages, how is package resolution managed

today?...

– CURRENT PACKAGESET special register

�Set to single collection id to indicate any package to be invoked

belongs to that collection

�Application must issue SET CURRENT PACKAGESET before

each package is invoked if collection for the package is different

from previous package

–BIND PLAN PKLIST

�Ability to specify list of collection ids for packages for local

OS/390 applications that use plans at execution time



Package Resolution - SQLJ�What about SQLJ?...

–Requirement

�SQLJ increases need for package switching and versioning

�With SQLJ, people bind multiple packages for the same thing with different bind options (i.e.,

different ISOs)

�People want to be able to switch between different versions of package depending on what has

been implemented at server (i.e., different qualifiers)

–Before Version 8

�Application does not know which one to use so has to issue multiple SET CURRENT

PACKAGE SETS and retry until it finds the right one -- laborious and time consuming

–With Version 8

�New CURRENT PACKAGE PATH special register allows list of package collections to be

specified, resulting in reduction in network traffic and CPU where applications use DB2 for z/OS

as requester

�Helps with stored procedures and UDF's and with versioning

�To execute statement, requester must specify new DRDA flow

�Special register is 4K (4096), separate collections with commas -- no checks made until

runtime so ensure they are spelled correctly



Package Resolution - DRDA

�What about remote clients connected via DRDA...

–Before Version 8

�PKLIST bind option allows them to search package collections at runtime requester function -- remote server doesn't know value set for PKLIST because it is

part of PLAN and only packages are used at remote server

–Message sent to server requesting package with first collection from PKLIST; if

results in SQLCODE -805, another message sent requesting package with next

collection in PKLIST

–PKLIST is a

–With Version 8

� New CURRENT PACKAGE PATH special register means crossing

network only once to resolve package collection id at server, instead of

crossing once per collection id to perform resolution at client



Package Resolution - procedures

�What about procedures and user-defined functions?

–Before Version 8

�Users cannot identify package resolution schemes independent from rules

established by caller's plan

�SET CURRENT PACKAGESET or COLLID option for routine can be used

within a procedure or function to change package resolution rule from invokers,

but can only specify one package collection at a time

–With Version 8

�New CURRENT PACKAGE PATH special register allows nested procedure,

user-defined function to be implemented without concern for invoker's runtime

environment and allows multiple collections to be specified



Scalar Fullselect

What is it? .....

• A scalar fullselect is a fullselect, enclosed in parentheses, that returns a single value

• Allows scalar fullselect where expressions were previously supported

• Example:SELECT PRODUCT, PRICE

FROM PRODUCTS

WHERE PRICE <= 0.7 * (SELECT AVG(PRICE)

FROM PRODUCTS);

Benefits .....


• Facilitates portability

• Conforms with SQL standards



Extension to Expressions Syntax



Scalar Fullselect -- Example Tables



Scalar Fullselects in a WHERE Clause

• Find which products have the prices of at least

twice the lowest price of all the products.



Nested Scalar Fullselects in a SELECT List

• Find the cost of inventory for each product by

calculating the sum of (price * onhand#) for each

part in the product.



Scalar fullselects -- in CASE expression of

UPDATE Give discount to the parts that have the large inventory and raise price on

the parts that have the small inventory.

CREATE TABLE NEW_PARTPRICE LIKE PARTPRICE;

INSERT INTO NEW_PARTPRICE SELECT * FROM PARTPRICE;

UPDATE NEW_PARTPRICE N SET PRICE =

CASE

WHEN( (SELECT ONHAND# FROM INVENTORY WHERE PART=N.PART) < 7)

THEN 1.1 * PRICE

WHEN( (SELECT ONHAND# FROM INVENTORY WHERE PART=N.PART) > 20)

THEN .8 * PRICE

ELSE PRICE

END;

SELECT * FROM NEW_PARTPRICE;

PART PROD# SUPPLIER PRICE

WIRE 10 ACWF 3.50

OIL 160 WESTERN_CHEM 1.20

MAGNETS 10 BATEMAN 65.45

PLASTIC 30 PLASTIC_CORP 2.20

BLADES 205 ACE_STEEL 8.90



Scalar Fullselect - Restrictions

• Scalar fullselect not supported in...

– A CHECK constraint

– A grouping expression

– A view that has a WITH CHECK OPTION

– A CREATE FUNCTION (SQL scalar)

– A column function

– ORDER BY clause

– Join-condition of the ON clause for INNER and OUTER JOINS



What is a Materialized Query Table (MQT)?

• Table containing materialized data derived from one or more source tables specified by a fullselect

– Source tables can be base tables, views, table expressions or user-defined table expression

– MQTs can be accessed directly via SQL or

– Chosen by the optimizer (through automatic query rewrite) when a base table or view is referenced

• Two types: Maintained by system or by user

• Synchronization between base table(s) and MQT

– Using 'REFRESH TABLE' statement

– Batch update, triggers, etc. for user-maintained MQTs

• Can provide significant query performance improvement



Multiple DISTINCT Clauses

What is it? .....

• Allows more than one DISTINCT keyword on the SELECT or HAVING clause for a query

Benefits .....


• DB2 Family compatibility

• Previously you would get an SQLCODE -127



Multiple DISTINCT Clauses - 2

Prior to Version 8 .....

• SELECT DISTINCT C1, C2 FROM T1;

• SELECT COUNT(DISTINCT C1) FROM T1;

• SELECT C1, COUNT(DISTINCT C2) FROM T1 GROUP BY C1;

• SELECT COUNT(DISTINCT(C1)),SUM(DISTINCT C1)FROM T1; --

same col

With Version 8 .....

• SELECT COUNT(DISTINCT C1), AVG(DISTINCT C2)

FROM T1 GROUP BY C1;

• SELECT SUM(DISTINCT C1), COUNT(DISTINCT C1),

AVG(DISTINCT C2)

FROM T1 GROUP BY C1 HAVING SUM(DISTINCT C1) = 1;

• SELECT DISTINCT COUNT(DISTINCT C1), SUM(DISTINCT C2)

FROM T1;

Not Supported in Version 8 .....

• SELECT COUNT(DISTINCT A1,A2)

FROM T1 GROUP BY A2;

• SELECT COUNT(DISTINCT(A1,A2))

FROM T1 GROUP BY A2;



VOLATILE Table Support

�Encourages index access for tables that have

unpredictable cardinality

�Significant performance improvement for some SAP

applications

CREATE TABLE XYZ ...... VOLATILE



XML Publishing Functions SQL/XML

�New built-in functions for generating XML

ƒXMLELEMENT generates XML element from arguments

ƒXMLATTRIBUTES specify attributes for the XML element

within XMLELEMENT

ƒXMLFOREST creates forest of XML elements that share a

specific pattern

ƒXMLCONCAT concatenates arguments to generate a

forest of XML elements

ƒXMLAGG aggregate produces forest of XML elements

from a collection of XML elements

ƒXML2CLOB converts transient XML data type into UTF-8

CLOB

�Replacing XML generation function of XML Extender



Query Example - Demo Query 1

SELECT

XML2CLOB(

XMLELEMENT

( "Dept",

XMLATTRIBUTES ( D.DEPTNO AS "deptno",

D.DEPTNAME AS "name" ),

( SELECT XMLAGG (

XMLELEMENT (

"Proj",

XMLATTRIBUTES (P.PROJNO AS "projno",

P.PROJNAME AS "name"),

( SELECT XMLAGG (

XMLELEMENT (

"Emp",

XMLATTRIBUTES

(E.EMPNO as "empno"),

E.FIRSTNME || ' ' || E.LASTNAME

)

)

FROM DSN8810.EMPPROJACT EP,

DSN8810.EMP E

WHERE EP.PROJNO = P.PROJNO AND

EP.EMPNO = E.EMPNO

) )

)

FROM DSN8810.PROJ P

WHERE P.DEPTNO = D.DEPTNO

)

) )

FROM DSN8810.DEPT D

WHERE D.DEPTNO = 'D01';

Query: Result: (formatted for easy viewing)

<DeptDept deptno="D01" name="DEVELOPMENT CENTER">

<ProjProj projno="AD3100" name="ADMIN SERVICES">

<EmpEmp empno="000010">CHRISTINE HAAS</Emp/Emp>

</Pro/Proj>

<ProjProj projno="MA2100" name="WELD LINE AUTOMATION">

<EmpEmp empno="000010">CHRISTINE HAAS</Emp/Emp>

<EmpEmp empno="000110">VINCENZO LUCCHESI</Emp/Emp>

</Proj/Proj>

</Dept/Dept>



SQL statements up to 2M bytes

�SQL statements can now be up to 2M bytes in length

�Parse tree has been completely rearchitected to

reduce SQLCODE -101 scenarios due to SQL

statement length

�Important for SQL Procedure Language applications



Multiple CCSIDs per statement

�A single SQL statement can now intermix EBCDIC,

ASCII and Unicode tables and host variables

�Unlike host variables are translated to column CCSID

�Unlike column CCSIDs are "promoted" to Unicode

ƒMay require query to be materialized/sorted

SELECT T1.COL_EBCDIC ||

T2.COL_ASCII ||

T3.COL_UNICODE FROM T1,T2,T3 ...;



Non-correlated EXISTS subquery

• Prior to V8, ALL qualifying rows of a non-correlated EXISTS subquery are retrieved and stored in a workfile– Potentially a lot of processing to find all qualifying rows for the subquery

– Potentially a lot of workfile space to store all these rows

• DB2 V8 stops evaluating the non-correlated EXISTS subquery as soon as ONE qualifying row is found– One qualifying row is sufficient to evaluate the predicate as true

– Example:

SELECT EMPNO,LASTNAME

FROM DSN8810.EMP

WHERE EXISTS (

SELECT *

FROM DSN8810.PROJ

WHERE PRSTDATE > ’2005-01-01’);



IN List Processing Enhancements

• V7 Enhancements to IN list processing– Predicate pushdown for IN list predicates (V7 APAR PQ73454)

– Correlated subquery transformation enhancement (V7 APAR PQ73749)

– Activated by INLISTP DSNZPARM (default value 0 in V7 = disabled)

• By default enabled in V8 (INLISTP=50)– IN list predicate pushdown into nested table expression (NTE) or

materialized view (MV)

• Better filtering inside NTE and MV ; fewer resulting rows

• Potential index usage on columns when resolving NTE or MV

– Correlated subquery transformation enhancement

• IN list predicates generated by predicate transitive closure "pulled up" to parent query block

– Filtering can be done at parent level, resulting in fewer invocations of subquery executions

– IN list predicate on parent query block can take advantage of existing indexes and provide a better access path for parent query block



Other SQL Improvements

�GROUP BY expression

–SELECT A+B,C FROM T ORDER BY A+B

GROUP BY A+B

�Qualified column names on SET clause

–UPDATE T1 SET T1.COL1...

�Qualified column names on INSERT

–INSERT T1.COL1 INTO T1 VALUES...



IS NOT DISTINCT FROM

SELECT C1 FROM T1 WHERE

C1 IS NOT DISTINCT FROM :hv;

�SQL uses three-valued logic where any given comparison can

return: TRUE, FALSE, or NULL

�Applications can use IS NOT DISTINCT FROM to get a TRUE result

instead of NULL when a comparing NULL values

C1 value :hv value RESULT

NULL 'ABC' FALSE

NULL NULL TRUE

'ABC' 'ABC' TRUE

'ABC' NULL FALSE

'ABC' 'DEF' FALSE



Stage 1 Indexable Unlike-types

�DB2 enhanced to allow index access when host

variable & target column are not the same data type

�Deals with programming languages that don't support

the full range of SQL data types

ƒC/C++ has no DECIMAL data type

ƒJava has no fixed length CHAR data type

ƒetc.

�Significant performance improvement for many

applications

�Simplifies application programmer & DBA tasks



Stage 1 and Indexable Predicates

• DB2 determines if a predicate is stage 1, based on predicate syntax, type and lengths of constants in the predicate, whether

• predicate evaluation is done before or after a join operation

• Prior to V8, if data types and lengths do not match, the predicate is evaluated at stage 2

• Major performance enhancement in DB2 V8 for queries involving predicates with mismatched data types and length comparison

• Certain stage 2 predicates become stage 1, and possibly Indexable

– Eliminates table space scan when mismatch between host variable and DB2 column

– Improved situation in unknown join sequence



Mismatched Data Types

• Becoming more common as not all programming languages

support the full range of SQL data types, for example

– C/C++ has no DECIMAL data type

– Java has no fixed character data type

• The following predicate types become stage 1 and also

indexable for unlike data types

– Col op expression

– Expression op col

– Col BETWEEN expression 1 and expression 2



Mismatched Operands Numeric Types Comparison



Backward Index Scan

• In V8, DB2 selects an ascending index and can use a backward scan to avoid the sort for the descending order

• In V8, DB2 uses the descending index to avoid the sort and can scan the descending index backwards to provide the ascending order

• To be able to use an index for backward scan,– Index must be defined on the same columns as ORDER BY and

– Ordering must be exactly opposite of what is requested in ORDER BY

• If index defined as DATE DESC, TIME ASC, can do:

– Forward scan for ORDER BY DATE DESC, TIME ASC

– Backward scan for ORDER BY DATE ASC, TIME DESC

– But must sort for

• ORDER BY DATE ASC, TIME ASC

• ORDER BY DATE DESC, TIME DESC



Same

Index is

used.

Avoid Sort by using Backward Index Scan with

ORDER BY

SELECT STATUS_DATE, STATUS

FROM ACCT_STAT

WHERE ACCT_NUM = :HV

ORDER BY STATUS_DATE DESC, STATUS_TIME DESC;

SELECT STATUS_DATE, STATUS

FROM ACCT_STAT

WHERE ACCT_NUM = :HV

ORDER BY STATUS_DATE ASC, STATUS_TIME ASC;

Index on ACCT_STAT is

ACCT_NUM, STATUS_DATE, STATUS_TIME

Backward

index scan

Forward

index scan

For

scrollable

and non

scrollable

cursors

DB2 optimizer will select an ascending index to

provide a descending sort order by traversing the

index backwards rather than do a sort



Padded/No Padded: Performance

Expectation• Factors affecting performance of PADDED / NOT PADDED index:

• NOT PADDED indexes can provide a true index-only access path

• Size of the index pages

– In general, number of index pages for NOT PADDED index are fewer than for the PADDED index, thus less index getpages and index page I/Os

– Potentially fewer index levels

– Smaller index size favors the index to be chosen for a query (Index-only access)

• Extra comparison

– NOT PADDED indexes that contain multiple VARCHAR columns require more than one comparison



Application Programming Issues

• Unicode SQL parser

• Program Preparation

• Functions, Routines, Stored Procedures

• DBRMs & SYSIBM.SYSSTMT & SYSIBM.SYSPACKSTMT



Program Preparation



Your DB2 Technical Evangelists…..

�Bill Schneweis [email protected] (316) 266-7025

�Kevin Harrison [email protected] (816) 556-6770

�Our Mission

� Facilitate DB2 Version migrations

� Enable customers for V6-V7 and V7-V8

�Technical Assistance

�Planning

�Migration Strategy



�DB2 for z/OS Version 8 Technical Preview (SG24-6871-00)

This IBM Redbook introduces the major changes and enhancements

made available with DB2 V8.

�DB2 UDB for z/OS Version 8: Everything You Ever Wanted to Know, …and

More (SG24-6079-00)

�This IBM Redbook will help you understand the functions offered by DB2 V8, and

provides information to help you to evaluate their applicability to your environment.

�A massive publication……….1,066 pages.

•DB2 UDB for z/OS V8: Through the Looking Glass & What SAP

Found There, SG24-7088

DB2 Redbooks - 2Q 2004 http://www.ibm.com/redbooks



Reference URLs

ibm.com/software/db2zos DB2 for z/OS

ibm.com/software/db2zos/db2zosv8.html V8

ibm.com/software/db2zos/support.html Support

ibm.com/software/data/db2imstools/ Tools

ibm.com/developerworks/db2 Applications

ftp site for papers, presentations:

ftp://ftp.software.ibm.com/software/db2storedprocedure/db2zos390/techdocs

/

Customer sample library & Trading post

http://www-306.ibm.com/software/data/db2/zos/exHome.html

Unicode: http://www-06.ibm.com/developerworks/library/whyunicode.html

db2® for z/os version 8 sql enhancements overview colorado

Documents

zos db2

ibm corporation

zos version

iteration db2

array2 atomic db2

recursive sql statement

n rows form

hv rows values