Most Amazing Benefits of Oracle Technology

We recently had a discussion with some of our clients about what is the best way to store data in an Oracle database. It goes without saying that the foundation should be based on the EMC infrastructure, but beyond that, which volume manager and/or file system is best for best performance and other important features?

There are many volume managers and many file systems available, more or less dependent on what hardware and operating system you're running the database on.

Oracle ASM is an Oracle volume manager specially designed for Oracle DBMS data storage. Oracle uses ASM in its production environments and is a core component in many of Oracle's own offerings (such as Oracle Exadata) when maximum performance is required. ASM offers support for Oracle RAC clusters without the need to install third party software such as cluster volume managers or file systems.

While ASM is not absolutely necessary to support an Oracle RAC cluster on EMC systems, we highly recommend using it as it reduces risk, costs, administrative overhead, and improves performance.

Oracle and other vendors have developed Oracle database storage management alternatives such as Oracle OCFS (and OCFS2), SUN/Oracle ZFS, IBM GPFS, and others. However, not all of them support Oracle clustering, and most of these file systems (and volume managers) are difficult to set up and require extensive tuning to provide good performance. Support (from Oracle or OS vendors) can also be an issue. Benefits of Oracle ASM

Compared to standard volume managers and file systems (both clustered and single system), ASM has a number of advantages:

It does not require large amounts of cache memory. However, memory not used for filesystem caching can be configured for Oracle memory (SGA), where it is more efficient (note that ASM typically requires a few hundred megabytes for back-end administration common to all databases) ASM spreads chunks of data pseudo-randomly across all available logical drives in a drive group, thereby removing potential performance bottlenecks ASM does not perform any I/O, so there are no "translation rules" for Oracle I/O to data files at disk block offsets. I/O from databases is directly applied to disk volumes without modification. This again reduces overhead and improves performance. Therefore, ASM also does not use read-ahead features (like file systems, for example) to read data into the cache that is never used by the database. ASM does not require painstaking configuration, including assigning fragment sizes and configuring file system journals. When creating an ASM disk group, you only need to define the size of the "chunk" and specify whether or not to perform thin striping. If you follow a few simple ASM configuration rules, it's unlikely that you'll make configuration errors that cause performance problems. ASM does not cause fragmentation. You may think that ASM balancing is a kind of fragmentation. However, the allocation units are large enough (usually 1 MB or more) for a very small disk to seek to read several subsequent (typically 8 KB) blocks. ASM does not split large I/O operations (i.e. 128K) into several smaller ones (4K or 8K), as some filesystems do. One large I/O is faster than many small ones Consistency does not require a "log" (like a "transaction log", etc.). This function is already performed by Oracle redo logs and therefore no additional overhead is required. ASM can be managed from the Oracle toolkit and does not require knowledge (this can be an advantage or disadvantage depending on the responsibilities of the various administrators in the organization). Adding or removing storage to/from ASM is very easy and doesn't require much planning (as is the case with volume managers and filesystems). Once a new storage is added, ASM will automatically "rebalance" the original storage so all disks will be used equally (evenly). This improves performance again. ASM runs on all major operating systems so it is platform independent SAP now supports Oracle ASM! Finally, EMC fully supports ASM, including various tools that integrate with Oracle (such as Replication Manager, as well as backup and reporting tools).

Disadvantages of Oracle ASM

Now let's remember the disadvantages of Oracle ASM? If you wrinkle your forehead a lot, then you can highlight the following "biggest" flaws that I identified:

Migrating from legacy filesystems to ASM can be a challenge and often requires a shutdown of the system (i.e. database production included) It is difficult (if not impossible) to view ASM content using standard OS tools. In some cases, ASM data can be accidentally overwritten by OS administrators who use disk volumes that (to them) appear to be empty. However, there are administrative ways to prevent this. Last but not least, I've run into a few situations where I/O load balancers (multipath drivers) have also messed up I/O from a higher level. In particular, I've seen 64K or 128K built-in multipath I/O translated into multiple 4K channels. Still not sure if this is a bug, an undocumented feature, or if it works as originally intended by the software. But it doesn't help Oracle's performance. We replaced the native EMC Powerpath driver with our own and immediately improved performance without further tweaking.