DB2 9 for z/OS: For Developers Only! Craig S. Mullins Corporate Technologist NEON Enterprise Software, Inc.
Authors <ul><li>This presentation was prepared by: </li></ul><ul><li>Craig S. Mullins Corporate Technologist </li></ul><ul...
Agenda <ul><li>DB2 9 for z/OS Overview </li></ul><ul><li>DB2 9 SQL Changes </li></ul><ul><li>Other DB2 9 Developer “Things...
DB2 9 for z/OS <ul><li>General Availability: March 2007 </li></ul><ul><li>DB2 9 – where’s the “V”? </li></ul><ul><li>V8 wa...
Multi-row INSERT, FETCH & multi-row cursor UPDATE, Dynamic Scrollable Cursors, GET DIAGNOSTICS, Enhanced UNICODE for SQL, ...
Multi-row INSERT, FETCH & multi-row cursor UPDATE, Dynamic Scrollable Cursors, GET DIAGNOSTICS, Enhanced UNICODE for SQL, ...
Multi-row INSERT, FETCH & multi-row cursor UPDATE, Dynamic Scrollable Cursors, GET DIAGNOSTICS, Enhanced UNICODE for SQL, ...
DB2 9 New SQL Stuff <ul><li>MERGE </li></ul><ul><li>TRUNCATE </li></ul><ul><li>SELECT FROM  UPDATE, DELETE, MERGE </li></u...
New SQL Statement: MERGE <ul><li>Have you ever had a program requirement to accept input, either from a file or online, an...
MERGE <ul><li>MERGE combines UPDATE and INSERT into a single SQL statement </li></ul><ul><ul><li>When source row matches t...
MERGE Syntax <ul><li>MERGE INTO   table_name   </li></ul><ul><li>USING   table_name   </li></ul><ul><li>ON  ( condition ) ...
MERGE Example <ul><li>MERGE INTO CUST C </li></ul><ul><li>USING VALUES  </li></ul><ul><li>((:CUSTNO, :CUSTNAME, :CUSTDESC)...
What Happens if we MERGE?  Target Table Source Table CEO Stacy 52 Foreman Bill 40 Boss George 35 Admin Sally 20 Clerk Joe ...
MERGE Results Target Table CEO Stacey 52 Foreman Bill 40 Boss George 35 Driver Vincent 30 Manager Sally 20 Clerk Joe 10 De...
New SQL Statement: TRUNCATE <ul><li>The TRUNCATE statement is simply a quick way to DELETE  all  of the data from a table....
TRUNCATE Example <ul><li>TRUNCATE TABLE EXAMPLE_TABLE  </li></ul><ul><li>REUSE STORAGE  </li></ul><ul><li>IGNORE DELETE TR...
TRUNCATE Considerations <ul><li>TRUNCATE can delete all data without actually processing each physical page as long as the...
New SQL: SELECT FROM DELETE, UPDATE, MERGE <ul><li>What if you need to read automatically generated data? For example:  </...
First, a V8 Refresher: SELECT FROM INSERT <ul><li>SELECT FROM INSERT, introduced in DB2 V8 allows you to both insert the r...
V9 Adds DELETE, UPDATE, and MERGE Support <ul><li>DB2 V9 allows the FROM clause of a SELECT statement †  to contain a sear...
An Example: SELECT FROM UPDATE <ul><li>SELECT SUM(SALARY) INTO :SAL-HV FROM FINAL_TABLE  (UPDATE EMP   SET SALARY = SALARY...
INCLUDE: SELECT FROM MERGE <ul><li>And because you might want to know which rows were updated and which were inserted, you...
Set Operations: INTERSECT, EXCEPT, and UNION INTERSECT is used to match result sets between two tables. If the  data is th...
INTERSECT Example <ul><li>For example, the following SQL will show all customers in the USA who are also employees (with n...
EXCEPT Example <ul><li>The following SQL will return only those items sold in March that were not also sold in April:   SE...
INTERSECT and EXCEPT Considerations <ul><li>The SELECT-lists must be UNION compatible. That is, they must have the same nu...
New Type of Trigger: INSTEAD OF  <ul><li>INSTEAD OF triggers can only be defined on VIEWs. </li></ul><ul><li>INSTEAD OF tr...
INSTEAD OF Trigger Example (The View) <ul><li>Let’s take a look at an example to better understand the INSTEAD OF trigger....
INSTEAD OF Trigger Example (Triggers #1) <ul><li>Since this view is a join, it is not updateable. We can now remedy this b...
INSTEAD OF Trigger Example (Triggers #2) <ul><li>Next we’ll consider updates: </li></ul>CREATE TRIGGER E_D_UPD INSTEAD OF ...
INSTEAD OF Trigger Example (Triggers #3) <ul><li>Finally we take care of deletions: </li></ul>CREATE TRIGGER E_D_DEL INSTE...
INSTEAD OF Trigger Considerations - 1 <ul><li>The view must exist at the current server and none of the following are perm...
INSTEAD OF Trigger Considerations - 2 <ul><li>Using an INSTEAD OF trigger, each requested modification operation made agai...
Native SQL Procedure Language Improvements <ul><li>Native SQL stored procedures contain only SQL procedure language (PL) s...
Reoptimization <ul><li>You can gain additional optimization for  dynamic SQL  using the REOPT parameter of the BIND comman...
REOPT Enhancements <ul><li>REOPT (NONE)  –PREPARE determines the access path and no reoptimization is performed. The bound...
REOPT Applicability: Dynamic vs. Static SQL Consider binding  static  programs with REOPT(ALWAYS) when the values for your...
Histogram Statistics <ul><li>A histogram is a way of summarizing data that is measured on an interval scale  ( for large d...
PLANMGMT: Plan Stability <ul><li>Plan stability, which works on packages only, allows you to keep backups versions of your...
PLANMGMT BIND Options <ul><li>PLANMGMT(OFF)  - No change to existing behavior. A package continues to have one active copy...
The Ol’ Switcheroo <ul><li>SWITCH (PREVIOUS)  - changes the current and previous packages: </li></ul><ul><ul><li>The exist...
LOB Improvements #1 <ul><li>LOB File Reference Variable </li></ul><ul><ul><li>A host variable defined in a host language t...
LOB Improvements #2 – FETCH CONTINUE <ul><li>Prior to Version 9, there were two methods you could deploy in your programs ...
LOB Improvements #2 – FETCH CONTINUE <ul><li>DB2 9: FETCH CONTINUE </li></ul><ul><ul><li>Can retrieve LOB columns in multi...
FETCH FIRST and ORDER BY in Subselect <ul><li>First, some basic education… The SELECT statement is broken down into three ...
Think of it this way… <ul><li>In a subselect you specify the FROM to get the tables, the WHERE to get the conditions, GROU...
The Pre-9 Problem <ul><li>In DB2 V8, the ORDER BY and FETCH FIRST n ROWS ONLY clauses are only allowed at the statement le...
The DB2 9 Solution <ul><li>Allow  FETCH FIRST  and  ORDER BY  in a subselect, for example: </li></ul><ul><li>SELECT T1.EMP...
Index on Expressions <ul><li>DB2 9 extends the CREATE INDEX statement to index expressions instead of just columns.  </li>...
Index on Expressions - Restrictions <ul><li>Each expression  must contain as least one reference to a column  of the table...
Index on Expressions - Examples <ul><li>CREATE INDEX XUPLN </li></ul><ul><li>ON EMP </li></ul><ul><li>(UPPER(LAST_NAME)) <...
New Built-in Functions – Char/String Functions <ul><li>ASCII_CHR  - returns the character that has the ASCII code value th...
New Built-in Functions – String manipulation <ul><li>LPAD  - returns a string that is padded on the left, with blanks (or ...
New Built-in Functions – “Similar Sounding” <ul><li>SOUNDEX  - returns a 4 character code that represents the sound of the...
New Built-in Functions – Date/Time <ul><li>EXTRACT  - returns a portion of a date or timestamp. You can use EXTRACT to sli...
New Built-in Functions - Timestamp <ul><li>TIMESTAMPADD  - adds an interval to a timestamp. </li></ul><ul><li>TIMESTAMPDIF...
Other New Built-in Functions <ul><li>RID  - returns the RID of a row </li></ul><ul><li>CORRELATION  - returns the coeffici...
OLAP Functions: RANK <ul><li>SELECT EMPNO, LASTNAME, FIRSTNAME,  </li></ul><ul><li>SALARY+BONUS+COMM AS TOTAL_COMP,  </li>...
OLAP Functions: RANK <ul><li>OK, what did that query do? </li></ul>300 ABBOTT RANDY 1000000 1 500 GREEN RACHEL   47000 3 1...
OLAP Functions: DENSE_RANK <ul><li>Both ABBOTT and MULLINS earn the most, but the amount is the same, so they share the nu...
OLAP Functions – ROW_NUMBER <ul><li>SELECT ROW_NUMBER() OVER(ORDER BY WORKDEPT,    LASTNAME) AS NUMBER, LASTNAME, SALARY  ...
Skipping Locked Data <ul><li>In DB2 9 it is possible to set up your SQL to skip over pages or rows that are locked.  </li>...
OK, How Do You Skip Locked Data? <ul><li>SKIP LOCKED DATA  – can be specified on: </li></ul><ul><ul><li>SELECT </li></ul><...
For Example Locked Locked SELECT COUNT (*)  FROM  EMP  WHERE COMM = 0  SKIP LOCKED DATA; 2 SELECT COUNT (*)  FROM  EMP  SK...
Optimistic Locking <ul><li>What is optimistic locking?  </li></ul><ul><ul><li>We are optimists and think that usually we w...
Optimistic Locking and ROW CHANGE TIMESTAMP <ul><li>For programs that use updateable static scrollable cursors, DB2 can us...
ROW CHANGE TIMESTAMP <ul><li>The ROW CHANGE TIMESTAMP can be used to find out when table rows were modified. For example: ...
Using the ROW CHANGE TIMESTAMP <ul><li>To find all of the customer rows that were changed in the past week (ie. the last 7...
ALTER and ROW CHANGE TIMESTAMP <ul><li>But what would happen if you issued a statement like on the previous slide, but aga...
New Data Type: BIGINT <ul><li>BIGINT  is an exact numeric data type capable of representing 63-bit integers. This is the t...
New Data Types: Binary Data <ul><li>BINARY  and  VARBINARY  data types extend current support of binary strings and are co...
New Data Type: DECFLOAT <ul><li>DECFLOAT  takes advantage of new System z9 hardware support delivering a data type that le...
Additional DECFLOAT Considerations <ul><li>The DECFLOAT data type is able to represent the following named special values ...
pureXML <ul><li>And finally, we get pureXML support to store XML as a native data type in DB2.  </li></ul><ul><ul><li>That...
Before we go… <ul><li>Plans and packages that were bound before DB2 V4 will be automatically rebound when first accessed b...
Summary <ul><li>DB2 9 for z/OS offers a wealth of new things and stuff for DB2 application developers. </li></ul><ul><ul><...
Craig S. Mullins <ul><li>NEON Enterprise Software </li></ul><ul><li>[email_address] </li></ul><ul><li>www.neonesoft.com </...
Upcoming SlideShare
Loading in …5
×

DB2 9 for z/OS: For Developers only!

3,293 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,293
On SlideShare
0
From Embeds
0
Number of Embeds
505
Actions
Shares
0
Downloads
62
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • These are the bullets from the abstract: * What are the Regulations? * Compliance Issues * IT Controls * Long-term Data Retention * Database Auditing * Additional DBA Concerns
  • This text just shows the relationship of DB2 for Linux, Unix &amp; Windows with DB2 for z/OS, comparing the z/OS Version 8 from March 2004 with the LUW version from October 2004. There are three sets of SQL noted above, with some that is unique to DB2 for z/OS in the first group, SQL that is common across DB2 for Linux, Unix, Windows and z/OS in the large group in the middle, then SQL that is unique to DB2 for Linux, Unix and Windows in the bottom group. Sheryl Larsen provided the base for this information, but the mistakes are probably mine. If you want to improve DB2 family consistency, then DB2 for z/OS Version 8 is a big step, changing the game from one of catch up to one of leapfrog.
  • This text just shows the relationship of DB2 for Linux, Unix &amp; Windows with DB2 for z/OS. This step in the process is DB2 9 for z/OS. DB2 9 moves about half of the LUW unique items into the common set and adds a little more that is unique to the z platform. At about this time we’ll also have a new release of DB2 9 for LUW, code named Viper. We are able to move more from the z list to the common list with Viper. There are three sets of SQL noted above, with some that is unique to DB2 for z/OS in the first group, SQL that is common across DB2 for Linux, Unix, Windows and z/OS in the large group in the middle, then SQL that is unique to DB2 for Linux, Unix and Windows in the bottom group. Sheryl Larsen provided the base for this information, but the mistakes are probably mine.
  • This text just shows the newest delivered relationship of DB2 for Linux, Unix &amp; Windows with DB2 for z/OS. This step in the process is DB2 9 for z/OS, (DB2 9). DB2 9 moves about half of the LUW unique items into the common set and adds a little more that is unique to the z platform. DB2 9.5 for LUW, code named Viper 2 is already generally available. We are able to move more from the unique z list to the common list with DB2 9 for luw. There are three sets of SQL noted above, with some that is unique to DB2 for z/OS in the first group, SQL that is common across DB2 for Linux, Unix, Windows and z/OS in the large group in the middle, then SQL that is unique to DB2 for Linux, Unix and Windows in the bottom group. The changes in a specific version are not consistent. As we introduce new function, sometimes it will be on one platform first, but movement from unique lists into the common list continues to be the strongest trend.
  • Seems easy enough, doesn’t it? But what are those additional parameters? Well, REUSE STORAGE tells DB2 to empty the storage that is allocated but keeps it allocated. The alternate, which is the default, is DROP STORAGE. This option tells DB2 to release the storage that is allocated for the table and to make it available for use for the same table or any other table in the table space. REUSE STORAGE is ignored for a table in a simple table space and the statement is processed as if DROP STORAGE is specified. The next parameter, which is the default if nothing is specified, is IGNORE DELETE TRIGGERS. This tells DB2 to not fire any DELETE triggers. Alternately, you could specify RESTRICT WHEN DELETE TRIGGERS, which will return an error if there are any delete triggers defined on the table. Finally, we have the IMMEDIATE option. This causes the TRUNCATE to be immediately executed and it cannot be undone. If IMMEDIATE is not specified you can issue a ROLLBACK to undo the TRUNCATE.
  • In the example, the data is inserted as specified in the VALUES clause, and retrieved as specified in the SELECT. Without the ability to select COL5, the program would have no knowledge of the value supplied to COL5, because it was assigned using CURRENT DATE. With this new syntax the program can retrieve the CURRENT DATE value that was just inserted into COL5 without incurring additional overhead.
  • In DB2 9, you can retrieve columns from rows that are modified via DELETE, UPDATE, and MERGE statements, thereby replacing multiple SQL calls with one. DB2 9 allows a searched UPDATE or a searched DELETE statement in the FROM clause of a SELECT statement that is a subselect, or in the SELECT INTO statement. This capability allows a user or program to know which values were updated or deleted. And, recall the new MERGE statement we just covered. Well, DB2 9 also adds the ability to SELECT from a MERGE. This allows you to return all the rows that were either inserted or updated as a result of the MERGE.
  • An insert against the view would not be inserting a new department, so we will be inserting data into the EMP table. If the department does not exist, we’ll raise an error.
  • You have to drop and re-create native stored procedures after moving to DB2 9 to take advantage of the changes.
  • NOREOPT(VARS) can be specified as a synonym of REOPT(NONE). REOPT(VARS) can be specified as a synonym for REOPT(ALWAYS).
  • Consider binding static programs with REOPT(ALWAYS) when the values for your program’s host variables or special registers are volatile and make a significant difference for access paths. This means that these statements get compiled at the time of EXECUTE or OPEN instead of at BIND time. During this compilation, the access plan is chosen, based on the real values of these variables.
  • DB2 V9 provides the ability to gather histogram statistics. A histogram is a way of summarizing data that is measured on an interval scale. A histogram is particularly helpful to quickly highlight how data is distributed; to determine if data is symmetrical or skewed; and to indicate whether or not outliers exists. The histogram is only appropriate for variables whose values are numerical and measured on an interval scale. It is generally used when dealing with large data sets. Histogram statistics can be quite useful to the optimizer for certain types of queries. Instead of the frequency statistics, which are collected for only a subset of the data, sometimes DB2 can improve access path selection by estimating predicate selectivity from histogram statistics, which are collected over all values in a table space. Consider collecting histogram statistics to improve access paths for troublesome queries with RANGE, LIKE, and BETWEEN predicates. They can also help in some cases for =, IS NULL, IN LIST and COL op COL predicates. The histogram statistics are collected in three new columns: QUANTILENO, LOWVALUE, and HIGHVALUE. These columns can be found in the following six DB2 Catalog tables: SYSIBM.SYSCOLDIST SYSIBM.SYSKEYTGTDIST SYSIBM.SYSCOLDIST_HIST SYSIBM.SYSCOLDISTSTATS SYSIBM.SYSKEYTGTDIST_HIST SYSIBM.SYSKEYTGTDISTSTATS. Here is an example of a RUNSTATS to gather histogram statistics for the key columns of the indexes. RUNSTATS TABLESPACE DB07.CSMTS02 INDEX ALL HISTOGRAM NUMCOLS 2 NUMQUANTILES 10 SHRLEVEL(CHANGE) UPDATE ALL REPORT YES
  • A file reference variable is a host variable that is defined in a host language to contain the file name that directs file input and output for a large object (LOB). Using file reference variables, large LOB values can be inserted from a file or selected into a file rather than a host variable. This means that your application program does not need to acquire storage to contain the LOB value. File reference variables also enable you to move LOB values from the DBMS to a client application or from a client application to a database server without going through the working storage of the client application.
  • V9 introduces a new clause, WITH CONTINUE, for use on your FETCH statements. By coding your program to use WITH CONTINUE you can retrieve LOB columns in multiple pieces without using a LOB locator, and continue a FETCH operation to retrieve the remaining LOB data when truncation occurs. (Note: this method can be used with XML data, too.) You will have to manage the buffers and reassemble the pieces of data in your application program. So, by specifying WITH CONTINUE on your FETCH statement you tell DB2 to allow subsequent FETCH CURRENT CONTINUE operations. These will allow you to access the remaining truncated LOB (or XML) column after the initial FETCH. If truncation occurs, DB2 will remember the truncation position and will not discard the remaining data. DB2 will return the total length that would have been required to hold all of the data of the LOB or XML column. This will either be in the first four bytes of the LOB host variable structure or in the 4 byte area that is pointed to by the SQLDATALEN pointer in the SQLVAR entry of the SQLDA for that host variable.
  • View with an inappropriate ORDER BY or FETCH FIRST will raise a -20211 or -104
  • So, what new function functionality do we get with DB2 9 for z/OS? First of all, we get some new ASCII and EBCDIC conversion functions. The ASCII_CHR function returns the character that has the ASCII code value that is specified by the argument.; and the ASCII_STR function returns a string, in the system ASCII CCSID that is an ASCII version of the string. Knowing that, I bet you can guess what EBCDIC_CHR and EBCDIC_STR do.
  • The results returned by the query would be: &apos;PLACEMENT &apos; (starting at position 4 overlay 4 bytes with 5 bytes &apos;CEMEN&apos;) &apos;INSISTING&apos; (starting at position 4 overlay 2 bytes with &apos;IS&apos;)
  • The SOUNDEX function returns a 4 character code that represents the sound of the words in the argument. The result can be used to compare with the sound of other strings. The data type of the result is CHAR(4). So what does this mean? Consider the following example: SELECT LASTNAME FROM DSN910.EMP WHERE SOUNDEX(LASTNAME) = SOUNDEX(’Smith’); This query would return not only employees with a last name of “Smith,” but also anything that sounds like Smith, such as Smythe. The DIFFERENCE function is related to SOUNDEX. It returns a value from 0 to 4 where the number represents the difference between the sounds of two strings based on applying the SOUNDEX function to the strings. The higher the value, the closer the two strings are to sounding alike. Consider: SELECT DIFFERENCE(’CONSTRAINT’,’CONSTANT’), SOUNDEX(’CONSTRAINT’), SOUNDEX(’CONSTANT’) FROM SYSIBM.SYSDUMMY1; This example returns the values 4, C523, and C523. Since the two strings return the same SOUNDEX value, the difference is 4 (the highest value possible). The more different-sounding the two strings are, the smaller the number would be.
  • Another interesting series of BIFs are focused on date and time data. These functions include EXTRACT, MONTHS_BETWEEN, and various new timestamp-related functions. EXTRACT returns a portion of a date or timestamp. You can use EXTRACT to slice up a date/time value into its component pieces. Consider: SELECT BIRTHDATE, EXTRACT (DAY FROM BIRTHDATE) AS DAY, EXTRACT (MONTH FROM BIRTHDATE) AS MONTH, EXTRACT (YEAR FROM BIRTHDATE) AS YEAR FROM DSN8910.EMP; This query would return the entire date, along with each component (year, month, day) of the date as a separate column. You can use one function (EXTRACT) to do the job of the already-existing YEAR, MONTH, and DAY functions. Of course, YEAR, MONTH, and DAY are still available for your use. Similar functionality for EXTRACT exists for time components using HOUR, MINUTE, and SECOND. The next temporal BIF introduced with DB2 9 for z/OS is the MONTHS_BETWEEN function. It returns an estimate of the number of months between two expressions. If the first expression represents a date that is later than the second, the result will be positive; if the opposite is true the result will be negative. The result is calculated based on a 31 day month. For example, consider this statement: SELECT MONTHS_BETWEEN (&apos;2007-02-20&apos;,&apos;2007-01-17&apos;) AS MONTHS_BETWEEN FROM SYSIBM.SYSDUMMY1; The result of this query would be 1.096774193548387. We also get four new timestamp-related BIFs: TIMESTAMPADD, TIMESTAMPDIFF, TIMESTAMP_FORMAT, and TIMESTAMP_ISO. The first two are rather straightforward: TIMESTAMPADD adds an interval to a timestamp and TIMESTAMPDIFF subtracts two timestamps and returns an interval. I will not get into a discussion of date/time arithmetic here, but if you are interested check out my article on that topic here (Q+As on Dates and DB2 - http://www.dbazine.com/db2/db2-mfarticles/mullins-qa ). What about the other two timestamp-related BIFs? TIMESTAMP_FORMAT offers the much-needed ability to choose different display formats for a timestamp value. The valid formats that can be specified are: ‘ YYYY-MM-DD’ ‘ YYYY-MM-DD-HH24-MI-SS’ ‘ YYYY-MM-DD-HH24-MI-SS-NNNNNN’ And instead of using the dash ( - ) as the separator, you can also use . / , : ; and blank. These separators can be used in any combination. And the VARCHAR_FORMAT function returns a character representation of a timestamp in a format specified as above. So, consider the following query: SELECT SUBSTR(NAME,1,8) AS TSNAME, VARCHAR_FORMAT(CREATEDTS,&apos;YYYY-MM-DD-HH24:MI:SS&apos;) AS TSCR FROM SYSIBM.SYSTABLESPACE; WHERE CREATEDTS &gt;= TIMESTAMP_FORMAT(&apos;2007-01-01 00:00:00&apos;,&apos;YYYY-MM-DD HH24:MI:SS&apos;); This query will return the name of all table spaces created since the first of the year, along with its creation timestamp using the format specified.
  • SELECT SUBSTR(NAME,1,8) AS TSNAME, VARCHAR_FORMAT(CREATEDTS,&apos;YYYY-MM-DD-HH24:MI:SS&apos;) AS TSCR FROM SYSIBM.SYSTABLESPACE; WHERE CREATEDTS &gt;= TIMESTAMP_FORMAT(&apos;2007-01-01 00:00:00&apos;,&apos;YYYY-MM-DD HH24:MI:SS&apos;);
  • This query will rank employees who have total compensation greater than $30,000, but order the results by last name. This allows you to rank data differently than the order in which it is presented.
  • The result of a RANK, DENSE_RANK, and ROW_NUMBER specification is BIGINT, and the result cannot be null.
  • In DB2 9 it is possible for a transaction to skip over rows that are locked. This can be accomplished by means of the SKIP LOCKED DATA option within your SQL statement(s). SKIP LOCKED DATA can be specified in SELECT, SELECT INTO, and PREPARE, as well as searched UPDATE and DELETE statements. You can also use the SKIP LOCKED DATA option with the UNLOAD utility. Of course, if a program skips over locked data then that data is not accessed and the program will not have it available. When this option is used DB2 will just skip over any locked data instead of waiting for it to be unlocked. The benefit, of course, is improved performance because you will not incur any lock wait time. But it comes at the cost of not accessing the locked data at all. This means that you should only utilize this clause when your program can tolerate skipping over some data. The SKIP LOCKED DATA option is compatible with cursor stability (CS) isolation and read stability (RS) isolation. But it cannot be used with uncommitted read (UR) or repeatable read (RR) isolation levels. DB2 will simply ignore the SKIP LOCKED DATA clause under UR and RR isolation levels. Additionally, SKIP LOCKED DATA works only with row locks and page locks. That means that SKIP LOCKED DATA does not apply to table, partition, LOB, XML, or table space locks.
  • SKIP LOCKED DATA works only with row locks and page locks. That means that SKIP LOCKED DATA does not apply to table, partition, LOB, XML, or table space locks. Let&apos;s look at an example. Suppose we have a table with 5 rows in it. Assume row level locking. Next assume that an UPDATE statement is run against the table changing COMM to 500 WHERE BONUS = 0. And it is hanging out there without a COMMIT. Next, we run: SELECT COUNT (*) FROM EMP WHERE COMM = 0 SKIP LOCKED DATA; The count returned would be 2 because DB2 skips the two locked rows. Of course, when the locks are released the data will be able to be read again.
  • DB2 Version 9 improves support for coding optimistic locking techniques. What is optimistic locking? Sometimes referred to as optimistic concurrency control, optimistic locking is basically just what it sounds like. We are optimists and think that usually we will be the only ones with interest in the data. In other words, when optimistic locking is implemented you are assuming that most of the time there will be no other programs that are interested in the page of data that you are planning to modify. Of course, even in the most optimistic world there will be exceptions, so optimistic locking does not assume that there will never be any concurrent processes that need to access your page(s). Basically, with optimistic locking you can improve performance by minimizing locking. So how do we do that?
  • OK, this is all well and good, and you can probably see the value of having this automagically changing timestamp in some of your tables, but where is the optimistic locking part? Well, for programs that use updateable static scrollable cursors DB2 can use optimistic locking as long as the plan/package is bound specifying ISOLATION(CS). If you have this situation, DB2 will deploy optimistic locking to reduce the duration of locks between consecutive FETCH operations and between fetch operations and subsequent positioned UPDATE or DELETE operations. Remember, though, DB2 cannot use optimistic concurrency control for dynamic scrollable cursors. With dynamic scrollable cursors, the most recently fetched row or page from the base table remains locked to maintain position for a positioned UPDATE or DELETE.
  • So when you have the need to store very large integers you don’t have to use DECIMAL with a zero scale any longer.
  • Two binary strings are equal only if the lengths are identical. If two strings are equal up to the length of the shorter string length, the shorter string is considered less than the longer string, even when the remaining bytes in the longer string are hex zeros.
  • DB2 V3 was released for GA in December 1993 DB2 V4 was released for GA in November 1995
  • DB2 9 for z/OS: For Developers only!

    1. 1. DB2 9 for z/OS: For Developers Only! Craig S. Mullins Corporate Technologist NEON Enterprise Software, Inc.
    2. 2. Authors <ul><li>This presentation was prepared by: </li></ul><ul><li>Craig S. Mullins Corporate Technologist </li></ul><ul><li>NEON Enterprise Software, Inc. </li></ul><ul><li>14100 Southwest Freeway, Suite 400 </li></ul><ul><li>Sugar Land, TX 77478 </li></ul><ul><li>Tel: 281.491.6366 </li></ul><ul><li>Fax: 281.207.4973 </li></ul><ul><li>E-mail: craig.mullins@neonesoft.com </li></ul><ul><li>This document is protected under the copyright laws of the United States and other countries as an unpublished work. This document contains information that is proprietary and confidential to NEON Enterprise Software, which shall not be disclosed outside or duplicated, used, or disclosed in whole or in part for any purpose other than to evaluate NEON Enterprise Software products. Any use or disclosure in whole or in part of this information without the express written permission of NEON Enterprise Software is prohibited. © 2006 NEON Enterprise Software (Unpublished). All rights reserved. </li></ul>
    3. 3. Agenda <ul><li>DB2 9 for z/OS Overview </li></ul><ul><li>DB2 9 SQL Changes </li></ul><ul><li>Other DB2 9 Developer “Things and Stuff” </li></ul>
    4. 4. DB2 9 for z/OS <ul><li>General Availability: March 2007 </li></ul><ul><li>DB2 9 – where’s the “V”? </li></ul><ul><li>V8 was large… sometimes painful </li></ul><ul><li>DB2 9 nowhere near as intimidating </li></ul><ul><li>But it offers some nice new development “things” and “stuff” </li></ul>
    5. 5. Multi-row INSERT, FETCH & multi-row cursor UPDATE, Dynamic Scrollable Cursors, GET DIAGNOSTICS, Enhanced UNICODE for SQL, join across encoding schemes, IS NOT DISTINCT FROM, Session variables, range partitioning Inner and Outer Joins, Table Expressions, Subqueries, GROUP BY, Complex Correlation, Global Temporary Tables, CASE, 100+ Built-in Functions including SQL/XML, Limited Fetch, Insensitive Scroll Cursors, UNION Everywhere, MIN/MAX Single Index Support, Self Referencing Updates with Subqueries, Sort Avoidance for ORDER BY, and Row Expressions, 2M Statement Length, GROUP BY Expression, Sequences, Scalar Fullselect, Materialized Query Tables, Common Table Expressions, Recursive SQL, CURRENT PACKAGE PATH, VOLATILE Tables, Star Join Sparse Index, Qualified Column names, Multiple DISTINCT clauses, ON COMMIT DROP, Transparent ROWID Column, Call from trigger, statement isolation, FOR READ ONLY KEEP UPDATE LOCKS, SET CURRENT SCHEMA, Client special registers, long SQL object names, SELECT from INSERT Updateable UNION in Views, ORDER BY/FETCH FIRST in subselects & table expressions, GROUPING SETS, ROLLUP, CUBE, INSTEAD OF TRIGGER, EXCEPT, INTERSECT, 16 Built-in Functions, MERGE, Native SQL Procedure Language, SET CURRENT ISOLATION, BIGINT data type, file reference variables, SELECT FROM UPDATE or DELETE, multi-site join, MDC z L U W c o m m o n SQL Compatibility: DB2 z V8 / DB2 LUW V8.2
    6. 6. Multi-row INSERT, FETCH & multi-row cursor UPDATE, Dynamic Scrollable Cursors, GET DIAGNOSTICS, Enhanced UNICODE for SQL, join across encoding schemes, IS NOT DISTINCT FROM, Session variables, TRUNCATE, DECIMAL FLOAT, VARBINARY, optimistic locking, FETCH CONTINUE, ROLE, MERGE, SELECT from MERGE Inner and Outer Joins, Table Expressions, Subqueries, GROUP BY, Complex Correlation, Global Temporary Tables, CASE, 100+ Built-in Functions including SQL/XML, Limited Fetch, Insensitive Scroll Cursors, UNION Everywhere, MIN/MAX Single Index Support, Self Referencing Updates with Subqueries, Sort Avoidance for ORDER BY, and Row Expressions, 2M Statement Length, GROUP BY Expression, Sequences, Scalar Fullselect, Materialized Query Tables, Common Table Expressions, Recursive SQL, CURRENT PACKAGE PATH, VOLATILE Tables, Star Join Sparse Index, Qualified Column names, Multiple DISTINCT clauses, ON COMMIT DROP, Transparent ROWID Column, Call from trigger, statement isolation, FOR READ ONLY KEEP UPDATE LOCKS, SET CURRENT SCHEMA, Client special registers, long SQL object names, SELECT from INSERT, UPDATE or DELETE, INSTEAD OF TRIGGER, Native SQL Procedure Language, BIGINT, file reference variables, XML, FETCH FIRST & ORDER BY in subselect and fullselect, caseless comparisons, INTERSECT, EXCEPT, not logged tables, OmniFind, Spatial, range partitioning, compression Updateable UNION in Views, GROUPING SETS, ROLLUP, CUBE, 16 Built-in Functions, SET CURRENT ISOLATION, multi-site join, MERGE, MDC, XQuery z L U W c o m m o n SQL Compatibility: DB2 9 – z vs. LUW
    7. 7. Multi-row INSERT, FETCH & multi-row cursor UPDATE, Dynamic Scrollable Cursors, GET DIAGNOSTICS, Enhanced UNICODE for SQL, join across encoding schemes, IS NOT DISTINCT FROM, TRUNCATE, VARBINARY, FETCH CONTINUE, MERGE, SELECT from MERGE, index compression Inner and Outer Joins, Table Expressions, Subqueries, GROUP BY, Complex Correlation, Global Temporary Tables, CASE, 100+ Built-in Functions including SQL/XML, Limited Fetch, Insensitive Scroll Cursors, UNION Everywhere, MIN/MAX Single Index, Self Referencing Updates with Subqueries, Sort Avoidance for ORDER BY, and Row Expressions, 2M Statement Length, GROUP BY Expression, Sequences, Scalar Fullselect, Materialized Query Tables, Common Table Expressions, Recursive SQL, CURRENT PACKAGE PATH, VOLATILE Tables, Star Join Sparse Index, Qualified Column names, Multiple DISTINCT clauses, ON COMMIT DROP, Transparent ROWID Column, Call from trigger, statement isolation, FOR READ ONLY KEEP UPDATE LOCKS, SET CURRENT SCHEMA, Client special registers, long SQL object names, SELECT from INSERT, UPDATE or DELETE, INSTEAD OF TRIGGER, Native SQL Procedure Language, BIGINT, file reference variables, XML, FETCH FIRST & ORDER BY in subselect & fullselect, caseless comparisons, INTERSECT, EXCEPT, not logged tables, OmniFind, spatial, range partitions, data compression, session variables, DECIMAL FLOAT, optimistic locking, ROLE Updateable UNION in Views, GROUPING SETS, ROLLUP, CUBE, more Built-in Functions, SET CURRENT ISOLATION, multi-site join, MERGE, MDC, XQuery, XML enhancements, array data type, global variables, Oracle syntax z l u w c o m m o n SQL Compatibility: DB2 9 – z vs. DB2 9.5 LUW
    8. 8. DB2 9 New SQL Stuff <ul><li>MERGE </li></ul><ul><li>TRUNCATE </li></ul><ul><li>SELECT FROM UPDATE, DELETE, MERGE </li></ul><ul><li>INTERSECT </li></ul><ul><li>EXCEPT </li></ul><ul><li>INSTEAD OF TRIGGER </li></ul><ul><li>Native SQL Procedure Language </li></ul><ul><li>REOPT Enhancements </li></ul><ul><li>Histogram statistics </li></ul>PLAN Management LOB Improvements FETCH FIRST and ORDER BY in subselect and fullselect Index on expressions New built-in functions Skip Locked Data Optimistic Locking New Data Types XML
    9. 9. New SQL Statement: MERGE <ul><li>Have you ever had a program requirement to accept input, either from a file or online, and take the following action(s): </li></ul><ul><ul><li>If the data is not in the database, INSERT it </li></ul></ul><ul><ul><li>If the data is in the database, UPDATE the existing row with any new values provided </li></ul></ul><ul><li>A common requirement is to present data using a spreadsheet metaphor, where rows can be inserted or modified on the screen. </li></ul>
    10. 10. MERGE <ul><li>MERGE combines UPDATE and INSERT into a single SQL statement </li></ul><ul><ul><li>When source row matches target, the target row is updated </li></ul></ul><ul><ul><li>When source row does not match, the source row is inserted into the target </li></ul></ul>
    11. 11. MERGE Syntax <ul><li>MERGE INTO table_name </li></ul><ul><li>USING table_name </li></ul><ul><li>ON ( condition ) </li></ul><ul><li>WHEN MATCHED THEN </li></ul><ul><li>UPDATE SET column1 = value1 [, column2 = value2 ... ] </li></ul><ul><li>WHEN NOT MATCHED </li></ul><ul><li>THEN INSERT column1 [, column2 ... ] VALUES ( value1 [, value2 ... ]) ; </li></ul>
    12. 12. MERGE Example <ul><li>MERGE INTO CUST C </li></ul><ul><li>USING VALUES </li></ul><ul><li>((:CUSTNO, :CUSTNAME, :CUSTDESC) </li></ul><ul><li>FOR :HV_NROWS ROWS) AS NEW (CUSTNO, NAME, DESC) </li></ul><ul><li>ON (C.CUSTNO = NEW.CUSTNO) </li></ul><ul><li>WHEN MATCHED THEN UPDATE </li></ul><ul><li>SET (C.NAME, C.DESC) = (NEW.NAME, NEW.DESC) </li></ul><ul><li>WHEN NOT MATCHED THEN INSERT (CUSTNO, NAME, DESC) </li></ul><ul><li>VALUES (NEW.CUSTNO, NEW.NAME, NEW.DESC) </li></ul><ul><li>NOT ATOMIC CONTINUE ON SQL EXCEPTION; </li></ul>Target Table Source Table
    13. 13. What Happens if we MERGE? Target Table Source Table CEO Stacy 52 Foreman Bill 40 Boss George 35 Admin Sally 20 Clerk Joe 10 Desc Name No CEO Stacey 52 Driver Vincent 30 Manager Sally 20 Desc Name No
    14. 14. MERGE Results Target Table CEO Stacey 52 Foreman Bill 40 Boss George 35 Driver Vincent 30 Manager Sally 20 Clerk Joe 10 Desc Name No New Row Edited Row Edited Row
    15. 15. New SQL Statement: TRUNCATE <ul><li>The TRUNCATE statement is simply a quick way to DELETE all of the data from a table. </li></ul><ul><ul><li>The table can be in any type of table space and it can be either a base table or a declared global temporary table. </li></ul></ul><ul><ul><li>If the table contains LOB or XML columns, the corresponding table spaces and indexes are also truncated. </li></ul></ul><ul><ul><li>DELETE triggers will not be fired. </li></ul></ul>
    16. 16. TRUNCATE Example <ul><li>TRUNCATE TABLE EXAMPLE_TABLE </li></ul><ul><li>REUSE STORAGE </li></ul><ul><li>IGNORE DELETE TRIGGERS </li></ul><ul><li>IMMEDIATE; </li></ul>REUSE STORAGE tells DB2 to empty allocated storage but keep it allocated. The alternate (default) is DROP STORAGE, which tells DB2 to release the storage that is allocated and to make it available for use (for that table or any other table in the table space). IGNORE DELETE TRIGGERS tells DB2 to not fire any DELETE triggers. Alternately, you can specify RESTRICT WHEN DELETE TRIGGERS, which will return an error if there are any delete triggers defined on the table. The IMMEDIATE option causes the TRUNCATE to be immediately executed and it cannot be undone. If IMMEDIATE is not specified you can issue a ROLLBACK to undo the TRUNCATE.
    17. 17. TRUNCATE Considerations <ul><li>TRUNCATE can delete all data without actually processing each physical page as long as the table is in a segmented table space or a universal table space… unless … </li></ul><ul><li>TRUNCATE will have to process each data page if: </li></ul><ul><ul><li>Table is in a simple table space </li></ul></ul><ul><ul><li>Table is in a partitioned table space </li></ul></ul><ul><ul><li>Table has CDC enabled, uses MLS, or VALIDPROC </li></ul></ul>
    18. 18. New SQL: SELECT FROM DELETE, UPDATE, MERGE <ul><li>What if you need to read automatically generated data? For example: </li></ul><ul><ul><li>default values (especially dates, times, and user-defined defaults) </li></ul></ul><ul><ul><li>IDENTITY columns </li></ul></ul><ul><li>In some cases, it is possible to perform actions on an inserted row before it gets saved to disk. For example, a BEFORE TRIGGER might change data before it is even recorded to disk. </li></ul><ul><ul><li>But the application program will not have any knowledge of this change that is made in the trigger. </li></ul></ul><ul><li>What if the program needs to know the final column values? Previously, this was difficult and inefficient to implement. </li></ul>
    19. 19. First, a V8 Refresher: SELECT FROM INSERT <ul><li>SELECT FROM INSERT, introduced in DB2 V8 allows you to both insert the row and retrieve the values of the columns with a single SQL statement. It performs very well because it performs both the INSERT and the SELECT as a single operation. </li></ul><ul><li>Consider the following example: </li></ul><ul><li>SELECT COL5 INTO :C5-HV FROM FINAL TABLE (INSERT (COL1, COL2, COL5 , COL7) INTO SAMPLE_TABLE VALUES('JONES', 'CHARLES', CURRENT DATE , 'HOURLY') ); </li></ul>
    20. 20. V9 Adds DELETE, UPDATE, and MERGE Support <ul><li>DB2 V9 allows the FROM clause of a SELECT statement † to contain a searched UPDATE, a searched DELETE, or a MERGE statement. </li></ul><ul><li>This allows the user, or a program, to know which values were updated or deleted. </li></ul>† a SELECT statement that is a subselect; or in a SELECT INTO statement
    21. 21. An Example: SELECT FROM UPDATE <ul><li>SELECT SUM(SALARY) INTO :SAL-HV FROM FINAL_TABLE (UPDATE EMP SET SALARY = SALARY * 1.02 WHERE WORKDEPT = 'A01'); </li></ul><ul><li>Prior to the capability you would have had to run the UPDATE statement, and then only after it finishes, you would run the SELECT to add up the new salary values. </li></ul><ul><li>Now, instead of multiple statements requiring multiple passes through the data, you can consolidate it into one. </li></ul>
    22. 22. INCLUDE: SELECT FROM MERGE <ul><li>And because you might want to know which rows were updated and which were inserted, you can INCLUDE a special column on MERGE: </li></ul>SELECT CUSTNO, STATUS FROM FINAL TABLE (MERGE INTO CUST C INCLUDE (STATUS CHAR(3) ) USING VALUES ((:CUSTNO, :CUSTNAME, :CUSTDESC) FOR :HV_NROWS ROWS) AS NEW (CUSTNO, NAME, DESC) ON (C.CUSTNO = NEW.CUSTNO) WHEN MATCHED THEN UPDATE SET (C.NAME = NEW.NAME, C.DESC = NEW.DESC, STATUS = 'UPD') WHEN NOT MATCHED THEN INSERT (CUSTNO, NAME, DESC) VALUES (NEW.CUSTNO, NEW.NAME, NEW.DESC, 'INS') NOT ATOMIC CONTINUE ON SQL EXCEPTION;
    23. 23. Set Operations: INTERSECT, EXCEPT, and UNION INTERSECT is used to match result sets between two tables. If the data is the same in both results sets it passes through. When INTERSECT ALL is specified, the result consists of all rows that are in both result sets. If INTERSECT is specified without the ALL option, the duplicates will be removed from the results. EXCEPT, on the other hand, combines non-matching rows from two result tables. Some other DBMS implementations refer to this as the MINUS operation. When EXCEPT ALL is specified, the result consists of all rows from the first result table that do not have a corresponding row in the second and any duplicate rows are kept. If EXCEPT is specified without the ALL option, duplicates are eliminated. Both of these new set operations work similarly to UNION, which has existed since the beginning days of DB2. UNION gives all rows in both tables regardless of which they originated from. UNION ALL keeps duplicates whereas UNION removes duplicates.
    24. 24. INTERSECT Example <ul><li>For example, the following SQL will show all customers in the USA who are also employees (with no duplicates): </li></ul>SELECT last_name, first_name, cust_num FROM CUST WHERE country = 'USA' INTERSECT SELECT last_name, first_name, emp_num FROM EMP WHERE country = 'USA';
    25. 25. EXCEPT Example <ul><li>The following SQL will return only those items sold in March that were not also sold in April: SELECT item FROM MARCH_SALES EXCEPT SELECT item FROM APRIL_SALES; </li></ul>
    26. 26. INTERSECT and EXCEPT Considerations <ul><li>The SELECT-lists must be UNION compatible. That is, they must have the same number of columns and the data type and length for each respective column must be compatible. </li></ul><ul><li>Cannot be used with CLOB, BLOB, DBCLOB, or XML data types. </li></ul><ul><li>More on SQL set operations Wikipedia at: </li></ul><ul><ul><li>http://en.wikipedia.org/wiki/Union_(SQL) </li></ul></ul>
    27. 27. New Type of Trigger: INSTEAD OF <ul><li>INSTEAD OF triggers can only be defined on VIEWs. </li></ul><ul><li>INSTEAD OF triggers enable views that would not otherwise be updatable to support updates. </li></ul><ul><li>Typically, a view that consists of multiple base tables cannot be updated. </li></ul><ul><li>With an INSTEAD OF trigger you can code logic to direct inserts, updates and deletes to the appropriate underlying tables that comprise the view. </li></ul>
    28. 28. INSTEAD OF Trigger Example (The View) <ul><li>Let’s take a look at an example to better understand the INSTEAD OF trigger. First, we create a view that joins the EMP and DEPT tables: </li></ul><ul><li>CREATE VIEW EMP_DEPT (EMPNO, FIRSTNME, MIDINIT, LASTNAME, PHONENO, HIREDATE, DEPTNAME) AS SELECT EMPNO, FIRSTNME, MIDINIT, LASTNAME, PHONENO, HIREDATE, DEPTNAME FROM EMP, DEPT WHERE EMP.WORKDEPT = DEPT.DEPTNO; </li></ul>
    29. 29. INSTEAD OF Trigger Example (Triggers #1) <ul><li>Since this view is a join, it is not updateable. We can now remedy this by coding up some INSTEAD OF triggers. First, we’ll take care of INSERTs : </li></ul>CREATE TRIGGER E_D_ISRT INSTEAD OF INSERT ON EMP_DEPT REFERENCING NEW AS NEWEMP FOR EACH ROW INSERT INTO EMPLOYEE (EMPNO, FIRSTNME, MIDINIT, LASTNAME, WORKDEPT, PHONENO, HIREDATE) VALUES(EMPNO, FIRSTNME, MIDINIT, LASTNAME, COALESCE((SELECT DEPTNO FROM DEPT AS D WHERE D.DEPTNAME = NEWEMP.DEPTNAME), RAISE_ERROR('70001', 'Unknown dept name')), PHONENO, HIREDATE); An insert against the view would not be inserting a new department, so we will be inserting data into the EMP table. If the department does not exist, we’ll raise an error.
    30. 30. INSTEAD OF Trigger Example (Triggers #2) <ul><li>Next we’ll consider updates: </li></ul>CREATE TRIGGER E_D_UPD INSTEAD OF UPDATE ON EMP_DEPT REFERENCING NEW AS NEWEMP OLD AS OLDEMP FOR EACH ROW BEGIN ATOMIC VALUES(CASE WHEN NEWEMP.EMPNO = OLDEMP.EMPNO THEN 0 ELSE RAISE_ERROR('70002', 'Must not change EMPNO') END); UPDATE EMP AS E SET (FIRSTNME, MIDINIT, LASTNAME, WORKDEPT, PHONENO, HIREDATE) = (NEWEMP.FIRSTNME, NEWEMP.MIDINIT, NEWEMP.LASTNAME, COALESCE((SELECT DEPTNO FROM DEPT AS D WHERE D.DEPTNAME = NEWEMP.DEPTNAME), RAISE_ERROR ('70001', 'Unknown dept name')), NEWEMP.PHONENO, NEWEMP.HIREDATE) WHERE NEWEMP.EMPNO = E.EMPNO;END An update against the view would be updating employee info, so we will be updating data in the EMP table. If the department does not exist, we’ll raise an error.
    31. 31. INSTEAD OF Trigger Example (Triggers #3) <ul><li>Finally we take care of deletions: </li></ul>CREATE TRIGGER E_D_DEL INSTEAD OF DELETE ON EMP_DEPT REFERENCING OLD AS OLDEMP FOR EACH ROW DELETE FROM EMP AS E WHERE E.EMPNO = OLDEMP.EMPNO; Again, deleting from this view would impact employee data, not department data, so we will code the trigger to delete the appropriate rows from the EMP table.
    32. 32. INSTEAD OF Trigger Considerations - 1 <ul><li>The view must exist at the current server and none of the following are permitted for a view to have an INSTEAD OF trigger: </li></ul><ul><ul><li>the WITH CASCADED CHECK option </li></ul></ul><ul><ul><li>a view on which a symmetric view has been defined </li></ul></ul><ul><ul><li>a view that references data encoded with different encoding schemes or CCSID values </li></ul></ul><ul><ul><li>a view with a ROWID, LOB, or XML column (or a distinct type that is defined as one of these types) </li></ul></ul><ul><ul><li>a view with a column based on an underlying column defined as an identity column, security label column, or a row change timestamp column </li></ul></ul><ul><ul><li>a view with a column that is defined (directly or indirectly) as an expression </li></ul></ul><ul><ul><li>a view with a column that is based on a column of a result table that involves a set operator </li></ul></ul><ul><ul><li>a view with any columns that have field procedures </li></ul></ul><ul><ul><li>a view where all of the underlying base tables are DB2 Catalog tables or created global temporary tables </li></ul></ul><ul><ul><li>a view that has other views dependent on it </li></ul></ul>
    33. 33. INSTEAD OF Trigger Considerations - 2 <ul><li>Using an INSTEAD OF trigger, each requested modification operation made against the view is replaced by the trigger logic. The trigger performs the insert, update, or delete on behalf of the view. No application changes are required because the code is in the trigger which resides in the database. </li></ul><ul><li>Only one INSTEAD OF trigger is allowed for each type of operation on a given subject view. </li></ul><ul><li>If you want to read more about INSTEAD OF triggers, check out this extensive article ( albeit for DB2 LUW ) available on the IBM Developer Works web site: </li></ul><ul><li>http://www.ibm.com/developerworks/db2/library/techarticle/0210rielau/0210rielau.html </li></ul>
    34. 34. Native SQL Procedure Language Improvements <ul><li>Native SQL stored procedures contain only SQL procedure language (PL) statements. </li></ul><ul><li>In V8: </li></ul><ul><ul><li>Native SQL stored procedures are converted to C, which must be compiled (and obviously, requires a C compiler), and stored in the DB2 Catalog. </li></ul></ul><ul><li>In DB2 9: </li></ul><ul><ul><li>Native SQL stored procedures are converted to a native representation before they are stored in the DB2 catalog. Native SQL stored procedures do not run under WLM, but in the DBM1 address space. This improves performance. </li></ul></ul><ul><ul><li>Native SQL stored procedures that are run through DDF are eligible to run on zIIP processors. </li></ul></ul><ul><ul><li>Stored procedures can be versioned, making it easer to develop and test them. </li></ul></ul>You have to drop and re-create native stored procedures after moving to DB2 9 to take advantage of these changes.
    35. 35. Reoptimization <ul><li>You can gain additional optimization for dynamic SQL using the REOPT parameter of the BIND command. </li></ul><ul><li>REOPT specifies whether to have DB2 determine an access path at run time by using the values of host variables, parameter markers, and special registers. </li></ul><ul><li>As of DB2 9, there are four options from which to choose when specifying REOPT. </li></ul>
    36. 36. REOPT Enhancements <ul><li>REOPT (NONE) –PREPARE determines the access path and no reoptimization is performed. The bound statement can be moved to the dynamic statement cache (DSC), if the cache is being used. </li></ul><ul><li>REOPT (ONCE) – PREPARE determines an initial access path before the host variable values are available. When the statement is first executed and the host variable values are known, the statement is reoptimized one time. The hope is that the one-time reoptimization will provide a better access path than the initial PREPARE. The statement can be placed in the dynamic statement cache and reused multiple times. </li></ul><ul><li>REOPT (ALWAYS) – The SQL statement is re-optimized each time it is executed, always using the latest host variable values. </li></ul><ul><li>REOPT (AUTO) – Leave it up to DB2 (autonomic?). If changes in the filter factors for the statement predicates warrant, DB2 can re-prepare the statement. The newly prepared statement would be executed and would replace the prepared statement currently in the Global Dynamic Statement cache. </li></ul>NOREOPT(VARS) can be specified as a synonym of REOPT(NONE). REOPT(VARS) can be specified as a synonym of REOPT(ALWAYS). DB2 V8 DB2 9
    37. 37. REOPT Applicability: Dynamic vs. Static SQL Consider binding static programs with REOPT(ALWAYS) when the values for your program’s host variables or special registers are volatile and make a significant difference for access paths. ONCE and AUTO are not valid for static SQL because they work with the dynamic statement cache, which does not apply to static SQL. NO YES AUTO NO YES ONCE YES YES ALWAYS YES YES NONE Static SQL Dynamic SQL REOPT Parameter
    38. 38. Histogram Statistics <ul><li>A histogram is a way of summarizing data that is measured on an interval scale ( for large data sets ). </li></ul><ul><ul><li>A histogram is particularly helpful to quickly highlight how data is distributed; to determine if data is symmetrical or skewed; and to indicate whether or not outliers exists. </li></ul></ul><ul><ul><li>Consider collecting histogram statistics to improve access paths for troublesome queries with RANGE, LIKE, and BETWEEN predicates. </li></ul></ul><ul><ul><li>They can also help in some cases for =, IS NULL, IN LIST and COL op COL predicates. </li></ul></ul>Skewed data: you know, like “beer drinkers” skews male… Only for variables whose values are numerical
    39. 39. PLANMGMT: Plan Stability <ul><li>Plan stability, which works on packages only, allows you to keep backups versions of your program’s access paths. </li></ul><ul><li>Why? Because sometimes, after rebinding your program, performance degrades. With plan stability you can fall back to a previous package. </li></ul>
    40. 40. PLANMGMT BIND Options <ul><li>PLANMGMT(OFF) - No change to existing behavior. A package continues to have one active copy. </li></ul><ul><li>PLANMGMT(BASIC) - A package has one active copy. One additional prior copy (PREVIOUS) is preserved.   </li></ul><ul><li>PLANMGMT(EXTENDED) - A package has one active copy, and two additional prior copies (PREVIOUS and ORIGINAL) are preserved. </li></ul>Previous and active copies of package. Original, previous and active copies of package.
    41. 41. The Ol’ Switcheroo <ul><li>SWITCH (PREVIOUS) - changes the current and previous packages: </li></ul><ul><ul><li>The existing current package takes the place of the previous package. </li></ul></ul><ul><ul><li>The existing previous package takes the place of the current package. </li></ul></ul><ul><li>SWITCH (ORIGINAL) - clones the original copy to take the place of the current copy: </li></ul><ul><ul><li>The existing current copy replaces the previous copy. </li></ul></ul><ul><ul><li>The existing previous copy is discarded. </li></ul></ul>Only if you bound using PLANMGMT EXTENDED (refer to previous slide).
    42. 42. LOB Improvements #1 <ul><li>LOB File Reference Variable </li></ul><ul><ul><li>A host variable defined in a host language to contain the file name that directs file input and output for a large object (LOB). </li></ul></ul><ul><ul><li>Using file reference variables, large LOB values can be inserted from a file or selected into a file rather than a host variable. </li></ul></ul><ul><ul><li>This means that your application program does not need to acquire storage to contain the LOB value. </li></ul></ul><ul><ul><li>File reference variables also enable you to move LOB values from the DBMS to a client application or from a client application to a database server without going through the working storage of the client application. </li></ul></ul>
    43. 43. LOB Improvements #2 – FETCH CONTINUE <ul><li>Prior to Version 9, there were two methods you could deploy in your programs to fetch LOB data: </li></ul><ul><ul><li>Fetching data into a pre-allocated buffer </li></ul></ul><ul><ul><ul><li>can cause virtual storage constraint problems, especially for larger LOBs) </li></ul></ul></ul><ul><ul><li>Using a LOB locator to retrieve a handle on the data. </li></ul></ul><ul><ul><ul><li>using LOB locators that commit infrequently or do not explicitly free the locators can use considerable amounts of DB2 resources </li></ul></ul></ul>
    44. 44. LOB Improvements #2 – FETCH CONTINUE <ul><li>DB2 9: FETCH CONTINUE </li></ul><ul><ul><li>Can retrieve LOB columns in multiple pieces without using a LOB locator. </li></ul></ul><ul><ul><li>Can continue a FETCH operation to retrieve the remaining LOB data when truncation occurs. </li></ul></ul><ul><ul><li>You will have to manage the buffers and reassemble the pieces of data in your application program. </li></ul></ul>Read LOBs in Chunks
    45. 45. FETCH FIRST and ORDER BY in Subselect <ul><li>First, some basic education… The SELECT statement is broken down into three sections: </li></ul><ul><li>The select-statement is the form of a query that can be directly specified in a DECLARE CURSOR statement, or prepared and then referenced in a DECLARE CURSOR statement. It is the thing most people think of when they think of SELECT in all its glory. If so desired, it can be issued interactively using SPUFI. The select-statement consists of a fullselect, and any of the following optional clauses: order-by, fetch-first, update, read-only, optimize-for, isolation and queryno. </li></ul><ul><li>A fullselect can be part of a select-statement, a CREATE VIEW statement, or an INSERT statement. This sometimes confuses folks as they try to put a FETCH FIRST n ROWS clause or an ORDER BY in a view or as part of an INSERT. A fullselect does not allow any of the following clauses: ORDER BY, FOR READ ONLY, FOR FETCH ONLY, FOR UPDATE OF, OPTIMIZE FOR, WITH, QUERYNO, and FETCH FIRST. A fullselect specifies a result table – and none of these afore-mentioned clauses apply. </li></ul><ul><li>Finally, a subselect is a component of the fullselect. A subselect specifies a result table derived from the result of its first FROM clause. The derivation can be described as a sequence of operations in which the result of each operation is input for the next. </li></ul>
    46. 46. Think of it this way… <ul><li>In a subselect you specify the FROM to get the tables, the WHERE to get the conditions, GROUP BY to get aggregation, HAVING to get the conditions on the aggregated data, and the SELECT clause to get the actual columns. </li></ul><ul><li>In a fullselect you add in the UNION (EXCEPT and INTERSECT) to combine subselects and other fullselects. </li></ul><ul><li>Finally, you add on any optional order-by, fetch-first, update, read-only, optimize-for, isolation and queryno clauses to get the select-statement. </li></ul><ul><li>Well, until DB2 9 that is… </li></ul>
    47. 47. The Pre-9 Problem <ul><li>In DB2 V8, the ORDER BY and FETCH FIRST n ROWS ONLY clauses are only allowed at the statement level as part of select-statement or a SELECT INTO statement. That is, you can specify the clauses as part of select-statement and write: </li></ul><ul><li>SELECT * FROM T ORDER BY c1 FETCH FIRST 1 ROW ONLY </li></ul><ul><li>But you cannot specify the clauses within the fullselect and write: </li></ul><ul><li>INSERT INTO T1 </li></ul><ul><li>(SELECT * FROM T2 ORDER BY c1 FETCH FIRST 1 ROW ONLY) </li></ul><ul><li>Why is this a problem? </li></ul><ul><ul><li>Assume a large table </li></ul></ul><ul><ul><li>You only want the first 1000 rows sorted in a particular order </li></ul></ul><ul><ul><li>Coding a SELECT using FETCH FIRST and ORDER BY clauses does the trick, but the sort is done before the fetch (runs a large sort for no reason). </li></ul></ul><ul><ul><li>As a work around you could code use a temp table, but that requires a lot more work. </li></ul></ul>
    48. 48. The DB2 9 Solution <ul><li>Allow FETCH FIRST and ORDER BY in a subselect, for example: </li></ul><ul><li>SELECT T1.EMPNO, T1.PROJNO </li></ul><ul><li>FROM DSN8910.EMPPROJACT T1 </li></ul><ul><li>WHERE T1.EMPNO IN </li></ul><ul><li>( SELECT T2.EMPNO </li></ul><ul><li> FROM DSN8910.EMP T2 </li></ul><ul><li> ORDER BY SALARY DESC </li></ul><ul><li> FETCH FIRST 3 ROWS ONLY ) </li></ul><ul><li>ORDER BY T1.PROJNO; </li></ul><ul><li>The subselect MUST be enclosed in parentheses and the ORDER BY or FETCH FIRST cannot be: </li></ul><ul><ul><li>in the outermost fullselect of a view </li></ul></ul><ul><ul><li>in a materialized query table </li></ul></ul>Enclosed in parentheses. Enclosed in parentheses.
    49. 49. Index on Expressions <ul><li>DB2 9 extends the CREATE INDEX statement to index expressions instead of just columns. </li></ul><ul><li>What is an expression? It can be as simple as a column reference, or it can be a built-in function invocation or even a more general expression, with certain restrictions. </li></ul>A + B / 7 ^2
    50. 50. Index on Expressions - Restrictions <ul><li>Each expression must contain as least one reference to a column of the table named in the ON clause of the index. </li></ul><ul><li>Referenced columns cannot be LOB, XML, or DECFLOAT data types nor can they be a distinct type that is based on one of those data types. </li></ul><ul><li>Referenced columns cannot include any FIELDPROCs nor can they include a SECURITY LABEL. </li></ul><ul><li>And the expression cannot include any of the following: </li></ul>Subquery Aggregate function Non-deterministic function Function that has an external action User-defined function Sequence reference Host variable Parameter marker Special register CASE expression OLAP specification
    51. 51. Index on Expressions - Examples <ul><li>CREATE INDEX XUPLN </li></ul><ul><li>ON EMP </li></ul><ul><li>(UPPER(LAST_NAME)) </li></ul><ul><li>USING STOGROUP DSN8G910 </li></ul><ul><li>PRIQTY 360 SECQTY 36 </li></ul><ul><li>ERASE NO COPY YES; </li></ul><ul><li>CREATE INDEX XTOTCOMP </li></ul><ul><li>ON EMP (SALARY + COMM + BONUS) . . . </li></ul><ul><li>CREATE UNIQUE INDEX XLNFN </li></ul><ul><li>ON EMP (SUBSTR(FIRSTNAME,1,1) CONCAT '. ' CONCAT LASTNAME) . . . </li></ul>
    52. 52. New Built-in Functions – Char/String Functions <ul><li>ASCII_CHR - returns the character that has the ASCII code value that is specified by the argument. </li></ul><ul><li>ASCII_STR - returns a string, in the system ASCII CCSID that is an ASCII version of the string. </li></ul><ul><li>EBCDIC_CHR / EBCDIC_STR - I bet you can guess what they do. </li></ul><ul><li>UNICODE - returns the Unicode UTF-16 code value of the leftmost character of the argument as an integer. </li></ul><ul><li>UNICODE_STR - returns a string in Unicode UTF-8 or UTF-16 (depending on the specified parameter) representing a Unicode encoding of the input string. </li></ul>
    53. 53. New Built-in Functions – String manipulation <ul><li>LPAD - returns a string that is padded on the left, with blanks (or a specific character). The LPAD function treats leading or trailing blanks as significant. </li></ul><ul><li>RPAD - does the same but on the right. So, in the following example the last name is left padded with periods, then right padded with blanks. </li></ul><ul><li>SELECT LPAD(LASTNAME, 30, ’.’ ) AS LAST, </li></ul><ul><li> RPAD(FIRSTNME, 30) AS FIRST </li></ul><ul><li>FROM DSN910.EMP; </li></ul><ul><li>OVERLAY - returns a string with portions of it overlaid by a specified value. You provide the string, a substring to be overlaid, and its starting point and length, and DB2 does the rest. For example: </li></ul><ul><li>SELECT CHAR(OVERLAY('PLATELET','CEMEN',4,4,OCTETS),9), </li></ul><ul><li> CHAR(OVERLAY('INSERTING','IS',4,2,OCTETS),10), </li></ul><ul><li>FROM SYSIBM.SYSDUMMY1; </li></ul>Returns: PLACEMENT Returns: INSISTING
    54. 54. New Built-in Functions – “Similar Sounding” <ul><li>SOUNDEX - returns a 4 character code that represents the sound of the words in the argument. The result can be used to compare with the sound of other strings. The data type of the result is CHAR(4). For example, this query would return not only employees with a last name of “Smith,” but also anything that sounds like Smith, such as Smythe: </li></ul><ul><li>SELECT LASTNAME </li></ul><ul><li>FROM DSN910.EMP </li></ul><ul><li>WHERE SOUNDEX(LASTNAME) = SOUNDEX(’Smith’); </li></ul><ul><li>DIFFERENCE - returns a value from 0 to 4 where the number represents the difference between the sounds of two strings based on applying the SOUNDEX function to the strings. The higher the value, the closer the two strings are to sounding alike. Consider this example which returns the values 4, C523, and C523: </li></ul><ul><li>SELECT DIFFERENCE(’CONSTRAINT’, ’CONSTANT’), </li></ul><ul><li> SOUNDEX(’CONSTRAINT’), </li></ul><ul><li> SOUNDEX(’CONSTANT’) </li></ul><ul><li>FROM SYSIBM.SYSDUMMY1; </li></ul>Since the two strings return the same SOUNDEX value, the difference is 4 (the highest value possible).
    55. 55. New Built-in Functions – Date/Time <ul><li>EXTRACT - returns a portion of a date or timestamp. You can use EXTRACT to slice up a date/time value into its component pieces. For example: </li></ul><ul><li>SELECT BIRTHDATE, </li></ul><ul><li> EXTRACT (DAY FROM BIRTHDATE) AS DAY, </li></ul><ul><li> EXTRACT (MONTH FROM BIRTHDATE) AS MONTH, </li></ul><ul><li> EXTRACT (YEAR FROM BIRTHDATE) AS YEAR </li></ul><ul><li>FROM DSN8910.EMP; </li></ul><ul><li>MONTHS_BETWEEN - returns an estimate of the number of months between two expressions. The result is calculated based on a 31 day month. For example, the result of this query would be 1.096774193548387: </li></ul><ul><li>SELECT MONTHS_BETWEEN ('2007-02-20','2007-01-17') </li></ul><ul><li>AS MONTHS_BETWEEN </li></ul><ul><li>FROM SYSIBM.SYSDUMMY1; </li></ul>
    56. 56. New Built-in Functions - Timestamp <ul><li>TIMESTAMPADD - adds an interval to a timestamp. </li></ul><ul><li>TIMESTAMPDIFF - subtracts two timestamps and returns an interval. </li></ul><ul><li>TIMESTAMP_FORMAT – changes the display format for a timestamp value. Valid formats that can be specified are: </li></ul><ul><ul><li>‘ YYYY-MM-DD’ </li></ul></ul><ul><ul><li>‘ YYYY-MM-DD-HH24-MI-SS’ </li></ul></ul><ul><ul><li>‘ YYYY-MM-DD-HH24-MI-SS-NNNNNN’ </li></ul></ul>
    57. 57. Other New Built-in Functions <ul><li>RID - returns the RID of a row </li></ul><ul><li>CORRELATION - returns the coefficient of correlation of a set of number pairs </li></ul><ul><li>COVARIANCE / COVARIANCE_SAMP - return the (population) covariance of a set of number pairs </li></ul><ul><li>And, of course, we also get scalar functions to support the new data types in DB2 9 (the new data types are discussed later in this presentation). </li></ul>
    58. 58. OLAP Functions: RANK <ul><li>SELECT EMPNO, LASTNAME, FIRSTNAME, </li></ul><ul><li>SALARY+BONUS+COMM AS TOTAL_COMP, </li></ul><ul><li>RANK() OVER(ORDER BY SALARY+BONUS+COMM DESC) AS RANK_COMP </li></ul><ul><li>FROM EMP </li></ul><ul><li>WHERE SALARY+BONUS+COMM > 30000 </li></ul><ul><li>ORDER BY LASTNAME; </li></ul>This query will rank employees who have total compensation greater than $30,000, but order the results by last name. This allows you to rank data differently than the order in which it is presented.
    59. 59. OLAP Functions: RANK <ul><li>OK, what did that query do? </li></ul>300 ABBOTT RANDY 1000000 1 500 GREEN RACHEL 47000 3 100 MULLINS CRAIG 1000000 1 200 SHAW DONNA 35000 4 400 WISER BUD 10000 5 RANK of the total compensation 5000 2000 40000 RACHEL GREEN 500 0 0 10000 BUD WISER 400 0 300000 700000 RANDY ABBOTT 300 0 10000 25000 DONNA SHAW 200 400000 100000 500000 CRAIG MULLINS 100 COMM BONUS SALARY FIRSTNAME LASTNAME EMPNO
    60. 60. OLAP Functions: DENSE_RANK <ul><li>Both ABBOTT and MULLINS earn the most, but the amount is the same, so they share the number one ranking. With a dense rank, the next rank value is 2, and not 3. </li></ul>300 ABBOTT RANDY 1000000 1 500 GREEN RACHEL 47000 2 100 MULLINS CRAIG 1000000 1 200 SHAW DONNA 35000 3 400 WISER BUD 10000 4 When there are two at the top, next is 2 not 3 w/DENSE_RANK. 5000 2000 40000 RACHEL GREEN 500 0 0 10000 BUD WISER 400 0 300000 700000 RANDY ABBOTT 300 0 10000 25000 DONNA SHAW 200 400000 100000 500000 CRAIG MULLINS 100 COMM BONUS SALARY FIRSTNAME LASTNAME EMPNO
    61. 61. OLAP Functions – ROW_NUMBER <ul><li>SELECT ROW_NUMBER() OVER(ORDER BY WORKDEPT, LASTNAME) AS NUMBER, LASTNAME, SALARY </li></ul><ul><li>FROM EMP </li></ul><ul><li>ORDER BY WORKDEPT, LASTNAME; </li></ul>ROW_NUMBER - specifies that a sequential row number is computed for the row that is defined by the ordering, starting with 1 for the first row.
    62. 62. Skipping Locked Data <ul><li>In DB2 9 it is possible to set up your SQL to skip over pages or rows that are locked. </li></ul><ul><li>The program will only “see” unlocked, committed data. </li></ul><ul><li>Why would you want to do this? Perhaps to improve application performance and availability. If you don’t have to wait for locks to be released then “things” should run faster, right? </li></ul><ul><li>But it comes at the cost of not accessing the locked data at all. Yes, this means your results will be inconsistent. You should only utilize this clause when your program can tolerate skipping over some data and NEVER when results must be 100% accurate, like when balancing financial data, for example. </li></ul>This is not the same as dirty reads (UR), which can “see” uncommitted, locked data.
    63. 63. OK, How Do You Skip Locked Data? <ul><li>SKIP LOCKED DATA – can be specified on: </li></ul><ul><ul><li>SELECT </li></ul></ul><ul><ul><li>PREPARE </li></ul></ul><ul><ul><li>searched UPDATE and DELETE </li></ul></ul><ul><ul><li>UNLOAD utility </li></ul></ul><ul><li>Can only be used with the following isolation levels: </li></ul><ul><ul><li>Cursor Stability (CS) </li></ul></ul><ul><ul><li>Read Stability (RS) </li></ul></ul><ul><ul><li>If any other isolation level is in use for the plan or package, the SKIP LOCKED DATA option is ignored. </li></ul></ul>
    64. 64. For Example Locked Locked SELECT COUNT (*) FROM EMP WHERE COMM = 0 SKIP LOCKED DATA; 2 SELECT COUNT (*) FROM EMP SKIP LOCKED DATA; 3 UPDATE EMP SET COMM = 500 WHERE BONUS = 0; Assume row level locking and no COMMIT. 5000 0 40000 RACHEL GREEN 500 0 2000 10000 BUD WISER 400 0 300000 700000 RANDY ABBOTT 300 0 0 25000 DONNA SHAW 200 400000 100000 500000 CRAIG MULLINS 100 COMM BONUS SALARY FIRSTNAME LASTNAME EMPNO
    65. 65. Optimistic Locking <ul><li>What is optimistic locking? </li></ul><ul><ul><li>We are optimists and think that usually we will be the only ones with interest in the data. </li></ul></ul><ul><ul><li>In other words, when optimistic locking is implemented you are assuming that most of the time there will be no other programs that are interested in the page of data that you are planning to modify. </li></ul></ul><ul><ul><li>Optimistic locking decreases the duration of locks and can improve performance and availability, helping to eliminate -911 and -913 locking issues. </li></ul></ul>
    66. 66. Optimistic Locking and ROW CHANGE TIMESTAMP <ul><li>For programs that use updateable static scrollable cursors, DB2 can use optimistic locking as long as the plan/package is bound ISOLATION(CS). </li></ul><ul><li>If you have this situation, DB2 will deploy optimistic locking to reduce the duration of locks between consecutive FETCH operations and between fetch operations and subsequent positioned UPDATE or DELETE operations. </li></ul>FETCH row 1 LOCK row 1 FETCH row 2 UNLOCK row 1 LOCK row 2 UPDATE row 2 FETCH row 1 LOCK row 1 UNLOCK row 1 FETCH row 2 LOCK row 2 UNLOCK row 2 UPDATE row 2 LOCK row 2 re-evaluate and compare UPDATE Regular Locking Optimistic Locking
    67. 67. ROW CHANGE TIMESTAMP <ul><li>The ROW CHANGE TIMESTAMP can be used to find out when table rows were modified. For example: </li></ul>CREATE TABLE CUSTOMER (CUSTNO CHAR(8) NOT NULL, CUST_INFOCHANGE NOT NULL GENERATED ALWAYS FOR EACH ROW ON UPDATE AS ROW CHANGE TIMESTAMP, CUST_NAME VARCHAR(50), CUST_ADDRESS VARCHAR(100), CUST_CITY CHAR(20), CUST_STATE CHAR(2), CUST_ZIP CHAR(9), CUST_PHONE CHAR(10), PRIMARY KEY (CUSTNO)) Now that the table is defined with the ROW CHANGE TIMESTAMP we can use it in our programs and queries to determine when the row was last changed.
    68. 68. Using the ROW CHANGE TIMESTAMP <ul><li>To find all of the customer rows that were changed in the past week (ie. the last 7 days) we could run the following query: </li></ul>SELECT CUSTNO, CUST_NAME FROM CUSTOMER WHERE ROW CHANGE TIMESTAMP FOR CUSTOMER <= CURRENT TIMESTAMP AND ROW CHANGE TIMESTAMP FOR CUSTOMER >= CURRENT TIMESTAMP - 7 DAYS;
    69. 69. ALTER and ROW CHANGE TIMESTAMP <ul><li>But what would happen if you issued a statement like on the previous slide, but against a table that was altered to include a ROW CHANGE TIMESTAMP, not created initially with one? </li></ul><ul><li>DB2 will use the time the page was last modified until your REORG. So the results will not be exactly correct because it would return all the rows on each page that qualifies (because at least one row on the page changed). </li></ul>Clean up the advisory REORG pending as soon as possible after adding the ROW CHANGE TIMESTAMP.
    70. 70. New Data Type: BIGINT <ul><li>BIGINT is an exact numeric data type capable of representing 63-bit integers. This is the third integer data type now available to DB2 and it offers the ability to store the largest range of values: </li></ul><ul><ul><li>SMALLINT values can range from -32768 to 32767 </li></ul></ul><ul><ul><li>INTEGER values can range from -2147483648 to 2147483647 </li></ul></ul><ul><ul><li>BIGINT values can range from -9223372036854775808 to 9223372036854775807 </li></ul></ul>
    71. 71. New Data Types: Binary Data <ul><li>BINARY and VARBINARY data types extend current support of binary strings and are compatible with BLOB data type. They are not compatible with character string data types. </li></ul><ul><li>It is somewhat easy to migrate existing columns defined as CHAR FOR BIT DATA or VARCHAR FOR BIT DATA over to BINARY or VARBINARY. If there is an index defined on the column, the index is placed in RBDP. </li></ul><ul><ul><li>You cannot alter BINARY or VARBINARY data types to CHAR FOR BIT DATA or VARCHAR FOR BIT DATA. </li></ul></ul>
    72. 72. New Data Type: DECFLOAT <ul><li>DECFLOAT takes advantage of new System z9 hardware support delivering a data type that lets you use decimal floating-point numbers with greater precision than the existing FLOAT data type. The maximum precision is 34 digits and the range of a decimal floating point number is either 16 or 34 digits of precision. The range of values supported by DECFLOAT is: </li></ul><ul><ul><li>DECFLOAT(16) range: -9.999999999999999×10 384 to 9.999999999999999×10 384 </li></ul></ul><ul><ul><li>Smallest positive DECFLOAT(16): 1.000000000000000×10 -383 </li></ul></ul><ul><ul><li>Largest negative DECFLOAT(16): -1.000000000000000×10 -383 </li></ul></ul><ul><ul><li>DECFLOAT(34) range: -9.999999999999999999999999999999999×10 6144 thru 9.999999999999999999999999999999999×10 6144 </li></ul></ul><ul><ul><li>Smallest positive DECFLOAT(34): 1.000000000000000000000000000000000×10 -6143 </li></ul></ul><ul><ul><li>Largest negative DECFLOAT(34): -1.000000000000000000000000000000000×10 -6143 </li></ul></ul>
    73. 73. Additional DECFLOAT Considerations <ul><li>The DECFLOAT data type is able to represent the following named special values representing “non-number numbers”: </li></ul><ul><ul><li>Infinity - a value that represents a number whose magnitude is infinitely large. </li></ul></ul><ul><ul><li>Quiet NaN - a value that represents undefined results which does not cause an invalid number condition. NaN is not a number. </li></ul></ul><ul><ul><li>Signaling NaN - a value that represents undefined results which will cause an invalid number condition if used in any numerical operation. </li></ul></ul><ul><li>DECFLOAT is only supported in Java, Assembler, and REXX. </li></ul>
    74. 74. pureXML <ul><li>And finally, we get pureXML support to store XML as a native data type in DB2. </li></ul><ul><ul><li>That means you can specify XML as a data type for columns in your DB2 tables in DB2 9 for z/OS. </li></ul></ul>
    75. 75. Before we go… <ul><li>Plans and packages that were bound before DB2 V4 will be automatically rebound when first accessed by DB2 9, so: </li></ul><ul><ul><li>It is a good idea to rebind these yourself, ahead of time, before you try to run them in DB2 9. </li></ul></ul><ul><ul><li>That way, you can see what the impact of the new version is on your access paths. </li></ul></ul>
    76. 76. Summary <ul><li>DB2 9 for z/OS offers a wealth of new things and stuff for DB2 application developers. </li></ul><ul><ul><li>Make sure you take the time to learn how these new features can help you build better DB2 applications! </li></ul></ul>… then maybe the work won’t keep piling up like this!
    77. 77. Craig S. Mullins <ul><li>NEON Enterprise Software </li></ul><ul><li>[email_address] </li></ul><ul><li>www.neonesoft.com </li></ul><ul><li>www.craigsmullins.com </li></ul><ul><li>www.DB2portal.com </li></ul>

    ×