IBM, the IBM logo, ibm.com, DB2 and DB2 for z/OS are trademarks or registered trademarks of International Business
Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked
on their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or
common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered
or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at “Copyright and
trademark information” at www.ibm.com/legal/copytrade.shtml
Other company, product, or service names may be trademarks or service marks of others.
DB2 9 – A Rich, Features Filled Release
SHRLEVEL(REFERENCE) for REORG Global query optimization DECIMAL FLOAT
of LOB tablespaces Generalizing sparse index and in- BIGINT
Online RENAME COLUMN memory data caching method VARBINARY, BINARY
Online RENAME INDEX Optimization Service Center TRUNCATE TABLE statement
Online CHECK DATA and CHECK LOB Autonomic reoptimization MERGE statement
Online REBUILD INDEX Logging enhancements FETCH CONTINUE
Online ALTER COLUMN DEFAULT LOBs network flow optimization ORDER BY and FETCH FIRST n ROWS
More online REORG by eliminating Faster operations for variable-length in sub-select and full-select
BUILD2 phase rows ORDER OF extension to ORDER BY
Faster REORG by intra-REORG NOT LOGGED tablespaces INTERSECT and EXCEPT Set
parallelism Index on expressions Operations
Renaming SCHEMA, VCAT, OWNER, Universal Tablespaces Instead of triggers
CREATOR Partition-by-growth tablespaces Various scalar and built-in functions
LOB Locks reduction APPEND option at insert Cultural sort
Skipping locked rows option Autonomic index page split LOB File Reference support
Tape support for BACKUP and Different index page sizes XML support in DB2 engine
RESTORE SYSTEM utilities
Support for optimistic locking Enhancements to SQL Stored
Recovery of individual tablespaces Procedures
and indexes from volume-level Faster and more automatic DB2
backups restart SELECT FROM
RLF improvements for remote UPDATE/DELETE/MERGE
Enhanced STOGROUP definition
application servers such as SAP Enhanced CURRENT SCHEMA
Conditional restart enhancements
Preserving consistency when IP V6 support
Histogram Statistics collection and recovering individual objects to a prior
exploitation Unified Debugger
point in time Trusted Context
WS II OmniFind based text search CLONE Table: fast replacement of one
DB2 Trace enhancements Database ROLEs
table with another
WLM-assisted Buffer Pools Automatic creation of database
Index compression objects
management Index key randomization
... Temporary space consolidation
... ‘What-If’ Indexes
...
TCO Reduction Continuous Operations Performance Scalability SQL Portability
SELECT FROM UPDATE/DELETE/MERGE
V8 V9
SELECT FROM INSERT SELECT FROM INSERT
UPDATE
Retrieves columns values DELETE
created by INSERT in a single MERGE
SELECT statement including:
• Identity columns One SQL call to DB2 modifies the
• Sequence values table contents and returns the
• User-defined defaults resultant changes to the
• Expressions application program.
• Columns modified by BEFORE E.g. we can now code destructive
INSERT trigger read from a table when a SELECT
• ROWIDs FROM DELETE statement is
included. This feature is
Avoids possible expensive
particularly useful when a table is
access path that separate
used as a data queue.
SELECT might be using
ORDER BY and FETCH FIRST in Subselect
V8 V9
Locators remain active for the scope of For CLI, activated by using streaming
the transaction (unless explicitly freed) interface SQLGetData
and valuable server resources are longer Requires DB2 Connect 9.1 FP 1, better yet
held. 9.5
New Data Types: BINARY and VARBINARY
V8 V9
V8 V9
V9
MERGE INTO archive AR
USING VALUES (:hv_activity, :hv_description) FOR :hv_nrows ROWS
AS AC (ACTIVITY, DESCRIPTION)
ON (AR.ACTIVITY = AC.ACTIVITY)
WHEN MATCHED THEN UPDATE SET DESCRIPTION = AC.DESCRIPTION
WHEN NOT MATCHED THEN INSERT (ACTIVITY, DESCRIPTION)
VALUES (AC.ACTIVITY, AC.DESCRIPTION)
NOT ATOMIC CONTINUE ON SQLEXCEPTION
MERGE Example
MERGE INTO account AS T
USING VALUES (:hv_id, :hv_amt) FOR 5 ROWS AS S (id, amt)
ON T.id = S.id
WHEN MATCHED THEN UPDATE SET balance = T.balance + S.amt
WHEN NOT MATCHED THEN INSERT (id, balance) VALUES (S.id, S.amt)
NOT ATOMIC CONTINUE ON SQLEXCEPTION
MERGE
R1 R2 R1 R2 R1 R2
subselect
(fullselect) DISTINCT
UNION subselect
EXCEPT ALL (fullselect)
INTERSECT
INSTEAD OF Triggers
V8 V9
• No unified mechanism for • A new type of trigger (in addition
controlling read and write to BEFORE and AFTER triggers)
access by an application • Can only be defined on views
(e.g. encryption) • DB2 only executes the triggered-
• Views are used for read action instead of the action
access control against the subject view
• Triggers on base table • application still believes all
are used for write access operations are performed
control against the view
• Provides means to update views
• No INSERT/UPDATE/DELETE that are considered read-only by
for read-only views (e.g. DB2
joins)
INSTEAD OF TRIGGERS
CREATE TABLE WEATHER (CITY VARCHAR(25), TEMPF DECIMAL(5,2))
CREATE VIEW CELCIUS_WEATHER (CITY, TEMPC) AS
SELECT CITY, (TEMPF-32)*5.00/9.00 FROM WEATHER
V8
With optimistic locking the retrieved rows are not protected by locks after
they are retrieved.
That means they can be changed by concurrent transactions after the
retrieval and before they are to be updated by the transaction that
retrieved them in the first place.
In order to ensure consistency, the retrieved rows must be checked if they
changed since they had been retrieved.
Prior to V9 all of the columns marked for update and their values in last
read operation are added explicitly in the WHERE clause of the UPDATE,
so that the UPDATE fails if the underlying column values have been
changed.
Support for Optimistic Locking
V9
V9 adds a new expression: ROW CHANGE TOKEN which returns a token that
represents a relative point in the modification sequence of a row
Instead of knowing all the old values that are to be updated, the application can
compare the current ROW CHANGE TOKEN value of a row with the value that
was stored when the row was last time fetched.
ROW CHANGE TOKEN is generated in two alternative ways:
– From an optional, explicit (but optionally hidden) column
– From the page RBA or LRSN