Your SlideShare is downloading. ×
DB2 for z/O S  Data  Sharing
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

DB2 for z/O S Data Sharing

2,460

Published on

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

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

1 Comment
1 Like
Statistics
Notes
  • I don't like it. It's possible to read just a bare transcription of this presentation. In my opinion it' completely useless !
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
2,460
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
1
Likes
1
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 IBM Distinguished Engineer How to reduce costs, increase capacity and achieve Continuous Availability with IBM DB2 Data Sharing ! The “Ultimate” Data Server !
  • 2. 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
  • 3. 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
  • 4. 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
  • 5. 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
  • 6. 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
  • 7. 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
  • 8. 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
  • 9. 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.
  • 10. 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
  • 11. 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
  • 12. 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
  • 13. DB2 Data Sharing OLTP Scalability
    • IMS/TM with DB2 V4 OLTP workload
    • 96.75% of ideal scalability from 2 to 8 nodes demonstrated
  • 14. 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%
  • 15. 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
  • 16. Customers using DB2 Data Sharing
  • 17. 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.
  • 18. 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
  • 19. 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
  • 20. 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 …
  • 21. CheckFree – Real Customer Experience
  • 22. Summary & Next Steps

×