DB2 for z/O S Data Sharing

John Campbell IBM Distinguished Engineer How to reduce costs, increase capacity and achieve Continuous Availability with IBM DB2 Data Sharing ! The “Ultimate” Data Server !

John Campbell - Introduction IBM Distinguished Engineer Member of IBM Academy of Technology Provide leadership to WW customers in high-end database, transaction, and application systems - consultancy, design, performance and benchmarking Based on customer experience drives direction of DB2 product and associated products across IBM Corporation Performance Team Leader for release of DB2 Data Sharing

Agenda What is DB2 Data Sharing ? Why Go to DB2 Data Sharing Parallel Sysplex and Data Sharing Architecture DB2 Data Sharing Continuous Availability Dynamic Workload Balancing What about Performance and Scaling? What about Application Changes? Real Customer Scenarios Next Steps

DB2 Data Sharing Definitions DB2 data sharing – allows applications running on more than one DB2 subsystem to read and write to the same set of data concurrently . DB2 data sharing – allows customers to provide highest level of scalability, performance and continuous availability to enterprise applications that use DB2 data. DB2A DB2B DB2n . . . Coupling Facilities

Why Go to DB2 Data Sharing? General drivers: Capacity : outgrow single system size Avoid splitting the databases Continuous availability requirements Protect against planned and unplanned outages Easier growth accommodation and cost effectiveness Need scalable, non-disruptive growth Dynamic workload balancing Effective utilization of available MIPS for mixed workloads Handle unpredictable workload spikes System consolidation for easier systems management Application Investment Protection SQL interface is unchanged for data sharing Applications do not need to become "cluster aware" “ Turbo Charger” for existing applications Most known DB2 members: 17-way

Parallel Sysplex (PSX) Scalable Capacity Flexible Configuration Workload Balancing 7x24 Availability Single System Image PSX Components: Sysplex Timers Coupling Facility (CF) - LPARs High-speed shared memory CF Control Code (CFCC) Structures (Lock, Cache, List) CF Links CF Resource Management (CFRM) Policy Cross-System Extended Services (XES), part of z/OS

DB2 Data Sharing Architecture IRLM Buffer Pools DB2A Coupling Facilities LOCK1 Group Buffer Pools 1 12 2 3 4 5 6 7 8 9 10 11 SCA Sysplex timers 1 12 2 3 4 5 6 7 8 9 10 11 DB2A Log IRLM Buffer Pools DB2B IRLM Buffer Pools DB2n . . . Shared DASD DB2B Log DB2n Log . . . DB2 Cat/Dir DB2 DBs

Design for Continuous Availability Single points of failure eliminated: DB2 subsystem or z/OS system (LPAR) CPC (or CEC) Goal: Continuous Availability across planned or unplanned outage of any single hardware or software element Strategy: Remove all causes for planned outages Build on legacy of robust, fault tolerant MVS components On a failure: Isolate failure to lowest granularity possible Automate recovery and recover fast DB2A DB2B DB2n . . . Coupling Facilities

DB2 Member Outage – Planned "Rolling" maintenance One DB2 or LPAR can be stopped at a time DB2 data continuously available via the N-1 members Other members temporarily pick up the work of the member that is down Batch work can be offloaded to another member with more available capacity to reduce the batch window Applies to hardware and operating system changes, too Rolling IPLs DB2B . … .. . DB2A DB2n X DB2 Group KEY TO SUCCESS: Applications must be able to run on more than oneDB2 member – several apps are identified as candidates.

DB2 Member Outage – Unplanned The other "surviving" members remain up and running The architecture allows all members to access all portions of the databases Work can be dynamically routed away from the failed DB2 member The failed member holds "retained locks" to protect inconsistent data from being accessed by other members MVS Automatic Restart Manager (ARM) can automatically restart failed DB2 members Restart ‘Light’ minimizes impact of LPAR failures DB2A DB2B DB2n . . . Coupling Facilities

Dynamic Workload Balancing Workload Manager (WLM) CICSPlex System Manager (CPSM) Route workload between CICS TORs and AORs WebSphere Connection pooling Connection concentration Distributed access (DDF) Dynamic Virtual I/P Addressing (DVIPA) Sysplex Distributor Appl Appl Appl Appl Appl Transaction Managers CICS IMS TM DB2 data sharing group z/OS Parallel Sysplex Network DDF WAS

Data Sharing Performance Summary CPU cost of data sharing varies based on: CF access intensity for locking and caching. This varies based on: Percentage of CPU time in DB2 Degree of read/write sharing Number of locks obtained Access rate to shared data Insert/delete intensity Release of DB2 Hardware configuration Lock contention rates Data sharing cost varies from one workload to another 'Typical' 2-way data sharing overhead about 10% Individual jobs/transactions may have higher overhead < 0.5% added cost per member past 2-way

DB2 Data Sharing OLTP Scalability IMS/TM with DB2 V4 OLTP workload 96.75% of ideal scalability from 2 to 8 nodes demonstrated

Data Sharing Performance in Production Host CPU effect with primary application involved in data sharing 10% is a typical average Scalability and performance for real life customer workloads Note: “Mi” stands for ‘million instructions’ Industry Trx Mgr / DB Mgr z/OS Images CF access per Mi % of used capacity Pharmacy CICS/DB2 3 8 10% Insurance CICS/IMS+DB2 9 9 10% Banking IMS/IMS+DB2 4 8 11% Transportation CICS/DB2 3 6 8% Banking IMS/IMS+DB2 2 7 9% Retail CICS/DB2+IMS 3 4 5% Shipping CICS/DB2+IMS 2 8 9%

Application Changes ? SQL interface does not change However, locking and commit frequency may impact data sharing performance Commit frequently – long-time recommendation Take advantage of lock avoidance ISO(CS) CURRENTDATA NO New messages and return codes Applications should be able to run on more than one DB2 member for high availability Summary: “Turbo Charger” for existing applications

Customers using DB2 Data Sharing

Why should you exploit DB2 Data Sharing ? Continuous Availability for critical applications in terms of infrastructure. Enhanced Operational Capability and Return On Investment – better leverage of investment in the mainframe. Low Risk Implementation – as technology is proven. Low cost or high cost implementation choices available – there are many options – see later slides for a cost effective option.

Continuous Availability Pain Points Individual applications currently boxed and isolated Applications becoming interdependent Application interdependency creates single points of failure No in-site local failover for applications Data Sharing Allows data to be shared directly without message passing Can eliminate certain service outages Can reduce the duration of remaining outages Could have avoided some past outages or reduced the outage duration

Enhanced Operational Capability and Return On Investment Have you already invested heavily in system infrastructure ? Not getting full value from that investment Leverage existing investment and achieve step change in operational capability Significant improvement to in-site operational recovery capability New model for in-site failover can be enabled vs. full DR invocation Better utilisation of existing system resources through workload balancing Removing scaling factors that might inhibit M&A activity

Low Implementation Risk Well proven technology Widespread deployment around WW global banking community Global experience and skills Evolve to target environment with incremental change Target applications – as identified in the High Availability Workshops Procis MSP CBS Huon TD01 Others …

CheckFree – Real Customer Experience

DB2 for z/O S Data Sharing

More Related Content

What's hot (20)

Viewers also liked (16)

Similar to DB2 for z/O S Data Sharing (20)

More from Surekha Parekh (12)

DB2 for z/O S Data Sharing