Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 
 Home
 E-mail Us
 Oracle Articles
New Oracle Articles


 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog


 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Analysis
 Design
 Implementation
 Oracle Support


 SQL Tuning
 Security

 Oracle UNIX
 Oracle Linux
 Monitoring
 Remote s
upport
 Remote plans
 Remote
services
 Application Server

 Applications
 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S
upport  
 Development  

 Implementation


 Consulting Staff
 Consulting Prices
 Help Wanted!

 


 Oracle Posters
 Oracle Books

 Oracle Scripts
 Ion
 Excel-DB  

Don Burleson Blog 


 

 

 


 

 

 

 

 

What is Automated Storage Management (ASM)?

Oracle RAC Cluster Tips by Burleson Consulting

This is an excerpt from the bestselling book Oracle Grid & Real Application Clusters.  To get immediate access to the code depot of working RAC scripts, buy it directly from the publisher and save more than 30%.


Automated Storage Management (ASM) was designed to simplify database administration. ASM eliminates the need for the DBA to directly manage the thousands of Oracle database files that could be present in a modern Oracle instance. ASM does this by enabling ASM disk groups, which are logical units comprised of disks and the files that reside on them. Using ASM, the management of thousands of Oracle files is reduced to managing a small number of disk groups.

The SQL statements used for creating database structures, such as tablespaces, redo logs, archive log files, and control files, must specify file location in terms of ASM disk groups in order to use ASM. ASM will then create and manage the associated underlying files.

ASM is the logical extension of the power of Oracle-managed files (OMF). In previous releases of OMF, files were created and managed automatically, but with ASM there are the additional benefits of features such as ASM disk group mirroring and striping. ASM was developed by the same group that developed Oracle Disk Manager (ODM) within Oracle Corporation.

ASM was designed to preserve all existing database functionality. Existing databases will operate as they always have. Existing databases using file systems or with storage on raw devices will operate as they always have. However, even in existing Oracle 10g Databases, new files can be created as ASM files while old ones are administered in the old way. This means that databases can have a mixture of ASM files, Oracle-Managed files, and manually managed files simultaneously.

Why ASM?

Before examining the role and position of ASM in the storage stack of the database files, a review of some of the storage management features that are often used in varying degree of the usage is warranted. They include:

* Direct I/O

* Asynchronous I/O

* Striping

* Mirroring

* SAME and Load Balancing

Direct I/O

Buffered I/O uses precious resources like memory and CPU cycles because the Oracle blocks are cached both in the SGA and in the file system buffer cache. By adopting the Direct I/O, a much higher cache hit ratio can be achieved. Oracle can handle cache much more efficiently than a file system. Oracle has a sophisticated touch count based cache replacement algorithm that is sensitive to both the frequency of usage and how recent the data blocks are.

Buffered I/O fills up the file system cache with Oracle Data, where as using the Direct I/O allows non-Oracle data to be cached in the file system much more efficiently. Also, the buffered I/O generally involves large physical writes, such as temp file writes. These writes are performed and waited for in series, and therefore they cannot be merged in the device driver or lower layers of the stack, unless a write-back disk cache is in use. This means that a full rotational latency of the physical disk is sustained between every pair of component writes.

Redo Log file writes also suffer from another severe inefficiency if buffered I/O is used. Because redo writes address an arbitrary number of log blocks, and log blocks are small relative to the size of file system buffers, it is normal that the last log block of a redo write does not align with the end of a file system buffer. Therefore, unless the target file system block is already in cache, the operating system must first read that block from disk before the new redo can be copied into part of its file system buffer.

To solve all these problems, direct I/O is highly desired. The way in which direct I/O is enabled varies from one system to another and also depends on the type of file system type. In some cases it is sufficient to set the filesystemio_options parameter. In other situations a file system mount option is required and direct I/O can also be configured on a file-by-file basis using special operating system commands. The use of ASM eliminates need for direct I/O configuration.

 


This is an excerpt from the bestselling book Oracle Grid & Real Application Clusters, Rampant TechPress, by Mike Ault and Madhu Tumma.

You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.

http://www.rampant-books.com/book_2004_1_10g_grid.htm


 

 
��  
 
 
Oracle Training at Sea
 
 
 
 
oracle dba poster
 

 
Follow us on Twitter 
 
Oracle performance tuning software 
 
Oracle Linux poster
 
 
 

 

Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


                    









Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


 

Copyright © 1996 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational