IBM PureData: Migrations made easy


Oracle Customers,

Moving to the IBM PureData System for Transactions is easier and cheaper than moving to Exadata.

If you are an existing Oracle customer, you have probably been getting a lot of pressure to move to Oracle’s shiny new toy, Exadata. You have probably been hearing that you can consolidate all of your databases onto a single Exadata system. But, it is not as easy as it seems!!!

If your existing applications are running on a single instance of Oracle (for example, not on Real Application Clusters (RAC)), then there is a lot more involved than simply moving your data. In order to get good performance on Oracle RAC (and Exadata is an Oracle RAC cluster with specialized I/O servers) you need to modify your database schemas and applications to make them RAC-aware.

The IBM PureData System for Transactions on the other hand provides transparent application scalability, so you can quickly move your data and applications and not have to worry about making changes to the schema and application to make them cluster aware.

The reason that RAC requires cluster awareness and the IBM PureData System for Transactions does not is due to the fundamental differences in their architectures. While both use a shared disk mechanism for scale out, that is the only real similarity. Oracle uses a distributed locking mechanism in RAC, while the IBM PureData System for Transactions uses a centralized locking mechanism.

Let’s use a small example to show the differences. Let’s consider a 2-server (node/member if you are RAC or the PureData System for Transactions) cluster and a database that is being accessed by applications connecting to these servers.

In the RAC case, if a user sends a request to server 1 to update a row, say for customer Smith, it must get that row from the database into its own memory, then it can work on that row (I apply the transaction). Then another user sends a request to server 2 asking it to update the row for customer Jones in the database. First server 2 must read that row into memory and then it can work on it. So far there are no issues, but let’s go on.

Now what happens if another user wants to update the data for customer Jones, but is routed to server 1?  In this case server 1 doesn’t have the row, it only has the row for customer Smith. So server one sends a message over to server two asking it to send the row for customer Jones over to server 1. Once server 1 has a copy of the row for customer Jones it can then work on that transaction. Now server 1 has both rows (Jones and Smith) so if a transaction affecting either customer comes to it, it can be processed right away.

The problem now is that any transaction (for customer Smith or Jones) that goes to server 2 requires that server to go to server 1 to get the resource since it has no rows that it can work on directly.

As transactions are randomly distributed amongst the two servers (in order to balance workload) the rows for the customers must be sent back and forth between the two servers. This results in very inefficient use of resources (too much network traffic and a lot of messages between the two servers to coordinate access to data).  This limits the scalability of a RAC cluster and also impacts performance. To make RAC scale you have to find the bottlenecks and remove them. In most cases the bottlenecks are too much data being shipped back and forth between nodes (difficult to find in the first place because you now have to look in many different places across the cluster to find the hot spots).  To solve the problem you have to repartition your application and your database to make it scale.

The IBM PureData System for Transactions on the other hand provides near linear scalability our to over 100 members (servers) with no partitioning of the application or database.

So let’s look at the work involved to move from single instance Oracle to either Exadata vs. the IBM PureData System for Transactions in the table below.

The data movement, test and tuning time will be similar, but the time to “fix” the application will be significantly longer with Oracle RAC and Exadata than with the IBM PureData System for Transactions.

Don’t take my word for the Exadata effort in the table above. At a number of customer experience panels during Oracle Open World in September, 2012 customers openly talked about their experiences moving to Exadata. In session 8424 (Data Warehouse and Big Data Customers’ View of the Future) Christopher Thompson from Coles, AU discussed their migration from Oracle to Exadata. He mentioned a two week long process just to get the Exadata system running in the data center after delivery, and then a three month long process to migrate a single database. In the same session, Daniel Dibbets from Allianz Insurance talked about their six month long migration process for a single database from Oracle to Exadata.

If you are experiencing issues with Oracle performance as many customers in this session and others said they were, you owe it to yourself to look for a better alternative. And the IBM PureData System for Transactions is that.


Comments Off on IBM PureData: Migrations made easy
Dwaine Snow

About Dwaine Snow

OLTP and Data Warehouse Competitive Analyst - Dwaine has worked for IBM for the past 21 years. In that time he spent a number of years working on DB2 for Linux, UNIX, and Windows and has written 8 books and numerous articles on DB2, and has presented at conferences around the world. He recently started to work with our new colleagues from Netezza in the Product Management and Product Marketing arena, and is hoping to start writing his first Netezza book soon. Follow Dwaine on Twitter @DwaineSnow and be sure to check out his blog! It's at