DB2 V12 Technical incompatibilities and Improvemnts over V11

2. Overview of DB2V12 Quick Hits
•Scale and speed for the next era of mobile applications
– Over 1 Million Inserts per second measured, will scale higher
– 256 trillion rows in a single table, with agile partition technology
• In Memory database
– Up to 23% CPU reduction for index lookup with advanced in-memory
techniques
• Next Generation application support
– 360 million transactions per hour through RESTful web API
• Deliver analytical insights faster
– Up to 2x speedup for query workloads, 100x for targeted queries

3. Traditional DB2 Migration Process till DB2V11
DSNTIJTC DSNTIJEN DSNTIJNF
V10
Catalog
V11
Catalog
V11
Catalog
V11
Catalog
V10 NFM V11 CM V11 ENF V11 NFM
3 – 6 Months
V10 CM*
Minutes
V10 NFM*
V11 EFM
Is LIVE

4. DB2 12 Continuous Delivery
DB2 12 continuous delivery
• Single Phase Migration
• New Enhancements and capabilities delivered in maintenances stream as Function
Levels
• Enhancements may or may not require CATMAINT
• A new Function Level is identified byVersion ID, Release number and Modification
identifier
• Example :V12R1M500
• Function Levels Enabled via –ACTIVATE command

5. DB2 12 New Migration Process
CATMAINT UPDATE
LEVEL(V12R1M100)
-ACTIVATE FUNCTION LEVEL
V12R1M500
V11
Catalog
V11
Libraries
V12RM100
Libraries
V12R1M500
Catalog
V11 NFM NoV12 New Function Mode available
Function Level V12R1M100
Rebind Applications with
APPLCOMPAT(V11R1) or (V12R1M100)
2 – 4 Months
Data sharing
coexistence
1 – 2 Weeks
V12 New Function
Available
Rebind Applications
with APPLCOMPAT
(V12R1M500)

6. DIS GROUP CommandV11
RUN –DIS GROUP command to view DB2Version information
DSN7100I -DB2A DSN7GCMD
*** BEGIN DISPLAY OF GROUP(DSNDB0B ) CATALOG LEVEL(111) MODE(NFM )
PROTOCOL LEVEL(2) GROUP ATTACH NAME(DB0B)
--------------------------------------------------------------------
DB2 DB2 SYSTEM IRLM
MEMBER ID SUBSYS CMDPREF STATUS LVL NAME SUBSYS IRLMPROC
-------- --- ---- -------- -------- --- -------- ---- --------
DB1A 2 DB1A -DB1A ACTIVE 111 SX1 B1LM DB1BB1LM
DB2A 1 DB2A -DB2A ACTIVE 111 SX3 B2LM DB2BB2LM
DB3A 3 DB3A -DB3A ACTIVE 111 SX2 B3LM DB3BB3LM
--------------------------------------------------------------------

7. DIS GROUP CommandV12
RUN –DIS GROUP command to view DB2Version information
DSN7100I -CA DSN7GCMD
*** BEGIN DISPLAY OF GROUP(........) CATALOG LEVEL(V12R1M500)
CURRENT FUNCTION LEVEL(V12R1M100)
HIGHEST ACTIVATED FUNCTION LEVEL(V12R1M100)
HIGHEST POSSIBLE FUNCTION LEVEL(V12R1M500)
PROTOCOL LEVEL(2)
GROUP ATTACH NAME(....)
-------------------------------------------------------------------
DB2 SUB DB2 SYSTEM IRLM
MEMBER ID SYS CMDPREF STATUS LVL NAME SUBSYS IRLMPROC
-------------------------------------------------------------------
........ 0 DB1A -CA ACTIVE 121100 S0W1 LC1A DC1AIRLM
-------------------------------------------------------------------

8. In Memory Index Optimization
A new Index FastTraverse Block (FTB) is introduced
• Memory optimized structure for fast index lookups
• Resides in memory areas outside of the buffer pool
• New zparmINDEX_MEMORY_CONTROL
• Default=AUTO (min. of 500 MB or 20% of allocated BP storage)
• UNIQUE indexes only, key size 64 bytes or less
• DB2 automatically determines which indexes would benefit from FTB
• DISPLAY STATS command shows which indexes are using FTBs
• New SYSINDEXCONTROL catalog table
• Specify time windows to control use of FTBs for an index
• New IFCIDs 389 and 477 to track FTB usage

9. Insert Performance
Insert workloads are amongst the most prevalent and performance critical
• DB2 12 delivers significant improvements for Non-clustered insert: journal table pattern
• UTS, MEMBER CLUSTER(Both with/without Append)
• Advanced new insert algorithm to streamline space search
• Default is to use the new fast algorithm for qualifying table spaces
• INSERTALGORITHM zparmcan change the default
• INSERTALGORITHM table space attribute can override zparm

10. DB2V12 Application Enablement. – Merge Support
Enhanced Merge Support
• DB2 z/OS initial support for MERGE statement with limited functionality was delivered with
Version 9:
• Limited to UPDATE and INSERT and only one of each
• Focused on use of host variable column arrays to provide multiple rows of input data
• In DB2 12, DB2 z/OS MERGE statement will be aligned with behavior defined in SQL Standard and DB2
family
• Source data as a table-reference
• Multiple MATCHED clauses
• Additional Predicates with [NOT]MATCHED
• Support DELETE operation

11. DB2V12 Application Enablement – SQL Pagination
SQL Pagination
• With the growth of web and mobile applications, application developers are looking for more efficient
ways to develop good performing applications
• Numeric-based pagination
SELECT * FROM tab OFFSET 10 ROWS FETCH FIRST 10 ROWS ONLY
• Data-dependent pagination
• Existing syntax:
WHERE (LASTNAME = ‘SMITH’ AND FIRSTNAME >= ‘JOHN’) OR (LASTNAME > ‘SMITH’)
• New equivalent syntax
WHERE (LASTNAME, FIRSTNAME) > (SMITH, JOHN)

12. DB2V12 Application Enablement – Delete Enhancement
Delete Enhancement
• Piecemeal DELETE – allow for interim commits Numeric-based pagination
e.g. Delete fromT1 where C1 > 7 “FETCH FIRST 5000 ROWS ONLY”
• Mitigate the effects of locking and logging when potentially millions of rows could be affected by a
simple statement like:
• "DELETE FROM T1WHERE C1 > 7“
• Solution
• Support full select as the target of a DELETE statements where the fullselect allows for the FETCH
FIRST N ROWS ONLY to be specified.
• DELETE FROM (SELECT * FROMT1WHERE C1 > 7 FETCH FIRST 5000 ROWS ONLY)

13. What is Plan Stability ?
• Possibility to create previous access path versions and the ability to switch back to them
• You can have up to 3 available access paths for each static database package
− SWITCH option for replacement of current with previous or original – falling back to old access
paths
− Setting/Resetting access paths for whole package possible (all queries contained in package)
• Requires Plan Management EXTENDED usage – set PLANMGMT (EXTENDED)
− Either as database subsystem parameter or as rebind option
− Default value of PLANMGMT is EXTENDED from DB2V10.To be confirmed again before
Migration.
DB2 System Catalog
Incoming
Copy
Current
Copy
Original
Copy
Previous
Copy
Pre-Previous
Copy
Bind
Rebind
Create Baseline

14. Plan Management PLANMGMT(EXTENDED)
• Bind creates a current(Active) copy of the package.
• First rebind creates a new current(active) copy
And a previous and original copy.
Further rebinds creates a new active copy and replace
The previous copy. Original copy remains untouched.
Current
Copy1
Current
Copy2
Previous
Copy1
Original
Copy1
Current
Copy3
Previous
Copy2
Original
Copy1

15. Application compatibility (APPLCOMPAT)
• DB2V11 Introduced the concept of ApplicationCompatibility as BIND Option
• Default value for APPLCOMPAT is the CURRENT (The DBVersion Level)
• In DB2V12 APPLCOMPAT is extended to a more granular level with the modification
level to follow the same format as function level.
• APPLCOMPAT are available as follows
• V10R1: SQL behaviors are compatible to DB2 10.
• V11R1: SQL behaviors are compatible to DB2 11.
• V12R1M100: Is equivalent toV11R1.
• V12R1M500: SQL behaviors are compatible to DB2 12 and can be specified
only if the subsystem or data sharing group is at function levelV12R1M500 or
greater

16. Application compatibility (APPLCOMPAT) - Migration
V12R1M100 Migration (Equivalent to Conversion Mode)
• During theV12R1M100 Migration, following activities needs to be done
• Check the APPLCOMPAT setting and make it toV12R1M100
• FREE PACKAGE<Package Name> PLANMGMTSCOPE(INACTIVE) FLAG(I)
• REBIND PACKAGE <Package Name> EXPLAIN(YES)
V12R1M500 Migration (Equivalent to New Function Mode)
• During theV12R1M500 Migration, following activities needs to be done
• Check the APPLCOMPAT setting and make it toV12R1M500
• This needs to be done to active the new SQL features introduced withV12
• REBIND PACKAGE <Package Name> EXPLAIN(YES)

17. Deprecated in earlier releases and removed in DB2 12
• Query I/O parallelism is no longer supported: query will be executed with sequential access mode.
• Basic row format is deprecated.
• Resource limit tables (DSNRLSTxx) and related index with formats earlier than DB2Version 8 are not supported
(To be checked by DC)
• Explain tables created in DB2V11 and earlier have to be recreated for DB2V12
• Utility Mapping tables (To be checked by DC for Daimler environments).
• TheTARGET_XRID column in static mapping tables should be changed from CHAR(9) to CHAR(11).
REORG Utility will throw below message if column length is not changed.
• For DEV environments Capgemini DBA will do the Mapping table changes.

18. Changes in ExplainTables
• As mentioned earlier Explain tables have to be re-created as per DB2V12 format before migrating toV12
• List of new and changed EXPLAIN tables
• PLAN_TABLE
• New columns
• PER_STMT_ID
• Changed columns
• COLUMN_FN_EVAL
• PRIMARY_ACCESSTYPE
• TNAME
• DSN_COLDIST_TABLE
• New columns
• PER_STMT_ID
• DSN_KEYTGTDIST_TABLE
• New columns
• PER_STMT_ID

19. Changes in ExplainTables…….continue 2
• DSN_DETCOST_TABLE
• New columns
• BLOCK_FETCH
• PER_STMT_ID
• DSN_FUNCTION_TABLE
• New columns
• PER_STMT_ID
• DSN_PGRANGE_TABLE
• New columns
• PER_STMT_ID
• DSN_PGROUP_TABLE
• New columns
• PER_STMT_ID
• DSN_PREDICAT_TABLE
• New columns
• PER_STMT_ID

20. Changes in ExplainTables…….continue 3
• DSN_PREDICATE_SELECTIVITY table
• New columns
• BLOCK_FETCH
• PER_STMT_ID
• DSN_PTASK_TABLE
• New columns
• PER_STMT_ID
• DSN_SORT_TABLE
• New columns
• PER_STMT_ID
• DSN_SORTKEY_TABLE
• New columns
• PER_STMT_ID
• Changed columns
• REASON
• STALE

21. Changes in ExplainTables…….continue 4
• DSN_STATEMENT_CACHE_TABLE
• New columns
• APPLCOMPAT
• CNO
• PER_STMT_ID
• QUERY_HASH
• QUERY_HASH_VERSION
• STABILIZED
• STAT_SUS_CHILDLLOCKS
• STAT_SUS_OTHERLLOCKS
• STAT_SUS_PPPLOCKS
• STAT_SUS_PAGEPLOCKS
• STAT_SUS_OTHERPLOCKS
• STBLGRP
• STAT_SUS_PIPE
• STAT_SUS_PQSYNC

22. Changes in ExplainTables…….continue 5
• DSN_STRUCT_TABLE
• New columns
• PER_STMT_ID