Don’t overpay for transaction processing power in your OLTP system!

IBM’er Glen Sheffield discusses why companies shouldn’t overpay Oracle for Exadata and instead should try the tool that is designed for transaction processing.  Enter Glen:

————————————————–

The right tool for the transaction processing job

Would you choose to do transaction processing on a system that is primarily designed for data warehouse? And would you pay extra for software features that are of no value for transaction processing? This is what puzzles me about customers who are thinking about Oracle’s Exadata for transaction processing – because that is exactly what they are doing.  A smarter solution for transaction processing is DB2 pureScale because you pay for exactly what you need.

Transaction processing is the backbone of every business.

Orders, shipments, payments, billing, reservations – all represent individual inserts, updates, deletes, and retrievals of records stored in a database.  These systems are very much mission critical requiring lightning fast performance, utmost reliability, and high availability.

Unique aspects of transaction systems

Transaction systems also have different characteristics than a data warehouse system. For example, the focus is on random I/O rather than sequential I/O, and the goal is to use as few cpu cycles as possible rather than to exploit all cpu resources to execute a query in parallel. Database sizes are typically smaller as well, and when scaling the system to handle higher transaction volumes it is often beneficial to add additional computing power without having to add additional storage.

Background on Exadata

Exadata was originally brought to market exclusively for data warehouse.  Because Oracle’s database architecture does not lend itself to easily deliver the high sequential I/O bandwidth needed for modern data warehouse workloads Oracle needed to do something. Even though additional servers can be added to Oracle RAC, there is still an I/O bottleneck to the shared storage. So the original intent of Exadata was to alleviate this I/O bottleneck by adding another tier of servers that could each deliver high sequential bandwidth, and scale out to add additional bandwidth to feed the Oracle database.

For example, in a full rack Exadata system there are 14 Exadata servers scanning the data at high speed and pumping it back to the Oracle database for processing.  Clearly this can help data warehouse workloads. Oracle has also built in some additional features in Exadata such as Smart Scan, Storage Indexes, and Hybrid columnar compression – but these are applicable only for data warehouse workloads.

Paying a steep price for Exadata

The extra sequential bandwidth comes at a steep price – in this case an additional $10,000 per disk drive for the new Exadata software. That adds up to $1,680,000 for a full rack Exadata system, which is more than the hardware!

A more sensible approach – get the power you need

But if I don’t need the additional I/O bandwidth for transaction processing, and if the Exadata software features don’t help transaction processing – why would I choose Exadata for transaction processing? Furthermore if you want to add additional compute power to support higher transaction volumes you are forced to add additional Exadata storage servers along with it. Even if you don’t need more storage space! For example going from ½ rack X2-2 to a full rack X2-2 doubles the Oracle database processing power from 4 servers to 8 servers – but it also doubles the storage servers from 7 to 14 (and doubles the Exadata software licenses that provide features for Data Warehouse).

Smarter transaction processing starts with DB2

A smarter solution for transaction processing is DB2 pureScale. You can scale up, you can scale out, both independent of adding more storage.  And there is no software charge for every disk drive on the system! Learn more about DB2 pureScale here.