One day I had to gather information on ASM for standalone server. Is it worth a while and resources to play with it? Please find some pros and cons I have gathered during my research.·

Pros:

  • Datafiles are not accessible to the operating system’s commands. It’s not possible to delete the files from the operating system level by accident
  • ASM distributes chunks of data pseudo-randomly across all available logical disks in a disk group, thereby removing potential performance “hot-spots”
  • ASM does not perform any I/O itself so there is no “translation layer” for Oracle I/O to datafiles into disk block offsets. I/O from databases is directly applied to disk volumes without modification. This again reduces overhead and improves performance.
  • ASM also does no read-ahead (like filesystems) to read data in (filesystem) cache that is never used by the database.
  • ASM does not cause fragmentation (you could argue that ASM balancing is some sort of fragmentation. However, the allocation units are large enough – typically 1MB or more – to allow for very little disk “seeks” to read a number of subsequent (typically 8K) blocks
  • ASM does not break large I/O’s (i.e. 128K) in multiple smaller ones (4K or 8K) like some filesystems do. One large I/O is faster than many small ones.
  • No “journal” (AKA “intent log” etc) is required for consistency (this function is already done by Oracle redo logs and having a journalled filesystem is therefore only overhead).
  • ASM can be managed from within Oracle tools and does not require Unix administration (this can be an advantage or disadvantage depending on responsibilities of various administrators in the organization).
  • You can add or remove disks from a disk group while a database continues to access files from the disk group. When you add or remove disks from a disk group, ASM automatically redistributes the file contents and eliminates the need for downtime when redistributing the content.  You don’t need to move the datafiles anywhere which would require a downtime.
  • You can switch online between storage devices in example between old and new storage hardware. The rebalance impact on the system can be reduced by setting REBALANCE POWER parameter properly.
  • Together with the Grid Infrastructure stack that you install for ASM, you get Oracle Restart feature which is very handy for setting Oracle Databases’ and listeners’ autostart.  It also guards accessibility of the instances and listeners and restarts in case of a crash.
  • Oracle writes and reads directly to the raw devices managed by ASM without the mediation of the operating system or kernel. ASMdoes not use the filesystem cache also. It does not require large amounts of memory for cache. The memory not required for file system caching can be configured for Oracle memory (SGA) where it is more efficient (note that ASM requires typically a few hundred megabytes for internal administration, shared across all databases)
  • It is like a volume manager that has been included in your license so no additional cost for the software or its support.
  • It provides a single point of support so there is no finger-pointing.
  • ASM Inherently Performs Asynchronous I/O Regardless of filesystemio_options Parameter
  • This is very mature technology that has been thoroughly tested for years by Oracle users community
  • Using ASM removes the risk of misconfigured volume managers, file systems and I/O path drivers.

Cons:

  • Additional resources required to run Grid Infrastructure stack for the ASM
    – 4-5GB RAM per server
    – 20 GB of disk space for GRID_HOME
  • More time needed to provision Oracle database to the new server. Estimated additional time around 4-6 hours for installing and configuring the GI with ASM.
  • Requires more administrative skills of the DBA
  • Patching is more complex, but with auto feature of opatch tool you can patch Grid Infrastructure, ASM and databases with one GO.
  • The disk storage presented for the ASM consists of more physical devices. Oracle recommends at least two separate diskgroups for DATA and FRA. The best practice is two have 4 physical devices per diskgroup, to have at least 4 queues of I/O s to the diskgroup devices at the OS level.
  • ASM does not use the filesystem cache anymore so you need bigger SGA, but remember you have gained the space because you no longer cache database files at the filesystem level
  • You don’t have direct access to the files, can’t  just copy the files aside. Backup cannot be done with traditional methods just like backup of OS files so you need integrated tools like RMAN
  • It is hard (if not impossible) to view ASM contents with standard OS tools. In some cases, ASM data can be accidentally overwritten by OS admins who are using disk volumes that (to them) seem to be empty. However, there are administrative ways to prevent this from happening

 

What do you think?? Please post your comments :)
Source: My experience and WorlWideWeb

About the author

 
maciej tokar
Maciej Tokar

An Oracle technology geek and crazy long distance runner, DBA24 Owner
Senior Oracle DBA / Consultant / [OCP10g, OCP12c, OCE RAC 10g] / [experience: 9y+]
Currently working for Bluegarden (Oslo Norway) by Miratech Group
Past: Mastercard / Trevica by Britenet, Citi International PLC, PZU

 
View Maciej Tokar's profile on LinkedIn         logoDB4
LinkedIn Auto Publish Powered By : XYZScripts.com