Exadata Storage: What is the Secret?

Hello guys!! Today I’ll post about some technologies from Exadata Storage. IMHO, Oracle has highly score when it launch this hardware for it database. The newest version of it is an X5-2 that can has it configuration using flash disks on the storage which it’s called Extreme Flash. Ok, let’s take a look on this machine and the most interesting features that are beside it.

This hardware is made of database servers which host the whole database and clusterware instances. The data is present on the storage nodes (cell nodes) and also the Exadata system software.The communication between this servers uses two infiniband switches which can handle data transfer up to 40 Gbps. Besides that there is a management switch and the PDUs. When we talk about High Availability, this machine is all about it.

OK, but what is the deal about this hardware because if it is all about hardware everyone can “copy and paste” it? It is all about avoiding or reducing I/O that the software can provide. And this can only be achieved because there is a communication from the databases and the storage servers using a protocol called iDB that allows intelligent I/O to be done. When the I/O is requested from the database nodes to the cell nodes, the cell node knows what kind of I/O is occurring and how to deal with it.

Most of the features that will be mentioned ahead are about the Smart Scan concept. This behaviour can only occur when Direct Path is performed on the database, so sequential reads will no have benefit from Smart Scan. Bellow are mentioned some of this features that minimize I/O on the Exadata:

  1. Column Filtering: As the name means, there is a filtering about the columns so when your query that retrieves only one column from a table that has 10 columns, only the selected column is returned to the database server. On a normal environment, the storage would retrieve all the columns and the SGBD would filter it;
  2. Predicate Filtering: Similar to the Column Filtering feature, but this one is happens on the row level. The Exadata Storage can retrieve only the rows that satisfy your query;
  3. Cell Offloading: Normally, the work can be offloaded to the cells. An example would be a query that count all the employees from a company (select count(*) from hr.employees), is work is done on the cell nodes and only the result goes back to the db node. There could be cases that when there is a high workload on the cells, it can’t offload the work and all the rows goes back to the database node as it would in a normal environment;
  4. Storage Indexes: The cell nodes have the ability to analyze the queries so they can build the Storage Indexes (SI). This structure resides on the memory of the cell nodes and they are lost on every restart from the cells. This feature can provide information about the minimum and maximum values from a column, so the Exadata knows exactly what are the blocks to hit. Each table can have a maximum of eight SI;
  5. Join Processing: The Exadata uses the Bloom Filtering technique which is a probabilist method when you join two tables to efficiently test result sets, this can only be used on database using version equal and above to 11.2.0.4;

So the Exadata storage has a technology addressed to the highest data throughput per transaction and this is not recommended for an OLTP environment? No exactly, there are three features that I see as better designed to OLTP environments:

  1. Exadata Smart Flash Cache: This isn’t similar to the Database Smart Flash Cache feature. This feature has a method of write called write-back cache which the data can be first written on the ESFC and than can be write asynchronously on the cell disks presented on the storage nodes. Also, you can choose to com compress the data on the ESFC which gives you a better data usage capacity;
  2. Smart Flash Cache Log: There is a small area which is built on the flash cache from each cell nodes designed to redo logs writes. This is known as Smart Flash Cache Log, so when the cell nodes attempts to write a redo log request it tries to write on both cell disks and flasch cache. The first it gets, it acknowledge the request back to the db node speeding redo logs write which is excellent for OLTP environments;
  3. Join Processing: this feature is a good one for both DW and OLTP environments;

I understand that Smart Flash Cache with write-back enabled can be a good feature for DW environments too, but when we move to high workload environment with high load of data, the data could probably not fit into Smart Flash Cache. Besides that, the Exadata Database Machine has a special feature called HCC (Hybrid Columnar Compression) where the data could be compressed at high levels reducing I/O and enhance the performance for this machine. Well guys, that’s all for now! See you!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s