Archive for August 2009
Database-Brothers Inc. (DBI) are organizing a regular Webcast called The DB2Night Show. It promises to be an informative and fun show, and has lined up interesting guests. It also has fun segments like the following:
We are going to go to a shopping mall and ask random people what they think and know about DB2, if they have heard of IBM, and how they are contributing to a Smarter Planet.
You can sign up for the shows at The DB2Night Show.
- IBM and SAP work together to optimize DB2 for SAP
SAP and IBM work together to optimize DB2 for SAP. The joint SAP and IBM teams co-located in Toronto, Canada and Walldorf, Germany make sure that DB2 is optimized and certified for each new release of SAP in a timely manner. DB2 is the only database software with such a close working arrangement. Other database vendors typically take several months to become officially supported by SAP.
- SAP Integrates DB2 into SAP Applications
By integrating DB2 into SAP applications, SAP offers you a single point-of-contact for support. IBM and SAP cooperate in every phase of the software lifecycle to provide you with the best possible integrated product offering.
- DB2 has more efficient storage
SAP environments often have large amounts of data. Some estimates claim that data storage costs represent almost half of enterprise IT infrastructure costs. DB2 typically outperforms other database software when it comes to minimizing data storage.
- DB2 is easier to administer
DB2 automates many DBA activities for SAP environments, including database reorganizations, memory tuning, collection of database statistics, database backups, log file management, and storage allocation.
- DB2 Makes SAP Faster
DB2 has consistent leadership of SAP SD 2-tier and 3-tier performance benchmarks. See for yourself at SAP Standard Application Benchmarks.
- DB2 offers High Availability and Disaster Recovery as standard
DB2 for SAP includes High Availability and Disaster Recovery capabilities for no extra charge. DB2 provides ultra-fast switchovers from the primary to standby systems; for example, in a SAP test environment with 600 users, services were resumed within 11 seconds.
- SAP uses DB2
There can be no greater endorsement than SAP choosing to use DB2 for all of its own SAP applications.
There is an article at SearchSAP.com describing how SAP infrastructure changes to databases, servers yield quick returns. The article quotes Derek Prior of AMR Research who says that “some are finding it cheaper to swap Oracle databases in a more Unix-oriented environment to DB2” and that companies are “realizing payback within nine to 10 months“.
This is consistent with what we are seeing at IBM. Here are a selection of quotes from organizations who recently swapped the database software for their SAP applications to DB2:
“The migration to DB2 was completed in three months. We estimate that database operational costs have been cut by 68 per cent… The migration was smooth and completed absolutely without a hitch.“—Ralf Rohrer, Head of Server and Storage Operations at Industrielle Werke Basel (IWB)
“Thanks to DB2, we are saving around 25 per cent on software licensing and maintenance fees – which means we have more money in the IT budget to spend on solutions that deliver additional competitive advantage for our business.“—Ozcan Soke, IT Manager, Borçelik
“Our database is now 43 per cent smaller than before, and some of the largest tables have been reduced by up to 70 per cent. Despite the compression, there has been no impact on batch performance, and our most important online transactions are actually 20 per cent faster with the new version of DB2.“—Roland Heim, SAP Basis Administrator, INTER Versicherungen
“Choosing DB2 has delivered significant benefits for our organization: database size has been reduced by 40 per cent and performance is 15 per cent above our targets.“—Brian Visser, IT Operations Director, Central Services at KONE
“We expected an improvement of around 20 per cent in terms of system response time, but we found that the new system was actually 40 per cent faster. The DB2 database is even more efficient than we had anticipated. This means that the investments in new server and storage hardware will actually last longer than planned, contributing to a better-than-forecast return on investment, which is very pleasing.“—Peter Boegler, Solution Architect at SAP IT
There are many more such quotes in the DB2 for SAP case studies.
Here is a video featuring Dr. Bernhard Wallner from SAP IT explaining why they chose DB2 as the database for their corporate business systems. Of course, it is especially gratifying when SAP chooses DB2 to power it’s own SAP applications. In the video, you will hear lots of great facts like how DB2 improves performance by 40% in the corporate HR system.
This Thursday, IBM will host another of its Chat with the Labs, where you get to hear directly from IBM developers. This week’s Webcast will cover various Data Studio topics including installation, management, utilities, configuration, and tuning. It will primaily cover the no charge features, but it will also talk about the paid features like change management, test data management, data privacy, and more. The Webcast will also describe how to use the new DB2 9.7 features like Workload Management and Oracle migrations. For more information, see http://tinyurl.com/studiochat.
Last week I described Why DB2 Data Compression is Better than Oracle Database. In my blog post, I focused on the reasons why the DB2 compression techniques get better compression rates than the Oracle Database compression techniques. In this post, I’d like to focus on a couple of recent additions to DB2 that even further enhance its ability to minimize your storage costs:
- DB2 9.7 also has compression for user temporary tables and system temporary tables. We have seen that temporary tables can occupy as much as one third of the data storage in certain environments, so compressing temporary tables can have a very significant impact on your data storage costs.
- When it comes to compressing database indexes, DB2 9.7 offers both RID list compression and dynamic-length prefix compression that includes substrings of columns. Oracle Database, on the other hand, offers only fixed-length prefix compression.
When you combine all of these DB2 advantages, it should be apparent that DB2 will typically do better than Oracle Database at lowering database-related storage costs. In fact, International Technology Group (ITG) came to the following conclusions in its report at VALUE PROPOSITION FOR IBM DB2 9.7: Cost Savings Potential Compared to Oracle Database 11g:
Oracle 11g compression rates are typically in the 20 to 30 percent range – many users find performance degradation at higher levels to be unacceptable – while early DB2 9.7 users have routinely employed 60 to 80 percent compression rates with negligible effects on processor performance.
However, you should be aware that data compression rates and performance are highly dependent on the nature of your data and the nature of your environment. Your best course of action is to get IBM and Oracle to prove the kinds of storage savings they can achieve for your data in your environment. That’s the only way to cut past the marketing and determine the real impact.
Here is an interview from 2008 with Bashir Khan from Dow Jones. In this interview, he tells us why Dow Jones chose DB2 ahead of other database management systems. I especially like the following quote where he indicates that they benchmarked the various vendors and DB2 came out ahead.
After looking at a lot of options, there was only one real option that was left for for us, and that was DB2 for LUW on the Unix platform. Before we made a final decision, we benchmarked some of the key database management systems that includes Oracle, SQL Server, and DB2. We ended up choosing DB2 for several reasons. One was reliability. Second was performance. And perhaps the most important factor was ease of use.
International Technology Group (ITG) just completed a study of database-related costs. In this study, they interviewed several companies to formulate profiles for a telecommunications company, a financial services company, and a retail company. They then determined the database-related hardware, software, storage, and staff needs for these profiles. They base their projections on information gathered from organizations that use Oracle Database and DB2, together with “street pricing” information. ITG claim that:
…use of DB2 9.7 results in combined three-year costs for database software, disk and tape storage systems, servers and personnel that average 36 percent less than those for use of Oracle 11g…
Here is a nice chart that captures their findings for each of the tree profiles:
You can read the full report at VALUE PROPOSITION FOR IBM DB2 9.7: Cost Savings Potential Compared to Oracle Database 11g.
Yesterday, in a blog post titled Data Compression in IBM DB2 and Oracle Database, we saw that IBM DB2 gets better data compression rates than Oracle Database for TPC-H data. You might wonder why DB2 is so much better. The reasons boil down to two basic differences:
- DB2 uses one compression dictionary for the entire database table, whereas Oracle Database uses a separate compression dictionary for each block in the database. A block is a unit of storage ranging in size from 4k to 32k. Because Oracle Database uses a much smaller scope for its data compression dictionaries, its compression rates are naturally going to be smaller.
- Both DB2 and Oracle can compress repeating patterns that span multiple columns. However, DB2 can compress substrings that span multiple columns, whereas Oracle Database cannot compress substrings. For instance, if we have rows with
EATON, CHRISTOPHER, DB2 can compress both of these by putting
EATON, CHRISin the compression dictionary, whereas Oracle Database cannot. Once again, the smaller scope for Oracle Database limits the compression rates it can achieve.
If you are in any doubt as to which vendor’s approach gets the best compression rates, consider the following quote from Oracle themselves. Two Oracle researchers in a paper at the Conference on Very Large Data Bases (VLDB) titled Data Compression in Oracle endorse the approach taken by DB2 as achieving better compression rates:
Due to its global optimality of compression a table-wide dictionary approach can result in high compression factors… Furthermore, a global dictionary may use less disk space compared to a block level approach, which potentially repeats dictionary entries across blocks.
The third annual IDUG India Conference will take place at the Chancery Pavillion Hotel in Bangalore on 24-26 September. The International DB2 Users Group (IDUG) have not officially announced the line up of speakers and topics yet. However, I have been talking with the conference planning committee and understand that they are lining up some very exciting speakers and topics for this year’s event. If you are a DB2 user in India, this is one event you will not want to miss. Not only are the conference organizers offering sessions that prepare you for DB2 certification and FREE DB2 certification tests, but they are also lining up some of the world’s leading DB2 experts to talk about the most exciting new features in DB2. You can learn more about the conference at IDUG 2009 – India. You can also see a short preview video at IDUG India Movie.
Last week, in my blog post titled Truth in Advertising – Advanced Data Compression in Oracle 11g, I discussed the fact that data compression rates are highly dependent upon 1) the nature of the data and 2) the database environment. I’d like to follow up on that post with a data point that directly compares IBM DB2 and Oracle Database.
Last week, I mentioned that TPC-C data contains random strings. As such, it is not an ideal data set for measuring data compression rates. TPC-H is actually a better data set, as it contains data that is closer in nature to “real world” data. There are issues with TPC-H data as well. Since the data is programmatically generated, most columns have a uniform distribution, which limits the clustering of data that tends to happen in “real world” data sets. Also, there are some “fill columns” with long unique content that is difficult to compress. Nonetheless, the TPC-H data is a better data set for comparing data compression rates than TPC-C.
Luckily for us, Oracle have published their compression results for TPC-H data in a paper at the Conference on Very Large Data Bases (VLDB) titled Data Compression in Oracle. In this paper, they write that:
When loaded with the compression feature, compression for LINEITEM is the highest at a compression factor of about 1.6, while ORDER compresses at a compression factor of about 1.2… LINEITEM shrinks from 79 GB to 49 GB while ORDERS shrinks from 17 GB to 14 GB.
When we compare these rates to the compression rates that DB2 gets for TPC-H data, we see that DB2 has significantly higher compression rates. And, of course, higher compression rates are better because they mean you need less storage. Nobody needs to be reminded that storage-related costs are often the most expensive component of a system. Lowering storage costs can have a very real impact on IT budgets.
Please keep in mind that these results are only for the TPC-H data, and your data may achieve different compression rates. For instance, Tellabs and SunTrust Bank both report using DB2 to reduce the size of database tables by as much as 83%. The only way to know what kind of compression rates you will experience is to get the database vendors to run their tools on your data and let you know.
The Independent DB2 User Group (IDUG) is hosting a number of regional events in November. These two-day events bring the latest DB2 sessions and the leading DB2 speakers to the following areas:
- Camp Hill, PA on 3-4 Nov
- Dallas, TX on 9-10 Nov
- Austin, TX on 12-13 Nov
- Minneapolis, MN on 16-17 Nov
- Kansas City, MO on 18-19 Nov
I expect details for the events to be posted soon on the IDUG events calendar.
You may have seen the following advertisement from Oracle. They claim that Advanced Data Compression for Oracle 11g cuts your data storage requirements in half. Anyone who knows anything about data compression know that this is misleading. Sure, its possible that data compression could cut your data storage requirements in half. But that depends on the kind of data you have and on your environment. As we will see below, compression rates vary greatly depending on the nature of the data.
Let’s take a quick look at the results of an InfoWorld investigation at Oracle Database 11g Advanced Compression Testbed, Methodology, and Results. In this investigation, InfoWorld analyzes two data sets: 1) the test kit that Oracle provides and 2) several tables from the TPC-C order entry benchmark data.
Let’s focus on the industry benchmark data. The first thing to notice is the variation in the compression rates. They vary greatly, depending on the nature of the data. The second thing to notice is that if do your math and figure out the before and after storage numbers, you will see that Advanced Data Compression for Oracle 11g reduces the total storage for these tables from 273,034 MB to 210,808 MB. This is a long way short of the 50% number that Oracle is touting! In fact, its actually saving less than 23%. However, as I have said, compression rates do vary greatly depending on the nature of the data and TPC-C data does contain random strings which do not compress well.
|Table Name||Original Size (MB)||Compression Rate (%)|
The next thing to notice in the InfoWorld article are the performance findings. While Oracle claims that “it runs faster” in the advertisement, the results of the InfoWorld investigation did not back this up. In fact, the InfoWorld investigation observed transactions per second for a mixed workload “falling from 28 to 13, which “represents a nearly 50% performance hit“. However, InfoWorld do point out that their tests are not a true representation of a real-world workload, and that the results are within acceptable parameters.
The point of this blog post is not to question whether Oracle can achieve high compression rates or whether performance is acceptable when compression is turned on. The point of this blog post is to make sure you are aware that compression rates and performance are highly dependent on the nature of your data and the nature of your environment, and don’t let vendors like Oracle tell you otherwise.
Gartner’s first take on DB2 9.7 makes for interesting reading. Gartner typically makes such reports available to the public for a short time before moving them behind paid subscription. Gartner’s first take on DB2 is currently available on their public site at IBM DB2 9.7 Shakes Up the DBMS Market With Oracle Compatibility.