The following is part of a series on the different aspects of disk I/O performance and optimization for Oracle databases. Each tip is excerpted from the not-yet-released Rampant TechPress book, "Oracle disk I/O tuning," by Mike Ault. Check back to the main series page for upcoming installments.
 |
|
Mike Ault
|
|
Mike Ault is one of SearchOracle.com's Oracle Internals experts. Mike is senior Oracle consultant with Burleson Consulting, and one of the leading names in Oracle technology.
To view Mike's expert responses or to ask him a question, click here.
|
|
|
What is Automated Storage Management?
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 for you.
ASM is the logical extension of the power of Oracle-managed files (OMF). In previous releases of OMF, files were created and managed automatically for you, but with ASM you reap the additional benefits of features such as ASM disk group mirroring and striping. ASM was developed by the same group that developed ODM (Oracle Disk Manager) with in Oracle Corporation.
ASM was designed to preserve all existing database functionality. Your 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 all at the same time.
Why ASM?
Before we examine the role and position of ASM in the storage stack of the database files, let us look at some of the storage management features that are often used in varying degree of the usage. 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 can handle. 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, the 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 some cases 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.
Click to buy the book, "Oracle disk I/O tuning," by Mike Ault.
About the author
Mike Ault is a SearchOracle.com expert and a senior Oracle consultant with Burleson Consulting, and one of the leading names in Oracle technology. The author of more than 20 Oracle books and hundreds of articles in national publications, Mike Ault has five Oracle Masters Certificates and was the first popular Oracle author with his landmark book "Oracle7 administration and management." Mike also wrote several of the "Exam Cram" books, and enjoys a reputation as a leading author and Oracle consultant. Ask Mike a question today!
