DB2 for z/O S Data Sharing

29 %
71 %
Information about DB2 for z/O S Data Sharing

Published on January 9, 2010

Author: SurekhaParekh

Source: slideshare.net

Description

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

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

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

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

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.

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

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

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

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

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.

"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

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

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

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

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

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

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

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%

Host CPU effect with primary application involved in data sharing

10% is a typical average

Scalability and performance for real life customer workloads

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

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 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

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

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 …

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

Summary & Next Steps

Add a comment

Related presentations

Related pages

DB2 for z/O S Data Sharing, SlideSearchEngine.com

How to reduce costs, increase capacity and achieve Continuous Availability with IBM DB2 Data Sharing! The “Ultimate” Data Server !
Read more

IBM Redbooks | DB2 11 for z/OS Technical Overview

IBM® DB2® Version 11.1 for z/OS® ... Chapter 5. Data sharing Part 2. Application functions ... Author(s) Paolo Bruni;
Read more

DB2 Subsystem Health: Performance and Availability Based ...

DB2 Subsystem Health: Performance and Availability ... – Locking activity / Data-sharing locking ... DB2 z/O S SKD S S full prepare
Read more

Z O/s | LinkedIn

Elton Olegário Z O/S DB2 & DBA Database Administrator. Campinas Area, Brazil. Information Technology and Services
Read more

DB2 11 - Installation and migration - Automating DB2 ...

Example of migrating a data sharing group to DB2 11 by using z/OSMF. Assume that a data sharing group contains members, ...
Read more

DB2 11 - Installation and migration - Installation panels ...

... S 1 CATALOG ALIAS ... A scenario-specific panel for choosing steps to include when migrating a non-data sharing DB2 subsystem ... DATA SHARING ===> NO ...
Read more

s9837- Data Sharing Best Practices for Distributed Access

DB2 Data Sharing Best Practices For Distributed Access Shivram Ganduri Senior Software Engineer, IBM August 8, 2011 Session number : 9837
Read more

Front cover DB2 for z/OS and OS/390 - IBM Redbooks

DB2 for z/OS and OS/390 ... with IBM DB2 UDB Server for z/OS and OS/390. ... 4.4.5 Data sharing monitoring ...
Read more