Archive for the ‘Exadata’ Category.

E4 2013 – Exadata Conference Call for Papers Closing

 

Just a quick note to remind you that the call for papers for E4 is closing in a few days (on April 30).  So if you have anything you think is interesting related to Exadata that you’d like to share we’d love to hear from you. By the way, you don’t have to be a world renowned speaker on Oracle technology to get accepted. You just need to have an interesting story to tell about your experience. Implementations, migrations and consolidation stories are all worthy of consideration. Any interaction between Exadata and Big Data platforms will also be of great interest to the attendees. Of course the more details you can provide the better.

Here’s a link to the submission page:

Submit an Abstract for Enkitec’s Extreme Exadata Expo

Feel free to shoot me an email if you have ideas for a talk that you want to discuss before formally submitting an abstract.

New Exadata Prototype

I got a look a new prototype for the next generation Exadata last week while doing some work with a company in Europe. Apparently there is a big push to be environmentally friendly there now and so Oracle is trying to come up with a model that uses less power and is biodegradable. The word on the street is that it won’t be available until after release 2 of the 12c database.

The new model has a few drawbacks though. For one thing, it only lasts a few weeks before you must either replace it or higher some rocket surgeon consultants to come in and tune it. From the early version of the prototype I saw, it does appear to be smaller and more tasty than previous models though.

 

 

That’s a picture of the lead designer (JP) showing off the prototype. The code name for the project is “Exanana” by the way. The new model should be available in select supermarkets after lunch (err launch).  Here’s another picture of JP and one of the other designers (Paul) hamming it up for the camera.

 

 

I probably should have saved this post for April 1st!

E4 Wrap Up – Part II – Cary Millsap Interview

The 2012 Enkitec Extreme Exadata Expo is behind us now. Our video guy (Bob) has been working diligently for the last week or so to get the presentations edited. They will be made available to the attendees shortly. We have already posted a video of the opening session. It is me interviewing Cary Millsap about his impressions of Exadata. One of the things I have found most interesting about Exadata is how it makes very experienced Oracle performance guys re-think things. It’s fun watching them being exposed to Exadata in an intimate way (not just Power Point). The reactions are interesting. There is usually a desire to try to break it although  it’s generally harder than it appears, at least initially. I got to watch Cary for a few days (along with several of his Method-R guys) when he had his first exposure and we talk about that during the video. Cary made a profound impact on me and my career and I think his insight into the Exadata architecture is worth watching. Hopefully the fact that I have a great face for radio will not deter you (too much). The video has the obligatory Enkitec logo and endless loop, non-descript music intro, but other than that, I certify it as marketing free! ;)

Be sure and check out enkitec.tv for other videos too.

Exadata vs. IBM P-Series

Earlier this year I participated in a Total Cost of Ownership (TCO) study that was run by a company called the FactPoint Group. The goal was to compare the cost of purchasing and running Oracle on Exadata vs. the cost of purchasing and running Oracle on IBM P-Series hardware. The findings are published here:

Exadata vs. IBM P-Series

Fair warning, the study was funded by Oracle and the first 10 minutes are a sales pitch for Exadata, but the data collected by FactPoint for the TCO study fills the rest of the presentation.. That part was very interesting (to me anyway). They interviewed people from 5 companies which had been running in production on Exadata for at least 6 months and 5 companies that had production systems running on IBM P-Series machines. As a bonus, 2 of the Exadata customers had previously run their systems on IBM P-Series hardware or currently had other systems running on P-Series machines.

The TCO calculations were based on equivalent systems from a CPU count basis. That is, they priced out an IBM P7 system that had the same number of cores as an Exadata Half Rack and used that for the calculations. I didn’t think that was really a fair comparison since the performance of the two systems was vastly different. In fact, one of the customers that had moved from IBM to an Exadata had the following to say:

“This data warehouse was originally on 12 a P570 and the nightly load took 5 hours. With Exadata it takes 30 minutes with the Exadata 1⁄4 rack running at only 5% CPU utilization. Weekly stats updating went from 60 hours to 35 minutes. Backups reduced from 14 hours to 45 minutes.”

This is only one of many quotes from the customers included in the presentation. The quotes were quite revealing, and to my way of thinking, were the most interesting part of the presentation. Another oddity of the cost calculations was that they included RAC licenses in the Exadata costs while not including RAC in the IBM costs. Again I felt that this was an unfair comparison as RAC provided HA capabilities to the Exadata platform that the IBM platform simple didn’t have. Nevertheless, the study found that Exadata was about 35% less expensive. I wonder what it would have been if they had tried to cost an IBM system that performed as well as an Exadata and provided the same HA capabilities.

Updated 11/23/2012 – Note that the official white paper produced as a result of this study is now available here: Cost Comparison – Oracle Exadata Database Machine vs. IBM Power Systems

E4 Wrap Up – Part I – OLTP Bashing

Well the Enkitec Extreme Exadata Expo (E4) is now officially over. I thoroughly enjoyed the event. I personally think Richard Foote stole the show with his clear and concise explanation of why a full table scan is not a straight forward operation on Exadata, and why that makes it so difficult for the optimizer to properly cost it. But Maria Colgan came out with a fiery talk on the optimizer that gave him a good run for his money (she actually had the highest average rating from the attendees that filled out evaluation forms by the way – so congratulations Maria!). Of course there were many excellent presentations from many very well known Oracle practitioners. Overall it was an excellent conference (in my humble opinion) due in large part to the high quality of the speakers and the effort they put into the presentations. I am also thankful for the fact that Intel agreed to sponsor the event and that Oracle supported the event by allowing so many of their technical folks to participate.

While I felt that the overall message presented at the conference was pretty balanced, I did leave with a couple of general impressions that didn’t really feel quite right. Of course having the ability to express one’s opinion is one of the founding principals of our country, so I am going to do a series of posts on generalities I heard expressed that I didn’t completely agree with.

The first was that I got the impression that some people think Exadata isn’t good at OLTP. No one really said that explicitly. They said things like “it wasn’t designed for OLTP” and “OLTP workloads don’t take advantage of Exadata’s secret sauce” (I may have even made similar comments myself). While these types of statements are not incorrect, they left me with the feeling that some people thought Exadata just flat wasn’t good at OLTP.

I disagree with this blanket sentiment for several reasons:

  1. While it’s true that OLTP workloads generally don’t make the best use of the main feature that makes Exadata so special (namely offloading), I have to say that in my experience it has shown itself to be a very capable platform for handling the single block access pattern that characterizes what we often describe as OLTP workloads. I’ve observed many systems running on Exadata that have average physical single-block read times in the sub-1ms range. These are very good times and compare favorably to systems that store all their data on SSD storage. So the flash cache feature actually works very well, which is not too surprising when you consider that Oracle has been working on caching algorithms for several decades.
  2.  

  3. I think part of the reason for the general impression that OLTP doesn’t work well on Exadata is the human tendency to make snap judgements based on reality vs. expectations, rather than actually thinking through the relevant facts. For example, when you go to a movie that has been hyped as being on of the best of the year and a great cinematic achievement, you are more likely to come away feeling that the movie was not that great, simply because it didn’t live up to your expectations. Whereas a little known movie is more likely to impress you simply because you weren’t expecting that much. When you sit down and actually evaluate the movies side by side, you will probably come to the conclusion that hyped movie was indeed better (people don’t usually bestow accolades on totally worthless stuff). I think that, at least to some degree, OLTP type work loads on Exadata suffer from the same issue. The expectations are so high for the platform in general that even good to excellent results fall short of the massive expectations that have been created based on the some of the impressive results with Data Warehouse type work loads. But that doesn’t mean that the platform is not capable of matching the performance of any other platform you could build at a similar price point.
  4.  

  5. I don’t think I’ve ever seen a true OLTP workload. That is to say, I can’t recall ever looking at a system that didn’t have some long running reporting component or batch process that does not fall into the simple single block access (OLTP) category. So I believe that the vast majority of systems categorized as OLTP should more correctly be called “mixed” workloads. In these types of systems, the offloading capability of Exadata can certainly make a big difference for the long running components of the system, but also can improve performance on the single-block access stuff by reducing the contention for resources caused by the long running queries that are unavoidable on standard Oracle architecture.
  6.  

  7. Very few of the Exadata systems we’ve worked on over the last few years are supporting a single application or even a single database. Consolidation has become the name of the game for many (maybe most) Exadata implementations. I did a presentation at last year’s Hotsos Symposium where I compiled statistics from 51 Exadatas that we had worked on. 67% were being used as consolidation platforms. This makes it even more likely that an OLTP type workload will benefit from running on the Exadata platform.

So does Exadata run stand alone “pure OLTP” workloads 10X faster than any other standard Oracle based system you could build yourself?

No it does not.

But it does work as well as almost any system you could build, regardless of how much money you spend on the components. By way of proof I’ll tell you a story about a system that we benchmarked on an Exadata V2 quarter rack system. The benchmark was on a batch process that updated well over a billion records, one row at a time, via an index. The system we were comparing against was an M5000 / Solaris system with 32 cores and all data was stored on an SSD SAN. The benchmark showed Exadata to be a little over 4 times faster. This was primarily because most of the work was logical i/o that was serviced by the buffer cache on both platforms. The faster CPUs in the Exadata accounted for most of the gains. Nevertheless, the system was not migrated to an Exadata. A new system was built using a faster Intel-based server which made up the CPU speed difference (and in fact exceeded specs on the V2) and a more capabile SSD based SAN was installed. The resulting system ran the benchmark in about the same time as the original V2 quarter rack (actually it was very slightly faster). Unfortunately the SAN alone cost more than the Exadata. And the real life system also did a bunch of other stuff like some long running ad hoc queries. Guess which platform dealt with those better. ;) Here’s a slide that summarizes some of the results.

In fairness, I should point out that there is a subset of “OLTP” workloads that are very write intensive. Since writes to data in Oracle are usually asynchronous, while writes to log files usually must complete before a transaction can complete, it’s usually writes to log files that are the bottle neck in these types of systems. However, if the synchronous log file writes can be avoided (or optimized), much higher transaction rates can occur and writes to DB files can become a bottle neck. In those cases, pure write IOPS can be a limiting factor. My opinion is that such systems are relatively rare. But they do exist. Exadata is not currently the best possible option for these extremely write intensive workloads. I say currently because at the time of this writing the storage software does not include any sort of write back cache for buffering writes to data files. However, this is a feature that is expected to be released in the near future. ;)

So that’s it for the OLTP topic.

Stay tuned for Part II, where I’ll discuss another general impression with which I didn’t really agree…