Thanks for the info, that def helps.
I'm new to ASM and was thinking about using it for some of our new database builds. We don't have a RAC environment and all the DBs will be single instance DBs.
The type of storage is a primary consideration. ASM makes little sense if your only fixed option is cooked file systems for database storage.
What are the benefits of using ASM on a single instance environment?
Being a new newcomer is it even worth it to dive into that as opposed to the standard file system?
I would instead ask which provides more robust management, use and performance for database storage - cooked file systems or raw disks?
And my answer is the latter. Cooked file systems need additional security considerations. Is a shared meduim/device. Space management is not easy. Has its own memory cache (device buffer) - which Oracle will now put its own cache (superior for databases) in front of. Which leads to problematic performance analysis as what Oracle sees as physical I/O may not be actual physical I/O. Etc.
There is also a performance consideration. A block device I/O (direct device I/O) to a raw device, bypasses a lot of internal moving parts in the kernel.
FWIW, even for the very smallest database servers I build these days, I insist on a separate (second) hard drive to use (as a raw device) for database storage.
When using raw devices, you need some kind of storage management tool that makes using raw devices easy and flexible. And that is ASM.
So the key question is not ASM or not-ASM. It is whether you want to use cooked file systems (ASM irrelevant), or raw devices (storage manager required).
Oracle 126.96.36.199 Databases
Fibre channel based? Dual ports?
We have been using this type of storage architecture for almost a decade now for most of our RACs. Experience has shown us that:
- LUNs as raw devices
- use Linux multipath to manage multiple I/O paths to a SAN LUN
- do NOT taint the kernel with a vendor proprietary driver (like EMC's Powerpath)
- use ASM to manage both Grid and RAC storage LUNs
Now whether the server architecture is RAC or non-RAC, does not change these points.
From what I understand the difference between raw devices and file systems is kernel buffering. Raw device bypasses the kernel's block buffer cache entirely. However, the concept of raw devices in Linux has become obsolete with the introduction of direct I/O in RHEL 5, which is a feature of the file system whereby file reads and writes go directly from the applications to the storage device, bypassing the operating system read and write caches. An application, such as Oracle RDBMS invokes direct I/O by opening a file with the O_DIRECT flag and ASM does the same.
1 person found this helpful
Support note Pros and Cons of Using Direct I/O for Databases (Doc ID 1005087.1) goes into the details.
The concept of raw devices existed long before the hack in older Linux kernels, in order to create a character devices for a block device for direct I/O - and calling this specific feature as "raw devices".
On Unix, the concept of cooked devices and raw devices existed since the 80's (my experience) and likely early. And have been used ever since, consistently. Do not let a poorly phrased term for an Linux kernel feature confuse you.
I said that the concept of raw devices has become obsolete in the Linux kernel since RHEL5, not that it was obsolete in the Unix world... Like you said, the concept of raw devices existed long before the hack in older Linux kernels, and still is in BSD and other commercial Unix systems. Raw device support was not a feature of the Linux kernel to begin with, which pursued the philosophy that the kernel should manage and optimize all I/O. It certainly made sense in the early days of PC for which sophisticated storage options were not available.
Thanks for all the feedback. We went ahead and did an ASM install and so far so good.