Exadata -- Improving Hardware in Exadata V1 to X4 , X5 key capacity and performance specs

Here is the evolution of the main hardware Exadata from V1 to X4. It is a view from the surface, ofcourse, but we can say that almost in every generation there is an increase in the capacity..

This increase capacity in capacity stands out more clearly in the hardware such as memory and connectivity and flash which brings us the speed in the hardware layer. 

In my opinion; the improvements in the hardware are done to catch the technological improvements and to increase the general hardware power of the machine.. Maybe supporting consodilation better, in a big scale or we can say that it may be for supporting the OLTP workload better...

Eventually, the hardware is not the key in Exadata, the success of it comes from the software technologies used in it. The advantage comes from its software , actually its hardware-software integration.. It is an "Engineered System", using unnecesary hardware is not the key.. It is engineered.. Note that : there are other dimensions like saving the energy and license costs.

Okay.. Lets take a look at the specs;

Evolution continues with Exadata X5, but we still have new environments built on top of X4s..
That 's why still focusing on the X4 at the moment..

According to the tests in POCs, we saw that;

X4-2 have 2x  X3-2 flash capacity
X4-2 have 2x  X3-2 disk capacity
X4-2 have 2x  X3-2 memory

Flash cards used in X42 can read %52  faster than X3-2
Flash cards used in X42 can write %68  faster than X3-2

Moreover, X4-2 supports active-active infiniband ports, so infiniband speed per server can reach to
80Gbit/second.

In May 1 2015, We will migrate a big EBS database to Exadata X5-2.. So it is good to mention the key capacity and performance metrics of Exadata X5-2 in this post..

Actual system performance varies by application. 

1 HC = High Capacity 

2 EF = Extreme Flash 

3 Bandwidth is peak physical scan bandwidth achieved running SQL, assuming no database compression. Effective user data bandwidth is higher when database compression is used. 

4 Based on 8K IO requests running SQL. Note that the IO size greatly affects Flash IOPS. Others quote IOPS based on smaller IOs that are not relevant for databases. 

5 Based on 8K IO requests running SQL. Flash write I/Os measured at the storage servers after ASM mirroring, which usually issues multiple storage IOs to maintain redundancy. 

6 Raw capacity is measured in standard disk drive terminology with 1 GB = 1 billion bytes. Usable capacity is measured using normal powers of 2 space terminology with 1 TB = 1024 * 1024 * 1024 * 1024 bytes. 

7 Actual space available for a database after mirroring (ASM normal redundancy) while also providing adequate space (one disk on Quarter and Half Racks and two disks on a Full Rack) to reestablish the mirroring protection after a disk failure in the normal redundancy case. 

8 Effective Flash Capacity is larger than the physical flash capacity and takes into account the high flash hit ratios due to Exadata’s intelligent flash caching algorithms, and the size of the underlying disk storage. It is the size of the data files that can often be stored in Exadata and be accessed at the speed of flash memory. 

9 Load rates are typically limited by database server CPU, not IO. Rates vary based on load method, indexes, data types, compression, and partitioning.
Anyways, we will see this in action in May :)