Thanks for the question, John.
Asked: September 17, 2020 - 12:29 am UTC
Last updated: September 18, 2020 - 4:52 am UTC
Version: 12.2.0.3
Viewed 1000+ times
You Asked
Typically companies that can afford the high cost of a multiple node RAC license, they can afford to have an enterprise SAN solution. The SAN solution like a Netapps is an appliance with it's own software and CPUs to process data quickly. They also usually have a dedicated SAN/storage expert to support it.
To me it seems asinine to request that we get RAW disks from that same Netapps SAN so that we can overlay ASM software on it. Now, we have to host the ASM processes on each database node, use CPUs on the database server for ASM and lose the SAN expertise since they will not be managing the ASM storage. Am I missing something here? How can Oracle recommend ASM in this scenario that I just mentioned over a Netapps SAN solution that will probably be NFS mounted drives for the RAC database, but will be managed by an expert SAN professional?
and Connor said...
We don't *force* you to use ASM, we simply recommend it.
Here's some reasons why:
1) Many general purpose clustered file systems (CFS) (ie, those that allow concurrent access from multiple nodes) where not designed for databases. That is not a criticism, just a reflection that their origins were more in high *quantity* of files and extreme levels of *people* accessing the files. A database is more about a small number of files with less concurrent access in terms of number, but much more extreme in terms of the amount of work each access does. (ie, 1 million people might access a CFS once per hour, whereas only 100 database processes access the CFS millions of times per second). So a CFS *may* get in the way of the performance needs of a database.
2) Putting aside clustering, file systems are often concerned about functionality about the *files*, eg, version history, modification logs, access tracking etc. Little or none of that really helps a database, and may hinder performance.
3) Obviously a database needs to be *really really really* confident of its file operations, because we if assumed some redo was written and in reality it wasn't (eg cached, or deferred, or silently failed), then if things go bad, the database is toast. So handing over the incredibly important responsibility to a file system layer that we have no control over increases risk, increases testing time, etc. Using ASM gives us a greater control over the stack.
4) Getting deeper into the IO stack also lets us "cheat". By that I mean look at our Exadata boxes. The *storage* layer can do some of the work that typically the database would be doing, eg, applying predicates etc. Lots of potential benefits there.
Having said all of that, we don't *disallow* non-ASM. Before I joined Oracle, the last project I did was a stretch RAC cluster all running on NetApp storage using NFS. And you can see our committment to NFS because we have our *own* NFS client (Direct NFS) which you can run on top of NetApp to get better performance plus access to other benefits (such as clone db).
Hope that answers your question
Is this answer out of date? If it is, please let us know via a Comment