A05 DB2 for z/os vs. Oracle RAC A Reality Check

Transcription

1 A05 DB2 for z/os vs. Oracle RAC A Reality Check Namik Hrle IBM Tuesday, October 3, :15 11:15 Platform: DB2 for z/os 1

2 Agenda Synergy with zseries hardware Integration with z/os operating system Design for enterprise applications DB2 Data Sharing vs. Oracle RAC Architectural differences Scale out Planned and unplanned outages DB2 Trends and Directions 2 DB2 for z/os is a true industrial strength database server that satisfies the most demanding requirements for high availability, continuous operations, virtually unlimited number of users and database size, superior scale out and top performance. The world's largest and most challenging installations regularly include DB2 as their prime database management system. In the recent years DB2 has been under considerable pressure from its competitors, most notably Oracle RAC. They claim to provide the same functionality and quality of service characteristics as DB2. Many in the IT community accept these claims very easily. DB2 specialists are often asked by the business decision makers to articulate DB2 technical advantages and justify the choice of DB2 as the database server. Why is DB2 for z/os considered the ultimate database server? What are the technical differentiators by which it stands out, particularly against Oracle RAC? Why should every enterprise infrastructure include DB2 for data serving? This presentation offers answers to these questions. 2

3 Deep Synergy With System z9 Hardware DB2 inherits all the quality of service characteristics of its zseries host Special zseries hardware assist capabilities, such as: Compression Data sharing (scale out) Unicode conversion Encrypted TCP/IP communication (SSL) Encrypted data Sorting Large storage pools Fast and reliable I/O (e.g. MIDAW) 3 DB2 inherits all the quality of service characteristics of its zseries host, augments them and add new ones through a tight integration with the underlying hardware and z/os operating system and its own leading edge database technology features. For the typical and frequently executed database functions special zseries hardware assist capabilities are exploited resulting in superior performance, reliability, availability and serviceability 3

4 Deep Synergy With z/os Operating System Uncompromised security thanks to the z/os Security Server (RACF) and DB2 internal authorization and security mechanisms Superior, policy based disk and tape management that provides virtualization over the external storage resources Integrated and completely unobtrusive volume based backups, and very fast and automated recoveries to any point in time z/os WLM exploitation by DB2 enables consolidating workloads with different service level agreements (SLA) 4 Another great example is our one-of-a-kind backup/recovery solution which is specifically developed for enterprise applications such as SAP. We can take a backup of many TBs of data in a few seconds, and have an absolute, 100% read/write availability during that time. So, not even a microsecond of temporary unavailability. Nobody is close to this. Then we can recover an entire system to any point in time in the fastest time theoretically possible. Online reorganization of both tables and indexes is another example. Oracle claims that they do not need reorganizations are false. They do not recommend it because, in their case it s very disruptive and they cannot take advantage of clustering (no prefetch for index-to-data access patterns). With unique WLM capabilities, the transactions and end users are characterized according to their individual SLA specifications and the database resources are allocated to them accordingly. With Unix the customers would most often run many boxes, dedicated to production systems. This is where major under-utilization effects kick in and this is where we have a great consolidation story. For the sites that have very large Unix boxes they can run multiple partitions, but there is either no or very crude workload management across these partitions. Additionally, you cannot control the workload within a particular partition, whereas with DB2 for z/os you can have granularity of individual user, transaction and program. This would be interesting to any Oracle customer: you can freely mix batch and online workload which is typical for enterprise appliactions without any major impact to your critical transactions. 4

5 Example: Security Isolation of partitions - Common Criteria Evaluation Assurance Level 5 Certification (EAL5 Security) System z servers with PR/SM LPAR are currently the only servers to achieve this prestigious assurance level for partitioning as of April 2006 From a security perspective, partitions are the functional equivalent of separate systems Partitions can't impact other partitions Partitions can't see into other partitions With full confidence you can run on the same z System: production and non-production different work 5 eweek 01/26/06 Oracle is advising its customers to quickly apply a critical database patch the company issued last week. Security experts warn the hole could allow even unsophisticated users to take control of Oracle databases. The hole is "very severe" and allows users to bypass the Oracle database's authentication and become administrative "super users"... eweek 01/06/06 Oracle 'Worm' Exploit Gets Ominous Tweak; Proof-of-concept code for a theoretical Oracle database worm has been modified and republished with a dangerous new attack technique. Exploit code for a malicious worm capable of wreaking havoc through Oracle databases has been tweaked and published, prompting a new round of warnings that an actual attack is inevitable. eweek 01/12/06 As Oracle Corp. grapples with its patch quality and speed, some in the security community have compared it unfavorably to Microsoft Corp. Gartner 01/26/06 Oracle has not yet experienced a mass security exploit, but this does not mean that one will never occur. System z offers the highest security assurance level. 5

6 Designed For The Most Challenging Applications Feature/function scorecards of any major DBMS look similar: The real difference is in the way these features and functions are developed and the actual goals that drive their implementation The features that characterize demanding database consumers have been in DB2 from the beginning Cost based optimization Partitioning and partitions independence Integrated, on-line utilities Automatic detection and recovery of physically inconsistent data Autonomic execution optimization 6 Feature/function scorecards of any major DBMS look similar: The real difference is in the way these features and functions are developed and the actual goals that drive their implementation The features that characterize demanding database consumers have been parts of DB2 for a very long time, often from its first releases which demonstrates DB2's orientation and understanding what are the real challenges for an industrial strength DBMS Cost based optimization for frequently changing operational and objects parameters coupled with complex joins and predicates Partitioning and partitions independence as the answer for huge and ever growing amounts of data. Integrated utilities for enabling unobtrusive database maintenance such as on-line backups and on-line reorganizations Automatic detection and recovery of physically inconsistent data Autonomic execution optimization: access pattern detection, lock avoidance, buffer pools throttling, dynamic adjustment of degree of parallelism, 6

7 DB2 Data Sharing Superior Scale-Out One-of-a-kind implementation of the shared-data architecture DB2 Data Sharing is more a hardware than a software solution Unlike Oracle Real Application Clusters (RAC) which is a shared-disk, software-based implementation that requires significant application-to-data affinity in order to scale, Taking advantage of the special purpose Coupling Facility hardware Packed by patented technology DB2 Data Sharing Deployed at hundreds of most demanding enterprise customers 7 One-of-a-kind implementation of the shared-data architecture Unlike Oracle Real Application Clusters (RAC) which is a shared-disk, software-based implementation that requires significant application-todata affinity in order to scale, DB2 Data Sharing is more a hardware than a software solution. In order to avoid crippling system-to-system messaging that grows exponentially with the increasing number of computing nodes, DB2 takes a full advantage of the special purpose Coupling Facility hardware that serves as a clustering hub and enables inter-system data coherency and global locking algorithms that are practically invariant to the number of computing nodes. Packed by patented technology DB2 Data Sharing is deployed at hundreds of most demanding enterprise customers who in reality have no viable alternative. This includes some of the largest SAP customers. Any large customer benefits from the unique DB2 scale-out. The largest single box is always smaller than two largest boxes. So, with zseries technology you can be sure that you can just add another box and do not depend on the scale-up performance of the single box. One can argue that the largest Unix boxes are quite powerful, but what about I/O and what about single system scaling effects if you go into 30, 40 or 64 processors? The benchmarks are totally unrealistic because they do not include any read I/O. That's just impossible in the real life, the I/O rates go into 10000s per second. 7

8 IBM IBM Architecture: Parallel Sysplex vs. Oracle RAC Parallel Sysplex Clustering Oracle RAC Clustering DB2 for z/os Database Coupling Facility Sysplex Da ta ba s e U U U U U D D D D D Single system image, one large db Dynamic workload management Sophisticated systems management Integrated, reliable HW/SW/OS solution No single points of failure High-speed inter-system links No zseries Coupling Facility means: More inter-system messaging Performance overhead DB partitioning, application may need changes 8 8

9 Components Of a RAC Cluster Global Cache Service (GCS) Manages Data Page Synchronization and sends blocks between nodes Global Enqueue Service (GES) Manages Global Locks for non data pages Buffer Cache Buffer Cache GES GCS GES GCS Shared Storage 9 Every data page in every file in a RAC database is assigned a Master node. The GCS on that node is responsible for managing access to that set of data pages. For example, in a 3 node cluster, each node manages access to 1/3 rd of the data. Whenever an instance wants to access a data page, it must first ask GCS on the master node for that data page GCS will either tell the requester to perform an I/O o tell another node that currently has that page in memory to ship it to the requester. 9

10 Example 1: One instance wants to read a block Instance A Instance B Instance C Instance C wants to read data block Master Node Instance D 1 Instance C must first ask master node The following example demonstrates inter-rac communication when an instance needs to read data. In this case the block is only on disk and not in the buffer cache of any other node. 10

11 Example 1: One instance wants to read a block Instance A Instance B Instance C Master tells Instance C to perform I/O 2 Instance C wants to read data block Master Node Instance D

12 Example 1: One instance wants to read a block Instance A Instance B Instance C Share Local Instance C reads the block into it s buffercache Master Node Instance D

13 Example 2: Another instance wants to read the same block Instance A Instance B Instance B wants to read the same data block Instance C 575 Share Local Master Node Instance D 1 Instance B must first ask master node The following example demonstrates inter-rac communication when another instance needs to read the same data. In this case the block is in the buffer cache of another node. 13

14 Example 2: Another instance wants to read the same block Instance A Instance B Instance B wants to read the same data block Instance C 2 Master tells C to send Block to B Master Node Instance D 575 Share Local

15 Example 2: Another instance wants to read the same block Instance A 3 Instance C C sends block to B Instance B 575 Share Local Instance B wants to read the same data block Share Local Master Node Instance D

16 Example 2: Another instance wants to read the same block Instance A 3 Instance C Instance B 575 Share Local Instance B wants to read the same data block Share Local 4 B tells master it now has block Master Node Instance D

17 DB2 Data Sharing Unmatched Continuous Availability The unplanned outages are handled with robust failover mechanisms Dealing with planned outages allowing controlled failovers Rolling DB2 software upgrades and maintenance Most impressive demonstration of DB2 Data Sharing Unique in the industry: on-line release upgrades and maintenance It demonstrates the attitude and passion for excellence with which the DB2 product is designed and developed 17 The unplanned outages are handled with robust failover mechanisms in which the surviving nodes seamlessly take over the processing of the failed node without any expensive resynchronization logic Dealing with planned outages is equally efficient: the DB2 Data Sharing architecture allows for controlled failovers that include quiescing the activity at the node that needs maintenance, routing the work to the remaining nodes and resuming the activity once the affected node becomes active. Most impressive demonstration of DB2 Data Sharing sophistication is rolling DB2 software upgrades and maintenance Unique in the industry: with DB2 Data Sharing the customers can do on-line release upgrades and maintenance without the need to stop their applications and end users access It demonstrates the attitude and passion for excellence with which the DB2 product is designed and developed Regarding downtimes for Oracle maintenance: Every patchset in Oracle requires them to recycle the database. They usually come out with one patchset a quarter so 4 per year (roughly). They also now have quarterly Critical Patch Updates (CPU) which is code for security bug fixes. These are also fairly large in size and in the last few cases, Oracle has strongly recommended that they be applied immediately. So that's another 4 outages per year for a total of 8 outages if you want to stay current. You might want to add to this some critical bug fixes, so it's quite frequent. 17

18 DB2 s Industry Leading Availability Database Server or Connectivity Planned and Unplanned Outages XDB2 DB2 Note: All data sharing members are active all the time Perfect environment for systems consolidation DB2 Connect exploitation of WLM Application server Application server 18 This chart demonstrates typical environment in which DB2 shows its unparalleled strength in handling planned and unplanned outages. Note that in the steady state all the nodes (members) actively participate in processing database workload (as opposed to active-passive configurations preferred by Oracle RAC). Because of this and WLM exploitation on both the client and server side, the z Systems are ideally suited for workload consolidation. 18

19 DB2 s Industry Leading Availability Loss of Computing Center X GDPS Systems Automation DB2 X DB2 X Application server Application server 19 19

20 RAC Steps Involved In A Node Failure Node failure detection Data block re-mastering Locking of pages that need recovery Redo and undo recovery 20 20

21 Data Block Re-Mastering When a node fails, the blocks it mastered must be redistributed to other nodes. While this is happening, GCS on all nodes is frozen Instance 1 Instance 2 Instance 3 Global Resource Directory Master for block Global Resource Directory Master for block Global Resource Directory Master for block One of the surviving nodes will perform the recovery It first freezes the database so no one can update any page It then reads the log files from the failed node and locks all of the data pages that need recovery The database is frozen because until all the pages are locked, there is no way for any surviving instance to know what pages need recovery This recovery node then perform redo and undo recovery on these pages 21

22 Availability in the Case of a Node Failure full availability partial Oracle RAC none Remastering Recovery Time full availability partial Recovery DB2 for z/os none 22 Time Most DBMS systems utilize a logging and recovery mechanism known as the ARIES algorithms. This recovery mechanism was initially designed by C. Mohan of the IBM Almaden Research Center in the mid 1980s ( ). Crash recovery involves two phases, first you must go through the log files to redo any transactions that updated data pages that did not yet make it to disk (i.e. the update was performed in the bufferpool but the page on disk was not updated). The second phase is to undo any transactions that were not committed but did update a page on disk. Both DB2 and Oracle must perform both phases. The node (subsystem, instance) that failed is recovered on another server and that server performs the crash recovery process. For both DB2 Data Sharing and RAC any transaction that was running on a node that did not fail can continue to process. In the case of DB2 Data Sharing only transactions that need data that was locked by the failed node are affected. In the case of Oracle RAC in addition to these transactions the transactions that need data that was mastered by the failed node are also affected. Oracle RAC has an additional step that is required for a RAC instance failure called data remastering. When one node in a RAC cluster fails, ownership of all of the data that was owned or mastered by that node must be transferred to the surviving nodes. During the process of remastering, the entire Oracle database on all nodes is frozen. That means all applications are suspended and there is no data access (read or write) available until the remastering process completes. there is no database availability. After remastering SMON is reading the redo log of the failed node to acquire all of the data blocks that will require redo processing. After that comes GCS reconfiguration. The impact of crash recovery log record processing must be then added on top of this outage. With DB2 for Data Sharing, only the data locked by the affected node is unavailable during the recovery process all other data on all other nodes remains fully accessible. In addition to freezing the entire database when one node fails, Oracle also has a single point of failure in their RAC architecture. Should the cluster management software fail for any reason, all nodes in the RAC cluster will fail. This single point of failure in a RAC cluster has no mitigation available. 22

23 DB2 V8: The biggest release ever Online schema change Backup and Recovery enhancements Automated space management Fast and automatic cached statements invalidation Transaction/end-user based accounting and workload management Enhancing RUNSTATS with DSTATS Long-running, noncommitting readers detection Lock escalation reporting improvement Providing cached statement id in IFCID 124 Improved LPL recovery DRDA and JCC tracing and diagnostics... Lifting virtual storage constraints Piece wise LOB insert More stage 1 predicates Index only access path for VARCHARs Fast retrieval of the most recent value Eliminating lock contention on special purpose tables Option to release locks at cursor close Allowing updating partitioning key column without partition locks Disassociating clustering from partitioning key DPSI Up to 4096 partitions Data sharing improvements DRDA performance improvements Array inserts and fetches Sparse indexes Reducing negative impact of host variables at access path selection REOPT(ONCE) Transparent ROWID for tables containing LOBs Full Unicode support Lifting database object names length limits Up to 255 tables in FROM Materialized Query Tables (a.k.a. Automatic Summary Tables) Common Table Expressions Recursive SQL Multiple DISTINCTs DB2 Connect 64-bit client for Linux on zseries Allowing comments in dynamic SQL... The following four charts demonstrate DB2 trends and directions. In addition to adding to traditional DB2 strengths (availability, reliability, performance, scalability, ) a major main theme emerges: reducing Total Cost of Ownership through ease of operations and autonomic features. 23

24 A Major V8 Theme: Reducing TCO Online schema change Backup and Recovery enhancements Automated space management Fast and automatic cached statements invalidation Transaction/end-user based accounting and workload management Enhancing RUNSTATS with DSTATS Long-running, non- committing readers detection Lock escalation reporting improvement Providing cached statement id in IFCID 124 Improved LPL recovery DRDA and JCC tracing and diagnostics... Lifting virtual storage constraints Piece wise LOB insert More stage 1 predicates Index only access path for VARCHARs Fast retrieval of the most recent value Eliminating lock contention on special purpose tables Option to release locks at cursor close Allowing updating partitioning key column without partition locks Disassociating clustering from partitioning key DPSI Up to 4096 partitions Data sharing improvements DRDA performance improvements Array inserts and fetches Sparse indexes Reducing negative impact of host variables at access path selection REOPT(ONCE) Transparent ROWID for tables containing LOBs Full Unicode support Lifting database object names length limits Up to 255 tables in FROM Materialized Query Tables (a.k.a. Automatic Summary Tables) Common Table Expressions Recursive SQL Multiple DISTINCTs DB2 Connect 64-bit client for Linux on zseries Allowing comments in dynamic SQL... 24

25 DB2 V9: Another features rich release Native SQL Procedural Language Optimistic locking XML support in DB2 engine TRUNCATE statement MERGE statement INSTEAD OF triggers SELECT FROM UPDATE / DELETE / MERGE ORDER BY and FETCH FIRST in subselect IPv6 and SSL support Modify early code without requiring an IPL APPEND option for inserts Relief for sequential key insert LOB performance and scalability INDEX on expression Index page size greater than 4K Utilities CPU reduction DB2 Trace filtering... Point in time recover improvements Faster restart of data sharing Decimal Floating Number, BIGINT, VARBINARY data types Reordered row format CLONE Table: fast replacement of one table with another Renaming column, index, and schema Table space that can add partitions, as needed for growth Improve ability to create an index online and rebuild it Online reorganization with no BUILD2 phase Parallel unload and reload during REORG Consistent recover of a single object Converged TEMP space Automatic objects creation 64-bit exploitation by DDF Automatic collection of performance data for long queries Autonomic access path reoptimization Automatic query monitoring for most frequent/expensive queries Optimization Service Center Index compression Database ROLEs Trusted security context Enhancing volume based backup/recovery: object-level recoveries Cross query block optimization Histogram statistics exploitation Generalized sparse index and inmemory data cache method Dynamic index ANDing for Star Schema EXCEPT and INTERSECT New process qualification options for RLF... 25

26 And Again, TCO Reduction Is A Major Theme Native SQL Procedural Point in time recover Automatic collection of performance Language improvements data for long queries Optimistic locking Faster restart of data sharing Autonomic access path XML support in DB2 engine Decimal Floating Number, reoptimization TRUNCATE statement BIGINT, VARBINARY data Automatic query monitoring for most types frequent/expensive MERGE statement queries Reordered row format INSTEAD OF triggers Optimization Service Center CLONE Table: fast replacement SELECT FROM UPDATE / Index compression of one table with another DELETE / MERGE Database ROLEs Renaming ORDER BY and FETCH FIRST column, index, and Trusted security context schema in subselect Enhancing volume based Table space that can add IPv6 and SSL support backup/recovery: object-level partitions, as needed for growth recoveries Modify early code without Improve ability to create an requiring an IPL Cross query block optimization index online and rebuild it APPEND option for inserts Histogram statistics exploitation Online reorganization with no Relief for sequential key insert Generalized sparse index and in- BUILD2 phase LOB performance and memory data cache method Parallel unload and reload scalability Dynamic index ANDing for Star during REORG INDEX on expression Schema Consistent recover of a single Index page size greater than 4K EXCEPT and INTERSECT object New process qualification options Utilities CPU reduction Converged TEMP space for RLF DB2 Trace filtering Automatic objects creation bit exploitation by DDF

27 Technology Evolution with Mainframe Specialty Engines Building on a strong track record of technology innovation with specialty engines, IBM intends to introduce the System z9 Integrated Information Processor Centralized data sharing across mainframes Internal Coupling Facility (ICF) 1997 Integrated Facility for Linux (IFL) 2001 Support for new workloads and open standards System z9 Application Assist Processor (zaap) 2004 Designed to help improve resource optimization for z/os JAVA workloads IBM System z9 Integrated Information Processor (IBM ziip) 2006 Designed to help improve resource optimization for eligible data workloads within the enterprise 27 ziips are introduced to further strengthen DB2 for z/os TCO proposition. They continue z Systems tradition of using specialty processors that are optimized for specific workloads and computing conditions. 27

28 DB2 Workloads That May Benefit from ziip 1. ERP or CRM application serving For applications, running on z/os, UNIX, Linux, Intel, or Linux on System z, that access DB2 for z/os V8 on a System z9, via DRDA over a TCP/IP connection DB2 gives z/os the necessary information to have portions of these SQL requests directed to the ziip TCP/IP CP TCP/IP CP New Engine 2. Data warehousing applications Requests that utilize DB2 for z/os V8 parallel queries may have portions of these SQL requests directed to the ziip when DB2 gives z/os the necessary information 3. Some DB2 for z/os V8 utilities A portion of DB2 utility functions used to maintain index maintenance structures (example LOAD, REORG, and REBUILD INDEX) typically run during batch, can be redirected to ziip 28 The ziip is designed so that a program can work with z/os to have all or a portion of it s Service Request Block (SRB) enclave work directed to the ziip. The above types of DB2 V8 work are those executing in SRB enclaves, portions of which can be sent to the ziip. Note that the body i.e. the mainline part of the stored procedures does not qualify for offloading to ziips. 28

29 Superior Data Serving For All Information Management Database Server Content Management Business Intelligence Information Integration 29 DB2 is often associated to providing database serving functionality. However, it is also a crucial part of many other information management segments such as Information Integration, Business Intelligence and Content Management. 29

30 Guess Who Said This? eweek ( 31-Oct-2003: I make fun of a lot of other databases - all other databases, in fact, except the mainframe version of DB2. It's a first-rate piece of technology. Larry Ellison, Oracle's Founder and CEO 30 30

31 Legal information The charts describing the contents of the next DB2 release are based on the current product plans and the information presented may not apply when the product becomes generally available. The product information (when it becomes available) needs to be consulted for more current status. Other company, product or service names may be trademarks or service marks of others such as: Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries

32 Session A05 DB2 for z/os vs. Oracle RAC A Reality Check Namik Hrle IBM hrle@de.ibm.com 32 32