Your SlideShare is downloading. ×
Webcast  _db2_11_for_zos_migration_planning_and_early_customer_experiences__part_2_prz
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Webcast _db2_11_for_zos_migration_planning_and_early_customer_experiences__part_2_prz

569

Published on

Webcast_db2_11_for_zos_migration_planning_and_early_customer_experiences__part_2_prz

Webcast_db2_11_for_zos_migration_planning_and_early_customer_experiences__part_2_prz

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
569
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. John Campbell Distinguished Engineer IBM DB2 for z/OS Development Campbelj@uk.ibm.com DB2 11 for z/OS: Migration Planning and Early Customer Experiences - Part 2
  • 2. Disclaimer: 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 Disclaimer: This document contains performance information based on measurements done in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon 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 throughput or performance improvements equivalent to the numbers stated here. 2
  • 3. Objectives • Share lessons learned, surprises, pitfalls • Provide hints and tips • Address some myths • Provide additional planning information • Provide usage guidelines and positioning on new enhancements • Help customers migrate as fast as possible, but safely 3
  • 4. Objectives • Share lessons learned, surprises, pitfalls • Provide hints and tips • Address some myths • Provide additional planning information • Provide usage guidelines and positioning on new enhancements • Help customers migrate as fast as possible, but safely 4
  • 5. Agenda • Introduction • ESP Highlights • Migration Considerations • Availability • Utilities • Performance and Scalability • Other Enhancements • Summary 5
  • 6. 6 Performance and Scalability
  • 7. 7 Performance Enhancements - no REBIND needed (CM) • DDF performance improvements – Reduced SRB scheduling on tcp/ip receive using new CommServer capabilities – Improved autocommit OLTP performance • xProcs above the bar • zIIP enablement for all SRB-mode DB2 system agents that are not response time critical • Avoid cross-memory overhead for writing log records • Data decompression performance improvement • INSERT performance – Latch contention reduction – CPU reduction for Insert column processing and log record creation – Data sharing LRSN spin avoidance – Page fix/free avoidance in GBP write
  • 8. 8 Performance Enhancements - no REBIND needed (CM) ... • Sort performance improvements • DPSI performance improvements for merge • Performance improvements with large number of partitions • XML performance improvements • Optimize RELEASE(DEALLOCATE) execution so that it is consistently better performing than RELEASE(COMMIT) • IFI 306 filtering capabilities to improve Replication capture performance • Utilities performance improvements • Automatic index pseudo delete clean-up • ODBC/JDBC Type 2 performance improvements • Java stored procedures – Multi threaded JVMs, 64-bit JVM – more efficient
  • 9. 9 Performance Enhancements – no REBIND needed (CM) ... • ACCESS DATABASE command performance • DGTT performance improvement – Avoid incremental binds for reduced CPU overhead • P-procs for LIKE predicates against Unicode tables • Improved performance for ROLLBACK TO SAVEPOINT • zEC12 exploitation • Latch contention reduction and other high n-way scalability improvements • Data sharing performance improvements
  • 10. 10 Performance Enhancements requiring REBIND (CM with or without REUSE) • Most In-memory techniques • Non correlated subquery with mismatched length • Select list do-once • Column processing improvements • RID overflow to workfile handled for Data Manager set functions • Performance improvements for common operators • DECFLOAT data type performance improvements
  • 11. 11 Performance Enhancements requiring REBIND (CM without REUSE) • Query transformation improvements – less expertise required to write performant SQL • Enhanced duplicate removal • DPSI and page range performance improvements • Optimizer CPU and I/O cost balancing improvements
  • 12. 12 Performance Enhancements - DBA or application effort required (NFM) • Suppress-null indexes • New PCTFREE FOR UPDATE attribute to reduce indirect references • DGTT performance improvements • Global variables • Optimizer externalization of missing/conflicting statistics • Extended optimization - selectivity overrides (filter factor hints) • Open data set limit raised to 200K
  • 13. 13 Optional Enhancements need NFM + DBA effort • DSNTIJCB – Optional – Convert BSDS for extended 10-byte RBAs – - STOP DB2 MODE(QUIESCE) • DSNTIJCV – Optional – Convert Catalog and Directory table and index spaces to extended 10-byte RBA format – Reorgs all Catalog and Directory table spaces SHRLEVEL CHANGE – Can be split up to run reorgs in parallel
  • 14. DB2 Lab Measurement Summary 14 Query Batch OLTP XML
  • 15. Example of Customer Performance Testing • DB2 10 NFM baseline • DB2 11 CM before REBIND • DB2 11 CM after REBIND • DB2 11 NFM (no need for further REBIND) • DB2 11 NFM after REORG (to migrate object to extended LRSN) • DB2 11 NFM Extended LRSN
  • 16. Example of Customer Performance Testing ... • Make sure that the CPU numbers are normalized across those intervals i.e., use CPU milliseconds per commit • Easy to combine statistics and accounting by stacking the various components of CPU resource consumption: – MSTR TCB / (commits + rollbacks) – MSTR SRB / (commits + rollbacks) – DBM1 TCB / (commits + rollbacks) – DBM1 SRB / (commits + rollbacks) – DBM1 IIP SRB / (commits + rollbacks) – IRLM TCB / (commits + rollbacks) – IRLM SRB / (commits + rollbacks) – Average Class 2 CP CPU * occurrences / (commits + rollbacks) – Average Class 2 SE CPU * occurrences / (commits + rollbacks)
  • 17. CICS Test Transaction Profile Avg. DML •3 Insert •7 Select •5 Open •103 Fetch Avg. Buffer pool •65 Getpages •13 Sync Read CPU consumption •Class 1: 3.2 msec •Class 2: 2.3 msec With CP-Speed 802 MIPS Fetch Intensive • Transaction types – E-Bank logon – Balance check – Financial Statement history – Account search
  • 18. CICS transaction CPU time
  • 19. DB2 system address space CPU per CICS transaction Activity moved to zIIP in CM
  • 20. Test Batch job profile DML • Commits: 4528 • Delete: 37613 • Rows: 482836 • Update: 45099 • Select: 119773 • Insert: 525884 • Fetch: 548947 Buffer pool • Getpage: 4.8 M • Sync Read: 133 K • Dyn Pref: 57 K CPU • Class 1: 69 Sec • Class 2: 67 Sec With CP-Speed 802 MIPS Elapsed: • Class 1: 07:02 min Insert and Delete Intensive
  • 21. Batch test CPU time LRSN spin loop eliminated in V11 E L No credit to V11 For V11 Reo improvement
  • 22. DB2 system address space CPU for Batch Activity moved to zIIP In CM LRSN spin loop eliminated in 11 EL reduces MSTR SRB
  • 23. TPC-H using Static SQLPL • 10% out-of-box improvement with DB2 11 when rebinding with APREUSE • 34% improvement in DB2 11 when rebinding to obtain DB2 11 access path 23 -1.4% -10% -34%
  • 24. 24 Automatic Pseudo Deleted Index Entry Clean-up • Recap on impact of pseudo deleted index entries – Index size grows with increasing number of pseudo-deleted index entries • More getpages and lock requests required • Increased CPU cost and possibly longer elapsed times for access via index search – Applications may encounter deadlocks and timeouts during INSERT/UPDATE/DELETE • Collisions with committed pseudo-deleted index entries • RID reuse by INSERT following DELETE => deadlock • Prior to V11, how are they cleaned up – DB2 removes pseudo-deleted entries during mainline operations • Insert / delete operations remove pseudo-deleted entries from index pages • SQL running with isolation level RR removes pseudo-deleted entries – Pages that only contain pseudo-deleted index entries are called pseudo-empty • DB2 attempts to clean up pseudo-empty index pages as part of DELETE processing – REORG INDEX removes pseudo-empty index pages and pseudo-deleted entries that were not cleaned up by the mainline processing
  • 25. 25 Automatic Pseudo Deleted Index Entry Clean-up … • Autonomic solution provided in CM and turned on automatically for all indexes 24*7 – Automatic clean-up of pseudo-deleted index entries in index leaf pages – Automatic clean-up of pseudo-empty index pages – Designed to have minimal or no disruption to concurrent DB2 work – Clean-up is done under system tasks, which run as enclave SRBs and are zIIP eligible – Parent thread (one per DB2 member) loops through RTS to find candidate indexes – Child clean-up threads only clean up an index if it already is opened for INSERT, UPDATE or DELETE on the DB2 member • Avoid creating GBP dependency on indexes • Potential disruption can be minimized by managing down the number of clean-up threads or specifying time when indexes are subject to clean-up – Can control the number of concurrent clean-up threads or disable the function using zparm INDEX_CLEANUP_THREADS • 0=Disable, 1-128, 10 is default – Entries in new Catalog table SYSIBM.SYSINDEXCLEANUP • Define when / which objects are to be considered in a generic way
  • 26. Automatic Pseudo Deleted Index Entry Clean-up • Up to 39% DB2 CPU reduction per transaction in DB2 11 compared to DB2 10 • Up to 93% reduction in Pseudo deleted entries in DB2 11 • Consistent performance and less need of REORG in DB2 11 26
  • 27. 27 Performance Enhancements • Qreplication log filtering – Reduce IFI log read cost by qualifying the objects with DBID/PSID – Additional benefit if objects are compressed – Move filtering from Qreplication capture task to DB2 engine – Potential for very significant reduction in the number of log records replicated – Requires IBM Infiophere Data Replication Q Replication or Change Data Capture 10.2.1 • Archive Transparency – Very useful new feature – Need to carefully examine the additional cost of ORDER BY sort when accessing the archive – When application only fetches a limited number of rows from the result set then the cost can increase significantly when also accessing the archive – Will typically be used by customers selectively on a case by case basis
  • 28. 28 Performance Enhancements … • Optimizer enhancements – Improved performance for legacy application programs – Better chance of achieving matching index scan – No need to rewrite SQL to get most of the improvements – Still important to choose the right data type and avoid implicit casting – Still very important to run RUNSTATS • GROUP BY grouping sets – Important feature for data analysis: CUBE, ROLLUP – All processing is performed in a single pass over the table – But there are some performance differences relative to the old GROUP BY with the same result set • SELECT C1, COUNT(*) FROM T1 GROUP BY C1 – No sort performed if the access path uses an index with leading column C1 • SELECT C1, COUNT(*) FROM T1 GROUP BY GROUPING SETS ((C1)) – A sort is always performed
  • 29. 29 Extended LRBA/LRSN • What you need to know for DB2 11 CM and DB2 10 NFM? – 6 byte format - LRBA/LRSN before DB2 11  x‘LLLLLLLLLLLL’ – 10 byte extended format– LRBA/LRSN has addressing capacity of 1 yottabyte (2**80) • 10 byte extended format - LRSN with DB2 11  x‘00LLLLLLLLLLLL000000’ • 10 byte extended format - LRBA with DB2 11  x‘00000000RRRRRRRRRRRR’ – Where do we find LRBA/LRSN? • DB2 Catalog  SYSCOPY, SYSxxxxPART, ….. • DB2 Directory  SYSUTILX, SYSLGRNX, …. • BSDS  pointer, Active & Archive Log values.. • DB2 Logs  active & archive logs • DB2 Pagesets  Catalog & Directory and all user-pagesets
  • 30. 30 Extended LRBA/LRSN … • What you need to know for DB2 11 CM and DB2 10 NFM? … – DB2 11 CM • DB2 internal coding deals with 10 byte extended format LRBA/LRSN values only • LRSN in Utility output is shown in 10 byte extended format with precision ‘000000’ except – QUIESCE utility, which externalizes LRSN in 10 byte extended format with precision ‘nnnnnn’ • RECOVER utility handles 10 byte extended format LRBA/LRSN input • Column ‘RBA_FORMAT’ in SYSIBM.SYSxxxPART is set to ‘B‘ for new defined or objects, which are reorged or loaded with replace-option (possible values ‚B, blank‚ U, E) – DB2 11 CM / DB2 10 NFM coexistence in data sharing • Full toleration of 10 byte extended format LRBA/LRSN value as input to the RECOVER Utility • Sanity checks included for ‘wrongly used 6 byte format LRBA/LRSN’
  • 31. 31 Extended LRBA/LRSN … • What you need to know for DB2 11 NFM? – Migration to DB2 11 NFM (via DSNTIJEN) • Catalog & Directory Table ‘LRBA/LRSN Columns’ are altered to 10 byte extended format • SYSIBM.SYSLGRNX entries are now stored as 10 byte extended format LRBA/LRSN values • SYSIBM.SYSCOPY – Conversion of all LRBA/LRSN values is done for existing data to 10 byte extended format with leading byte ‘00’ and precision, ‘000000’ for LRSN and right justified right with leading ‘00000000’ for LRBA values – New data is stored in 10 byte extended format with precision ‘nnnnnn’ • LRBA/LRSN for all Utilities use now 10 byte extended format • LRBA/LRSN values are still written to DB2 logs in 6 byte format • LRBA/LRSN values are still written to DB2 pagesets in 6 byte format
  • 32. 32 Extended LRBA/LRSN … • What you need to know for DB2 11 NFM? … – BSDS converted to 10 byte extended format LRBA/LRSN in NFM only (DSNJCNVT) • There is no way back for BSDS! • Now LRBA/LRSN values are written to DB2 logs of the subject DB2 member now in 10 byte extended format with precision ‘nnnnnn’ • LRBA/LRSN values are still written to DB2 pagesets in 6 byte format – Conversion (10 to 6 or 6 to 10 byte) has to be done – LRSN Spin can still happen – DSN1LOGP and REPORT RECOVER output will show 10 byte extended format LRBA/LRSN although never externalized to pagesets (different output, for DSN1PRNT of pagesets) • Can be done, whenever you want to do it after entry to V11 NFM, regardless of pageset formats
  • 33. 33 Extended LRBA/LRSN … • What you need to know for DB2 11 NFM? … – Reorg Catalog and Directory pagesets to ‘extended format’ (in NFM only!) • Can be done whenever you want to, regardless of BSDS and user pageset formats • Now LRBA/LRSN values are written to converted pagesets in 10 byte extended format – LRSN with precision ‘nnnnnn’, if update is done on a DB2 member with 10 byte extended format BSDS – LRSN with precision ‘000000’, if update in done in a member with 6 byte format BSDS • Column ‘RBA_FORMAT’ in SYSIBM.SYSxxxPART is updated to ‘E’ • LRSN Spin could still happen for DB2 member with 6 byte format BSDS • Can be converted back to 6 byte format (all or at part level)
  • 34. 34 Extended LRBA/LRSN … • What you need to know for DB2 11 NFM? … – Reorg User pagesets to ‘extended format’ (in NFM only!) • Can be done whenever you want to, regardless of BSDS, Catalog & Directory pageset formats • Now LRBA/LRSN values are written to converted pagesets in 10 byte extended format – LRSN with precision ‘nnnnnn‘, if update is done in a member with 10 byte extended format BSDS – LRSN with precision ‘000000‘, if update in done in a member with 6 byte format BSDS • Column ‘RBA_FORMAT’ in SYSIBM.SYSxxxPART is set to ‘E‘ • LRSN Spin could still happen for a DB2 member with 6 byte format BSDS • Can be converted back to 6 byte (all or at part level) • Is done by REORG, LOAD .. REPLACE or REBUILD with ‘RBALRSN_CONVERSION EXTENDED’ or if zparm OBJECT_CONVERTED=EXTENDED • ‘RECOVER ... TOCOPY ...’ using a 6 byte Copy can reset format back to ‘basic’
  • 35. 35 Extended LRBA/LRSN … • Enhancements to improve usability characteristics based on 6 byte/10 byte format LRBA/LRSN handling – Prevent DSNJCNVT from converting DB2 10 NFM BSDS to extended format – Support 10 byte extended format input to RECOVER in DB2 10 – Perform sanity checks to guard against invalid LRSN values i.e., 6 byte LRSN values with leading byte of zeros, to prevent PIT recoveries using bad RBA/LRSN from failing (RC=8 in UTILINIT phase instead) – Sanity check also performed in DB2 10 (coexistence) – Support for ‘NOBASIC’ value for OBJECT_CONVERSION zparm to prevent converting back pagesets in extended format , and to ‘EXTENDED’ as default if ‘NOBASIC’ is set and catalog column is <> ‘E’ – Add LRSN values to archive log information in REPORT RECOVERY utility output – Technical white paper being produced explains about ‘6/10 byte LRBA/LRSN handling’ – Several enhancements to DB2 11 books
  • 36. 36 Extended LRBA/LRSN … • Recommended best practice migration strategy 1. Run pre-migration jobs and steps to clean-up 2. Migration to DB2 11 CM 3. Migration to DB2 11 NFM 4. Convert ALL BSDS of data sharing group within ‘n’ weekends 5. Reorg ALL Directory & Catalog Pagesets to ‘extended LRBA/LRSN format’ 6. Set OBJECT_CREATE and UTILITY_CONVERSION zparms to EXTENDED - New objects will be created in 10 byte extended format - REORG, LOAD REPLACE and REBUILD will convert user objects to extended format without need to change utility control statements 7. Reorg all objects to extended LRBA/LRSN format by executing normal reorg jobs or some additional jobs • Perform regular check for ongoing progress by selecting rows where RBA_FORMAT = ‘E’ in SYSIBM.SYSxxxxPART 8. If all done, set OBJECT _CONVERSION zparm to NOBASIC
  • 37. 37 How to convert 10 byte LRSN to Timestamp • DB2 10 NFM or less – use TIMESTAMP function LRSN-format: 6 byte wherever used from  e.g. ‘CBE2B5955DCF’ convert by: SELECT TIMESTAMP(x'CBE2B5955DCF ' || x'0000') from …. • DB2 11 CM – use TIMESTAMP function LRSN-format: 6 byte in logs, catalog and directory, pages  e.g. ‘CBE2B5955DCF’ 10 byte in all outputs (except DSN1PRNT) e.g. ‘00CBE2B5955DCF086C00’ convert by: SELECT TIMESTAMP(x'CBE2B5955DCF ' || x'0000') from ….
  • 38. 38 How to convert 10 byte LRSN to Timestamp … • DB2 11 NFM – use TIMESTAMP function LRSN-format: 6 byte for non-converted data pages (DSN1PRNT)  e.g. ‘CBE2B5955DCF’ 10 byte in Catalog and Directory and in all outputs  e.g. ‘00CBE2B5955DCF086C00’ convert by: SELECT TIMESTAMP(x'CBE2B5955DCF ' || x'0000') from …. 6 byte LRSN can be used by ‘cut and paste’ 10 byte LRSN can be used, if first 2-digits are cut and digits 3 to 14 are used, but only if first two digits are ‘00’ otherwise this conversion is NOT usable! SELECT TIMESTAMP(bx'CBE2B5955DCF0000') from …. 6 byte LRSN can be used by ‘cut and paste’ and padded with ‘0000’ at the right 10 byte LRSN can be used, if first 2-digits are cut and digits 3 to 18 are used, but only if first two digits are ‘00’ otherwise this conversion is NOT usable!
  • 39. 39 How to convert 10 byte LRSN to Timestamp … • DB2 11 NFM – use new ‘binary hex’ function – SELECT TIMESTAMP(bx'00CBE2B5955DCF086C00000000000000') from ...  6 byte LRSN can be used by ‘cut and paste’, ‘00’ in front of and padded with ‘000000000000000000’ digits at the right  10 byte LRSN can be used by ‘cut and paste’ and right padded with ‘000000000000’ – (BX’ can be replaced by (BINARY(X’ or (VARBINARY(X’….. – Convert 10 byte RBA/LRSN to Timestamp  Works great, but need APPLCOMPAT(V11R1)!
  • 40. 40 Other performance recommendations • Make sure HVCOMMON in IEASYSxx can accommodate log output buffer • Configure additional 1MB LFAREA (z/OS parameter in IEASYSxx) for maximum benefit • LRSN spin avoidance requires both BSDS and objects conversion in NFM • Monitor log I/O performance due to log record size increase – 3% to 40% increase in log record size observed following BSDS conversion • Essential to make sure enough zIIP capacity available before V11 CM migration – zIIP ‘Help Function” IIPHONORPRIORITY should be set to YES in case there is a shortage of zIIP capacity – Continue to monitor zIIP capacity thereafter • Bufferpool re-classification change - prefetched pages will again be reclassified as random after random getpage – May need to re-evaluate VPSEQT setting for certain bufferpools • MRU (Most Recently Used) used for pages brought in by utilities • New FRAMESIZE parameter independent from PGFIX parameter
  • 41. 41 Performance Summary • Opportunity for improved performance for legacy application programs • Your mileage will vary based on your SQL application workload as certain features only apply to certain workloads • Immense CPU savings observed for some workloads • Highly optimized static SQL and/or simple SQL may not see much benefit • More benefit for more complex SQL i.e., not read a single row by primary key • Do not sell (or buy) the savings before you have seen them for your workload
  • 42. 42 Other Enhancements
  • 43. 43 Remove package security vulnerabilities • Problem use case scenario – Each main routine has it’s own plan and both names are the same – All packages are bound into a single collection – Each plan is bound with PKLIST(col.*) – If EXECUTE privilege is granted on one plan, this authid/user can run any main program • Solution – New BIND PLAN option PROGAUTH supported by a new table SYSIBM.DSNPROGAUTH in the Catalog – To ensure that a main program M can only be executed with plan P • Insert row into SYSIBM.DSNPROGAUTH with PROGNAME M, PLANNAME P, ENABLED Y • Bind plan P with PROGAUTH(ENABLE)
  • 44. 44 Archive transparency • Create an archive-table and connect the base-table to the archive-table – Via ALTER base-table ENABLE archive clause – Archive-table and base-table must have exactly the same columns – No additional columns are allowed e.g., archive-timestamp • Set SYSIBMADM.MOVE_TO_ARCHIVE global variable to ‘Y’ or ‘E’ – DB2 automatically moves deleted rows to the archive table – If set to ‘Y’, update to rows will fail with SQLCODE -20555 – If set to ‘E’ , update will only work for active rows in the base table – Delete of active rows in the base table will then appear in the archive-table • If SYSIBMADM.MOVE_TO_ARCHIVE global variable is set to ‘N’ – Delete of active rows in the base table are lost – So important to check that the setting of the global variable to ‘Y’ or ‘E’ actually worked as ‘N’ is the default value
  • 45. 45 Archive transparency … • Must set SYSIBMADM.GET_ARCHIVE global variable to ‘Y’ for query to search the rows from the archive-table – Update only applies to active rows in the base-table • Subsequent query may get updated rows and not updated rows • ARCHIVESENSITIVE (YES|NO) option on package BIND – Only affects read from archive-table – Deleted rows will only be moved to archive-table if MOVE_TO_ARCHIVE global variable is set correctly • REORG DISCARD on base-table – Generates LOAD statement to load rows into the archive-table – DISCARD dataset can be used as input • Dynamic scrollable cursors are not allowed • Package owner must have the WRITE privilege for the respective global variables
  • 46. 46 Summary
  • 47. 47 Summary • Share lessons learned, surprises, pitfalls • Provide hints and tips • Address some myths • Provide additional planning information • Provide usage guidelines and positioning on new enhancements • Help customers migrate as fast as possible, but safely
  • 48. DB2 11 Resources 48 • IBM Information Center / Knowledge Center • DB2 11 Technical Overview Redbook (SG24-8180) • DB2 11 links: https://www.ibm.com/software/data/db2/zos/family/db211/ – Links to DB2 11 Announcement Letter, webcasts and customer case studies – Whitepaper: “DB2 11 for z/OS: Unmatched Efficiency for Big Data and Analytics” – Whitepaper: “How DB2 11 for z/OS Can Help Reduce Total Cost of Ownership” • DB2 11 Migration Planning Workshop – http://ibm.co/IIJxw8 • Free eBook available for download – http://ibm.co/160vQgM • “DB2 11 for SAP Mission Critical Solutions” – http://scn.sap.com/docs/DOC-50807
  • 49. Join The World of DB2, Big Data & Analytics on System z 49
  • 50. Thank You for Joining Us today! If you would take a moment to fill out the feedback form by clicking on the survey link now appearing in your slide window, it would be greatly appreciated. Your comments are very important to us. Go to www.ibm.com/software/systemz/events/calendar to: Replay this webcast View previously broadcast webcasts Register for upcoming webcasts

×