DB2 LUW Performance: Scalability, Availability, and Disaster Recovery


Posted by Scott on February 9, 2010, 7:03 am
in DB2 Performance Best Practices ( DB2 Performance)

IBM is generating a lot of buzz with DB2 pureScale, and there is plenty of press to read on Database and Hardware wars. The DB2Night Show™ Episode #4 featured special guests from the IBM Toronto Lab who gave us an outstanding introduction to DB2 pureScale - catch the WMV replay if you missed it. On the heels of DB2 9.7 Oracle enablement, DB2 pureScale is an exciting response to Oracle RAC. But is pureScale right for your organization, or should you be considering Xkoto GRIDSCALE instead? First and foremost, IBM DB2 PureScale is NOT a Disaster Recovery solution, but Xkoto GRIDSCALE is. How else are these technologies different?
IBM is generating a lot of buzz with DB2 pureScale, and there is plenty of press to read on Database and Hardware wars. The DB2Night Show™ Episode #4 featured special guests from the IBM Toronto Lab who gave us an outstanding introduction to DB2 pureScale - catch the WMV replay if you missed it. On the heels of DB2 9.7 Oracle enablement, DB2 pureScale is an exciting response to Oracle RAC. But is pureScale right for your organization, or should you be considering Xkoto GRIDSCALE instead? First and foremost, IBM DB2 PureScale is NOT a Disaster Recovery solution, but Xkoto GRIDSCALE is. How else are these technologies different?


IBM DB2 pureScale only runs on IBM pSeries 550 and 595 servers. Special networking cards must be installed, and the servers must be co-located in the same data center... thus making pureScale NOT a DR solution. Have you seen the sticker prices for this hardware?


Xkoto GRIDSCALE, on the other hand, can run DB2 on AIX, Linux, Sun, HP, or Windows. GRIDSCALE can use DB2 Enterprise Server Edition, Workgroup Edition, Express Edition, or Express-C Edition data servers on brand name or white box commodity servers.


Both solutions assert themselves to be "continuous" availability solutions, but


  1. if the power goes out in your data center due to a snow storm, pureScale is no longer continuous
  2. the administrative ease of varying DB2 servers in a cluster online and offline seems easier with Xkoto (IMHO)

The data servers participating in an Xkoto GRIDSCALE cluster can use rolling maintenance windows to incrementally update the DB2 servers (as can pureScale), but GRIDSCALE will additionally permit the use of DB2 data servers being on different DB2 release and even version levels - with such flexibility, it may be easier, or less risky, to "ease into" new releases of DB2. (We have heard from a number of DB2 customers upgrading to 9.5 and experiencing performance degradation).


Xkoto GRIDSCALE supports DB2 V8.2, V9.1, V9.5, and V9.7. I wouldn't be surprised if Xkoto is even supporting DB2 9.8. IBM DB2 pureScale supports, well, DB2 V9.8.


If you visit Xkoto's website, you'll note that they also talk about Reducing IT Costs. You might just be able to retire your old 8, 16, or 32-way Sun servers with DB2 Enterprise Edition Licenses, and swap for Linux 4-Way clusters with DB2 Workgroup Edition licenses instead - you could achieve greater performance at a fraction of the hardware and licensing costs.


Some people are looking at DB2 9.7 for its HADR dirty read capability. If you want the 9.7 HADR dirty reads, get ready to buck up for full DB2 LUW licenses for the HADR server instead of just the one CPU cost of DB2 9.5 and earlier. Now, if you are going to have to pay full boat for your DB2 LUW licenses on the active and DR server - but you only get read access on DR - then why not spend a few extra dollars on GRIDSCALE to make both servers active with true continuous availability and the scalability of two actives? If done correctly, there's likely a way to swap out two 8-way servers (one active and one HADR) for two 4-way servers which are BOTH active and realize net cost savings with improved performance and scalability.


Full disclosure here - when I first learned about Xkoto GRIDSCALE a few years ago I thought "Great, here's another way for organizations to throw money at hardware to try to solve performance problems." It seems that IBM DB2 pureScale is yet another opportunity to spend a lot of money on expensive hardware in pursuit of solving performance problems.


Well, let me shoot you straight (as we say in Texas). The world has an obesity problem. People are increasingly overweight (I read this in Reader's Digest ). And, you know what? Our data centers are overweight and bloated too - energy is wasted and license costs are inflated.


If you put your DB2 database server transaction processing costs on a diet (yes, this means tuning) so that transactions complete with lower CPU and I/O costs, then:


  1. You can lower energy costs by 24-44% or more
  2. You will improve response times for transactions and reports
  3. Productivity will increase for data server end users (no one likes to wait)
  4. You can improve server consolidation ratios, or defer or avoid hardware upgrades
  5. You can achieve even greater scalability with fewer active servers if you use either Xkoto Gridscale or IBM DB2 pureScale
    • You'll save more using commodity hardware and Xkoto Gridscale


From years of experience, we've seen the consequences of hardware binges. For at least 9 out of 10 databases that we work with, we are usually able to help our clients and customers cut CPU utilization by 30-90%, cut storage system I/Os by just as much, and often cut response times in half or more.


So, if the "saved" system capacity is re-invested to double throughput on a given server (2X), and you clone a tuned server instead of a bloated, un-tuned server (1X), now your Active-Active pair can achieve performance at a factor of 4X (2 x 2X) instead of (2 x 1X) 2X. In fact, it would take 4 un-tuned servers (1X) to achieve the same 4X performance as two well-tuned servers.


Ouch - that last paragraph might have hurt your brain. Let me spell it out for you in dollars. Working with 8-way servers, each server might cost $300K and database licenses might cost 8x33K, or $250K (rounding down to allow some discounts). So, each server runs $550K (plus energy costs). If you put your database transaction processing costs on a diet and tune your servers, 4X performance will cost you two servers at $550K, or $1.1M. If you just throw hardware at performance and don't optimally tune, then 4X performance will cost your organization 4 x $550K, or $2.2M - plus double the energy costs and floor space. If you spend $80K on performance analysis and tuning tools and only 1/4 FTE on database tuning efforts, you still just saved $1M. In this economy, your fiscal prudence will shine.


Putting an end to Hardware Addiction


You can defer or avoid hardware upgrades by tuning your DB2 data servers. 9 out of 10 database servers have bloated workload costs that can be reduced by 30-90% in just a few days (if only losing weight was this easy!) ). No matter which scalability and availability solution you choose, or whether or not you deploy these technologies, I assure you that you can eliminate waste from your IT budget by putting your database transaction processing costs on a diet.


Cutting to the Chase


Hardware sales guys hate us. Software license sales guys hate us. Your users, energy company, and IT budget will love us. Contact DBI BEFORE you contact your hardware salesman! Really! Get an independent, objective, unbiased opinion from the company that delivers Remarkable Breakthrough Results around the world.


Our magic is in our methods, metrics, and analysis



Using DBI's Brother-Panther®, you can achieve 30-90% CPU utilization reductions in SIX mouse clicks or fewer. Your first mouse click could show:


Brother-Panther Tablespace Performance Analysis


Tablespace I/O Performance Analysis


With just one more mouse click, you can discover all of the Tables contributing I/O to a tablespace and quickly learn which tables are the I/O heavy hitters along with which tables have I/O problems:


Brother-Panther Table Performance Analysis


OLTP Tables with Table Rows Read per Transaction (TBRRTX) > 10 have I/O problems


Give us a third mouse click, and we will show you which SQL/XML statements are driving I/O to any selected table:
Statements, and their aggregate and relative costs, driving I/O to a selected table


This is Statement Cost Aggregation showing total costs for statements contributing I/O to the selected table plus relative costs. Please notice the absence of rates (bah-humbug).


Grant us just one more mouse click, and we'll give you a physical design solution or solutions that will likely reduce your overall workload cost by 30-90%, lower your CPU utilization, increase your SRP and lower I/O costs, and measurably improve application response times and SLA attainments.


That's it. If you work with DBI, we'll help you lower your IT costs and improve application performance in fewer than a half dozen (6) mouse clicks. If we made database tuning any easier or more fun, we'd have to reclassify our company with the Internal Revenue Service (IRS, or taxing authority for non-US readers) as a shrink wrapped video game provider. Look for the Nintendo Wii Edition of our software next year.


Get started with a Proof of Concept. CONTACT DBI or give us a call toll free in the US at 1-866-773-8789 or international at 1-512-249-2324. We'd be happy to give you a briefing on Xkoto Gridscale as well - just let us know.


Thanks for reading. Hope this helped you learn about the differences between IBM DB2 pureScale and Xkoto Gridscale. This blog post took four hours to write.


Kind regards,

Scott Hayes

President & CEO, DBI

IBM GOLD Consultant and Data Management Champion

Host of The DB2Night Show

Post from : http://www.dbisoftware.com/blog/db2_performance.php
Printed from : http://www.dbisoftware.com/blog/db2_performance.php?id=183