DB2 Design for High Availability and Scalability

784 views

Published on

Are you overwhelmed by the growing amount of data in your environment? Are you maximizing application availability? As the number of tables with billions of rows continues to grow, so do the management challenges. In this session, we will discuss the challenges and solutions for optimum availability and performance, with techniques to efficiently and effectively manage very large amounts of data.

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

  • Be the first to like this

No Downloads
Views
Total views
784
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Laboratory measurements and early customer experience have shown substantial savings in the primary constrained address space, DBM1. Most measurements have shown 75% to 90% savings for the virtual storage in that address space below the 2 GB bar. Some EDMPOOL and some working storage remains below the bar. This storage relief allows many more threads or concurrent users in a DB2 subsystem, allowing new possibilities for optimization. Some customers will be able to consolidate data sharing members, saving on memory, CPU and administration time. Other customers will be able to use the storage to improve service or to reduce CPU time more. Some common examples are expected to be use of RELEASE(DEALLOCATE) and larger amounts of dynamic statement cache.
  • Increasing the number of concurrent threads will expose the next tier of constraints. DB2 10 will address these as well. The UTSERIAL lock means that scheduling 20 concurrent REORGs for hundreds of partitions in each one will result in timeouts or deadlocks too often. Reducing the granularity by removing this lock means that the jobs run instead of fail. DB2 10 eliminates the use of UTSERIAL by DB2 utilities. This enhancement prevents the majority of timeouts on the global UTSERIAL lock resource. Improving the catalog structure to allow row level locking can improve concurrency substantially. The DB2 catalog structure is changed to move most of the large fields with repeating rows of data into LOB columns, eliminating the 64 GB limit and making the information more readable by separating character from binary data. The LOB columns are inline for improved performance.
  • The DB2 catalog and directory are restructured in DB2 10 ENFM to improve productivity and availability. You’ll see these improvements in NFM. The current size limits are increased substantially and contention among process like BIND, dynamic SQL, data definition and utilities is reduced. With more table spaces and more structures, more work is required for some process, such as BIND. The primary techniques are changes in the DB2 catalog to remove links and the special structures for the catalog. These table spaces change from many tables to one table per table space in a partition by growth table space defined as DSSIZE 64 GB and MAXPART 1. Row level locking is used in place of page level locking. The new catalog tables use a partition by growth universal table space structure. Each table space holds a single table, so many more table spaces are needed. Rather than repeating columns with parts of long strings, the catalog will use CLOB and BLOB columns to store the data, expanding maximum sizes. Inline LOBs are used for the performance improvements. The new structure allows more standard processes, so that all catalog tables can be reorganized and checked online. The DB2 catalog changes from using manual definition and extension to DB2 managed data sets under SMS control. The changes improve productivity and availability, but take time to set up.
  • APAR PM26480 for online DDF changes. Up to 40 dynamic aliases allowed.
  • Graph is LOBs unloaded in seconds.
  • Notes for use of fc: No unload from a flashcopy. Solution would be to create a sequential copy from the fc and then unload from that. If fc were to fail on REORG then REORG will complete but object will be left in copy-pending.
  • Notes for use of fc: No unload from a flashcopy. Solution would be to create a sequential copy from the fc and then unload from that. If fc were to fail on REORG then REORG will complete but object will be left in copy-pending.
  • IBM IOD 2011 02/21/13 Prensenter name here.ppt 02/21/13 15:41
  • DB2 Design for High Availability and Scalability

    1. 1. IBM Software GroupDB2 10 for z/OS;BreakingBarriers and BeyondDesigning forAdvanced Availabilityand Scalablity © 2010 IBM Corporation
    2. 2. Migration Planning Workshop Disclaimer and TrademarksInformation contained in this material has not been submitted to any formal IBM review and is distributed on "as is" basiswithout any warranty either expressed or implied. Measurements data have been obtained in laboratory environment.Information in this presentation about IBMs future plans reflect current thinking and is subject to change at IBMsbusiness discretion. You should not rely on such information to make business plans. The use of this information is acustomer responsibility.IBM MAY HAVE PATENTS OR PENDING PATENT APPLICATIONS COVERING SUBJECT MATTER IN THISDOCUMENT. THE FURNISHING OF THIS DOCUMENT DOES NOT IMPLY GIVING LICENSE TO THESE PATENTS.TRADEMARKS: THE FOLLOWING TERMS ARE TRADEMARKS OR ® REGISTERED TRADEMARKS OF THE IBMCORPORATION IN THE UNITED STATES AND/OR OTHER COUNTRIES: AIX, AS/400, DATABASE 2, DB2, e-business logo, Enterprise Storage Server, ESCON, FICON, OS/390, OS/400, ES/9000, MVS/ESA, Netfinity, RISC, RISCSYSTEM/6000, System i, System p, System x, System z, IBM, Lotus, NOTES, WebSphere, z/Architecture, z/OS, zSeriesThe FOLLOWING TERMS ARE TRADEMARKS OR REGISTERED TRADEMARKS OF THE MICROSOFTCORPORATION IN THE UNITED STATES AND/OR OTHER COUNTRIES: MICROSOFT, WINDOWS, WINDOWS NT,ODBC, WINDOWS 95For additional information see ibm.com/legal/copytrade.phtmlDISCLAIMER: Information regarding potential future products is intended to outline our general product direction and itshould not be relied on in making a purchasing decision. The information mentioned regarding potential future products isnot a commitment, promise, or legal obligation to deliver any material, code or functionality. Information about potentialfuture products may not be incorporated into any contract. The development, release, and timing of any future features orfunctionality described for our products remains at our sole discretion. 2 © 2010 IBM Corporation
    3. 3. Migration Planning Workshop Focus on avoiding outages and “show stoppers” Availability Scalability To be able to make changes to the To avoid outages caused either by subsystem or member without system or object size limits causing an system outage – TS physical limits(Segmented – CDB updates(add another DB2 server) TS 64g limit;Partition DSSIZE limit(PM42175) ) – DDF/TCPIP member subsetting – Workfile sort record cannot – Log RBA/LRSN limit span pages(32k) limit-sort reached(DB2 11) key limit(16k) – Add active log – RID pool failures causing TS To be able to make changes to DB2 scans objects without causing an object To avoid DB2 outages caused by outage(read or read write) Virtual Storage Constraint – Rename or drop(DB2 11) a – 64 bit addressing column – Migrate to UTS from PTS or – Increase number of active segmented threads by a factor of 10 – Alter Limit Key(DB2 11) – New Storage zparms to avoid – Online-Reorg the runaway DB2/LPAR shutdown Catalog/Directory3 © 2010 IBM Corporation
    4. 4. Migration Planning WorkshopDB2 10 Virtual Storage Constraint Relief-Scalability DB2 10 DBM1 below 2GB Global DSC CT/PT – 75-90% less usage in DB2 10 compared to DB2 9 DBD – Some of working storage (stack, Local DSC xproc storage) stays below 2GB SKCT Thread / Stack SKPT Larger number of threads – Possible data sharing member consolidation Thread / Stack/ working storage Improve CPU with storage 75-90% less usage – More release deallocate DBM1 below bar – Larger MAXKEEPD values for after REBIND KEEPDYNAMIC=YES 4 © 2010 IBM Corporation
    5. 5. Migration Planning WorkshopAvailability:Managing DB2 Storage and avoiding DB2outage Real storage – Need to carefully plan, provision and monitor real storage consumption even in DB2 10 – Prior to V10 a hidden zparm SPRMRSMX (‘real storage kill switch’) existed • SPRMRSMX prevents a runaway DB2 subsystem from taking the LPAR down – Should be used when there is more than one DB2 subsystem running on the same LPAR – Aim is to prevent multiple outages being caused by a single DB2 subsystem outage – Should to set to 2x normal DB2 subsystem usage – Kills the DB2 subsystem when SPRMRSMX value reached5 5 25/02/2013 © 2010 IBM Corporation
    6. 6. Migration Planning WorkshopAvailability:Managing DB2 Storage and avoiding a DB2outage cont.. • SPRMRSMX hidden zparm now becomes an opaque parameter REALSTORAGE_MAX • Will also introduce DISCARD mode to contract storage usage to protect against excessive paging and use of AUX – New zparm REALSTORAGE_MANAGEMENT controls when DB2 frees storage frames back to z/OS > ON -> Discard unused frames all the time - discard stack, thread storage, keep footprint small > OFF -> Do not discard unused frames unless things are getting out of hand > AUTO (default) -> Detect whether paging is imminent and try to reduce the frame counts to avoid system paging – With AUTO, DB2 monitors paging rates, switches between ON/OFF and decides when to discard frames based on > 80% of SPRMRSMX reached > 50% of AUX (ENF55 condition) used > Hitting AVQLOW (available real storage frame) – New messages (DSNV516I, 517I) for when paging rate thresholds cause DB2 to free real frames • Strong recommendation to apply PTF for APAR PM24723 before going into business production and to run with REALSTORAGE_MANAGEMENT=AUTO 6 © 2010 IBM Corporation
    7. 7. Migration Planning WorkshopOther Availability & Scalability Improvements Reduced latch and lock contention – Improved efficiency for latch suspend/resume – UTSERIAL lock elimination New access currently committed option for readers to avoid waiting for inserters or deleters Use 64-bit common storage to avoid ECSA constraints DB2 10 NFM catalog restructure improves BIND / Prepare concurrency Remove SPT01 64Gb constraint (inline LOB’s and Compression) Improved accounting rollup, compress SMF option – Reduced SMF data volume Lower overhead for very large buffer pools Group Bufferpool write-around protocol enablement for heavy group buffer pool write pageset(DB2 11) 7 © 2010 IBM Corporation
    8. 8. 8 Migration Planning Workshop Major changes in DB2 10 catalog & directory Improve availability and productivity Increase maximum size substantially Reduce contention: BIND, Prepare, Utilities – DDL concurrency also improved from removal of DBD01 hash anchor locks Catalog changes: Remove links, hashes – Many more table spaces, partition by growth – Row level locking, reordered row format – CLOB and BLOB columns for long strings o Inline for performance – Online reorganization and check – More automatic: DB2-managed SMS-controlled 8 © 2010 IBM Corporation
    9. 9. Migration Planning WorkshopRecent System APARs DDF Availability Enhancements – Change DDF location alias names online o New MODIFY DDF ALIAS command o New “dynamic alias” concept in addition to existing 8 static aliases – Online DDF CDB changes o LOCATIONS, IPNAMES, IPLIST – PM26480 (V10) Ability to SELECT from SYSLGRNX – PM35190 & PM42331 (V10) – ISO(UR) enforced 9 © 2010 IBM Corporation
    10. 10. Migration Planning WorkshopBusiness value of Advanced Design-Pending Alters Availability – REORG with share level reference or change to move your simple table spaces to new universal table spaces – Move a segmented table space at the 64GB limit seamlessly into a partition by growth table space without an outage (aside from the rebinds) Productivity – Have DB2 materialize online ALTERs at DBA’s discretion at a future date – No need to CREATE new table spaces, UNLOAD/LOAD, GRANT, DROP, REBIND 10 © 2010 IBM Corporation
    11. 11. Migration Planning WorkshopUniversal Table Spaces What kind of Table Space will be created? (* optional)CREATE SEGSIZE NUMPARTS MAXPARTITIONS CommentsTABLESPACE... *SEGSIZE is optional.Segmented * Default for explicitly created TS & implicitly created TS for CM8. SEGSIZE defaults to 4. Default for DB2 9 NFMUTS PBG with implicitly created * TS. Single table TS. *SEGSIZE will default to 32. Single table TSUTS PBR *SEGSIZE will default to * 32. Partitioning TS prior toClassic * V9 *SEGSIZE 0 will create classic partitioned andPartitioned TS CM8 behavior is same as v8 NFM 11 © 2010 IBM Corporation DSN
    12. 12. Migration Planning WorkshopImproved availability ALTER… Classic Partitioned Table Space Range-Partitioned See APAR UTS PBR PM25648 Single-Table Segmented Table Space Hash Single-Table Simple Partition-By-Growth Table Space UTS PBG 12 DSN © 2010 IBM Corporation
    13. 13. Migration Planning WorkshopPossible online schema changes for TS and IX 13 © 2010 IBM Corporation
    14. 14. Migration Planning WorkshopImproved ALTER…Pending changes materialized with an online REORG apply to UTS– SEGSIZE – no other pending ALTERs can be done before this is materialized– DSSIZE – no other pending ALTERs can be done before this is materialized (IMPDSSIZE ZParm for default)– MEMBER CLUSTER – new for UTS– MAXPARTITIONS • If other pending changes are involved, or changing table space type: it is pending • Otherwise it is immediate– Page Size (BUFFERPOOL) • Can be done with REORG TABLESPACE (for indexes and tables) or REORG INDEX for only index changesOther ALTERs are immediate MAXPARTITIONS– The above statements if TS or IX not defined– MAXPARTITIONS (unless changing TS)– BUFFERPOOL PGSTEAL NONE– LOB INLINE LENGTH LOB 14 DSN © 2010 IBM Corporation
    15. 15. Migration Planning WorkshopOnline Schema – Details on Execute ALTER Statement Statement is validated – Semantic checking against effective catalog definition Assuming all checks out ok: – Statement is put on pending list – Table space is placed in Advisory-REORG pending :AREOR (non-restrictive) • Not to be confused with REORG-pending advisory (AREO*) which says access path could be degraded – Statement completes with SQLCODE +610 to advertise the advisory state Drop changes – ALTER TABLESPACE… DROP PENDING CHANGES • still in AREOR • all changes for that table space will be dropped SYSIBM.SYSPENDINGDDL: DBNAME TSNAME DBID PSID OBJSCHEMA OBJNAME OPTION_ OPTION_ STATE … KEYWORD VALUE … MENT_ TEXT 15 DSN © 2010 IBM Corporation
    16. 16. Migration Planning WorkshopOnline Schema – Details on Online REORGPending DDL is materialized - DSNU1163I– Catalog is updated with the new attributes– OBD is updated with the new attributes– Data sets are updated with the new attributes– Materialized SYSPENDINGDDL entries are removedStats are collected– Default is TABLE ALL INDEX ALL UPDATE ALL HISTORY ALL unless overridden– Warning message is issued to indicate that some partition statistics may no longer be accurate - DSNU1166I • (COLGROUP, KEYCARD, HISTOGRAM …)SYSCOPY entries show inability to recover object prior to changesAREOR state is reset 16 DSN © 2010 IBM Corporation
    17. 17. Migration Planning WorkshopOnline Schema… Restrict RECOVER across materializing REORGs(some availability in DB2 11) Alter MEMBER DML activities CLUSTER On REORG converts to Member RECOVER to Cluster structure with In-line copy Currency Image copy + log records Plans and packages are invalidated if – When changing the MAXPARTITIONS attribute of a simple or segmented table space to convert it to a partition-by- growth universal table space – The SEGSIZE attribute of a partitioned table space is changed to convert the table space to a range-partitioned universal table space 17 DSN © 2010 IBM Corporation
    18. 18. Migration Planning WorkshopMember Cluster speed ClusteringMEMBER CLUSTER added to UTS– Avoid hotspots, P-lock, and page latch contention • Usually only applicable for data sharing, concurrent access • Each member is assigned a set of space map pages • Ignores clustering index on insert, REORG to get clustering back • Space map covered 199 data pages in DB2 9 • Space map covers 10 segments in DB2 10– New column SYSTABLESPACE.MEMBER_CLUSTER– LOCKSIZE row and larger page size may work better– Very important for APPEND tables (DB2 9) 18 DSN © 2010 IBM Corporation
    19. 19. Migration Planning WorkshopDB2 10 Range Defined Table Spaces ---------------------------------- Random Inserts -------------------------------- Throughput CPU Time PLL RLL PLL RLL 25000 1.2 1 Msec / Commit 20000 Rows/Sec 0.8 15000 0.6 10000 0.4 5000 0.2 0 0 PTS PTS/MC PBR PBR/MC PTS PTS/MC PBR PBR/MC -------------------------------- Sequential Inserts -------------------------------- Throughput CPU Time PLL RLL PLL RLL 120000 20 100000 Msec / Commit 15 Rows/Sec 80000 60000 10 40000 5 20000 0 0 PTS PTS/MC PBR PBR/MC PTS PTS/MC PBR PBR/MC19 19 25/02/2013 © 2010 IBM Corporation
    20. 20. Migration Planning WorkshopDB2 10 Non-range Defined Table Spaces ---------------------------------- Random Inserts -------------------------------- Throughput CPU Time PLL RLL PLL RLL 25000 1.2 Msec / Commit 1 20000 Rows/Sec 0.8 15000 0.6 10000 0.4 5000 0.2 0 0 SEG PBG PBG/MC SEG PBG PBG/MC -------------------------------- Sequential Inserts -------------------------------- Throughput CPU Time PLL RLL PLL RLL 120000 25 100000 Msec / Commit 20 Rows/Sec 80000 15 60000 10 40000 20000 5 0 0 SEG PBG PBG/MC SEG PBG PBG/MC20 20 25/02/2013 © 2010 IBM Corporation
    21. 21. Migration Planning WorkshopCompress on INSERTData compression occurs when a dictionary existsPrior to DB2 10– Dictionary not built on a table space with COMPRESS YES attribute until: • REORG or • LOAD utility was executed– For some customers, REORG or LOAD are not executed frequently– LOAD COPYDICTIONARY offered in DB2 9DB2 10 NFM allows for build of compression dictionary on:– INSERT– MERGE– LOAD utility with REPLACE, RESUME NO, or RESUME YES SHRLEVEL CHANGE, and without KEEPDICTIONARYEliminate need for REORG or LOAD needed to build compression dictionary 21 DSN © 2010 IBM Corporation
    22. 22. Migration Planning WorkshopHow Compress on INSERT worksINSERT, MERGE and LOAD trigger the creation of a compressiondirectory if:– The table space or partition is defined with COMPRESS YES– The table space or partition has no compression dictionary built– Inserted data reaches a threshold that allows the build of the compression dictionaryIf threshold is reached, dictionary build is done asynchronously– Data continues to be inserted uncompressed until dictionary is readyNo way to turn off Compress on insert– Use COMPRESS NO if unwanted– DSNU235I – dictionary not built 22 DSN © 2010 IBM Corporation
    23. 23. Migration Planning WorkshopLocation of compression dictionary pagesIf the dictionary pages are scattered throughout table a DSNU1232I -REORG or COPY SYSTEMPAGES(YES) is needed to COMPRESSEDUNLOAD rows ROW IS IGNORED BECAUSE THE H SM D D .. DICTIONARY IS COPY TS... .. H SM D D .. D D D D NOT AVAILABLE SYSTEMPAGES .. NO FOR TABLE D D D D D DI D DI table-name D DI D DI COPY TS... SYSTEMPAGES ..Dictionary pages YES .. (option makes H SM DI DInot necessarilyafter space map page! DB2 copy the D D D D dictionary pages-Could use inline after space map D D DCOPY during REORG page)To ensure dictionarypages up front 23 DSN © 2010 IBM Corporation
    24. 24. Migration Planning WorkshopExtended Address Volumes Continue the direction started with the 3390-54 of defining larger volumes by increasing the number of cylinders beyond 65520 in z/OS V1R10 and higher to support 262,668 cylinders New track address format(CCCCHHHH-CCCCcccH) – Continue relief provided by PAV, HyperPAV – Benefit: 54 GB • Increased z/OS addressable disk storage-supports SMS and non_SMS Max cyls: 65,520 • Easier to manage flash enabled devices for recover 3390-54 • Caution – small data sets may grow faster due to larger allocation in chunks of 21 cyls Extended Addressing is needed for any DB2 dataset larger than 4GB – Catalog and directory must belong to EA SMS Size limited to STOGROUP 223 GB (262,668 Max – Previously ‘LARGE’ datasets limited to 4GB, DSSIZE is cylinders) now preferred method of defining size in z/OS V1R10 – Still have 64GB limit on dataset(DSSIZE) 3390-A “EAV” Up to 225 TB 24 DSN © 2010 IBM Corporation
    25. 25. Migration Planning WorkshopEAV DB2 Enablement 25 © 2010 IBM Corporation
    26. 26. Migration Planning Workshop26 © 2010 IBM Corporation

    ×