An Oracle database will typically consist of hundreds of files, and managing these files can be a problem, especially for multiple databases or very large databases. Sometimes files need to be placed to ensure adequate performance or ensure a service will survive a disk failure, and this requires detailed knowledge of the underlying disk system to ensure the files are placed correctly.
ASM (Automatic Storage Management) is designed to simplify this management by combining disks into groups, so the administrator manages a small number of disk groups, rather than managing individual disks or files. ASM also looks after I/O balancing to optimise the database performance. Templates are used to allocate new disks, different templates select different striping and mirroring options, and ASM does the rest.
ASM runs as a separate instance and it must be started before the database instance, otherwise the database will not be able to find its files. RMAN is the only way to backup ASM disks.
ASM uses a kernel module called Oracle ASM Filter Driver or Oracle ASMFD, which intercepts all I/O that is directed to Oracle ASM disks. Oracle ASM uses the filter driver to validate write I/O requests to Oracle ASM disks. If any of these I/Os are invalid, for example if they come from outside of Oracle, then ASMFD will reject them. This prevents external writes from corrupting your databases. ASMFD also simplifies the configuration and management of disk devices by eliminating the need to rebind disk devices used with Oracle ASM each time the system is restarted.
Oracle 11g introduced the ASM Cluster File System (ACFS), which is touted as a 'multi-platform, scalable file system, and storage management technology that extends Oracle ASM functionality to support customer files maintained outside of Oracle Database'. It supports all those non-database files that an Oracle database needs to operate, such as logs, trace files, executables and configuration files. It also supports general-purpose application files. This non-database data can be accessed by using native operating system file system APIs and command-line interface tools.
The advantage of doing this is that Oracle ACFS uses 64-bit file and file system data structure sizes which means that it could support exabyte size files and file systems on 64 bit platforms. Other advantages are built in performance tuning, metadata checksums for data intergrity and journaling for fast recovery.
Disk groups are the ASM unit of management and basically consist of groups of disks that are lumped together and managed as a single entity. Data is striped within a disk group and should be mirrored between disk groups.
Failure groups are groups of disks that can potentially all fail at the same time, for example, because they share the same SCSI controller. If your ASM redundancy policy is for 2-way mirroring, then the data on each side of the mirror must be on different failure groups. Then if any component fails in one failure group, the data on the other failure group is not affected. Triple redundancy requires three failure groups, and ASM can then tolerate concurrent failures in any two groups.
Templates are used to simplify creating files and mapping them to the correct disk group. Templates consist of attributes that a file can have, for example, UNPROTECTED or MIRROR, which are used to describe no redundancy or a 2 way mirror. COARSE and FINE are a little less obvious, they describe the granularity used for striping. Fine-grained striping is appropriate for log files as they require low latency. This allows larger I/Os to be split and processed in parallel by multiple disks and so speeding up response times.
ASM provides a set of default templates, for example ONLINELOG provides file redundancy and striping for redo log files. It is also possible to write your own templates for your own site needs
ASM stripes its files across all the disks that belong to a disk group using a version of RAID 3, RAID3 is used because it is much easier to add or remove disk from a RAID3 system than RAID5 or RAID6. Ideally, all the disks in a disk group should be the same size.
However, don't confuse this striping with redundancy. The striping is for performance reasons, redundancy involves mirroring data between disk groups. Disk groups can have no external redundancy, two-way mirroring or three-way mirroring. These last two are often called normal and high mirrors. If possible, the disk groups should run under different controllers to provide failover for controller errors.
ASM automatically handles changes to the disk count within a group, whether this is down to a disk failure, or disks being added or removed, and does this while the database is operating. The rebalancing process happens in the background with minimal impact on database performance.
If you add a disk, ASM will automatically redistribute the data so that it is evenly spread across all disks in the disk group, including the new disk. When you request to remove a disk, ASM will first relocate all the file extents from the disk being removed to the other disks in the disk group. The data is spread evenly to conserve the I/O balance.
ASM gives DBAs the ability to refer to ASM files with user-friendly names, rather than the fully qualified ASM filenames. This is bad news for a storage person as if they get problems you then have to translate between what they call the file, and the real file name. If you get problems locating a file, ask your DBA to check if he is using an alias or not.