Karla News

Does Oracle’s Exadata OLTP Database Machine Provide Too Much Hardware Dependence?

Microprocessors

Oracle’s Exadata OLTP Database Machine showcases the close knit relationship between Sun Microsystems and Oracle’s Relational Database product, but some might question whether the entire purpose of relational database design is to maintain independence from the hardware. On the other hand, the real world of database development often means that a customer application requires first rate performance that is achieved by fine tuning the database implementation. That Oracle has provided the capabilities to do this fine tuning conveys the message that Oracle is listening closely to the requirements of their customers and their user base.

I dug through the Oracle documentation set [1-7] to provide my assessment of some of the issues involved, here’s a summary of what I found.

Oracle Exadata OLTP Database Machine Hardware Features

Oracle has laid out a two-tiered database hardware approach with their new Oracle Exadata OLTP Database Machine. On one hand, it has four levels of hardware expansion for their database server in a traditional configuration of online disk storage so that a company can steadily upgrade their system hardware as the data load for their applications increase. [see specifics on 6]

On the other hand, Oracle has added the ground breaking Exadata Smart Cache Flash that delivers better storage performance in the form of Sun developed microprocessors using Smart chip technology that is used for cache memory and for data decompression. The use of the Exadata Smart Cache Flash hardware is optional but provides quicker run time delivery of query data with adequate risk management for the potential failure and backup needs of this data.

See also  Review: Shure KSM32 Professional Condenser Microphone

Oracle Exadata OLTP Database Software Features

Database developers often get tied up in their decision making about table creation when a large number of queries either look at column data or row data with a bad decision causing performance issues. Oracle’s Exadata OLTP Database implementation offers a solution to the dilemma by providing SQL extensions where the developer can have the best of both cases through the use of cache data storage. High use data can be explicitly stated during the creation and load of the tables or implicitly by Oracle’s underlying relational database management system software.

Data compression is provided on a column basis and is implemented inside the relational database system software. An example of data that can be compressed is name data. Name data varies in length but doesn’t change often but the developer must specify the column for the largest name their database contains. Oracle estimates of the amount of disk storage saved using this compression is very large and can help avoid the costs of additional hardware. A side effect of the implementation of compression is that the relational database management software can read metadata about the column that allows them to reduce the input/output load for the applications.

My Assessment of Oracle Exadata OLTP Database Implementation Issues

As with any system upgrade, database owners will have to deal with data migration and validation on implementation of the upgrade to the Oracle Exadata OLTP Database system and business justification for the expenditure for the add on equipment. The good news is that Oracle provides good ammunition related to cost savings.

See also  Product Review: Scythe 5th Anniversary Edition Ninja Copper

Additionally, I would expect database owners to want to validate the conversion process for the compressed data when it was provided for initial load, backup, restore and recovery and in response to queries. This is not a minor issue. Doing this task would be asked by data owners that wanted to insure relational database independence via the option to transition or use on other database management products in support of their users.

As to the design of the database, the changes to SQL are minor in my opinion since they simple add SQL clauses that allow developers to specify that table data maybe cached, compressed or archived . These SQL clauses would need to be found in the code and modified if the database was ported to a new database management system.

As to the hardware of the Exadata Smart Cache Flash, I think smart chip technology such as that provided by the Sun Smart Flash technology is probably the long term direction for all database storage needs due to the faster i/o and access rates and this is a small step for hardware developers along the way.

[1] http://www.oracle.com/us/corporate/press/033684

[2] http://www.oracle.com/us/products/database/exadata/index.html

[3] http://www.oracle.com/technology/products/bi/db/exadata/pdf/exadata-technical-whitepaper.pdf

[4] http://www.oracle.com/technology/products/bi/db/exadata/pdf/Exadata_Smart_Flash_Cache_TWP_v5.pdf

[5] http://www.oracle.com/technology/products/bi/db/exadata/pdf/exadata-datasheet.pdf

[6] http://www.oracle.com/technology/products/bi/db/dbmachine/ds_db_machine.pdf

[7] http://www.oracle.com/database/docs/sun-oracle-database-machine-faq.pdf