« EMC's New DW/BI Competency Center | Main | Information Governance Webcast »

December 12, 2008


Matthew Zito

It seems like, on the Exadata side, at least, there's a couple of red herrings being thrown about. I'd like to go through them one by one:

- "One server can support only 12 disks, and only half of them are usable. In a big DW environment, that's a lot of servers, and half your storage is wasted for redundancy purposes. " - but that's true in many SAN/shared array environments too. RAID-1, you lose half the disks. The fact you have more servers is part of the design, because now queries can be pushed out to the storage. If I do a full table scan with a predicate on a Symm, I'm going to have to read the entire table in. On an exadata, that FTS is going to execute on the storage itself. Clearly, in this situation, having more servers is a benefit for performance.

- "From EMC's perspective, pointing at ASM as an example of a storage management capability is probably not the best industry example to serve up. And when you start probing around at topics like backup, archiving, remote replication and other storage capabilities, there's a pretty thin story." - Well, I'll concede that compared to really elegant software volume managers like Veritas, ASM looks dumber'n a pile of rocks.

But when it comes to backup and remote replication, etc., Oracle has a massively better story than anything EMC has come up with. Oracle's Flashback query and table is unbelievably elegant, and far smarter than anything at an array level. The ability to say, "hey, snap back an individual table to 9am this morning", or even better, "let me run a query on this database as it looked like at 9am" is not even possible with a shared array without knowing in advance that you want to be able to look back at that time, and requires spawning off a whole separate Oracle instance.

When it comes to remote replication, I've always given EMC credit for making the industry's more robust and reliable remote replication solution. It's not the smartest, though. For example, with Oracle's Data Guard, I can say something as elegant as, "remotely replicate every transaction that is committed, but wait 2 hours to apply it, unless I have a failure, then roll the transactions automatically". With SRDF, I've got the basic "synchronous or async" question. With synchronous, I drop a table by accident on the near side, and on the far side it's promptly dropped as well. Whoops.

I agree with some of your assertions that Forrester makes it look a lot simpler than it will be, but the reality is that at the Oracle level, the application is in a position to be far smarter than a storage array ever will be. Oracle is leveraging that as far as they can go. Large arrays still have value with very strong availability and throughput, but I see more and more organizations using the database as the conduit for HA, DR, backup, and archiving, because it's simply a better way to do it.

Chuck Hollis

Hi Matthew -- you've got a very unique perspective.

Let's see what we can do here ...

You first claim is that arrays use RAID 1 too. This is true, but it's one of many storage protection options, including (most notably) space saving RAID 5 and RAID 6. A 14+1 RAID 5 scheme, for example, in a DW environment wouldn't be entirely out of the question.

With Exadata, there's just no choice whatsoever. You'll waste half your disks whether you want to or not. Trust me, you'll want to go fix this. Bad enough in the general case, really painful when we start talking about things like enterprise flash drives.

Your second claim has to do with "pushing queries to the storage". Pure marketing hyperbole from a factual perspective, amigo. What you're really doing is pushing queries to multiple commodity servers attached to a low-budget RAID card and SATA disks.

This approach is architecturally no different whatsoever than any other divide-and-conquer architectural approach. A query that wants to bring in all the data will bring in all the data, regardless of approach. Please spare us the hand-waving magic juju.

We go head to head now with Exadata using standard storage and standard servers -- sometimes with Oracle as the software, but more often not -- and kick patootie almost every time.

We must have very different ideas of what "storage management" means, as you described the Veritas volume management product as "storage management".

Goes to my point about application and database people not usually having a good idea about how storage really works.

I think Oracle's Flashback is a great feature, one of many. As a matter of fact, there are lots of great application and file system specific features in the marketplace.

So, how many "great features" does it take to run a modern data center? Part of the argument is that there's more than Oracle on the floor, and complexity grows unmanageable when each and every application has it's own set of "great features".

Oh, and I should point out that if for some reason you'd like to make copies of databases to run on different kit for testing, etc. -- a common use case --- you're pretty much hosed with the Exadata case. Don't get me started on DR, either.

BTW, I'd truly enjoy going head-to-head with you on replication functionality using RecoverPoint. It can rewind indidividual tables, logs and indexes to arbitrary points in time -- do a query on a previous logical view of a database without requiring a separate instance across multiple instances -- multiple servers -- multiple non-Oracle applications -- either local or at a distance -- on anyone's storage.

Lessee Oracle's Flashback do that, shall we? You should know that one of the more popular environments for RecoverPoint is -- of course -- larger Oracle databases.

BTW, your knowledge of SRDF is very dated as well. Longer lags are possible if desired. And your "whoops" scenario an happen with Datagaurd as well, can't it?

More organizations using the database to implement HA, DR, backup and archiving? Really? In what markets and use cases? If this is happening, we haven't seen it.

If anything, it's just the opposite -- standard infrastructure for ALL your applications, and not just the ones running on an Oracle database. The data center environment is just a tad more complex than that.

I know you're trying to make your case that "applications are smarter", but -- given your comments here -- you haven't scored a single valid point, IMHO.

You guys need to go back to the whiteboard, and think about this whole thing a bit harder. It's a nice marketing schtick, but I don't think it's going to get too far.


Taylor Allis

Hi Chuck –

Well, I thought I’d offer my 2 cents – and you may find me more “agreeable” now that I have left Sun and started a Storage Consultancy that is also an EMC reseller (ahhh, the irony). But I will say that before I was asked to pick up the “Open Storage” mantle at Sun I was a STKer – and our new company is founded by ex-EMCers and STKers. Ever imagine the day when EMC and StorageTek are working together? ;- )

I have not read the report (nor will I spend the $279) so my comments are based on your comments:

Utilization – I’d be interested in how the report talks about “utilization” because most in the industry misuse the term. Utilization is how often data is referenced or used – and utilization tends to be pretty good with shared storage. Allocation is really the measure of how efficiently you use the storage you buy. Allocation should be the focus and always needs to be improved – but for every storage device, not just SANs.

Mixing people processes with technology issues - I think you wisely state that the report mixes technology issues with people issues and this can be dangerous. “Project-oriented funding models” and “workload sharing” are issues with processes and management – and not limited to SANs. Often business processes can cause storage inefficiencies more than storage technology does. In storage – you need to focus on both. This line of reasoning is like buying a new car in order to fix your stalling issues with your stick-shift truck (when the issues are caused by you simply popping the clutch too early!)

Storage Managed by Applications – I can write a book on this since I came from StorageTek (back office storage) and Sun (front-office Server Vendor). In a nutshell, applications support business objectives and storage supports applications. So, it looks like Forrester did articulate a TOP issue with storage management – “the relationship between storage teams and application teams is characterized by limited communication.”

But in my experience, and yours too it looks like, putting all the power in the application owner’s hands sounds good but seldom works (I know from personal experience). Storage is a lower priority for them – and they rarely have the insight or training on just how storage impacts their application goals and performance. They also don’t want to be in the storage business (this is why they are in the application business!)

I think storage management needs to get better at interviewing application managers on their critical business and IT needs; then deliver to their needs while communicating how they improved/met their needs.

You nail that and everyone’s happy. And, oh, by the way – this has NOTHING to do with SAN technology…

Chuck Hollis

Hi Taylor -- sounds like you're enjoying your new gig! I think storage consultancies are good and valuable businesses, especially with people like you who can look beyond the vendor fog and steer people in a practical direction.

And, hey, I'd say that even if you weren't an EMC reseller :-)

So, I guess you reacted to that report pretty much the way I did -- not only is it wrong, it's really badly wrong on so many levels.

I'd be interested to see what others will have to say.

Thanks for the thoughtful comment!

-- Chuck

David Vellante

Great post Chuck. This argument has been going on and off over the years in the industry and I thought it was put to bed. I too have great respect for Forrester's work and even in this case I'm happy they're getting the discussion going-- makes for a good reality check.

Like you I fundamentally disagree with the premise of the piece. I mean from the point of view of a specific application and from an application vendor's standpoint, sure, cut out the middleman and reduce the overhead-- hard to argue. The problem is this assumes an ability to manage the performance and availability for each and every application which is not only silly and impractical; it's a nightmare.

You are right, the proposed 'new' alternative isn't new at all. This is what the world did before SAN. It didn't work. Application people always over-provisioned storage because they couldn't accurately forecast demand. Then eventually, they ran out of storage and reacted to a crisis. This proved FAR more expensive than sharing resources with a SAN. That SAN hasn't lived up to ALL its promises is worth noting but really is immaterial.

If you have an application where I/O is a bottleneck and you have a really clear reason that a SAN would get in the way then go for it. Otherwise you'll find this model way too time-consuming and expensive. Let's not go forward to the past... -Dave from Wikibon.org

John Webster


I know and respect Andrew and I'm sure he's given this much thought. However, I’m not going to pony up for this paper - not that I fundamentally disagree with the paper’s premise as I’ve often wondered if the industry created something of a monster ever since SANs first appeared. So I haven’t read it and probably won’t unless someone sends it to me.

That said, I’ve always seen this issue in fundamentally different terms. For me it's never been about DAS vs. SAN. Rather I see the dichotomy as DAS vs. networked storage. In terms of sharing, its shared infrastructure vs. shared data. NAS is ignored in this discussion as is the potential need for shared data (i.e. true data sharing).

NAS is sometimes called the “poor-man’s SAN” because it’s often a cheaper way to network storage and share it. So if the cost of SAN infrastructure bothers you, but you still want to share infrastructure that you would otherwise duplicate along with and all of the required management processes in going with DAS, NAS has always been there for you. And with unified storage and DCE on the horizon the differences between SAN and NAS begin to blur for me and I’m again left with a DAS vs. networked storage debate.

Re infrastructure sharing vs. true data sharing, I wonder if application-centric model that Andrew appears to be promoting considers that? From this posting of yours I would guess not. However, there may be food for thought on this issue in conjunction with the application-centric storage model. However, in this case, data sharing may or may not be heterogeneous as practiced in reality by the app vendors.

If not, then were left with two arguments for app-centric storage: “cut out the middle man” and manage storage from the application layer. There are ways to cut out the middleman without making the app guy the storage manager. I’ve liked the concept of the storage ATM for example and see some vendors promoting it. As for managing storage from the application layer and doing server based data management (replication for example), for me that debate has resurfaced with VMware. Veritas made a big push years ago to host data replication at the server level. It was good for some users, but bad for most. Veritas didn’t get very far. VMware has a different playing field in that there are potentially more server cycles available now to do this….Or are there? Maybe, and maybe not if you’re a user looking to run the critical apps on VMware.

In the end, the app-centric model may be more well suited for smaller IT environments. But those have traditionally shunned SANs in favor of NAS or DAS anyway. For me, SANs won’t go away. NAS gets more market share. And then there’s the cloud – plug in your app and off you go. That’s ultimately where I think the industry is headed long-term.

The comments to this entry are closed.

Chuck Hollis

  • Chuck Hollis
    SVP, Oracle Converged Infrastructure Systems

    Chuck now works for Oracle, and is now deeply embroiled in IT infrastructure.

    Previously, he was with VMware for 2 years, and EMC for 18 years before that, most of them great.

    He enjoys speaking to customer and industry audiences about a variety of technology topics, and -- of course -- enjoys blogging.

    Chuck lives in Vero Beach, FL with his wife and four dogs when he's not traveling. In his spare time, Chuck is working on his second career as an aging rock musician.

    Warning: do not ever buy him a drink when there is a piano nearby.

    Note: these are my personal views, and aren't reviewed or approved by my employer.
Enter your Email:
Preview | Powered by FeedBlitz

General Housekeeping

  • Frequency of Updates
    I try and write something new 1-2 times per week; less if I'm travelling, more if I'm in the office. Hopefully you'll find the frequency about right!
  • Comments and Feedback
    All courteous comments welcome. TypePad occasionally puts comments into the spam folder, but I'll fish them out. Thanks!