Showdown: IBM DB2 versus Oracle Database for OLTP

13,185 views

Published on

A comparison of IBM DB2 and Oracle Database for OnLine Transaction Processing (OLTP) environments.

Published in: Technology

Showdown: IBM DB2 versus Oracle Database for OLTP

  1. 1. Showdown: DB2 vs. Oracle Database for OLTP Conor O’Mahony Email: [email_address] Twitter: conor_omahony Blog: db2news.wordpress.com Conor O’Mahony Email: [email_address] Twitter: conor_omahony Blog: database-diary.com
  2. 2. Agenda <ul><li>What Improves OLTP Performance? </li></ul><ul><li>Comparing OLTP Performance </li></ul><ul><li>Comparing Cluster Scalability </li></ul><ul><li>Comparing Cluster Availability </li></ul><ul><li>What Users are Saying </li></ul>
  3. 3. Technology for OLTP Performance <ul><li>Efficient I/O </li></ul><ul><ul><li>High performing data access </li></ul></ul><ul><ul><li>Logger most critical choke point </li></ul></ul><ul><li>Large Memory Exploitation </li></ul><ul><ul><li>Multiple buffer pools </li></ul></ul><ul><li>Ability to handle lots of users </li></ul><ul><ul><li>Low memory footprint per user </li></ul></ul><ul><ul><li>Connection concentrator </li></ul></ul>
  4. 4. Efficient I/O <ul><li>Logging is the most critical factor in high volume OLTP </li></ul><ul><li>TPC-C proves that DB2 has a more efficient logger </li></ul><ul><ul><li>DB2 logs less than ½ of Oracle Database and SQL Server </li></ul></ul><ul><ul><ul><li>DB2 9 = 2.4KB of log per transaction </li></ul></ul></ul><ul><ul><ul><li>Oracle 10gR2 = 4.9KB of log per transaction </li></ul></ul></ul><ul><ul><ul><li>SQL Server 2005 = 6.0KB of log per transaction </li></ul></ul></ul><ul><li>Reduced logging = increased performance </li></ul>
  5. 5. Large Memory and Efficient Memory Usage <ul><li>TPC-C benchmark with DB2 on p5 595 used 2TB of real memory </li></ul><ul><ul><li>1.9TB of buffer pool space allocated by DB2 </li></ul></ul><ul><ul><ul><li>Using multiple buffer pools of different page sizes </li></ul></ul></ul><ul><li>DB2 is now threaded </li></ul><ul><ul><li>One flat memory address space for all of DB2 </li></ul></ul><ul><ul><li>No more private memory (all shared) </li></ul></ul><ul><ul><ul><li>Reduces per connection footprint by 1MB </li></ul></ul></ul><ul><li>More efficient memory access = better performance </li></ul>
  6. 6. User Scalability <ul><li>DB2 has a proven ability to support lots of users </li></ul><ul><li>Supports two connection methods: </li></ul><ul><ul><li>Each client has connection process on server </li></ul></ul><ul><ul><li>Server processes are shared amongst incoming requests </li></ul></ul><ul><li>DB2 has a lower memory footprint per agent (connection) than other vendors </li></ul><ul><ul><li>Enables more client connections for a given amount of memory </li></ul></ul><ul><li>Better user scalability = more throughput </li></ul>
  7. 7. Agenda <ul><li>What Improves OLTP Performance? </li></ul><ul><li>Comparing OLTP Performance </li></ul><ul><li>Comparing Cluster Scalability </li></ul><ul><li>Comparing Cluster Availability </li></ul><ul><li>What Users are Saying </li></ul>
  8. 8. Transactional Performance <ul><li>Two large-scale standardized performance benchmarks for transactional workloads are often used for comparisons </li></ul><ul><ul><li>TPC-C – industry standard OLTP benchmark </li></ul></ul><ul><ul><li>SAP SD – represents an SAP R/3 Sales and Distribution application </li></ul></ul>
  9. 9. Longevity in TPC-C Performance Results as of April 21, 2008
  10. 10. Apples-to-Apples Comparison <ul><li>Both on exactly the same server (8way 1.9GHz p5 570) </li></ul><ul><li>DB2 v8 vs. Oracle 10g </li></ul><ul><li>DB2 leads in performance by 16% over Oracle </li></ul>16% Faster Results current as of Feb 24, 2008 Check http://www.tpc.org for latest results
  11. 11. Longevity in SAP 3-Tier SD Performance Results as of Jan 8, 2008
  12. 12. SAP SD 3-tier <ul><li>This benchmark represents a 3-tier SAP R/3 environment </li></ul><ul><ul><li>Database on separate server </li></ul></ul><ul><li>DB2 outperforms Oracle by 68% with half the number of cores </li></ul><ul><ul><li>DB2 running on 32-way p5 595 </li></ul></ul><ul><ul><li>Oracle running on 64-way HP </li></ul></ul>
  13. 13. 2-tier SAP SD Benchmarks <ul><li>DB2 on IBM Power leads Oracle on HP by 18% on ½ the number of cores </li></ul><ul><li>DB2 on IBM Power delivers significantly more SAPS/Watt saving you money </li></ul>Results as of April 8, 2008
  14. 14. Agenda <ul><li>What Improves OLTP Performance? </li></ul><ul><li>Comparing OLTP Performance </li></ul><ul><li>Comparing Cluster Scalability </li></ul><ul><li>Comparing Cluster Availability </li></ul><ul><li>What Users are Saying </li></ul>
  15. 15. Oracle RAC - Single Instance Wants to Read a Page <ul><li>Process on Instance 1 wants to read page 501 mastered by instance 2 </li></ul><ul><ul><li>System process checks local buffer pool: page not found </li></ul></ul><ul><ul><li>System process sends an IPC to the Global Cache Service process to get page 501 </li></ul></ul><ul><ul><ul><li>Context Switch to schedule GCS on a CPU </li></ul></ul></ul><ul><ul><ul><li>GCS copies request to kernel memory to make TCP/IP stack call </li></ul></ul></ul><ul><ul><li>GCS sends request over to Instance 2 </li></ul></ul><ul><ul><ul><li>IP receive call requires interrupt processing on remote node </li></ul></ul></ul><ul><ul><li>Remote node responds back via IP interrupt to GCS on Instance 1 </li></ul></ul><ul><ul><li>GCS sends IPC to System process (another context switch to process request) </li></ul></ul><ul><ul><li>System process performs I/O to get the page </li></ul></ul>Buffer Cache Instance 2 Buffer Cache system 1 2 3 4 GCS GCS 5 6 501 501 Instance 1
  16. 16. What Happens in DB2 pureScale to Read a Page <ul><li>Agent on Member 1 wants to read page 501 </li></ul><ul><ul><li>db2agent checks local buffer pool: page not found </li></ul></ul><ul><ul><li>db2agent performs Read And Register (RaR) RDMA call directly into CF memory </li></ul></ul><ul><ul><ul><li>No context switching, no kernel calls. </li></ul></ul></ul><ul><ul><ul><li>Synchronous request to CF </li></ul></ul></ul><ul><ul><li>CF replies that it does not have the page (again via RDMA) </li></ul></ul><ul><ul><li>db2agent reads the page from disk </li></ul></ul>Group Buffer Pool CF Buffer Pool Member 1 db2agent 1 2 3 4 501 501 PowerHA pureScale
  17. 17. Oracle RAC - Single Instance Wants to Read a Page <ul><li>Process on Instance 1 wants to read page 501 mastered by instance 2 </li></ul><ul><ul><li>System process checks local buffer pool: page not found </li></ul></ul><ul><ul><li>System process sends an IPC to the Global Cache Service process to get page 501 </li></ul></ul><ul><ul><ul><li>Context Switch to schedule GCS on a CPU </li></ul></ul></ul><ul><ul><ul><li>GCS copies request to kernel memory to make TCP/IP stack call </li></ul></ul></ul><ul><ul><li>GCS sends request over to Instance 2 </li></ul></ul><ul><ul><ul><li>IP receive call requires interrupt processing on remote node </li></ul></ul></ul><ul><ul><li>Remote node responds back via IP interrupt to GCS on Instance 1 </li></ul></ul><ul><ul><li>GCS sends IPC to System process (another context switch to process request) </li></ul></ul><ul><ul><li>System process performs I/O to get the page </li></ul></ul>Buffer Cache Instance 2 Buffer Cache system 1 2 3 4 GCS GCS 5 6 501 501 Instance 1
  18. 18. What Happens in DB2 pureScale to Read a Page <ul><li>Agent on Member 1 wants to read page 501 </li></ul><ul><ul><li>db2agent checks local buffer pool: page not found </li></ul></ul><ul><ul><li>db2agent performs Read And Register (RaR) RDMA call directly into CF memory </li></ul></ul><ul><ul><ul><li>No context switching, no kernel calls. </li></ul></ul></ul><ul><ul><ul><li>Synchronous request to CF </li></ul></ul></ul><ul><ul><li>CF replies that it does not have the page (again via RDMA) </li></ul></ul><ul><ul><li>db2agent reads the page from disk </li></ul></ul>Group Buffer Pool CF Buffer Pool Member 1 db2agent 1 2 3 4 501 501 PowerHA pureScale
  19. 19. The Advantage of DB2 Read and Register with RDMA <ul><li>DB2 agent on Member 1 writes directly into CF memory with: </li></ul><ul><ul><li>Page number it wants to read </li></ul></ul><ul><ul><li>Buffer pool slot that it wants the page to go into </li></ul></ul><ul><li>CF either responds by writing directly into memory on Member 1: </li></ul><ul><ul><li>That it does not have the page or </li></ul></ul><ul><ul><li>With the requested page of data </li></ul></ul><ul><li>Total end to end time for RAR is measured in microseconds </li></ul><ul><li>Calls are very fast, the agent may even stay on the CPU for the response </li></ul>Much more scalable, does not require locality of data Direct remote memory write with request I don’t have it, get it from disk I want page 501. Put into slot 42 of my buffer pool. Direct remote memory write of response Member 1 CF 1, Eaton, 10210, SW 2, Smith, 10111, NE 3, Jones, 11251, NW db2agent CF thread
  20. 20. Transparent Application Scalability <ul><li>Scalability without application or database partitioning </li></ul><ul><ul><li>Centralized locking and real global buffer pool with RDMA access results in real scaling without making application cluster aware </li></ul></ul><ul><ul><ul><li>Sharing of data pages is via RDMA from a true shared cache </li></ul></ul></ul><ul><ul><ul><ul><li>not synchronized access via process interrupts between servers) </li></ul></ul></ul></ul><ul><ul><ul><li>No need to partition application or data for scalability </li></ul></ul></ul><ul><ul><ul><ul><li>Resulting in lower administration and application development costs </li></ul></ul></ul></ul><ul><ul><li>Distributed locking in RAC results in higher overhead and lower scalability </li></ul></ul><ul><ul><ul><li>Oracle RAC best practices recommends </li></ul></ul></ul><ul><ul><ul><ul><li>Fewer rows per page (to avoid hot pages) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Partition database to avoid hot pages </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Partition application to get some level of scalability </li></ul></ul></ul></ul><ul><ul><ul><ul><li>All of these result in higher management and development costs </li></ul></ul></ul></ul>
  21. 21. 2, 4 and 8 Members Over 95% Scalability Scalability for OLTP Applications 64 Members 95% Scalability 16 Members Over 95% Scalability 32 Members Over 95% Scalability 88 Members 90% Scalability 112 Members 89% Scalability 128 Members 84% Scalability
  22. 22. Agenda <ul><li>What Improves OLTP Performance? </li></ul><ul><li>Comparing OLTP Performance </li></ul><ul><li>Comparing Cluster Scalability </li></ul><ul><li>Comparing Cluster Availability </li></ul><ul><li>What Users are Saying </li></ul>
  23. 23. Online Recovery <ul><li>DB2 pureScale design point is to maximize availability during failure recovery processing </li></ul><ul><li>When a database member fails, only in-flight data remains locked until member recovery completes </li></ul><ul><ul><li>In-flight = data being updated on the failed member at the time it failed </li></ul></ul><ul><li>Target time to row availability </li></ul><ul><ul><li><20 seconds </li></ul></ul>Shared Data CF CF Log Log Log Log DB2 DB2 DB2 DB2 % of Data Available Time (~seconds) Only data in-flight updates locked during recovery Database member failure 100 50
  24. 24. Steps Involved in DB2 pureScale Member Failure <ul><li>Failure Detection </li></ul><ul><li>Recovery process pulls directly from CF: </li></ul><ul><ul><li>Pages that need to be fixed </li></ul></ul><ul><ul><li>Location of Log File to start recovery from </li></ul></ul><ul><li>Restart Light Instance performs redo and undo recovery </li></ul>
  25. 25. Failure Detection for Failed Member <ul><li>DB2 has a watchdog process to monitor itself for software failure </li></ul><ul><ul><li>The watchdog is signaled any time the DB2 member is dying </li></ul></ul><ul><ul><li>This watchdog will interrupt the cluster manager to tell it to start recovery </li></ul></ul><ul><ul><li>Software failure detection times are a fraction of a second </li></ul></ul><ul><li>The DB2 cluster manager performs very low level, sub second heart beating (with negligible impact on resource utilization) </li></ul><ul><ul><li>DB2 cluster manager performs other checks to determine congestion or failure </li></ul></ul><ul><ul><li>Result is hardware failure detection in under 3 seconds without false failovers </li></ul></ul>
  26. 26. Member Failure Summary DB2 Single Database View CF Shared Data <ul><li>Member Failure </li></ul><ul><li>DB2 Cluster Services automatically detects member’s death </li></ul><ul><ul><li>Inform other members, and CFs </li></ul></ul><ul><ul><li>Initiates automated member restart on same or remote host </li></ul></ul><ul><ul><li>Member restart is like crash recovery in a single system, but is much faster </li></ul></ul><ul><ul><ul><li>Redo limited to in-flight transactions </li></ul></ul></ul><ul><ul><ul><li>Benefits from page cache in CF </li></ul></ul></ul><ul><li>Client transparently re-routed to healthy members </li></ul><ul><li>Other members fully available at all times – “Online Failover” </li></ul><ul><ul><li>CF holds update locks held by failed member </li></ul></ul><ul><ul><li>Other members can continue to read and update data not locked by failed member </li></ul></ul><ul><li>Member restart completes </li></ul><ul><ul><li>Locks released and all data fully available </li></ul></ul>DB2 DB2 DB2 CF Updated Pages Global Locks Primary CF Secondary CF Updated Pages Global Locks Log CS CS Clients CS CS CS CS Log Log Log Log Records Pages kill -9
  27. 27. Steps involved in a RAC node failure <ul><li>Node failure detection </li></ul><ul><li>Data block remastering </li></ul><ul><li>Locking of pages that need recovery </li></ul><ul><li>Redo and undo recovery </li></ul>Unlike DB2 pureScale, Oracle RAC does not centralize lock or data cache
  28. 28. With RAC – Access to GRD and Disks are Frozen <ul><li>Global Resource Directory (GRD) Redistribution </li></ul>No more I/O until pages that need recovery are locked No Lock Updates GRD GRD Instance 1 fails Instance 1 Instance 2 Instance 3 I/O Requests are Frozen GRD
  29. 29. With RAC – Pages that Need Recovery are Locked GRD GRD Instance 1 fails I/O Requests are Frozen Instance 1 Instance 2 Instance 3 Recovery Instance reads log of failed node Recovery instance locks pages that need recovery x x x x x x redo log redo log redo log GRD Must read log and lock pages before freeze is lifted.
  30. 30. DB2 pureScale – No Freeze at All Member 1 fails Member 1 Member 2 Member 3 No I/O Freeze CF knows what rows on these pages had in-flight updates at time of failure x x x x x x x x x x x x CF always knows what changes are in flight CF Central Lock Manager
  31. 31. Agenda <ul><li>What Improves OLTP Performance? </li></ul><ul><li>Comparing Cluster Scalability </li></ul><ul><li>Comparing Cluster Availability </li></ul><ul><li>Comparing OLTP Performance </li></ul><ul><li>What Users are Saying </li></ul>
  32. 32. Sample of Feedback… <ul><li>“ We compared DB2 with Oracle and found that DB2 was more reliable and has a better price-performance ratio.” </li></ul><ul><ul><li>― Dr. Yuki Kitaoka, Kyoto National Hospital </li></ul></ul><ul><li>“ We chose DB2 over Oracle and Sybase for its proven performance, availability and cost-effectiveness.” </li></ul><ul><ul><li>― Atakan Karaman, Anadolu Group </li></ul></ul><ul><li>“ DB2 Universal Database is the bank’s database of choice for its high availability, scalability and performance.” </li></ul><ul><ul><li>― Patrick Stearn, Bayerische Landesbank </li></ul></ul><ul><li>“ In comparison tests with both Oracle and Microsoft, DB2 continually demonstrated a better price-to-performance ratio -- the quality of DB2 is quite astonishing.” </li></ul><ul><ul><li>― Benjamin Simmen, Zurich Financial Services </li></ul></ul><ul><li>“ When making our decision, we discovered that a $250,000 DB2/Linux solution performed better than a $1.5 million Oracle/Solaris solution” </li></ul><ul><ul><li>― Carl Ansley, CTO, Clarity Payment Solutions, Inc. </li></ul></ul>
  33. 33. Thank You! <ul><li>For more information, see www.ibm.com/db2 </li></ul><ul><li>Or contact me at: </li></ul>Conor O’Mahony Email: [email_address] Twitter: conor_omahony Blog: database-diary.com

×