Re: exadata v2
- From: Kerry Osborne <kerry.osborne@xxxxxxxxxxx>
- To: Dan Norris <dannorris@xxxxxxxxxxxxx>
- Date: Thu, 29 Apr 2010 14:34:22 -0500
Dan,
Sorry, I didn't mean to imply that it was a fluke that the storage server was
able to restart. In fact they have the restart manager (rs) watching cellsrv
all the time right? I was actually quite impressed with how seamless the
recovery was and that the database just kept right on chugging. The failure was
a hard crash of the cellsrv process itself by the way. One of the team members
logged onto one of the storage servers as root and ran the cellsrv process
interactively, then ctl-c'd out and it crashed the original cellsrv process.
Not exactly something I would think the developers would have been expecting.
But nevertheless, it started right up without a hitch.
Kerry Osborne
Enkitec
blog: kerryosborne.oracle-guy.com
On Apr 29, 2010, at 11:47 AM, Dan Norris wrote:
> "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:
