Automatic Storage Management (ASM)
Automatic Storage Management (ASM) is oracle’s logical volume manager, it uses OMF (Oracle Managed Files) to name and locate the database files. It can use raw disks, filesystems or files which can be made to look like disks as long as the device is raw. ASM uses its own database instance to manage the disks, it has its own processes and pfile or spfile, it uses ASM disk groups to manage disks as one logical unit.The benefits of ASM are
- Provides automatic load balancing over all the available disks, thus reducing hot spots in the file system
- Prevents fragmentation of disks, so you don't need to manually relocate data to tune I/O performance
- Adding disks is straight forward - ASM automatically performs online disk reorganization when you add or remove storage
- Uses redundancy features available in intelligent storage arrays
- The storage system can store all types of database files
- Using disk group makes configuration easier, as files are placed into disk groups
- ASM provides stripping and mirroring (fine and coarse gain - see below)
- ASM and non-ASM oracle files can coexist
- ASM is free!!!!!!!!!!!!!
| ASM Instance | is a special instance that does not have any data files, there is only ASM instance one per server which manages all ASM files for each database. The instance looks after the disk groups and allows access to the ASM files. Databases access the files directly but uses the ASM instance to locate them. If the ASM instance is shutdown then the database will either be automatically shutdown or crash. |
| ASM Disk Groups | Disks are grouped together via disk groups, these are very much like logical volumes. |
| ASM Files | Files are stored in the disk groups and benefit from the disk group features i.e. stripping and mirroring. |
| ASM Summary |
|
- Not Managed by ASM - Oracle binaries, alert log, trace files, init.ora or password file
- Managed by ASM - Datafiles, SPFILES, redo log files, archived log files, RMAN backup set / image copies, flash recovery area.
There are a number of new processes that are started when using ASM, both the ASM instance and Database will start new processes
ASM Instance
| |
| RBAL (rebalance master) | coordinates the rebalancing when a new disk is add or removed |
| ARB[1-9] (rebalance) | actually does the work requested by the RBAL process (upto 9 of these) |
Database Instance
| |
| RBAL | opens and closes the ASM disk |
| ASMB | connects to the ASM instance via session and is the communication between ASM and RBMS, requests could be file creation, deletion, resizing and also various statistics and status messages. |
ASM Disk Groups
An ASM disk group is a logical volume that is created from the underlying physical disks. If storage grows you simply add disks to the disks groups, the number of groups can remain the same.
ASM file management has a number of good benefits over normal 3rd party LVM's
- performance
- redundancy
- ease of management
- security
ASM stripes files across all the disks within the disk group thus increasing performance, each stripe is called an ‘allocation unit’. ASM offers two types of stripping which is dependent on the type of database file
| Coarse Stripping | used for datafile, archive logs (1MB stripes) |
| Fine Stripping | used for online redo logs, controlfile, flashback files(128KB stripes) |
Disk mirroring provides data redundancy, this means that if a disk were to fail Oracle will use the other mirrored disk and would continue as normal. Oracle mirrors at the extent level, so you have a primary extent and a mirrored extent. When a disk fails, ASM rebuilds the failed disk using mirrored extents from the other disks within the group, this may have a slight impact on performance as the rebuild takes place.
All disks that share a common controller are in what is called a failure group, you can ensure redundancy by mirroring disks on separate failure groups which in turn are on different controllers, ASM will ensure that the primary extent and the mirrored extent are not in the same failure group. When mirroring you must define failure groups otherwise the mirroring will not take place.
There are three forms of Mirroring
- External redundancy - doesn't have failure groups and thus is effectively a no-mirroring strategy
- Normal redundancy - provides two-way mirroring of all extents in a disk group, which result in two failure groups
- High redundancy - provides three-way mirroring of all extents in a disk group, which result in three failure groups
The data files you create under ASM are not like the normal database files, when you create a file you only need to specify the disk group that the files needs to be created in, Oracle will then create a stripped file across all the disks within the disk and carry out any redundancy required, ASM files are OMF files. ASM naming is dependent on the type file being created, here are the different file-naming conventions
- fully qualified ASM filenames - are used when referencing existing ASM files (+dgroupA/dbs/controlfile/CF.123.456789)
- numeric ASM filenames - are also only used when referencing existing ASM files (+dgroupA.123.456789)
- alias ASM filenames - employ a user friendly name and are used when creating new files and when you refer to existing files
- alias filenames with templates - are strictly for creating new ASM files
- incomplete ASM filenames - consist of a disk group only and are used for creation only.
Creating a ASM instance is like creating a normal instance but the parameter file will be smaller, ASM does not mount any data files, it only maintains ASM metadata. ASM normally only needs about 100MB of disk space and will consume about 25MB of memory for the SGA, ASM does not have a data dictionary like a normal database so you must connect to the instance using either O/S authentication as SYSDBA or SYSOPER or using a password file.
The main parameters in the instance parameter file will be
- instance_type - you have two types RDBMS or ASM
- instance_name - the name of the ASM instance
- asm_power_limit - maximum speed of rebalancing disks, default is 1 and the range is 1 - 11 (11 being the fastest)
- asm_diskstring - this is the location were oracle will look for disk discovery
- asm_diskgroups - diskgroups that will be mounted automatically when the ASM instance is started.
ASM Configuration
| |
| Parameter file (init+asm.ora) | instance_type=’asm’ instance_name=’+asm’ asm_power_limit=2 asm_diskstring=’\\.\f:’,’\\.\g:’,’\\.\h:’ asm_diskgroup= dgroupA, dgroupB Note: file should be created in $ORACLE_HOME/database |
| Create service (windows only) | c:> oradim –new –asmsid +ASM –startmode manual |
| Set the oracle_sid environment variable (windows or unix) | c:> set ORACLE_SID=+ASM (windows only) export ORACLE_SID=+ASM (unix only) |
| Login to ASM instance and start instance | c:> sqlplus /nolog; sql> connect / as sysdba; sql> startup pfile=init+asm.ora Note: sometimes you get a ora-15110 which means that the diskgroups are not created yet. |
ASM Operations
| |
| Instance name | select instance_name from v$instance; |
| Create disk group | create diskgroup diskgrpA high redundancy failgroup failgrpA disk ’\\.\f:’ name disk1 failgroup failgrpB disk ’\\.\g:’ name disk2 force failgroup failgrpC disk ’\\.\h:’ name disk3; create diskgroup diskgrpA external redundancy Note: force is used if disk has been in a previous diskgroup, external redundancy uses third party mirroring i.e SAN |
| Add disks to a group | alter diskgroup diskgrpA add disk '\\.\i:' name disk4; '\\.\j:' name disk5; |
| Remove disks from a group | alter diskgroup diskgrpA drop disk disk6; |
| Remove disk group | drop diskgroup diskgrpA including contents |
| resizing disk group | alter diskgroup diskgrpA resize disk 'disk3' size 500M; |
| Undo remove disk group | alter database diskgrpA undrop disks; |
| Display diskgroup info | select name, group_number, name, type, state, total_mb, free_mb from v$asm_diskgroup; select group_number, disk_number, name, failgroup, create_date, path, total_mb from v$asm_disk; select group_number, operation, state, power, actual, sofar, est_work, est_rate, est_minutes from v$asm_operation; |
| Rebalance a diskgroup (after disk failure and disk has been replaced) | alter diskgroup diskgrpA rebalance power 8; Note: to speed up rebalancing increase the level upto 11, remember that this will also decrease performance, you can also use the wait parameter this will hold the commandline until it is finished |
| Dismount or mount a diskgroup | alter diskgroup diskgrpA dismount; alter diskgroup diskgrpA mount; |
| Check a diskgroups integrity | alter diskgroup diskgrpA check all; |
| Diskgroup Directory | alter diskgroup diskgrpA add directory '+diskgrpA/dir1' Note: this is required if you use aliases when creating databse files i.e '+diskgrpA/dir/control_file1' |
| adding and drop aliases | alter diskgroup diskgrpA add alias '+diskgrpA/dir/second.dbf' for '+diskgrpB/datafile/table.763.1'; alter diskgroup diskgrpA drop alias '+diskgrpA/dir/second.dbf' |
| Drop files from a diskgroup | alter diskgroup diskgrpA drop file '+diskgrpA/payroll/payroll.dbf'; |
Using ASM Disks
| |
| Examples of using ASM disks | create tablespace test datafile ‘+diskgrpA’ size 100m; alter tablespace test add datafile ‘+diskgrpA’ size 100m; alter database add logfile group 4 ‘+dg_log1’,’+dg_log2’ size 100m; alter system set log_archive_dest_1=’location=+dg_arch1’; alter system set db_recovery_file_dest=’+dg_flash’; |
| Display performance | select path, reads, writes, read_time, write_time, read_time/decode(reads,0,1,reads) "AVGRDTIME", write_time/decode(writes,0,1,writes) "AVGWRTIME" from v$asm_disk_stat; |
RMAN is the only way to backup ASM disks.
| Backup | backup as copy database format ‘+dgroup1’ |
Compared to standard volume managers and filesystems (either clustered or single system), ASM has a number of advantages:
- 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)
- 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.
- Therefore ASM also does no read-ahead (like filesystems) to read data in (filesystem) cache that is never used by the database.
- ASM does not require intensive tuning such as setting fragment sizes correctly and tuning file system journals. When creating an ASM disk group you only need to define the “chunk size” and whether or not to perform fine striping. It is unlikely to make configuration errors (causing performance issues) if a few simple ASM configuration guidelines are followed.
- 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 tooling and does not require Unix administration (this can be an advantage or disadvantage depending on responsibilities of various administrators in the organization).
- Adding or removing storage to/from ASM is very easy and does not require careful planning (as is the case with volume managers and filesystems). After adding storage, ASM will automatically “rebalance” storage so all disks will be utilized equally. This again increases performance.
- ASM works on all major operating systems so it is platform independent.
- SAP now supports Oracle ASM.
- Finally, EMC fully supports ASM including various tooling that integrate with Oracle (such as Replication Manager, and backup and reporting tools).
Disadvantages? A few, maybe. Biggest disadvantages that I have identified:
- Migration from legacy filesystems to ASM can be a problem and often requires an outage
- 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
- Backup cannot be done with traditional methods that just backup OS files so you need integrated tooling or use Oracle’s native tools (RMAN)
