Exadata v/s Solid State Disk ! Performance & Scalability Comparison.

During one of my Exadata Presentation, one of the attendees asked about the Performance & Scalability Difference between EXADATA and SSD. He mentioned that the Performance POC for one of their critical application on SSD and Exadata gave similar results. Before replying to his query, I asked him “What was the Average CPU Utilization during both the POC’s ?”. While the answer to my question was interesting, thought of writing a short blog on this debate and at the end will be the response by the attendee to my question.

Lot has been written on the comparison between the two. For example, visit asktom.oracle.com and Kevin Closson’s blog. I will just write on my reply with a brief explanation.

EXADATA is one of the biggest breakthrough in achieving fast computing and therefore, clearly overpowers other technologies around it. While other technologies might give you a similar performance, but investing only for performance is not the only Organization Goal. The primary reason, which I feel, Exadata scores over others is the Scalability Factor. With that said, while Exadata gives Extreme Performance, it improves the Scalabiity as well. SSD and any other technologies are Hardware components, whereas, Exadata is a combination of Hardware and Intelligent Software and this combination makes it Faster and Scalable.

In an Oracle Database or an Application deployed on top of Oracle, Latches are considered to be a Performance and Scalability Inhibitor. Every Block access (into the cache or from the cache), requires Latch and if these latch gets are in access, these excessive visits to the cache will burn the CPU power thus impacting the performance and scalability. Exadata has changed this approach, by introducing a faster hardware that scans the required blocks and an Intelligent Software on top of it, to filter only the required column data directly to the Private Memory Area (PGA) of the User Process. This Intelligence bypasses the buffer cache thus avoiding a costlier step of Latching. This has a huge impact on the CPU Cycles and therefore, if the Database Server has enough CPU Power available, this additional CPU Power can be translated to Scalability.

Usually, in an Oracle Database on a traditional (non-exadata) storage, the blocks are read from the Disk to the Buffer Cache and then the required column data is filtered and fetched to the Private Memory of the User Process. Reading a Block from Disk to Cache, filtering the required data from Cache involves CPU. All of these consume CPU Cycles on the Database Server. As mentioned, in an Exadata Storage, the combination of Hardware and Software works together to eliminate the costlier from the Database Server. From this explanation, it is quite evident that Exadata is not only improves performance, but also provides scalability. All of this is achieved without making any changes in the application. However, further optimization in an Exadata is also possible.

Now to the reply on my Question “What was the Average CPU Utilization during both the POC’s ?”. The reply was that through out the POC, the CPU Utilization on an Exadata Machine was always far below than the POC on SSD. Solid State Disk’s would provided faster access to the blocks that are read from the disk, but will not eliminate the costlier steps of latching the blocks from the Database Server. Therefore, savings in CPU Cycles is not expected. Infact, it may worsen the performance.

In one of the paragraph above, I mentioned about the steps as a part of row fetching that an Oracle Database, on an non-exadata storage, performs on behalf of a User. This is, a block is read from Disk to the Cache and then the required columns and row data is fetched to the Private Memory area, which is to the PGA, of the User Process. This contradicts to the steps that I mentioned in one of my previous blog on Consistent Gets. This blog rectifies the error in my assumption on the steps performed and mentioned in the said previous blog.

Advertisements

About Vivek Sharma
I am an Oracle Professional from Mumbai (India). I blog on the issues that I feel is Interesting for my readers. Some of these are my real life examples, which I hope, you would find interesting. Comments are always a welcome. The Technical Observations & Views here are my own and not necessarily those of Oracle or its affiliates. These are purely based on my understandings, learnings and resolutions of various customer issues.

9 Responses to Exadata v/s Solid State Disk ! Performance & Scalability Comparison.

  1. Praveen Tallakokula says:

    Nice Explanation on Comparison of Exadata and SSD, Expectin a lot more on Exadata Thanks for the valuable info…

    Like

  2. I am not sure I understand your explanation, but a few comments:

    – Full scans to PGA (private hence latchless access) is not an exclusive property of the Oracle database running with Exadata storage. It is a general 11g feature, which kicks in if the segment to be scanned is bigger than 5 times _small_table_threshold, and the number of blocks currently in the buffer cache less than 50%.

    – The power which comes into play in your comparison between SSD’s and Exadata is the Exadata only feature of smart scans. Smart scans mean part of the processing is taken to the storage server (cell or cell daemon), and a result set is send back to the database layer, instead of all the blocks of the segment. Because the database foreground (or foregrounds in the case of PQ) only need to process result sets, instead of processing the entire block, overall CPU usage is reduced.

    – Please mind that in my tests smartscans greatly outpowered normal scans, meaning the response time of the query was much lower with smartscans, but the CPU usage of the foreground doing smartscans during processing was much higher, because the time it spends waiting on blocks (because rotating disks are the slowest component) is greatly reduced, so it can optimally process the result sets, thus use CPU.

    Please mind this means that overall the CPU usage reduces with smartscans (processing is partly taken to storage).

    Like

    • Vivek says:

      Hi Frits,

      Thanks for your comments and a detailed explanation.

      As mentioned in my blog, I wanted to keep this a short explanation. As you rightly mentioned, the Costlier Steps that an Oracle Database on a Traditional Storage is optimized in Exadata via Smart Scans. While I have not used this terminology in my blog, but I too was referring to the same. Another reason, I did not use this term was I wanted to mention that Exadata is not to be considered just as a Hardware, but is a combination of Hardware and Intelligent Software.

      On Full Scans to PGA, yes, it is not an exclusive property of Exadata and I have not mentioned this explicitly anywhere in my blog. In Exadata, this feature is not size dependent, whereas on Non-Exadata boxes, this is triggered based on thresholds.

      As you mentioned in the comment, may be my explanation was not upto the mark (may be I am not a good writer :)), but my blog means the same that you have commented. Thanks for your comments, as this will help other readers understand what I actually wanted to explain.

      Regards
      Vivek

      Like

      • Thank you for your comments Vivek. I do not criticise your writing or writing skills. I just try to understand what you try to tell, with the knowledge I’ve gathered when working with Exadata.

        Non-buffered full scans are always an optimizer decision, both on exadata and non-exadata, and are not depended on exadata or not. In fact, up to V11.2.0.3, there isn’t any code in the optimizer which deals with Exadata.

        If the optimizer has decided to do a full scan, on exadata, the decision for doing the exadata specific smartscan is in the non-buffered full scan code (on the database), which knows it deals with exadata because of the exadata specific disk path (o/*/*).

        That’s the reason the execution plan can’t tell you if your are offloading/smartscanning, the execution plan is the outcome of what the optimizer thinks is the best (cheapest) way of executing.

        Like

      • Vivek says:

        Thanks Frits, we all are from same community and get to learn from each other. Beleive me, I have not taken your comments as Criticism. I appreciate your comments on my Blog.

        Regards,
        Vivek

        Like

  3. Kevin says:

    > The reply was that through out the POC, the CPU Utilization on an Exadata Machine was always far below than the POC on SSD.

    …aren’t DB host RAC licenses the expensive part? If the results were comparable I think the most important factor is cost.

    Like

    • Vivek says:

      Hi Kevin,

      Will not be able to comment on the Cost Factor. That customer has to decide on the requirement of future Scalability and Performance. BTW…SSD requires huge investments as well, at the same time, the involvement of Performance Optimization Expert to Optimize the Resource Intensive Queries. SSD will just improve the response time of the Disk Reads, but will not reduce the amount of I/O’s the Application Queries does, thus the risk of Latching still exists.

      Regards
      Vivek

      Like

  4. Kevin says:

    I don’t understand your train of though on latching and it appears my friend Frits is in the same boat. Sorry.

    Like

    • Vivek says:

      Hi Kevin, may be my explanation is not upto the mark and this is what I mentioned to Frits as well. I appreciate the comments on my writing as this will just improve my skills.

      On my train of thoughts that you raised a concern, why do you feel this is incorrect ? Don’t you agree with me that by offloading the queries using smart scans, it will reduce the concurrency (thus contention) on shared resources. Any reduction on these contention will have an impact on the latching, like CBC latches as well.

      Regards,
      Vivek

      Like

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s