Re: exadata v2
- From: Dan Norris <dannorris@xxxxxxxxxxxxx>
- To: Kerry Osborne <kerry.osborne@xxxxxxxxxxx>
- Date: Thu, 29 Apr 2010 11:47:02 -0500
*"On a side note, we did manage to crash one of the storage cells. The
interesting thing is that the database never blinked an eye. It got a few
lines written to the alert log, but the other cells took over for it and the
cellsrv program restarted itself and the cell came back on-line without any
intervention. Pretty cool. (maybe just lucky, I'm not sure at this point -
more testing needed)"*
Kerry,
That (automatic recovery) wasn't an accident at all--it is an important
feature that was baked in from the start. Additionally, the MAA team at
Oracle spends a significant amount of time intentionally testing these very
same features. It is very good for all customers to test these same types of
events to ensure they know how such things impact (or don't impact, as the
case may be) the system.
Dan
On Tue, Apr 27, 2010 at 6:57 PM, Kerry Osborne <kerry.osborne@xxxxxxxxxxx>wrote:
> There are several companies in the Dallas area that either have V2's
> already or have them on order. We have been fortunate enough to have a
> client that has allowed us to help with their evaluation and testing for the
> last month or so. I personally think there are a couple of major break
> throughs with Exadata. The first is offloading SQL processing to the storage
> layer. (You mean I don't have send every block back that might have a row in
> it that I'm interested in, Brilliant!) The second is the management of a
> large cache at the storage layer. (Oracle's pretty good at managing a cache)
> Both of these enhancements are obviously aimed at improving physical i/o,
> which some of our databases don't do much of. But a lot of those same "OLTP"
> oriented systems do some type of batch processing, often moving data to a
> completely separate platform. In fact, in many environments, the vast
> majority of work that goes on is this moving data around business. During
> our testing we had another machine with CPUs from the same family as the V2
> (our stand alone box had 5570's which are somewhat faster than the 5540's in
> the Exadata). We did several comparisons between the Exadata and the other
> box and there were some things that ran slightly faster on the stand alone
> system. As you might expect, they were statements where the Exadata
> enhancements didn't come into play. But for the big stuff, where completely
> avoiding physical i/o is not possible, the Exadata screamed. I am not a big
> fan of over blown marketing claims, but I must say that in many cases,
> Oracle's claims about performance improvements with Exadata are justified.
>
> The more familiar you are with O/S and storage the better, since the DBA is
> probably going to be the SAN Admin by default. The good news is that the
> platform is standard, so it's not like you have to be the first guy to
> figure out how to configure your specific combination of disks, HBA's,
> multi-pathing software, etc... But it would probably behoove you to be
> knowledgeable in these areas. On a side note, we did manage to crash one of
> the storage cells. The interesting thing is that the database never blinked
> an eye. It got a few lines written to the alert log, but the other cells
> took over for it and the cellsrv program restarted itself and the cell came
> back on-line without any intervention. Pretty cool. (maybe just lucky, I'm
> not sure at this point - more testing needed) And the way the storage is
> architected, like a bunch of Sans all working together, but with independent
> cpus, cache, etc... is also very interesting. I'll try to post some more
> detailed info about that as time allows.
>
> Anyway, my response is that I think Exadata is a leap forward as opposed to
> slow steady progress. And it makes me wonder what the future holds for the
> major disk vendors. I guess time will tell.
>
> Kerry Osborne
> Enkitec
> blog: kerryosborne.oracle-guy.com
>
>
>
Other related posts:
