to bypass the OS overhead,
to simplify Oracle data management,
to enforce the SAME (Stripe And Mirror Everywhere, RAID10), and
to provide a platform for file sharing in RAC and Grid computing.
Automatic Storage Management (ASM) is a new type of file system. ASM provided a foundation
for highly efficient storage management with kernelized asynchronous I/O, direct I/O,
redundancy, striping, and an easy way to manage storage. ASM is recommended file system
for RAC and single instance ASM for storing database files. This provides direct I/O to the file
and performance is comparable with that provided by raw devices. Oracle creates a separate
instance for this purpose.
ASM includes volume management functionality similar to that of a generic logical volume
manager. Automatic Storage Management (ASM) will take physical disk partitions and manages
their contents in a way that efficiently supports the files needed to create an Oracle database.
Automatic Storage Management (ASM) simplifies administration of Oracle related files by
allowing the administrator to reference diskgroups rather than hundreds of individual disks
and files, which are managed by ASM. The ASM functionality is an extension of the Oracle
Managed Files (OMF) functionality that also includes striping and mirroring to provide balanced
and secure storage. The ASM functionality can be used in combination with existing raw and
cooked file systems, along with OMF and manually managed files.
Before ASM, there were only two choices: file system storage and raw disk storage. File system
storage is flexible, allowing the DBA to see the individual files and to move them, copy them,
and back them up easily, but it also incurs overhead. Raw disk storage has no file directories
on it, and Oracle manages its blocks directly, which makes it more efficient. Raw disk storage
is such a manageability nightmare that few DBAs use it.
ASM is the middle ground. It's raw disk storage managed by Oracle, and it is very efficient.
Oracle uses a scaled down Oracle instance to simulate a file structure on it where none exists,
by recording all the metadata. The metadata enables the Recovery Manager (RMAN) to backup
and restore Oracle files easily within it.
Setting up storage takes a significant amount of time during most database installations.
Zeroing on a specific disk configuration from among the multiple possibilities requires careful
planning and analysis, and most important, intimate knowledge of storage technology, volume
managers, and file systems. The design tasks at this stage can be loosely described as follows:
- Confirm that storage is recognized at the OS level and determine the level of redundancy protection that might already be provided (hardware RAID, called external redundancy in ASM).
- Assemble and build logical volume groups and determine if striping or mirroring is also necessary.
- Build a file system on the logical volumes created by the logical volume manager.
- Set the ownership and privileges so that the Oracle process can open, read, and write to the devices.
- Create a database on that file system while taking care to create special files such as redo logs, temporary tablespaces, and undo tablespaces in non-RAID locations, if possible.
All above tasks, striping, mirroring, logical file system building, are done to serve Oracle database. Oracle database offers some techniques of its own to simplify or enhance the process. Lets DBAs execute many of the above tasks completely within the Oracle framework. Using ASM you can transform a bunch of disks to a highly scalable and performance file system/volume manager using nothing more than what comes with Oracle database software at no extra cost and you don't need to be an expert in disk, volume managers, or file system management.
You can store the following file types in ASM diskgroups:
- Datafiles
- Control files
- Online redo logs
- Archive logs
- Flashback logs
- SPFILEs
- RMAN backups
- Temporary datafiles
- Datafile copies
- Disaster recovery configurations
- Change tracking bitmaps
- Datapump dumpsets
In summary, ASM provides the following functionality/features:
- Manages groups of disks, called diskgroups. Must be careful while choosing disks for a diskgroup.
- Manages disk redundancy within a diskgroup.
- Provides near-optimal I/O balancing without any manual tuning.
- Enables management of database objects without specifying mount points and filenames.
- Supports large files.
- Replacement for CFS (Cluster File System).
- Also useful for Non-RAC databases.
- A new instance type - ASM is introduced in 10g.
- ASM instance has no data dictionary.
- A Disk can be a partial, full or a LUN from the RG.
- I/O is spread evenly across all disks of a diskgroup.
- Disks can be dynamically added to any diskgroup.
- When combined with OMF increases manageability.
- ASM cannot maintain empty directories “delete input” has issues, create a dummy directory.
- Use of ASM diskgroup is very simple create tablespace.
- Enterprise Manager can also be used for administering diskgroups
- Only RMAN can be used with ASM.
- Introduces three additional Oracle background processes – RBAL, ARBx and ASMB.
- ASMB - This ASMB process is used to provide information to and from cluster synchronization services used by ASM to manage the disk resources. It's also used to update statistics and provide a heart beat mechanism.
- Re-Balance, RBAL - RBAL is the ASM related process that performs rebalancing of disk resources controlled by ASM.
- Actual Rebalance, ARBx - ARBx is configured by ASM_POWER_LIMIT.
- ASM instance has it own set of v$views and init.ora parameters.
The advantages of ASM are
- Disk Addition - Adding a disk is very easy. No downtime is required and file extents are redistributed automatically.
- I/O Distribution - I/O is spread over all the available disks automatically, without manual intervention, reducing chances of a hot spot.
- Stripe Width - Striping can be fine grained as in redolog files (128K for faster transfer rate) and coarse for datafiles (1MB for transfer of a large number of blocks at one time).
- Mirroring - Software mirroring can be set up easily, if hardware mirroring is not available.
- Buffering - The ASM file system is not buffered, making it direct I/O capable by design.
- Kernelized Asynchronous I/O - There is no special setup necessary to enable kernelized asynchronous I/O, without using raw or third-party file systems such as Veritas Quick I/O.
The ASM functionality is controlled by an ASM instance. This is a special instance, not a database where users can create objects, just the memory structures and as such is very small and lightweight.
With ASM, you don't have to create anything on the OS side; the feature will group a set of physical disks to a logical entity known as a diskgroup. A diskgroup is analogous to a striped and optionally mirrored, file system, with important differences: it's not a general-purpose file system for storing user files and it's not buffered. Diskgroup offers the advantage of direct access to this space as a raw device, yet provides the convenience and flexibility of a file system. All the metadata about the disks are stored in the diskgroups themselves, making them as self-describing as possible.
This special ASM instance is similar to other file systems in that it must be running for ASM to work and can't be modified by the user. One ASM instance can serve number of Oracle databases. ASM instance and database instances have to be present on same server. Otherwise it will not work.
Logical volume managers typically use a function, such as hashing, to map the logical address of the blocks to the physical blocks. This computation uses CPU cycles. When a new disk is added, this typical striping function requires each bit of the entire data set to be relocated. In contrast, ASM uses this special instance to address the mapping of the file extents to the physical disk blocks. This design, in addition to being fast in locating the file extents, helps while adding or removing disks because the locations of file extents need not be coordinated.
You should start the instance up when the server is booted i.e. it should be started before the database instances, and it should be one of the last things stopped when the server is shutdown. From 11.2.0, we can use ASMCMD to start and stop the ASM instances.
The initialization parameters that are specific to an ASM instance are:
- INSTANCE_TYPE - Set to ASM. The default is RDBMS.
- ASM_DISKGROUPS - The list of diskgroups that should be mounted by an ASM instance during instance startup, or by the ALTER DISKGROUP ALL MOUNT statement. ASM configuration changes are automatically reflected in this parameter.
- ASM_DISKSTRING - Specifies a value that can be used to limit the disks considered for discovery. The default value is NULL allowing all suitable disks to be considered. Altering the default value may improve the speed of diskgroup mount time and the speed of adding a disk to a diskgroup. Changing the parameter to a value which prevents the discovery of already mounted disks results in an error.
- ASM_POWER_LIMIT -The maximum power for a rebalancing operation on an ASM instance. The valid values range from 1 (default) to 11. The higher the limit the more resources are allocated resulting in faster rebalancing operations. This value is also used as the default when the POWER clause is omitted from a rebalance operation. A value of 0 disables rebalancing.
- ASM_PREFERRED_READ_FAILURE_GROUPS - This initialization parameter value (default is NULL) is a comma-delimited list of strings that specifies the failure groups that should be preferentially read by the given instance. This parameter is generally used only for clustered ASM instances and its value can be different on different nodes. This is from Oracle 11g.
- DB_UNIQUE_NAME - Specifies a globally unique name for the database. This defaults to +ASM but must be altered if you intend to run multiple ASM instances.
To create an ASM instance first create pfile, init+ASM.ora, in the /tmp directory, containing the following parameter.
INSTANCE_TYPE = ASM
Next, connect to the ideal instance.
$ export ORACLE_SID=+ASM
SQL> sqlplus "/as sysdba"
Create a spfile using the contents of the init+ASM.ora file.
SQL> CREATE SPFILE FROM PFILE='/tmp/init+ASM.ora';
SQL> startup nomount
ASM instance started
Total System Global Area 130023424 bytes
Fixed Size 2028368 bytes
Variable Size 102829232 bytes
ASM Cache 25165824 bytes
The ASM instance is now ready to use for creating and mounting diskgroups.
Once an ASM instance is present, diskgroups can be used for the following parameters in database instances (INSTANCE_TYPE=RDBMS) to allow ASM file creation:
- CONTROL_FILES
- DB_CREATE_FILE_DEST
- DB_CREATE_ONLINE_LOG_DEST_n
- DB_RECOVERY_FILE_DEST
- LOG_ARCHIVE_DEST_n
- LOG_ARCHIVE_DEST
- STANDBY_ARCHIVE_DEST
The options for the STARTUP command are:
- NOMOUNT - Starts the ASM instance without mounting any diskgroups.
- MOUNT - Starts the ASM instance and mounts the diskgroups specified by the ASM_DISKGROUPS parameter.
- OPEN - ASM instance does not have open stage.
- FORCE - Performs a SHUTDOWN ABORT before restarting the ASM instance.
ASMCMD equivalent for this command is startup (11g R2 command).
Shutdown of ASM Instances
The options for the SHUTDOWN command are:
- NORMAL - The ASM instance waits for all connected ASM instances and SQL sessions to exit then shuts down.
- IMMEDIATE - The ASM instance waits for any SQL transactions to complete then shuts down. It doesn't wait for sessions to exit.
- TRANSACTIONAL - Same as IMMEDIATE.
- ABORT - The ASM instance shuts down instantly.
The main components of ASM are diskgroups, each of which comprise of several physical disks that are controlled as a single unit. The physical disks are known as ASM disks, while the files that reside on the disks are known as ASM files. The locations and names for the files are controlled by ASM, but user-friendly aliases and directory structures can be defined for ease of reference.
Diskgroup is a terminology used for logical structure which holds the database files. Each diskgroup consists of disks/raw devices where the files are actually stored. Any ASM file (and it's redundant copy) is completely contained within a single diskgroup. A diskgroup might contain files belonging to several databases and a single database can use files from multiple diskgroups.
In the initial release of Oracle 10g, ASM diskgroups were a black box. We had to manipulate ASM diskgroups with SQL statements while logged in to the special ASM instance that manages the diskgroups.
In Oracle 10g Release 2, Oracle introduced a new command line tool called ASMCMD that lets you look inside ASM volumes (which are called diskgroups). Now you can do many tasks from the command line.
While creating a diskgroup, we have to specify an ASM diskgroup type based on one of the following three redundancy levels:
- Normal redundancy - for 2-way mirroring, requiring two failure groups, when ASM allocates an extent for a normal redundancy file, ASM allocates a primary copy and a secondary copy. ASM chooses the disk on which to store the secondary copy in a different failure group other than the primary copy.
- High redundancy - for 3-way mirroring, requiring three failure groups, in this case the extent is mirrored across 3 disks.
- External redundancy - to not use ASM mirroring. This is used if you are using hardware mirroring or third party redundancy mechanism like RAID, Storage arrays.
ASM is supposed to stripe the data and also mirror the data (if using Normal, High redundancy). So this can be used as an alternative for RAID (Redundant Array of Inexpensive Disks) 0+1 solutions.
No, we cannot modify the redundancy for diskgroup once it has been created. To alter it we will be required to create a new diskgroup and move the files to it. This can also be done by restoring full backup on the new diskgroup.
Failure groups are defined within a diskgroup to support the required level of redundancy, using normal/high redundancy. They contain the mirrored ASM extents and must be containing different disks and preferably on separate disk controller.
In addition failure groups and preferred names for disks can be defined in CREATE DISKGROUP statement. If the NAME clause is omitted the disks are given a system generated name like "disk_group_1_0001". The FORCE option can be used to move a disk from another diskgroup into this one.
SQL> CREATE DISKGROUP dg_asm_data NORMAL REDUNDANCY
FAILGROUP failure_group_1 DISK
'/devices/diska1' NAME diska1, '/devices/diska2' NAME diska2,
FAILGROUP failure_group_2 DISK
'/devices/diskb1' NAME diskb1, '/devices/diskb2' NAME diskb2;
For two-way mirroring we would expect a diskgroup to contain two failure groups, so individual files are written to two locations.
SQL> CREATE DISKGROUP dg_asm_fra HIGH REDUNDANCY
FAILGROUP failure_group_1 DISK
'/devices/diska1' NAME diska1, '/devices/diska2' NAME diska2,
FAILGROUP failure_group_2 DISK
'/devices/diskb1' NAME diskb1, '/devices/diskb2' NAME diskb2,
FAILGROUP failure_group_3 DISK
'/devices/diskc1' NAME diskc1, '/devices/diskc2' NAME diskc2;
For three-way mirroring we would expect a diskgroup to contain three failure groups, so individual files are written to three locations.
SQL> CREATE DISKGROUP dg_grp1 EXTERNAL REDUNDANCY
DISK '/dev/d1','/dev/d2','/dev/d3','/dev/d4' ... ...;
In the above command, database will create a diskgroup named dg_grp1 with the physical disks named /dev/d1, /dev/d2, and so on. Instead of giving disks separately, we can also specify disk names in wildcards in the DISK clause as DISK '/dev/d*'.
We have also specified a clause EXTERNAL REDUNDANCY, which indicates that the failure of a disk will bring down the diskgroup. This is usually the case when the redundancy is provided by the hardware, such as mirroring. If there is no hardware based redundancy, the ASM can be set up to create a special set of disks called failgroup in the diskgroup to provide that redundancy.
SQL> CREATE DISKGROUP dskgrp1 NORMAL REDUNDANCY
FAILGROUP failgrp1 DISK '/dev/d1','/dev/d2',
FAILGROUP failgrp2 DISK '/dev/d3','/dev/d4';
Although it may appear as such, d3 and d4 are not mirrors of d1 and d2. Rather, ASM uses all the disks to create a fault-tolerant system. For example, a file on the diskgroup might be created in d1 with a copy maintained on d4. A second file may be created on d3 with copy on d2, and so on. That is, primary copy will be on one failure group and secondary copy will be another (third copy will be another, for high redundancy).
Failure of a specific disk allows a copy on another disk so that the operation can continue. For example, you could lose the controller for both disks d1 and d2 and ASM would mirror copies of the extents across the failure group to maintain data integrity.
SQL> CREATE DISKGROUP dg1 DISK '/dev/raw/*'
ATTRIBUTE 'compatible.rdbms' = '11.1', 'compatible.asm' = '11.1'; (11g R1 command)
SQL> CREATE DISKGROUP dg2 EXTERNAL REDUNDANCY
DISK '/dev/sde1' ATRRIBUTE 'au_size' = '32M'; (11g R1 command)
SQL> CREATE DISKGROUP archdg NORMAL REDUNDANCY
FAILGROUP fg1 DISK
'/devices/diska1','/devices/diska2','/devices/diska3','/devices/diska4'
FAILGROUP fg2 DISK
'/devices/diskb1','/devices/diskb2','/devices/diskb3','/devices/diskb4'
ATTRIBUTE 'au_size'='4M','compatible.asm'='11.2','compatible.rdbms'='11.2','compatible.advm'='11.2'; (11g R2command)
To find out all the diskgroups:
SQL> SELECT * FROM V$ASM_DISKGROUP;
Diskgroups can be deleted using the DROP DISKGROUP statement.
SQL> DROP DISKGROUP disk_group_1 INCLUDING CONTENTS;
SQL> DROP DISKGROUP disk_group_1 FORCE; (11g R1 command)
SQL> DROP DISKGROUP disk_group_1 FORCE INCLUDING CONTENTS; (11gR1 command)
Disks can be added or removed from diskgroups using the ALTER DISKGROUP statement. Remember that the wildcard "*" can be used to reference disks so long as the resulting string does not match a disk already used by an existing diskgroup.
We may have to add additional disks into the diskgroup to accommodate growing demand.
SQL> ALTER DISKGROUP dskgrp1 ADD DISK '/dev/d5';
SQL> ALTER DISKGROUP dg1 ADD DISK '/devices/disk*3', '/devices/disk*4';
The following command shows all the disks managed by the ASM instance for all the client databases.
SQL> SELECT * FROM V$ASM_DISK;
ASMCMD equivalent for this command is lsdsk (11g R1 command).
The following command shows all the database instances connected to the ASM instance.
SQL> SELECT * FROM V$ASM_CLIENT;
We can remove a disk from diskgroup.
SQL> ALTER DISKGROUP dg4 DROP DISK diska4;
ASMCMD equivalent for this command is chdg (11g R2 command).
Disks can be resized using the RESIZE clause of the ALTER DISKGROUP statement. The statement can be used to resize individual disks, all disks in a failure group or all disks in the diskgroup. If the SIZE clause is omitted the disks are resized to the size of the disk returned by the OS.
SQL> ALTER DISKGROUP dg_data_1 RESIZE DISK diska1 SIZE 150G;
Resizing all disks in a failure group
SQL> ALTER DISKGROUP dg_data_1 RESIZE DISKS IN FAILGROUP fg_1 SIZE 50G;
Resizing all disks in a diskgroup
SQL> ALTER DISKGROUP dg_data_1 RESIZE ALL SIZE 100G;
Undropping disks
The UNDROP DISKS clause of the ALTER DISKGROUP statement allows pending disk drops to be undone. It will not revert drops that have completed, or disk drops associated with the dropping of a diskgroup.
SQL> ALTER DISKGROUP disk_group_1 UNDROP DISKS;
SQL> ALTER DISKGROUP data ONLINE DISK 'disk_0000', 'disk_0001';
SQL> ALTER DISKGROUP data ONLINE DISKS IN FAILGROUP 'fg_99';
SQL> ALTER DISKGROUP data ONLINE ALL;
ASMCMD equivalent for this command is online (11gR2 command).
Offline disks
SQL> ALTER DISKGROUP data OFFLINE DISK 'disk_0000', 'disk_0001';
SQL> ALTER DISKGROUP data OFFLINE DISKS IN FAILGROUP 'fg_99';
SQL> ALTER DISKGROUP data OFFLINE DISK d1_0001 DROP AFTER 30m;
Diskgroups are mounted at ASM instance startup and unmounted at ASM instance shutdown. Manual mounting and dismounting can be accomplished using the ALTER DISKGROUP statement as below.
SQL> ALTER DISKGROUP ALL MOUNT;
SQL> ALTER DISKGROUP dg_data2 MOUNT;
SQL> ALTER DISKGROUP dg_data2 MOUNT RESTRICTED; (11gR1 command)
ASMCMD equivalent for this command is mount (11gR2 command).
Dismounting diskgroups
SQL> ALTER DISKGROUP ALL DISMOUNT;
SQL> ALTER DISKGROUP dg_fra DISMOUNT;
ASMCMD equivalent for this command is umount (11gR2 command).
SQL> ALTER DISKGROUP data3 SET ATTRIBUTE 'compatible.rdbms' = '11.1'; (11gR1 command)
SQL> ALTER DISKGROUP data3 SET ATTRIBUTE 'compatible.asm' = '11.2';
SQL> ALTER DISKGROUP data3 SET ATTRIBUTE 'disk_repair_time' = '4.5h'; (11gR1 command)
ASMCMD equivalent for this command is setattr (11gR2 command).
Listing attributes
SQL> SELECT * FROM V$ASM_ATTRIBUTE;
ASMCMD equivalent for this command is lsattr (11gR2 command).
Diskgroups can be rebalanced manually using the REBALANCE clause of the ALTER DISKGROUP statement. If the POWER clause is omitted the ASM_POWER_LIMIT parameter value is used. Rebalancing is only needed when the speed of the automatic rebalancing is not appropriate.
SQL> ALTER DISKGROUP disk_group_1 REBALANCE POWER 6;
ASMCMD equivalent for this command is rebal (11gR2 command).
IO statistics of a diskgroup
SQL> SELECT * FROM V$ASM_DISK_IOSTAT;
Until 11.1.0, all the above commands can not be performed with ASMCMD. From 11.2.0, we can.
Directories
As in other file systems, an ASM directory is a container for files, and an ASM directory can be part of a tree structure of other directories. The fully qualified filename represents a hierarchy of directories in which the plus sign (+) represent the root directory. In each diskgroup, ASM automatically creates a directory hierarchy that corresponds to the structure of the fully qualified filenames in the diskgroup. The directories in this hierarchy are known as system-generated directories.
An absolute path refers to the full path of a file or directory. An absolute path begins with a plus sign (+) followed by a diskgroup name, followed by subsequent directories in the directory tree. The absolute path includes directories until the file or directory is reached. A fully qualified filename is an example of an absolute path to a file. A relative path includes only the part of the filename or directory name that is not part of the current directory. That is, the path to the file or directory is relative to the current directory.
A directory hierarchy can be defined using the ALTER DISKGROUP statement to support ASM file aliasing.
SQL> ALTER DISKGROUP dg_1 ADD DIRECTORY '+dg_1/my_dir';
SQL> ALTER DISKGROUP dg_1 RENAME DIRECTORY '+dg_1/my_dir' TO '+dg_1/my_dir_2';
SQL> ALTER DISKGROUP dg_1 DROP DIRECTORY '+dg_1/my_dir_2' FORCE;
ASMCMD equivalent for this command is rm.
Files
There are several ways to reference ASM files. Some forms are used during creation and some for referencing ASM files. Every file created in ASM gets a system-generated filename, known as fully qualified filename, this is same as complete path name in a local file system.
The forms of the ASM filenames are:
| Filename Type | Format
|
|---|
| Fully Qualified ASM Filename | +dgroup/dbname/file_type/ file_type_tag.file.incarnation
|
| Numeric ASM Filename | +dgroup.file.incarnation
|
| Alias ASM Filenames | +dgroup/directory/filename
|
| Alias ASM Filename with Template | +dgroup(template)/alias
|
| Incomplete ASM Filename | +dgroup
|
| Incomplete ASM Filename with Template | +dgroup(template) |
ASM generates filenames according to the following scheme:
+diskGroupName/databaseName/fileType/fileTypeTag.fileNumber.incarnation
e.g: +dgroup2/crm/CONTROLFILE/Current.256.541956473
+dg_fra/hrms/DATAFILE/users.309.621906475
ASM does not place system-generated files into user-created directories; it places them only in system-generated directories. We can add aliases or other directories to a user-created directory.
Dropping Files
Files are not deleted automatically if they are created using aliases, as they are not Oracle Managed Files (OMF), or if a recovery is done to a point-in-time before the file was created. For these circumstances it is necessary to manually delete the files, as shown below.
Dropping file using an alias
SQL> ALTER DISKGROUP dg_2 DROP FILE '+dg_2/my_dir/my_file.dbf';
Dropping file using a numeric form filename
SQL> ALTER DISKGROUP dg_2 DROP FILE '+dg_2.321.123456789';
Dropping file using a fully qualified filename
SQL> ALTER DISKGROUP dg_2 DROP FILE '+dg_2/mydb/datafile/my_ts.292.265390671';
ASMCMD equivalent for this command is rm.
Aliases
Aliases allow you to reference ASM files using user-friendly names, rather than the fully qualified ASM filenames.
Creating an alias, using the fully qualified filename
SQL> ALTER DISKGROUP dg_3 ADD ALIAS '+dg_3/my_dir/users.dbf' FOR '+dg_3/mydb/datafile/users.392.333222555';
Creating an alias, using the numeric form filename
SQL> ALTER DISKGROUP dg_3 ADD ALIAS '+dg_3/my_dir/my_file.dbf' FOR '+dg_3.317.111222333';
SQL> ALTER DISKGROUP dg_3 RENAME ALIAS '+dg_3/my_dir/my_file.dbf' TO '+dg_3/my_dir/my_file2.dbf';
SQL> ALTER DISKGROUP dg_3 DELETE ALIAS '+dg_3/my_dir/my_file.dbf';
Attempting to drop a system alias results in an error.
Templates
Templates are named groups of attributes that can be applied to the files within a diskgroup. The level of redundancy and the granularity of the striping can be controlled using templates. Default templates are provided for each file type stored by ASM, but additional templates can be defined as needed.
Available attributes are:
- UNPROTECTED - No mirroring or striping regardless of the redundancy setting.
- MIRROR - Two-way mirroring for normal redundancy and three-way mirroring for high redundancy.
- COARSE - Specifies lower granularity for striping.
- FINE - Specifies higher granularity for striping.
MIRROR, COARSE, FINE attributes are cannot be set for external redundancy.
SQL> ALTER DISKGROUP dg_4 ADD TEMPLATE mf_template ATTRIBUTES (MIRROR FINE);
SQL> ALTER DISKGROUP dg_4 ALTER TEMPLATE c_template ATTRIBUTES (COARSE);
ASMCMD equivalent for this command is chtmpl (11gR2 command).
Listing templates
SQL> SELECT * FROM V$ASM_TEMPLATE;
ASMCMD equivalent for this command is lstmpl (11gR2 command).
SQL> ALTER DISKGROUP dg_4 DROP TEMPLATE u_template;
The internal consistency of diskgroup metadata can be checked in a number of ways using the CHECK clause of the ALTER DISKGROUP statement.
Checking metadata for a specific file
SQL> ALTER DISKGROUP dg_5 CHECK FILE '+dg_5/my_dir/my_file.dbf'
Checking metadata for a specific disk in the diskgroup
SQL> ALTER DISKGROUP dg_5 CHECK DISK diska1;
Checking metadata for a specific failure group in the diskgroup
SQL> ALTER DISKGROUP dg_5 CHECK FAILGROUP failure_group_1;
Checking metadata for all disks in the diskgroup
SQL> ALTER DISKGROUP dg_5 CHECK ALL;
SQL> ALTER DISKGROUP dg_5 CHECK;
SQL> ALTER DISKGROUP dg_5 CHECK NOREPAIR;
SQL> ALTER DISKGROUP dg_5 CHECK REPAIR;
ASMCMD equivalent for this command is chkdg (11gR2 command).
User Management
From Oracle 11g release 2, we can create ASM users and usergroups and manipulate the permissions and ownership of files.
Creating an ASM usergroup
SQL> ALTER DISKGROUP data_dg ADD USERGROUP 'grp1';
SQL> ALTER DISKGROUP data_dg ADD USERGROUP 'grp2' WITH MEMBER 'oracle1','oracle2';
ASMCMD equivalent for this command is mkgrp (11gR2 command).
Listing ASM usergroups
To find out the list of ASM usergroups.
SQL> SELECT * FROM V$ASM_USERGROUP;
ASMCMD equivalent for this command is lsgrp (11gR2 command).
Dropping an ASM usergroup
SQL> ALTER DISKGROUP data_dg DROP USERGROUP 'grp1';
ASMCMD equivalent for this command is rmgrp (11gR2 command).
Modifying(adding/deleting ASM users to/from) an ASM usergroup
SQL> ALTER DISKGROUP data_dg MODIFY USERGROUP 'grp2' ADD MEMBER 'oracle3';
SQL> ALTER DISKGROUP data_dg MODIFY USERGROUP 'grp2' DROP MEMBER 'oracle3';
ASMCMD equivalent for this command is grpmod (11gR2 command).
Creating an ASM user
SQL> ALTER DISKGROUP data_dg ADD USER 'oracle1';
ASMCMD equivalent for this command is mkusr (11gR2 command).
Listing ASM users
To find out the list of ASM users.
SQL> SELECT * FROM V$ASM_USER;
ASMCMD equivalent for this command is lsusr (11gR2 command).
Listing ASM usergroups to which user belongs
SQL> SELECT * FROM V$ASM_USERGROUP_MEMBER;
ASMCMD equivalent for this command is groups (11gR2 command).
Dropping an ASM user
SQL> ALTER DISKGROUP data_dg DROP USER 'oracle1';
ASMCMD equivalent for this command is rmusr (11gR2 command).
Modifying permissions for a file
SQL> ALTER DISKGROUP data_dg SET PERMISSION OWNER=read write, GROUP=read only, OTHER=none FOR FILE '+data_dg/controlfile.f';
ASMCMD equivalent for this command is chmod (11gR2 command).
Modifying ownership of a file
SQL> ALTER DISKGROUP data_dg SET OWNERSHIP OWNER='oracle1', GROUP='grp1' FOR FILE '+data_dg/controlfile.f';
ASMCMD equivalent for this command is chown (11gR2 command).
Volume Management
From 11g release 2, we can create Oracle ASM Dynamic Volume Manager (Oracle ADVM) volumes in a diskgroups. The volume device associated with the dynamic volume can then be used to host an (Oracle ACFS) file system.
Creating a volume
SQL> ALTER DISKGROUP data_dg ADD VOLUME volume1 SIZE 20G;
ASMCMD equivalent for this command is volcreate (11gR2 command).
Listing volume information
To find out the volumes information.
SQL> SELECT * FROM V$ASM_VOLUME;
ASMCMD equivalent for this command is volinfo (11gR2 command).
Listing volume statistics
To find out the volumes statistics information.
SQL> SELECT * FROM V$ASM_VOLUME_STAT;
ASMCMD equivalent for this command is volstat (11gR2 command).
Dropping a volume
SQL> ALTER DISKGROUP data_dg DROP VOLUME volume1;
ASMCMD equivalent for this command is voldelete (11gR2 command).
Resizing a volume
SQL> ALTER DISKGROUP fra_dg RESIZE VOLUME volume1 SIZE 25G;
ASMCMD equivalent for this command is volresize (11gR2 command).
Disabling a volume
SQL> ALTER DISKGROUP redo_dg DISABLE VOLUME volume1;
SQL> ALTER DISKGROUP ALL DISABLE VOLUME ALL;
ASMCMD equivalent for this command is voldisable (11gR2 command).
Enabling a volume
SQL> ALTER DISKGROUP arch_dg ENABLE VOLUME volume1;
ASMCMD equivalent for this command is volenable (11gR2 command).
Setting a volume
SQL> ALTER DISKGROUP asm_dg_data MODIFY VOLUME volume1 USAGE 'acfs';
ASMCMD equivalent for this command is volset (11gR2 command).
Misc
Listing the current operations
SQL> SELECT * FROM V$ASM_OPERATION;
ASMCMD equivalent for this command is lsop (11gR2 command).
Creating Tablespaces
Now create a tablespace in the main database using a datafile in the ASM-enabled storage.
SQL> CREATE TABLESPACE user_data DATAFILE '+dskgrp1/user_data_01'
SIZE 1024M;
ASM filenames can be used in place of conventional filenames for most Oracle file types, including controlfiles, datafiles, logfiles etc. For example, the following command creates a new tablespace with a datafile in the disk_group_1 diskgroup.
SQL> CREATE TABLESPACE my_ts DATAFILE '+disk_group_1' SIZE 100M AUTOEXTEND ON;
Note how the diskgroup is used as a virtual file system. This approach is useful not only in datafiles, but in other types of Oracle files as well. For instance, we can create online redo log files as
...
LOGFILE GROUP 1 (
'+dskgrp1/redo/group_1.258.659723485',
'+dskgrp2/redo/group_1.258.659723485'
) SIZE 50M,
...
Archived log destinations can also be set to a diskgroup. Everything related to Oracle database can be created in an ASM diskgroup. Backup is another great use of ASM. You can set up a bunch of inexpensive disks to create the recovery area of a database, which can be used by RMAN to create backup datafiles and archived log files.
ASM supports files created by and read by the Oracle database only; it is not a replacement for a general-purpose file system.
Until Oracle 11g release1, we cannot store binaries or flat files. We cannot use ASM for storing the voting disk and OCR. It is due to the fact that Clusterware starts before ASM instance and it should be able to access these files which are not possible if you are storing it on ASM. You will have to use raw devices or OCFS or any other shared storage. But from 11g release 2, we can store ALL files on ASM.
Can we see the files stored in the ASM instance using standard Unix commands?
No, you cannot see the files using standard Unix commands like ls. You need to use utility called asmcmd to do this.Oracle 10g release2 introduces asmcmd which makes administration very easy.
$ asmcmd
ASMCMD>
ASMLIB is the support library for the ASM. ASMLIB allows an Oracle database using ASM more efficient and capable access to diskgroups. The purpose of ASMLIB, is to provide an alternative interface to identify and access block devices. ASMLIB API enables storage and OS vendors to supply extended storage-related features.
Migrating to ASM using RMAN
The following method shows how a database can be migrated to ASM from a disk based backup:
1) Shutdown the database.
SQL> SHUTDOWN IMMEDIATE
2) Modify the parameter file of the database as follows:
Set DB_CREATE_FILE_DEST and DB_CREATE_ONLINE_LOG_DEST_n parameters to the relevant ASM diskgroups.
3) Remove CONTROL_FILES parameter from the spfile so the control files will be moved to the DB_CREATE_* destination and the spfile gets updated automatically. If you are using a pfile the CONTROL_FILES parameter must be set to the appropriate ASM files or aliases.
4) Start the database in nomount mode.
RMAN> STARTUP NOMOUNT
5) Restore the controlfile into the new location from the old location.
RMAN> RESTORE CONTROLFILE FROM 'old_control_file_name';
6) Mount the database.
RMAN> ALTER DATABASE MOUNT;
7) Copy the database into the ASM diskgroup.
RMAN> BACKUP AS COPY DATABASE FORMAT '+disk_group';
8) Switch all datafile to the new ASM location.
RMAN> SWITCH DATABASE TO COPY;
9) Open the database.
RMAN> ALTER DATABASE OPEN;
10) Create new redo logs in ASM and delete the old ones.
- Support for rolling upgrades.
- We can maintain version compatibilites at diskgroup level.
SQL> alter diskgroup dg-name set attribute 'compatible.rdbms'='11.1';
SQL> alter diskgroup dg-name set attribute 'compatible.asm'='11.1';
- ASM drops disks and if they remain offline for more than 3.6 hours. The diskgroups default time limit is altered by changing the DISK_REPAIR_TIME parameter with a unit of minutes(M/m) or hours(H/h).
SQL> alter diskgroup dg-name set attribute 'disk_repair_time'='4.5h';
- Automatic bad block detection and repair.
- Supports variable extent(allocation unit) sizes. The total number of extents in shared pool will be significantly reduced and improved performance.
SQL> create diskgroup ... attribute 'au_size' = 'number-of-bytes';
- New SYSASM role (like SYSDBA, SYSOPER) & OSASM OS group (like OSDBA, OSOPER) to manage ASM instance only. This will separate storage administration from database administration.
$ sqlplus "/as sysasm" or $ asmcmd -a sysasm
- ASM Preferred Mirror Read or Preferred Read Failure Groups - ASM_PREFERRED_READ_FAILURE_GROUPS parameter is set to the preferred failure groups for each node.
- Faster Mirror Resync - Fast mirror resync after temporary connectivity lost.
- We can drop a diskgroup forcefully.
SQL> drop diskgroup dg-name force including contents;
- Can mount the disk in restricted mode, to rebalance faster.
SQL> alter diskgroup dg-name mount restricted;
- New commands in ASMCMD.
- cp - to copy between ASM and local or remote destination.
- md_backup - to backup metadata.
- md_restore - to restore metadata.
- lsdsk - to list(check) disks.
- remap - to repair a range of physical blocks on disk.
- ASM Configuration Assistant (ASMCA) is a new tool to install and configure ASM.
- ASM Cluster File System (ACFS) provides support for files such as Oracle binaries, Clusterware binaries, report files, trace files, alert logs, external files, and other application datafiles. ACFS can be managed by ACFSUTIL, ASMCMD, OEM, ASMCA, SQL command interface.
- ASM Dynamic Volume Manager (ADVM) provides volume management services and a standard device driver interface to its clients (ACFS, ext3, OCFS2 and third party files systems).
- ACFS Snapshots are read-only on-line, space efficient, point in time copy of an ACFS file system. ACFS snapshots can be used to recover from inadvertent modification or deletion of files from a file system.
- ASM can hold and manage OCR (Oracle Cluster Registry) file and voting file.
- ASM diskgroups can be renamed, by using renamedg command.
- ASMCMD utility can do
- startup and shutdown of ASM instances.
- Managing diskgroups (create, mount, alter, drop).
- File access control (like OS, ugo and rwx ...).
- User management.
- Template management.
- Volume management.
- We can execute OS commands at asmcmd by using !, in the same we do at SQL prompt.
ASM New features in Oracle Clusterware 12c
1. Oracle Flex ASM - This feature of Oracle Clusterware 12c claims to reduce per-node overhead of using ASM instance. Now the instances can use remote node ASM for any planned/unplanned downtime. ASM metadata requests can be converted by non-local instance of ASM.
2. ASM Disk Scrubbing - From RAC 12c, ASM comes with disk scrubbing feature so that logical corruptions can be discovered. Also Oracle 12c ASM can automatically correct this in normal or high redundancy diskgroups.
3. Oracle ASM Disk Resync & Rebalance enhancements.
ASM Views
The ASM configuration can be viewed using the V$ASM_% views, which contain information depending on whether they are queried from the ASM instance, or a dependant database instance.
| View | In ASM instance | In DB instance
|
|---|
| V$ASM_ALIAS | Displays a row for each alias present in every diskgroup mounted by the ASM instance. | Returns no rows.
|
| V$ASM_ATTRIBUTE (11gR2) | Displays attributes of diskgroups. | Displays attributes of diskgroups. |
| V$ASM_CLIENT | Displays a row for each database instance using a diskgroup managed by the ASM instance. | Displays a row for the ASM instance if the database has open ASM files.
|
| V$ASM_DISK or V$ASM_DISK_STAT | Displays a row for each disk discovered by the ASM instance, including disks which are not part of any diskgroup. | Displays a row for each disk in diskgroups in use by the database instance.
|
| V$ASM_DISK_IOSTAT(11gR2) | Displays IO statistics of disks. | Displays IO statistics of disks. |
| V$ASM_DISKGROUP or V$ASM_DISKGROUP_STAT | Displays a row for each diskgroup discovered by the ASM instance. | Displays a row for each diskgroup mounted by the local ASM instance.
|
| V$ASM_FILE | Displays a row for each file for each diskgroup mounted by the ASM instance. | Displays no rows.
|
| V$ASM_FILESYSTEM (11gR2) | Displays a row for each filesystem for each diskgroup mounted by the ASM instance. | Displays no rows.
|
| V$ASM_OPERATION | Displays a row for each file for each long running operation executing in the ASM instance. | Displays no rows.
|
| V$ASM_TEMPLATE | Displays a row for each template present in each diskgroup mounted by the ASM instance. | Displays a row for each template present in each diskgroup mounted by the ASM instance. |
| V$ASM_USER (11gR2) | Displays a row for each ASM user. | - |
| V$ASM_USERGROUP (11gR2) | Displays a row for each ASM usergroup. | - |
| V$ASM_USERGROUP_MEMBER(11gR2) | Displays ASM usergroups and it's members. | - |
| V$ASM_VOLUME orV$ASM_VOLUME_STAT(11gR2) | Displays a row for each volume. | - |
ASM backup can be taken by spooling the output of the ASM views to text file.
SPOOL asm_views.log
SET ECHO ON
SELECT * FROM V$ASM_ALIAS;
SELECT * FROM V$ASM_ATTRIBUTE;
SELECT * FROM V$ASM_CLIENT;
SELECT * FROM V$ASM_DISK;
SELECT * FROM V$ASM_DISK_IOSTAT;SELECT * FROM V$ASM_DISK_STAT;
SELECT * FROM V$ASM_DISKGROUP;
SELECT * FROM V$ASM_DISKGROUP_STAT;
SELECT * FROM V$ASM_FILE;
SELECT * FROM V$ASM_FILESYSTEM;
SELECT * FROM V$ASM_OPERATION;
SELECT * FROM V$ASM_TEMPLATE;
SELECT * FROM V$ASM_USER;
SELECT * FROM V$ASM_USERGROUP;
SELECT * FROM V$ASM_USERGROUP_MEMBER;
SELECT * FROM V$ASM_VOLUME;
SELECT * FROM V$ASM_VOLUME_STAT;
SPOOL OFF
Source: Internet
In other words:
Automatic storage management (ASM) is a new feature in Oracle Database 10g from oracle . It integrates file system and the Logical Volume Manager (LVM) . In ASM Volume Manager is specifically built for Oracle database files. The ASM can provide management for single SMP machines or across multiple nodes of a cluster for Oracle Real Application Clusters support.
Automatic Storage Management (ASM) simplifies administration of Oracle related files by allowing the administrator to reference disk groups rather than individual disks and files, which are managed by ASM.
Manual I/O tuning can be eliminated while ASM distributes input/output (I/O) load across all available resources to optimize performance while removing the need for manual I/O tuning.
The ASM has the flexibility of maintaining redundant copies of data to provide fault tolerance, or it can be built on top of vendor-supplied reliable storage mechanisms. Data management in ASM is basically done by choosing the desired reliability and performance characteristics for classes of data rather than with human interaction of per-file basis.
Automated storage management gives the time to DBA’s by increasing their ability to manage larger databases and more of them with increased efficiency.
Automatic Storage Management (ASM) is a feature in Oracle Database 10g/11g that provides the database administrator with a simple storage management interface that is consistent across all server and storage platforms. ASM provides the performance of async I/O with the easy management of a file system.
Some of the Key features of ASM
- Stripes files rather than logical volumes
- Enables online disk reconfiguration and dynamic rebalancing
- Provides adjustable rebalancing speed
- Provides file based redundancy
- Supports only Oracle files
- It’s cluster aware
Why ASM ?
Some of the storage management features with ASM include
- Striping
- Mirroring
- Asynchronous I/O
- Direct I/O
- SAME and Load Balancing
- Is automatically installed as part of the base code set
ASM includes striping and mirroring to provide balanced and secure storage. The level of redundancy and the granularity of the striping can be controlled using templates. The new ASM functionality can be used in combination with existing raw and cooked file systems, along with OMF and manually managed files.
Direct I/O
By making use of Direct I/O, higher cache hit ratio can be achieved. Buffered I/O uses most important resources like CPU and memory. In case of buffered I/O Oracle blocks are cached both in the SGA and in the file system buffer cache.
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.
Key Features and Benefits of ASM
The ASM functionality is controlled by an ASM instance.
The main components of ASM are disk groups, each of which comprise of several physical disks that are controlled as a single unit. The physical disks are known as ASM disks, while the files that reside on the disks are know as ASM files.
The ASM divides a file into pieces and spreads them evenly across all the disks. The ASM uses an index technique to track the placement of each piece. Traditional striping techniques use mathematical functions to stripe complete logical volumes. The ASM includes mirroring protection without the need to purchase a third-party Logical Volume Manager. One unique advantage of ASM is that mirroring is applied on file basis, rather than on a volume basis. Therefore, the same disk group can contain a combination of files protected by mirroring, or not protected at all.
The ASM supports data files, log files, control files, archive logs, Recovery Manager (RMAN) backup sets, and other Oracle database file types. The ASM supports Real Application Clusters (RAC) and eliminates the need for a cluster Logical Volume Manager or a cluster file system.
Note:- ASM is shipped with the database and available as part of base code set and there is no need to go through a separate installation in the custom tree installation. It is available in both the Enterprise Edition and Standard Edition installations.
One of the flexible feature of ASM is it does not eliminate any existing database functionality which uses non ASM files. Existing database are able to operate as they always have been. New files may be created as ASM files, while existing ones are administered in the old way or can be migrated to ASM.
In ASM, at the top of the new hierarchy, you can find what are called ASM disk groups. Any single ASM file is contained in only one disk group. However, a disk group may contain files belonging to several databases, and a single database may use storage from multiple disk groups.
ASM files are always spread across all ASM disks in the disk group.
The ASM disks are partitioned in allocation units (AU) of on megabyte each. An AU is the smallest contiguous disk space that ASM allocates. The ASM does not allow physical blocks to split across AUs.
ASM General Architecture
To use ASM, you must start a special instance called an ASM instance before you start your database instance.
ASM instances manage the metadata needed to make ASM files available to ordinary database instances. Both ASM instances and database instances have access to a common set of disks call disk group. Database instances access contents of ASM files directly, communicating with an ASM instance only to get information about the layout of these files.
An ASM instance is like any other database instance except it contains two new background processes. First one coordinates rebalance activity for disk groups and it is called RBAL. The second one performs the actual rebalance activity for AU movements. At any given time there can be many of these, and they are called ARB0, ARB1, and so on. An ASM instance also has most of the same background processes as a ordinary database instance (SMON, PMON, LGWR, and so on.)
Each database instance using ASM has two new background processes called ASMB and RBAL. RABL performs global opens of the disks in the disk groups. At database instance startup, ASMB connects as a foreground process into the ASM instance. All communication between the database and ASM instances is performed via this bridge. This includes physical file changes such as data file creation and deletion. Over this connection, periodic messages are exchanged to update statistics and to verify that both instances are healthy
It is quite possible to cluster ASM instances and run them as RAC, using the existing Global Cache Services (GCS) infrastructure. There is one ASM instance per node on a cluster.
Storage in Oracle Real Application Clusters
Storage for RAC databases must be shared. In other words, datafiles must reside in an Automatic Storage Management (ASM) disk group, on a cluster file system, or on shared raw devices. This must include space for an undo tablespace for each instance if you are using automatic undo management. Additionally, for each instance you must create at least two redo log files that reside on shared storage. Oracle recommends, you can use one shared server parameter file (SPFILE) with instance-specific entries. Or you can use a local file system to store client-side parameter files (PFILEs).
If you do not use ASM, if your platform does not support a cluster file system, or if you do not want to use a cluster file system to store datafiles, then create additional raw devices as described in your platform-specific Oracle Real Application Clusters installation and configuration guide.
Automatic Storage Management in Real Application Clusters
ASM automatically optimizes storage to maximize performance by managing the storage configuration across the disks. ASM does this by evenly distributing the storage load across all of the available storage within your cluster database environment. ASM partitions your total disk space requirements into uniformly sized units across all disks in a disk group. ASM can also automatically mirror data to prevent data loss. Due to these added features, ASM significantly reduces administrative overhead.
As in single-instance Oracle databases, To use ASM in RAC, select ASM as your storage option when you create your database with the Database Configuration Assistant (DBCA).
Note:- using ASM in RAC does not require I/O tuning.
Automatic Storage Management Components in RAC
When you create your database, Oracle creates one ASM instance on each node in your RAC environment if one does not already exist. Each ASM instance has either an SPFILE or PFILE type parameter file.
The shared disk requirement is the only substantial difference between using ASM in a RAC database compared to using it in a single-instance Oracle database. ASM automatically re-balances the storage load after you add or delete a disk or disk group.
In a cluster, each ASM instance manages its node's metadata updates to the disk groups. In addition, each ASM instance coordinates disk group metadata with other nodes in the cluster. As in single-instance Oracle databases, you can use Enterprise Manager, DBCA, SQL*Plus, and the Server Control Utility (SRVCTL) to administer disk groups for ASM in RAC
Automatic Storage Management
ASM automatically optimizes storage to maximize performance by rebalancing the storage configuration across the disks that ASM manages. ASM spreads the storage load across all available storage within your cluster database environment for optimal performance. ASM partitions your total disk space into uniformly sized units across all disks in a disk group.
ASM functionality is controlled by an ASM instance.
The main components of ASM are disk groups, each of which comprise of several physical disks that are controlled as a single unit. The physical disks are known as ASM disks, while the files that reside on the disks are know as ASM files.
