• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
What's New in DB2 9 for z/OS
 

What's New in DB2 9 for z/OS

on

  • 2,095 views

 

Statistics

Views

Total Views
2,095
Views on SlideShare
2,095
Embed Views
0

Actions

Likes
1
Downloads
59
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    What's New in DB2 9 for z/OS What's New in DB2 9 for z/OS Presentation Transcript

    • What’s New in DB2 9 for z/OS 2009. 05. 14 Soohee Lee(lshee@kr.ibm.com) 시스템 서비스 사업본부 IBM Global Technology Services
    • Agenda
      • DB2 9 for z/OS
      • Synergy with System z
      • Scalability
      • Availability
      • Data sharing
      • Application Enhancements
      • Utilities
      • Performance
    • DB2 9 for z/OS
      • Many SQL improvements
      • New built-in OLAP expressions
      • Histogram statistics
      • Optimization Server Center
      Dynamic Warehousing
      • Index compression
      • Partition By Growth tables
      • Cloned tables
      Simplification Reduced TCO
      • More online schema changes
      • Online REBUILD INDEX
      • Parallel Sysplex clustering improvements
      Workload Consolidation
      • pureXML
      • Optimistic locking for WebSphere
      • LOB performance, usability
      SOA Enablement
    • Synergy with System z
      • DB2 9 for z/OS
      • Synergy with System z
      • Scalability
      • Availability
      • Data sharing
      • Application Enhancements
      • Utilities
      • Performance
      • Faster CPU, more CPU, more memory
        • 50% more n-way performance “on average”
        • 62% more uniprocessor performance
        • 70% more server capacity (54->64 CPUs)
        • Up to 64 CPUs, z/OS 1.9 needed for 64-way in a single LPAR
        • Up to 1.5TB, z/OS 1.8 needed for > 256G in a single LPAR
      • Infiniband Coupling Facility links
      • New OSA-Express3, 10 GbE for faster remote apps
      • HiperDispatch
      • Hardware Decimal Floating Point facility
      • 1MB page size (DB2 X plans to exploit)
      • 50+ instructions added to improve compiled code efficiency (DB2 X plans to use)
      IBM System z10 Benefits for DB2
      • portions of DB2 for z/OS V8 and DB2 9(blue) workloads may benefit from zIIP*:
      • ERP, CRM, Business Intelligence or other enterprise applications
      • Via DRDA over a TCP/IP connection (enclave SRB, not stored procedure or UDFs)
      • DB2 9 for z/OS Remote native SQL procedure
      • DB2 9 XML paring
      DB2 & IBM zIIP value New Specialty Engine
      • Data warehousing application*: Large parallel SQL queries
      • DB2 9 higher percentage of parallel queries eligible for zIIP
      • DB2 utilities LOAD, REORG & REBUILD (maintaining index structures)
      zIIP allows a program working with z/OS to have all or a portion of its enclave Service Request Block(SRB) work direction to zIIP. Above types of DB2 work are those running in enclave SRBs, of which portions can be sent to zIIP.
      • zIIP Software
        • z/OS V1R8 기반 ( 운영체제 기능에 기본 내장 )
        • z/OS V1R6-V1R7
          • FMIDs : R6 – JBB77S9 / R7 – JBB772S
          • SPE for SDSF (APAR PK18215) / RMF (APAR OA13499)
        • DB2 V9.1 기반 ( 소프트웨어 기능에 기본 내장 )
        • DB2 V8
          • DRDA : PK18454
          • Utilities : PK19920
          • Parallel Query / Star Join – PK19921
      • zIIP projection
        • SYS1.PARMLIB (IEAOPTxx) : PROJECTCPU=YES
        • determine how much work can be offloaded to the zIIP (without zIIP)
      zIIP Enabling
      • DB2 V9.1 for z/OS
      • Synergy with System z
      • Scalability
      • Availability
      • Data Sharing
      • Application Enhancements
      • Utilities
      • Performance
      Scalability
    • DB2 9 64 bit Evolution (Virtual Storage Relief)
      • EDMPOOL Changes:
        • V8 - DBD storage moved above 2GB bar.
        • DB2 9 - SKCT, SKPT some CT, PT storage moved aboved 2GB bar .
        • DB2 9 approx. 60% reduction in below-the-bar storage EDMPOOL size observed for lab workloads.
      • Other changes :
        • Some storage acquired for distributed application moved above 2GB bar.
        • Control blocks for table spaces and RTS move aboved the bar.
        • Control block structures for dynamic SQL-related storage
      Virtual Storage Constraint in an important issue for many DB2 customers.
    • Automated memory monitoring
      • Built-in monitor runs from startup to shutdown and checks the health of the system at one-minute intervals .
      • DBM1 storage below the bar is monitored for critical storage increases.
        • If the DBM1 storage below the bar reaches specific thresholds of 88, 92, 96, or 98 percent
        • Then issue messages (DSNV508I, DSNV510I, DSNV511I, and DSNV512I)
        • Report current DBM1 storage consumption and indicate the agents that are consuming the most storage.
    • 64-bit DDF - Shared Private Storage with DBM1
      • DDF address space runs in 64-bit addressing mode
        • Shared 64-bit memory object avoids cross memory moves between DBM1 and DDF and improve performance.
      • Shared memory : new virtual storage type allowing multiple address spaces to share storage.
      • Similar to ECSA - always addressable, avoids XM moves.
      • Different from ECSA - only available to those address spaces registering with z/OS to shared this storage.
      • Reduces data formatting and data movement.
      • Reduces virtual storage
        • It exists once, instead of in each address space
      • Set by HVSHARE in PARMLIB(IEASYSxx)
      • DISPLAY VIRTSTOR,HVSHARE
    • WLM assisted Buffer Pool management
      • WLM-assisted buffer pool management
        • ALTER BUFFERPOOL () AUTOSIZE(YES)
        • z/OS 1.8
        • DB2 registers BP to WLM and reports synch read I/O delays to WLM
        • DB2 periodically reports BP hit stats to WLM
        • WLM projects effect of adjusting BP size on workload performance goals
        • WLM drives DB2 exit to adjust size if appropriate
          • DB2 9 restricts to +/- 25%
      BP0 DBM1 WLM Data Collection DB2 Periodic Report Buffer Pool Sizes Hit Ratio for Random Reads 1 Plots size and hit ratio over time. 2 Projects effects of changing the size Bufferpool Adjustment + - 25%
    • NOT LOGGED Table spaces
      • ALTER / CREATE TABLESPACE as NOT LOGGED
        • ALTER not allowed if in same UOW with an update to the table space
      • Reduce logging in situations where is not required.
      • Turn ON/OFF logging during the heavy insert or update activity.
      • Effects the UNDO / REDO records
        • Control information is still logged.
      • A Unit of Recovery (UR) is still created
      • Indexes, LOB and XML inherit the logging attribute of the base
      LOG YES is a synonym for LOGGED LOG NO is a synonym for NOT LOGGED Recommendation: Don’t sacrifice recovery for minor performance gain.
    • Universal Table Spaces
      • Combination of segmented with partitioning options
        • improved space management
        • improved mass delete performance
      • 2-types of partitioning
        • Partition by RANGE (PBR)
          • Key range partitioning that we’ve always had
        • Partition by GROWTH (PBG)
          • New partitions are added as data grows
      • Single table only (1 TABLE / 1 TABLESPACE)
      • DROP / CREATE to migrate existing page sets
      • Simple table spaces can not be created
        • Default table space is now Segmented
    • Universal Table Spaces (PBR & PBG)
      • UTS - Partition by range (PBR)
        • This is no difference to Version 8 (and prior) partitioning
        • A UTS PBR is created just like a normal partitioned table space
        • But with a SEGSIZE clause
      • UTS - Partition by growth (PBG)
        • Starts off as one partition table space
        • As data is inserted/loaded the partition will fill up
        • When it is full, another partition is automatically created
          • No -904
          • No partitioning key
        • You specify the limit to the number of partitions on the CREATE/ALTER table space statement
          • MAXPARTITIONS
      • Regardless of the order of columns in a CREATE TABLE statement
      • Physically, the fixed length columns will be first
      • Followed by the variable length ones
        • This is known as Reordered Row Format (RRF)
        • As opposed to Basic Row Format (BRF)
      • Reordered Row Format (RRF)
        • The performance of RRF is SO much better than BRF
        • This is NOT optional
        • Once you are in New Function Mode this is the only way
          • For every CREATE TABLE
          • And after every REORG or LOAD REPLACE
        • Reduce the impact and overhead of processing variable-length columns.
      Variable-Length Column Improvements
    • Indexing Enhancements
      • Larger index pages
        • 8K /16K /32K page
        • Fewer page splits for long keys
        • More key values per page
      • Index compression
        • Reduce the storage consumed by large index (like as DW Application)
        • CREATE/ALTER INDEX COMRESS YES/NO
        • No compression dictionaries
        • Only compress the data in leaf pages
        • Data is compressed to 4K pages on disk
        • 32K/16K/8K pages results in up to 8x/4x/2x disk savings
    • Indexing Enhancements
      • Asymmetric Index Page Splits
      • Index split roughly 50/50 (prior to DB2 9)
      • Sequential inserts into the middle of an index resulted in some pages with 50% free space
      • Asymmetric Index page split in DB2 9
      • New algorithm dynamically accommodates a varying pattern of inserts
      • Improve space utilization and reduce contention that results from frequent page splits in a index with sequential insert patterns
    • Indexing Enhancements
      • RANDOM index key
        • Avoid hot spots with multiple processes inserting sequential keys
        • Reduce contention of index page P-lock
        • Trade-off between contention relief and additional Getpage, read/write I/O
    • Native SQL Procedure
      • Run entirely within DB2 and do not require a WLM stored procedure AS
      • Eliminates the cross address space overhead between the DBM1 and WLM stored procedure AS as well as the round-trip between Workload Manager and DBM1
      • eligible for ZIIP if invoked from DRDA/TCPIP connections
      • Native SQL Procedural Language
        • Fully integrated into the DB2 engine
        • Eliminates generated C code and compilation
        • An SQL procedure created without FENCED or EXTERNAL is a native SQL procedure
    • DB2 Trace Filtering
      • New filtering capabilities for –START TRACE that INCLUDE or EXCLUDE based on these keywords:
        • USERID -- client userid
        • WRKSTN -- client workstation name
        • APPNAME -- client application name
        • PKGLOC -- package LOCATION name
        • PKGCOL -- package COLLECTION name
        • PKGPROG -- PACKAGE name
        • CONNID -- connection ID
        • CORRID -- correlation ID
      • In V8 , only PLAN, AUTHID, LOCATION
      • DB2 V9.1 for z/OS
      • Synergy with System z
      • Scalability
      • Availability
      • Data Sharing
      • Application Enhancements
      • Utilities
      • Performance
      Availability
    • CLONE Tables
      • Fast way to replace table contents
      • Eliminate outage for LOAD REPLACE
      • CLONE are created with an ALTER statement
        • ALTER TABLE ADD CLONE clone-table-name
        • UTS only
      • A CLONE inherits ALL of the attributes of the base table
        • Including all indexes, constraints, triggers
        • Structures ONLY - not data
      • CLONE has a different INSTANCE number to the base object.
        • VCAT.DSNDBC.ddd.ppp. I0002 .Annn
      • CLONE and base table can be used independently
        • For SQL
        • For Utilities (new CLONE keyword, except RUNSTATS)
    • CLONE Tables
      • EXCHANGE DATA BETWEEN syntax
        • Drain & switch
        • DB2 switches the instance numbers in the catalog
        • This is FAST
          • Very like a switch phase
      • Before EXCHANGE
      • After EXCHANGE
      Base-table clone-table Base-table clone-table
    • Recovery to point in time with consistency
      • Prior to DB2 V8, if point-in time recovery, consistency is not ensured. (If the point is not consistency point)
      • In DB V9 , Full data consistency
        • Occurs for TOLOGPOINT & TORBA - not for TOCOPY
        • Uncommitted URs will be rolled back
        • Reduce need for QUIESCE points
        • After LOGAPPLY , new 2 phase (LOGSCR,LOGUNDO)
          • LOGSCR : Analyzes log records and constructs information about in-flight, indoubt, inabort, and postponed abort units of recovery.
          • LOGUNDO : Rolls back any uncommitted changes that the active units of recovery made to the recovered objects.
    • APPEND Table
      • CREATE / ALTER TABLE APPEND YES/NO
      • Ignore clustering during SQL inserts and online LOAD processing
      • Rows are appended at the end of the table or appropriate partition
      • You can insert or online LOAD your data quickly and regain the clustering order later by running REORG.
      • Benefit !!:
        • Maximizes performance for “INSERT at end”
        • Avoids overhead of attempting to preserve clustering sequence
      TABLE INSERT or Online LOAD
    • REFRESH for EARLY code
      • Modify early code without IPL
      • New command
        • REFRESH DB2,EARLY
        • Member-scope
        • The command is rejected if the DB2 subsystem is already active.
        • The EARLY code can only be properly updated when DB2 is not active
    • RENAME INDEX & RENAME COLUMN
      • Change object characteristics without need to drop and recreate the object.
      • RENAME INDEX
        • RENAME INDEX source-index-name TO new-index-name
        • Does not change OBID
        • Plan and package will not be invalidated
      • RENAME COLUMN
        • ALTER TABLE tablename RENAME COLUMN old-col TO new-col
        • Invalidation of any plan or package that is dependent on the table
        • Auto Rebinding occurs
          • Scenario1 : no reference the renamed column
            • Rebind will be successful
          • Scenario2 : reference the renamed column
            • Rebind will not be successful
            • Must modify, recompile and rebind your application
    • Log truncation by timestamp
      • Conditional restart log truncation by timestamp
        • New parameters on CRESTART CREATE
          • ENDTIME
          • SYSPITRT (SYSTEM LEVEL RECOVERY MODE)
    • Ability to cancel “DB command”
      • Ability to cancel “database command” that have been issued from the console.
      • - STOP DB(DSN0170) SP(TESTIMP*) command with some other thread
      • - DIS THD(*) TYPE(SYSTEM)
      • You can issue, -CANCEL THD(93) for command or system agent.
      • After CANCEL, You can issue -START DB command to change status STOPP to RW.
    • Migration and Fallback Path
      • With DB2 9 , you can always drop back to the previous stage
      • Cannot fallback to V8 after entry to DB2 9 (ENFM), but can fallback to DB2 9 (CM*)
    • Data Sharing
      • DB2 V9.1 for z/OS
      • Synergy with System z
      • Scalability
      • Availability
      • Data Sharing
      • Application Enhancements
      • Utilities
      • Performance
    • Data Sharing Enhancement
      • Log latch contention relief
      • Restart performance enhancement
        • Reduced impact of retained lock - Allowing table level retained locks
        • Open data sets ahead of log apply
      • Remove GBP-dependency at object level by command
        • ACCESS DB MODE(NGBPDEP)
        • Typical usage would be before batch run
      • Open dataset ahead of use via command
        • Available to pre-open or prime the data set
        • ACCESS DB MODE(OPEN) [PART]
      • Auto-recover GRECP/LPL objects on group restart
        • Useful in disaster recovery or GDPS scenarios
      • Balance group attach connections across multiple members on same LPAR (round-robin basis)
    • SQL
      • DB2 V9.1 for z/OS
      • Synergy with System z
      • Scalability
      • Availability
      • Data Sharing
      • Application Enhancements
      • Utilities
      • Performance
    • MERGE
      • “ Upsert”
        • A combination of UPDATE and INSERT, MERGE is a single SQL operation
        • Single row or multi-row
      • If a row matches the ON condition it is updated,
      • Otherwise it is inserted
      • Provides better performance, less interaction across the network, less DB2 and application interaction, and less SQL to code.
    • SELECT FROM UPDATE/DELETE/MERGE
      • Used to determine the values before or after records
        • FINAL TABLE : select from rows after update
        • OLD TABLE : select from row before update
      • INCLUDE clause
        • include a new column to the result table but not add the column to the target table.
    • FETCH FIRST/ ORDER BY in Subselect
      • FETCH FIRST and ORDER BY clauses are now allowed in subselects.
      • In this example both clauses are used in the subselect as a way to select the top 10 rows from table T1 as ordered by columns C2 and C1.
      INSERT INTO T2 (SELECT C1, C2, C3 FROM T1 FETCH FIRST 10 ROWS ONLY ORDER BY C2, C1);
    • SKIP LOCK DATA in SELECT
      • SKIP LOCK DATA in SELECT
        • Rows with incompatible locks by other transactions are skipped
        • Page or Row lock only
        • Reduce lock contention and improve performance
      X X X data data data data data data data data SQL
    • TRUNCATE
      • Very quickly delete all rows from a table
        • Simple , Segmented, Partitioned , Universal Tablespaces
        • IGNORE delete triggers ,deletes the data WITHOUT firing delete triggers
        • Table level deletion (LOAD REPLACE works on tablespace level)
        • IMMEDIATE option - operation cannot rolled back
    • INTERSECT / EXCEPT
      • Intersect – Returns the records that two result sets have in common
        • Frequently used in ‘find the duplicates query’
        • Rows from either result set that do not match are excluded.
      • Except – Returns the records that are members of one result set that are not members of the other
      • Requirement
        • Both result sets must have the same column structure .
      RS2 RS1 Intersect RS2 RS1 RS1 RS2 Except
    • Index on Expression
      • Simple indexes can contain concatenated column
      CREATE INDEX totalPay on W2_TABLE(salary,bonus)
      • Index on expression
        • Value of the index has been transformed
        • Optimizer can use this index
        • Query performance can be enhanced
        • Evaluate during insertion time or during index rebuild
      CREATE INDEX totalPay on W2_TABLE(salary+bonus)
    • Built-in Functions (RANK, DENSE_RANK)
      • RANK
        • Generates a row number defining the rank as 1 plus the number of rows that precede the row.
        • If two or more rows are not distinct with respect to the ordering, there will be one or more gaps in the sequential rank numbering. Also referred to as Olympic Ranking.
      • DENSE_RANK
        • Similar to RANK but ensures there are no gaps .
    • Built-in Functions (RANK, DENSE_RANK) SELECT SMALLINT(DENSE_RANK() OVER (ORDER BY score DESC)) AS DENSE_RANK,athlete, event, score FROM scores; SELECT SMALLINT(RANK() OVER (ORDER BY score DESC)) as RANK, athlete, event, score FROM scores;
      • RANK
      • DENSE_RANK
    • Built-in Functions (ROW_NUMBER)
      • ROW_NUMBER
        • Creates a sequential row number that is computed for each row starting with 1.
        • No number skipping.
      SELECT SMALLINT(ROW_NUMBER() OVER (ORDER BY score DESC)) AS ROW_NUMBER, athlete, score FROM scores ORDER score DESC;
    • Time Scalar Functions
      • TIMESTAMPADD(interval, number, timestamp)
        • Returns the result of adding the specified number of the specified interval to the specified timestamp
        • Add 1 year to the current timestamp
        • SELECT TIMESTAMPADD(256,40,TIMESTAMP('1965-07-27-15.30.00')) FROM SYSIBM.SYSDUMMY1;
        • Returns a value ’2005-07-27-15.30.00.000000’.
        • Interval values are 256=years, 128=quarters, 64=months, etc
      • TIMESTAMP_ISO(expression)
        • Returns a timestamp based on a date, a time, or a timestamp expression.
        • SELECT TIMESTAMP_ISO(DATE(‘1992-02-19’)) FROM SYSIBM.SYSDUMMY1;
        • Returns a value ‘1992-02-19-00.00.00.000000’
    • Real-Time Statistics Evolution
      • Real Time Statistics (RTS) have been collected automatically since V7
      • DB2 9 moves RTS into the Catalog & externalizes the information automatically
        • DSNDB06.SYSRTSTS
          • SYSIBM.SYSTABLESPACESTATS
          • SYSIBM.SYSINDEXSPACESTATS
        • During ENFM processing, the data is moved from user-defined tables to the new catalog tables
        • Drop user-defined tables after ENFM
      • Gather information about indexes that are used / not used
        • SYSINDEXSPACESTATS.LASTUSED
        • "Used", as defined by DB2 is the following:
          • As an access path for query or fetch.
          • For searched UPDATE / DELETE SQL statement.
          • As a primary index for referential integrity.
          • To support foreign key access.
    • Plan Stability
      • New function of DB2 9 (PK52523)
        • Protects customers against access path regression
        • Allows for a “safe” way to REBIND (fall back)
        • Available even in DB2 9 (CM) as it can benefit migration and fallback
        • Strongly recommended
        • Make sure that the pre-conditioning APAR for Plan Stability (PK52522) is applied on all V8 (NFM) systems
      • What is the problem?
        • REBINDs can cause access path changes
        • Most of the time, this improves query performance …
        • … But when it doesn’t
          • No easy way to undo the REBIND
          • Can lead to a lot of grief to our customers and to IBM
    • Plan Stability...
      • At REBIND, save old copies of packages
        • Catalog tables
        • Directory
      • Two flavors
        • BASIC and EXTENDED
        • Controlled by new ZPARM PLANMGMT
        • Default is OFF
        • Also supported as REBIND options
      • REBIND PACKAGE …
        • PLANMGMT(BASIC)
          • 2 copies: Current and Previous
        • PLANMGMT(EXTENDED)
          • 3 copies: Current, Previous, Original
      • Most bind options can be changed at REBIND
        • But a few must be the same
      • REBIND PACKAGE …
        • SWITCH(PREVIOUS)
          • Switch between current & previous
        • SWITCH(ORIGINAL)
          • Switch between current & original
      • FREE PACKAGE …
        • PLANMGMTSCOPE(ALL) – Free package completely
        • PLANMGMTSCOPE(INACTIVE) – Free all old copies
      • Invalidation and Auto rebind
        • Each copy invalidated separately
        • Auto rebind replaces only the current copy , previous and original are not affected
    • Plan Stability...
      • REBIND ... PLANMGMT(BASIC)
      • REBIND ... SWITCH(PREVIOUS)
    • Plan Stability...
      • REBIND ... PLANMGMT(EXTENED)
      • REBIND ... SWITCH(ORIGINAL)
    • Plan Stability...
      • Sample Strategy for Migration using Plan Stability
      • Migration strategy with Plan Stability
        • Before migrating to DB2 9 (CM), ensure V8 plan table information is available
        • On migration to DB2 9 (CM), set ZPARM PLANMGNT to EXTENDED
          • Objective: Make sure that the V8 version of package is kept as the original in case a fallback to DB2 V8 is required
          • Restriction: EXTENDED means that DB2 always keeps 3 versions of the package (even if they are the same). Watch out for SPT01 growth (limit is still 64GB with DB2 9).
        • Delay rebind on DB2 9 (CM) until running stable
          • Do not rebind on DB2 9 (CM) until RUNSTATS has been run
          • Make sure new ZPARM STATCLUS=ENHANCED (Default)
          • Introduces major change to CLUSTERRATIO calculation in DB2 9 and introduction of new statistic Data Repetition Factor (DRF)
    • Plan Stability...
      • Sample Strategy for Migration using Plan Stability
      • REBIND in DB2 9 (CM)
        • DB2 now stores 3 versions of the package
        • Initial REBIND
          • Current version = DB2 9 version
          • Previous version = Original version = V8 version
          • If needed because of V9 access path regression, use REBIND PACKAGE …SWITCH(PREVIOUS) to fallback to the V8 version
        • Subsequent REBINDs
          • Current version = “New” DB2 9 version
          • Previous version = Latest DB2 9 version
          • Original version = V8 version
          • Use REBIND PACKAGE … SWITCH(PREVIOUS) to fallback to the previous V9 version
    • Plan Stability...
      • Sample Strategy for Migration using Plan Stability
      • In case of fallback to DB2 V8, before falling back to V8
        • Use REBIND PACKAGE … SWITCH(ORIGINAL) to fall back to original version of package (V8 version)
      • In the future, to establish a new original version e.g to move forward to the version after DB2 9
        • Use FREE PACKAGE … PLANMGMTSCOPE(INACTIVE) to free off the original (will also free off the previous version)
    • Two ways to store XML in a Databases DB2 Storage Competitors DB2 9 Pure XML create table dept (deptID char(8),…, deptdoc xml); … … … … … <dept> … <emp>…</emp> </dept> “ PR27” deptdoc deptID
    • Pure XML in DB2 9 create table dept (deptID char(8),…, deptdoc xml);
      • XML data is stored in XML-typed columns in tables
        • XML is stored in a parsed hierarchical format
        • Relational columns are stored in relational format
        • The XML table space inherits the base table attributes
      • SQL/XML constructor functions and XPath support
      • XML Indexing
        • improve the efficiency of queries on XML
      • Improve XML performance
      DB2 Storage … … … … … <dept> … <emp>…</emp> </dept> “ PR27” deptdoc deptID
    • Utilities
      • DB2 V9.1 for z/OS
      • Synergy with System z
      • Scalability
      • Availability
      • Data Sharing
      • Application Enhancements
      • Utilities
      • Performance
    • DB2 9 Utilities Performance Improvement
      • CPU reduction in LOAD, REORG and REBUILD
      • Reductions mostly due to improved index processing (* with exceptions)
      • 10 to 20% in Image Copy (* even with forced CHECKPAGE YES)
      • 5 to 30% in load, Reorg, Reorg Partition, Rebuild Index
        • Except REORG TABLESPACE SHR CHG PART with NPIs
      • 20 to 40% in Load
      • 20 to 60% in Check Index
      • 35% in Load Partition
      • 30 to 40% in Runstats Index
      • 40 to 50% in Reorg Index
      • Up to 70% in Load Replace Partition with dummy input
    • REORG Enhancement
      • Elimination of BUILD2 phase
        • REORG TS PART SHRLEVEL CHANGE
        • NPI also shadowed
        • NPI implicitly reorged
        • Improved availability
          • But concurrent REORGs at part level for same tablespace not permitted
      • REORG parallelism for UNLOAD, RELOAD, LOG phases
        • Parallel uload & load of partitions
        • Separate concurrent jobs not required
        • Improve performance
    • REORG Enhancement
      • Automatic display of blocking claimers for REORG
    • Online REBUILD INDEX
      • REBUILD INDEX SHRLEVEL CHANGE
      • Great for building new non-unique indexes or when index is in RBDP
      • Do not use REBUILD INDEX to move the index to a new location.
        • use REORG INDEX to move volume
        • use REBUILD INDEX SHR CHG to fix a broken or restricted index, or to build an index after DEFER.
      • Tables space must be in LOGGED state (new log phase)
      • SHRLEVEL CHANGE is not well suited for unique indexes and concurrent DML
        • Inserts and updates of the index will fail with a resource unavailable (-904) because uniqueness checking cannot be done while the index is in RBDP.
    • Online CHECK DATA
      • CHANGE CHECK DATA works on a copy of the data and indexes ( shadows )
      • Applications can read from and write to the index, table space, or partition that is to be checked.
      • Improve availability
    • UNLOAD SKIP LOCKED DATA
      • Skipping locked rows during UNLOAD
        • UNLOAD SHRLEVEL CHANGE ISOLATION CS & SKIP LOCKED DATA
        • With SKIP LOCKED DATA, the UNLOAD utility can skip rows on which incompatible locks are held by other transactions.
        • Reduce lock contention, improve performance
    • MODIFY RECOVERY
      • MODIFY RECOVERY simplification and safety
      • You can specify
        • What you want to delete : DELETE keyword
        • What you want to keep : RETAINE keyword (new in V9)
        • Improve usability
    • RECOVER Enhancement
      • RECOVER RESTOREBEFORE(RBA OR LRSN)
        • When lost the least recent image copy (with TORBA or TOLOGPOINT)
        • Tell db2 to not try to allocate the lost image copy but to work with older copy
      • Displaying progress of RECOVER (During LOGAPPLY phase)
        • -DISPLAY UTILITY result with a new message DSNU116I
        • Indicates the range of the log that needs to be applied
        • Show the progress that has been made up to the last commit and the elapsed time since the start of the log apply phase of the recovery.
    • Julian Data and Time in Utility Output
      • Julian date and time stamp(local time) in utility output
        • Easier to analyze utility runs ,
        • Include timestamp with message number in SYSPRINT
    • Performance
      • DB2 V9.1 for z/OS
      • Synergy with System z
      • Scalability
      • Availability
      • Data Sharing
      • Application Enhancements
      • Utilities
      • Performance
    • DB2 9 for z/OS Performance Overview Your situation will vary. Z800 and z900 expect +5% to +10% CPU
      • DB2 9 z9 and z990 performance plan example
      Utilities Histogram statistics REBIND DSNZPARMs DB design adjustments Index Improvements Application changes Native SQL procedures SQL adjustments
    • DB2 9 for z/OS Performance Overview
      • Significant CPU time reduction in most utilities
      • Synergy with new hardware : zIIP, MIDAW, DS8000,...
      • Performance / Scalability Enhancements
        • Especially Insert, Update & Delete
      • Query / Access Path Performance Enhancements
      • Other performance enhancements : LOB, varchar, native SQL procedure, index compression
      • Improve virtual storage usage below 2GB DBM1
    •