DB2 12 Overview what s coming

Transcription

1 DB2 12 Overview what s coming Tom Crocker (tom_crocker@uk.ibm.com) IBM Date of presentation (01/11/2016) Session IA

2 Please Note IBM s statements regarding its plans, directions, and intent are subject to change or withdrawal without notice at IBM s sole discretion. Information regarding potential future products is intended to outline our general product direction and it should not be relied on in making a purchasing decision. The information mentioned regarding potential future products is not a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potential future products may not be incorporated into any contract. The development, release, and timing of any future features or functionality described for our products remains at our sole discretion. Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon many factors, including considerations such as the amount of multiprogramming in the user s job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve results similar to those stated here. 3 3

3 Extend the unique value of System z DB2 Strategy Scalable Reliable Efficient Secure Highly Available Empower the next wave of applications Cloud Self provisioning, Multi-tenancy, Self managing, guaranteed SLAs Mobile Agile development, Enterprise mobile scale Analytics Real time analytics integrated with OLTP 4

4 DB2 12 Goals Application Enablement DBA Function OLTP Performance Query Performance IDAA improvements to expand to new use cases SQL/SQLPL improvements for next wave of applications Relieve table scalability limits Simplify large table management 5-10% CPU reduction with use of inmemory features 2x increase in Insert throughput for non-clustered 20-30% CPU reduction for query workloads Improve efficiency by reducing other resource consumption Address key customer requirements to expand use of existing features Mobile, hybrid cloud, and DevOps enablement Remove biggest 24x7 inhibitors Security and compliance improvements Remove system scaling bottlenecks for high n-way systems Serviceability, availability 80% UNION ALL performance improvement Simplify access path management 5

5 DB2 for z/os Timeline 2004 V V DB V8 EOS 4/2012 DB2 11 V9 EOS 4/ DB2 12 V10 EOS 9/2017 Version GA V7 3/2001 DB2 12 ESP started in March, 2016 V8 3/2004 V9 3/2007 V10 10/2010 V11 10/2013 6

6 DB2 12: Open for Data An early look Redefining enterprise IT for digital business and the mobile app economy Scale and speed for the next era of mobile applications Over 11 Million Inserts per second measured (so far) 280 trillion rows in a single table, with agile partition technology In Memory database 23% CPU reduction for lookups with advanced in-memory techniques Next Gen application support Up to 384 million transactions per hour through RESTful web API Deliver analytical insights faster Up to 100x speedup for query workloads 7

7 DB2 12 Performance Enhancements In-memory contiguous buffer pools Direct row access in-memory, avoid GetPage overhead In-memory index for fast traversal More granular Global Commit LSN Potential huge improvement in lock avoidance (data sharing) Also will help space reuse for insert Faster INSERT performance 3x faster, 20% less CPU Non-clustered, journal table pattern (common) >4G active logs BP size limit raised to 16 TB 8

8 In-Memory Index Optimization A new Index Fast Traverse Block (FTB) is introduced Memory optimized structure for fast index lookups Resides in memory areas outside of the buffer pool New zparm INDEX_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

9 Simple Look-up : Faster & Cheaper Up to 23% CPU reduction for index look up using DB2 12 In-memory index tree CPU Improvement (%) from Simple Lookup in DB % 16% 11% 6% Index Levels 10 10

10 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 Advanced new insert algorithm to streamline space search Default is to use the new fast algorithm for qualifying table spaces INSERT ALGORITHM zparm can change the default INSERT ALGORITHM table space attribute can override zparm 11

11 Significant CPU Reduction in DB2 Query Workloads Complex reporting, large sort UNION ALL w/view Complex Outer Join, UDF Simple query or large data scan 12 CPU Reduction % 12

12 DB2 12: Simplicity and RAS Dynamic SQL Plan Stability Stabilize performance of repeating dynamic SQL statements RUNSTATS automation Optimizer automatically update profile with RUNSTATS recommendations RLF control for static packages LOB compression Using zedc hardware DRDA Fast Load Callable command for fast load of data into DB2 directly from files on distributed client 13

13 Dynamic SQL Plan Stability Problem: Unstable performance of repeating dynamic SQL statements Environmental changes can result in change in access path or performance regression, and this can be tough to manage RUNSTATS applying sw maintenance DB2 release migration zparm changes schema changes Static SQL has several advantages Access path established at BIND time Static plan management gives advanced management functions Objective: extend static SQL advantages to dynamic SQL 14

14 Dynamic Plan Stability DB2 12 plan base infrastructure Opaque parameter CACHEDYN_STABILIZATION Capture Command with / without monitoring Global variable FREE EXPLAIN (current, invalid) Invalidation LASTUSED (identify stale statements) Instrumentation (query hash, explain, cache + catalog hit ratio) APPLCOMPAT is part of matching criteria Key DB2 12 limitations Temporal stabilization not currently included REBIND support not included No PLANMGMT/SWITCH/APREUSE 15

15 Capture options STBLGRP Stabilization group. Used to logically associate a related set of stabilized dynamic queries. THRESHOLD When a qualified query s execution count is greater than or equal to this integer constant, it will be scheduled for stabilization. Note: IFCID318 must be turned on. CURSQLID (*) Capture all cached statements that meet threshold (SQLID) Capture all statements with specified CURSQLID that meet threshold. MONITOR NO Stabilize queries currently in the cache that are eligible (i.e. meet CURSQLID and THRESHOLD criteria). YES Stabilize eligible queries currently in the cache, and also when they become eligible in the future (as long as monitor still active). This includes queries entering the cache after the MONITOR(YES) command was issued. STMTID / STMTTKN Capture a statement from the statement cache with specified STMTID, STMTTOKEN SCOPE LOCAL Capture only on local DB2 subsystem GROUP Start capture on all members of DB2 data sharing group

16 Capture examples 1. Capture individual statement -START DYNQUERYCAPTURE STBLGRP(APP1) STMTID(1253) Stabilize stmtid 1253 into catalog with stabilization group APP1. 2. Snapshot capture -START DYNQUERYCAPTURE STBLGRP(APP1) THRESHOLD(100) CURSQLID(APP1ID) MONITOR(NO) Capture statements in cache with APP1ID CURSQLID, and STAT_EXECB >= Capture with monitoring -START DYNQUERYCAPTURE STBLGRP(APP1) THRESHOLD(100) CURSQLID(APP1ID) MONITOR(YES) Capture eligible statements in the cache now (same as #2 above), and continue to apply criteria as long as the capture is active.

17 DB2 12 DRDA Fast Load Problem: DB2 provides the DSNUTILU stored procedure to load data from a client But this is difficult to use, app must transfer data to z/os file Solution: DB2 Client API (CLI and CLP) for remote load into DB2 Easy/fast loading of data from file that resides on client Internal format (SAP), as well as delimited and spanned (LOB data) Overlap network operations with data ingest on the DB2 server Measured results show as fast or faster than DB2 LOAD utility ziip eligible 18

18 DB2 12: Application Enablement Several SQLPL Improvements SQLPL in triggers, including versioning and debug support SQLPL obfuscation Support for constants Dynamic SQL in SQLPL UDFs and stored procedures ARRAY and LOB global variables Enhanced MERGE support New SQL Pagination syntax Piece-wise modification of data (DELETE) XMLModify multiple update support Bi-temporal improvements Inclusive/inclusive support Temporal RI Logical transaction for system time 19

19 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 Allow IGNORE and SIGNAL 20

20 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) 21

21 Piece-wise Modification of Data Mitigate the effects of locking and logging when potentially millions of rows could be affected by a simple statement like: "DELETE FROM T1 WHERE C1 > 7 Solution Allow the fetch clause to be specified on a searched delete statement DELETE FROM T1 WHERE C1 > 7 FETCH FIRST 5000 ROWS ONLY; COMMIT; 22

22 DBA Productivity DB2 12 Goals Relief for table scalability limits Simplify large table management Improve availability Agile schemas (more online schema changes) Security and compliance improvements Streamline migration process Utility performance, availability, usability 23

23 Partition By Range Current Limitations Maximum table size limited to 16Tb (4k pages) or 128Tb (32k pages) Maximum number of partitions is also dependent on DSSIZE and page size E.g. if DSSIZE = 256 GB and page size = 4K then Max Parts is 64 When Altering DSSIZE REORG must run on Entire Table Space DSSIZE is at Table Space Level not Part Level All Parts inherit the same DSSIZE set at Table Space No ability to have differing Partition sizes Altering DSSIZE requires REORG of entire tablespace 24

24 DB2 12 Lifting the Limits New PBR tablespace structure called PBR RPN Relative page numbers (RPN) instead of absolute Remove dependency between #partitions & partition size New RID is Relative RID Part Number stored in Partition Header Page Page number stored in Data Page, relative to start of the partition 25

25 DB2 12 Lifting the Limits Up to 1TB Partition Size, or 4 Petabytes (PB) per table space Maximum number of rows with 4K pages increased from 1.1 to 280 rows inserted per second, more than 8800 years to fill! Increasing DSSIZE is supported at partition-level New DSSIZE support for indexes Infrastructure changes positions for future enhancements Increase in partition limits, increase number of rows per page Attribute variance by partition, schema changes vis REORG PART 26

26 DB2 12 Online Schema Improvements Insert partition Ability to insert a new partition with specified limitkey value ALTER TABLE ADD PARTITION ENDING AT xxx Split existing partition, distribute data between new and old Online change through pending alter Only affected partition(s) need to be REORGed No PIT recovery prior to materializing REORG Online deferred ALTER INDEX COMPRESS YES Previously placed indexes in RBDP Option to defer column-level ALTERs Materialize through online REORG Avoid availability constraints & conflict with other deferred alters ZPARM to control default 27 TRANSFER OWNERSHIP

27 DB2 12 Data Sharing Improvements Performance improvements Lock avoidance UNLOAD and RUNSTATS with REGISTER NO Availability improvements Auto retry of GRECP and LPL recovery DB2 peer recovery Parallel Sysplex enhancements Async CF duplexing DRDA related enhancements 28

28 Utilities REORG Improved FlashCopy management REORG with only a FLASHCOPY inline image copy (no traditional IDs) now causes REORG to fail (RC=8) if the FLASHCOPY fails Improved part-level UTS PBG REORGs Supports creation of new PBG partition for overflow rows during a part level REORG Prevent copy-pending on LOB table spaces during REORG of PBGs Avoid leaving copy pending on LOB table spaces when new PBG partitions grown during log phase of REORG REORG-level management of delete of PBG partitions Add a new keyword, DROP_PART, for REORG empty UTS PBG partition pruning when zparm alteration is not feasible. 29

29 Utilities REORG Support new COMPRESSRATIO catalog column Add LOAD/REORG/RUNSTATS ability to gather average compression ratio at the record level instead of at the page saved level Up to 17% additional offload to ziip The reload phase can now be run on ziip New mapping table format support New format supports 7 byte RIDS needed with UTS PBR RPN support Permit REORG against RO pagesets REORG with any SHRLEVEL can be run against any RO table space and index Retrofitted back to service level with APAR PI46774 Display claimer information on each drain failure, not just last retry 30

30 Utilities LOAD LOAD PART REPLACE with dummy input against empty PBR partition NPI processing optimized to not scan the whole NPI to find keys to be deleted for the partition being RELACEd if it was already empty Reduced elapsed time and CPU time significantly if there were a lot of keys for the other logical parts of the NPI Up to 99% CPU, 98% ET reduction LOAD SHRLEVEL CHANGE PARALLEL support for PBG Modified to remove the single input parallelism restriction for PBG table spaces for LOAD SHRLEVEL CHANGE Lab measurements saw up to 76% elapsed time savins with some CPU overhead LOAD SHRLEVEL NONE PGB PARALLEL is still s restriction Up to 90% additional ziip offload RELOAD phase of the LOAD utility can be ziip offloaded This includes the data conversion and loading of the record into the page set 31

31 Utilities... LOAD LOAD RESUME SHRLEVEL NONE BACKOUT YES to avoid RECP for page set on failure New option to allow backout of rows already loaded upon encountering an error (such as conversion, LOB/XML, duplicate key, RI constraint) without leaving the page set in RECP PREFORMAT support for aux tables Indicates the remaining pages are preformatted for up to the highallocated RBA in the table space and index spaces that are associated with the table that is specified in table-name 32

32 Utilities... LOAD Maintain MAXASSIGNEDVAL for identity columns & sequences Maintains MAXASSIGNEDVAL for user provided input and also will reset the value if a LOAD REPLACE on the table space is run Eliminate datasharing overhead with UNLOAD ISO(UR) REGISTER NO option New options to bypass page registration in the Coupling Facility and avoid any data sharing overhead LOAD REPLACE support for COMPRESSRATIO column Gathers the average compress ratio at the record level instead of the page saved level 33

33 Utilities Backup & Recovery PIT recovery support for PBG table spaces Allow recovery of PBG UTS to a PIT prior to a REORG that materialized these physical pending alters: page size (buffer pool), DSSIZE, SEGSIZE, MEMBER CLUSTER FLASHCOPY_PPRCP parameter for RESTORE & RECOVER Allows users to specify/override the preserve mirror option for PPRC (sync disk mirroring) on the utility statement Previously RESTORE SYSTEM used HSM default; RECOVER used zparm FLASHCOPY_PPRC Option to skip PIT recovery for non-updated page sets New *default* behavior for PIT RECOVER utility objects which were not updated *after* the recovery point are skipped and not recovered Reasoning: data in these objects still reflect that PIT, so not need to recovery Saves CPU consumption and elapsed time Default behavior can be overridden with SCOPE(*ALL) 34

34 Utilities Backup & Recovery System Level Backup support for multiple copy pools BACKUP SYSTEM and RESTORE SYSTEM now support multiple copypools Allows the user to keep daily golden copy or backup for critical events DFSMShsm messages included in utility job output for BACKUP SYSTEM / RESTORE SYSTEM Improved messaging for BACKUP SYSTEM and RESTORE SYSTEM HSM and DSS messages are included in the DB2 utility job output so that user does not have to look in the (separate) HSM job logs for messages Available with z/os 2.2 COPY option to specify FASTREPLICATION(REQUIRED) New COPY utility zparm COPY_FASTREPLICATION REQ PREF NONE allows user control of whether FlashCopy is required during creations of the FlashCopy image copy With FASTREPLICATION REQUIRED, DSS will allocate target data set within same DASD box, ensuring that FlashCopy can be used Previously COPY defaulted to FASTREPLICATION PREFERRED 35

35 Utilities RUNSTATS USE PROFILE support for inline stats in REORG & LOAD COLGROUP inline stats support for LOAD PARALLEL INVALIDATECACHE option to avoid dynamic cache invalidation Default behavior has changed to not invalidate prepared statements COLGROUP performance 25% CPU, 15% ET reduction When COLGROUP column specifications are redundant with INDEX columns, the duplicate COLGROUP is ignored in lieu of the index processing 36

36 Utilities RUNSTATS New DSNUTILV stored procedure supporting CLOB input >32Mb DSNUTILV UTSTMT utility statement parameter is now a CLOB instead of a VARCHAR, so DB2 now supports a 4 byte length (up to 2 GB) For existing applications still passing a VARCHAR, DB2 will do the conversion from VARCHAR to CLOB DSNACCOX changes for REORG avoidance Number of recommendations reduced by changing the default for recommending REORG based on the number of inserts and pseudo deletes since the last REORG to off Removed the criteria of recommending a REORG based on REORGLASTTIME, LOADRLASTTIME, or REBUILDLASTTIME being NULL Improved utility concurrency for MODIFY, COPYTOCOPY, MERGECOPY Allows MODIFY RECOVERY, COPYTOCOPY, MERGECOPY and exclusive utilities like LOAD and REORG to run concurrently on the same target objects 37

37 Migration & Catalog Single phase migration process No ENFM phase New function activated through new command -ACTIVATE FUNCTION LEVEL APPLCOMPAT rules, fallback rules continue to apply BSDS conversion to support 10 byte log RBA is pre-requisite BRF is deprecated BRF pagesets still supported, but zparm & REORG options are removed Temporal RTS tables Defined in catalog, enablement is optional 38

38 Migration Overview DB2 11 NFM à DB2 12 DB2 11 New Function Mode (NFM) With SPE PI33871 DSNTIJTC (CATMAINT) DB2 12 Before new function activated Command: -ACTIVATE FUNCTION LEVEL(V12R1M500)) DB2 12 After new function activated DB2 11 Catalog DB2 12 Catalog 1 2 months DB2 11 Libraries Coexist or fallback 1 week Data Sharing Coexistence DB2 12 Libraries Use APPLCOMPAT(V10R1 or V11R1) here APPLCOMPAT (V10R1, V11R1, and V12R1M500) available 39

39 Beyond DB2 12 Continuous Delivery Starting with DB2 12 New Function will ship in the maintenance stream Rationale: Faster delivery of new features to customers Easier for customers to consume new features Enabling new function is controlled by use of Catmaint -ACTIVATE FUNCTION LEVEL APPLCOMPAT APPLCOMPAT is extended to apply to DDL, DCL, and to control IBM Data Server Driver Packages (ODBC, JDBC,.Net, PHP, RUBY SAP). SYSLEVELUPDATES contains History on when system changes occurred 40 Documentation will change to help highlight new function

40

41 DB2 Data-as-a-service DB2 Adapter for z/os Connect V1 Delivered Dec 11,

42 Session feedback Please submit your feedback at Session is 1A