This content has been marked as final. Show 4 replies
Dear,1 person found this helpful
The most important feature that exadata brings to an application is smart scan and the offloading of SQL processing to the storage layer. The goal of these two new features is to improve physical I/O. But for smart scan to happen there is a fundamental condition or a pre-requisite for that: your select should be done via direct path read. It means your select should bypass the buffer cache.
Do you think that your application is doing a lot of physical I/O so that the exchanged volume of data between the database server and the data files in the physical disk is generating a huge amount of SQL*Net traffic?
If your application is doing several non performant queries due to non performant execution plans(logical I/O and not physical I/O) and not due to a huge volume of data that has to be taken from the disks then there is big chance that exadata will not bring any added value.
Mohamed Houri wrote:
Do you think that your application is doing a lot of physical I/O so that the exchanged volume of data between the database server and the data files in the physical disk is generating a huge amount of SQL*Net traffic?Hi Mohamed, how do I find out if my application is doing lot of physical IO.
U mean like if there are lots of sorting to be done and lots of joins and calculations to be done there is not much "physical" i/o but only logical i/o?
Edited by: 957072 on Mar 19, 2013 9:21 PM
Hi,1 person found this helpful
my guess is that you'd be able to achieve some performance improvement, but not the x10 gain you're expecting, and the situation with the scalability won't change radically.
Exadata does have features useful for OLTP workloads (Exadata Flash Smart Scan), but the most impotant ones like cell offloading, storage indexes etc. -- you won't be able to benefit much from it.
In order to make your application more scalable, you need to either work on your data design (e.g. [re] partition key application tables in a more performant way), or migrate the entire application to a horizontally scalable system (like Hadoop Hbase), giving up some of the benefits of relational database to gain performance and scalability.
However, it could also be that your performance problem originate from a few poorly written (and frequently executed) statements, in which it would suffice to fix the poorly performing code to achieve acceptable performance level. I would start by posting an AWR report for a period of particulary bad performance in "Database - General questions" to evaluate the current situation. Also, I provide free AWR consultations if you're interested: http://savvinov.com/awr/
Hi Friend1 person found this helpful
Points to remember :
1. Any application needs some minor changes are required to utilize Exadata machine capabilities
2. Before porting your application into Exadata know your database design fully and application functionality, so that it will help you to choose Exadata features.
3. Basically Processing will happen in Storage Server rather then in Compute Nodes. So Query Offloading will be done at Storage Level
4. There is Infiniband between Compute Node and Storage Server. It will gives you 40 Gbps throughput between these two layers. In Traditional FC Cables maximum 8 Gbps only
5. Query Offloading, Smart Scan, Hybrid Columnar Compression, Storage Indexes and DBRM+IORM features will help for better performance.
Hope it helps.