On a test environments... one of two controllers didn't work as expected and it was not able to redirect I/O to the other, then they both were able to freeze the instance and hang or reboot happened. It was a bug. That instance wrote directly to disk without any ASM instance.
We solved introducing the ASM instance and creating different disk group where to write: one for every controller. No hang or reboot anymore...

I have a question what is difference between san and asm because san also provide mirroring like asm,why we shuld go for asm.

It is NOT an issue of ASM vs SAN.

ASM is a storage management layer - and this runs on top of a storage layer that can be SAN, NAS, local disks, etc.

There are 2 basic choices for RAID. Do it in the storage management layer (s/w RAID). Do it on the physical storage layer. This can be either s/w RAID (like on a SAN), or h/w RAID (using an onboard RAID controller) like with local disks.

The decision on where to RAID is one that is based on requirements and architecture.

For example, RAID in ASM allows you to use SAN1 and SAN2 as mirrors. This will not be possible on SAN1 or SAN2 as they can only mirror locally within that SAN.

RAID on the SAN may be chosen as RAID5 is a viable and feasible option and cheaper than using RAID1 (mirroring) in ASM. The SAN could also be highly specialised (using SSDs and scsi and custom RAID levels). In such a case RAID would typically be done on the SAN and not ASM.

It comes down to what the architecture supports and what the requirements are. That said, if you do use a SAN for Oracle, it would be a mistake not using ASM as the storage management layer for the Oracle databases. There is no competition between ASM and SANs - they should almost always be used together when dealing with storage for Oracle.

Thanks Billy Verreynne for your response,but i want to know if i don't use asm or use asm storage layer for oracle dbf file?.what is the benefit of using asm storage because some of organization don't use asm storage.

ASM can do online LVM (add or replace disks)
ASM can do the Storage mirroring for you (which is maybe faster with asm preffered reader)
ASM can help you in Online Storage Migration
ASM can be faster (because there is no filesystem overhead)
ASM can mirror your data for protection

This are feature which ASM can do, but there are also other storage vendors and filesystem vendors which can do similar functions.

A storage area network (SAN) is a dedicated network that provides access to consolidated data storage. Automatic Storage Management (ASM) is a feature provided by Oracle that aims to simplify the management of database files. ASM provides data redundancy based on allocation units and uses the free space of available failure groups, rather than striping or mirroring complete disks like RAID.

So your understanding of how ASM mirrors data or provides redundancy seems wrong, which might have triggered your question. For instance you can add ASM disks to increase capacity without having to rebuild your volumes, which you cannot do with a SAN/RAID system. ASM and SAN are complementary products and not competing products.

926840 wrote:
but i want to know if i don't use asm or use asm storage layer for oracle dbf file?.what is the benefit of using asm storage because some of organization don't use asm storage.

There are two basic types of storage for Oracle databases.

"Cooked" file system. This means the disk is formatted and managed via a specific file system driver. On Windows, that would be ntfs. On Linux, that typically would be something like ext3.

This file system is managed by the file system driver loaded into the kernel. It does directory and file management, service I/O calls to read and write files, provides caching, and so on.

ASM does not support cooked file system as it already has a driver that manages that formatted file system drive/partition.

Raw disks is the second storage type. This means it is unformatted - and as such, you cannot (via standard o/s commands) use the drive to create/update/delete/etc directories and files.

ASM supports managing such raw (non-cooked) devices. As these devices are directly used by the database, the database can better control and managed device access.

Simple example. The database writes 10 8KB database blocks to a cooked file system. It has no idea whether those 10 blocks were actually written to disk.. or whether the file system driver has cached that write and all 10 blocks still sit in memory. The database itself also has a cache. So there are now 2 memory caches.. a physical database I/O may actually be a logical file system I/O.. These factors make managing and determining performance complex.

A raw non-cooked device does not have such a secondary cooked file system cache. If the database does a physical write to disk, the data is actually written to disk. There is a single memory cache that is managed by the database. Less complexity and less ambiguity. And it can also mean better performance.

Manually managing raw device is however complex. And in the past, problematic as the database directly used the raw device without providing any type of management layer for raw devices. ASM addresses that issue - and addresses it very well.

Using SAN LUNs as cooked file systems for an Oracle database does not make much sense IMO. SAN LUNs should be used as raw devices for the database - and ASM used as management layer for these devices.