Oracle-related questions for a refresh..

Saty:

You are missing the storage protocol-related questions. Not surprising. Most EMC guys are what we used to call "SAN bigots". I come from a different place: I was at NetApp for 8 years before EMC, and in that role was largely responsible for the initial technical work in the area of Oracle on NFS. Anyway, the relevant questions would be:

• IP storage vs. SAN (obviously).
• If IP storage then dNFS vs. iSCSI (which will really be rare, other than on Windows where it is fairly common in some shops).
• If SAN then of course ASM vs. ext, NTFS, Veritas, etc. Lots of blind ends there.

Regards,

Jeff

Great point Jeff.. I think a lot of SEs may not be aware of the advantages (perceived or otherwise) of having NFS mounted directories for Oracle, or shared NFS (single-code base) for Oracle.. Now of course there's disadvantages of having a single Oracle home (code tree) for a RAC environment as well..

But from a IP vs SAN perspective, or ASM vs ext or 3rd party FS, these are areas we & the account SEs should be finding out more about as well..

Thanks

-Saty

Saty:

I am not sure the advantages are that compelling any more. But at the time (late 90s and early 2000s), NFS was a killer feature, and when 10g shipped with dNFS it was officially over: NFS was mainstream.

The advantages (at the time) were:

• Reduced port cost vs. FC (i.e., switches, HBAs, etc. were more expensive than equivalent ethernet gear). Is that still true? Barely. I would say in an era of 10 GbE / 16 Gb FC, we are about to get to a point where the wire really doesn't matter. And many switches allow you to install a port module with either ethernet or FC ports on it.
• Snapshots were very popular with NetApp early on. The perception was that NetApp snaps were somehow better than ours. Hogwash. I had to laugh when NetApp finally came out with read / write snaps, as if that was something great. Our snaps were always read / write. Yes, NetApp's snaps have no write performance penalty. But they have (effectively) a big sequential read penalty, and so, bottom line, it's about even in my view. No advantage for NFS there either, now.
• Perceived simplicity / ease of management of IP vs. FC. Again, is this really true now? I don't see any significant difference between administering an FC port vs. an ethernet port on a switch (say Cisco MDS) which allows either one.

Oracle has muddied the waters a bit by adding features to dNFS which ASM lacks. Arguably, ASM is falling behind in that area. dNFS clonedb is an utterly charming feature, for example, that ASM presently does not have.

Having said that, at least in an EMC-centric view, FC is way cooler. On FC you can do VPLEX, RecoverPoint, Timefinder, etc. On NFS, you have the old Celerra Replicator and Celerra Snapsure checkpoint stuff. Which is just not as cool as VPLEX or RecoverPoint. Not even close.

Eventually, once we get to software defined networking, the network protocol no longer matters. And we are very close to that point.

Regards,

Jeff

All great points!

I would like to recommend our Oracle Sales Playbook with a list of comprehensive questions to end users, application owners and CXOs from high level messages to technical details.

Great idea Simon..

Let's collect these responses and add others..

Thanks

Hi Sam,

I agree with you but I think it does apply to storage, more and more I see startups trying to work on this space and they are starting to see un uptick on smaller accounts, yes SuperFast Ethernet is coming and sooner than we all expect...

I would like to add some more questions here :-

1) What should be the difference in the time lag between the Primary and the DR ?

2) What is the maximum possible time that the downtime can be allowd ?

3) What will be the recovery stategy ? How frequently the DR test will be performed ?

Based on the input we can strategise the oracle solutions.

Saty,

Good set of questions to get the conversation going with customers and very similar to what I have been asking. How about posting this to the Oracle PreSales Minors site?

Yes folks, EMC is actively training its presales technical teams on the Oracle stack and on Oracle and EMC integration. The goal is for EMC to fully engage the Oracle owners and expand EMC's existing global Oracle Specialists team.

bg

WBGaynor,

Good call on posting those questions to the Oracle Pre-sales Minor community!

Bill.. Thanks.. Great idea...

To continue this thread, and to consolidate (Before posting on the Oracle Minors site), in light of the additional options available to customers for Oracle workloads, (Flash technology), we should also ask

1. What their current Oracle IO profile is (and then position either a complimentary Oracle AWR analysis through MiTrend, or the DBClassify Professional Service (depending on the propensity of the customer to purchase it)

2. Will they benefit from all-Flash arrays and technologies, and / or will you benefit from sub-millisecond response times being offered out-of-the-box by all-Flash arrays such as XtremIO ?

3. Are you evaluating other all-Flash arrays such as Pure, or Flash card technologies like Fusion-IO ?

4. What array are they today for Oracle ? (And does it primarily have one type of disk, say SAS, or does it have tiering capabilities ? Or do they pin specific 'hot' tablespaces to faster disk (say EFD)

Thanks..

Sam:

Eventually, I think when we get to the Software Defined Data Center (SDDC), then the wire is irrelevant and the protocol arguably no longer matters (or perhaps a better way to say it would be that you can run whatever protocol you like on whatever wire you like).

Cisco now makes switches which allow you to change out the module which determines the wire and protocol. MDS, for example, can switch on the fly between FC and IP / 10 GbE. Once we get to the point where we can do that in software (and we are very close to that point right now), then the entire protocol argument is over.

Which has primarily been about latency and bandwidth anyway. The benchmark for a performant network technology at the moment is Infiniband (IB). In a pre-SDDC context, IB provides theoretically about 40 GbE of throughput with small single-digit millisecond to low triple-digit microseconds in latency. (See: InfiniBand - Wikipedia, the free encyclopedia.) But after SDDC, IP / Ethernet (or whatever they are going to call it in the post-SDDC context) will provide 100 GbS of throughput with very similar latency as IB.

At that point, the network is no longer the bottleneck, arguably. We will flood the bus, and the CPU layer will then become the bottleneck for a while.

It will be interesting soon!

Regards,

Jeff