For those of you who haven’t followed all the Oracle Exadata and database machine information, and want a brief introduction to the database machine: here it is!
There is some confusion about ‘exadata’ and ‘the database machine’. If we look at the official product names, ‘Exadata’ is the storage server, and the ‘Database machine’ is the complete boxed machine, including exadata for storage. But…in the real world, in different kinds of papers (technical, advertising) exadata sometimes is used as an alias for the database machine.
What is the database machine?
Essentially, the database machine is a version of the Oracle database on balanced, optimised hardware from Oracle. But that is a very short description, and does harm to the unique feature of the database machine: the Oracle Exadata storage server. Exadata offers database offloading by execution some of the database functions on the storage layer. This is a schematic drawing of the architecture of the database machine (cell server is the internal name of the exadata software):
The database machine, a little more verbose
One of the basic design principles of the database machine is fault tolerancy. This means any component may fail, whilst the database still is able to function. So if you look at the schematic drawing above, it means there are multiple instances of the database (=Oracle RAC), there are TWO infiniband switches (in a quarter and half rack, there are three infiniband switches in a full rack), and there are multiple storage servers (3/quarter-, 7/half-, 14/full-rack). The redundancy of the database is NOT done by the storage servers, but is done using Oracle’s ASM (Automatic Storage Management) ‘normal redundancy’, which essentially means data is stored double.
It is possible to use a single server (non RAC) version of the database on the database machine, but that does harm to the architecture of the database machine (in my opinion).
The storage servers are fitted with 384 GB flash memory attached via PCI-X. This flash memory can be used as flash disks, but is configured as flash memory for caching of the storage server by default.
Last but not least the database is able to offload some database actions to the storage:
– Smart scans: row filtering, column filtering, join filtering, incremental backup filtering, data mining model scoring. Transparently.
– Storage indexes: stores min and max values of columns of database blocks every 1MB. Transparently.
– Hybrid Columnar Compression: database compression mechanism where data is stored by column, then compressed. (HCC is using several database blocks). Needs to be specified explicitly as a compression option during creation of modification.
I hope this article was able to get you a basic understanding of the architecture of the database machine. Perhaps it might even make you enthusiastic about it, because it offers several unique features:
– A hardware infrastructure purely built for database performance. Something encountered ‘in the wild’ very rarely.
– State of the art hardware.
– Common Oracle database, no need to alter anything when moving to the database machine.