Views Containing Oracle ASM Disk Group Information

Views Containing Oracle ASM Disk Group Information

View	Description
V$ASM_ALIAS	Contains one row for every alias present in every disk group mounted by the Oracle ASM instance.
V$ASM_ATTRIBUTE	Displays one row for each attribute defined. In addition to attributes specified by CREATE DISKGROUP and ALTER DISKGROUP statements, the view may show other attributes that are created automatically. Attributes are only displayed for disk groups where COMPATIBLE.ASM is set to 11.1 or higher.
V$ASM_CLIENT	In an Oracle ASM instance, identifies databases using disk groups managed by the Oracle ASM instance. In a DB instance, contains information about the Oracle ASM instance if the database has any open Oracle ASM files.
V$ASM_DISK	Contains one row for every disk discovered by the Oracle ASM instance, including disks that are not part of any disk group. This view performs disk discovery every time it is queried.
V$ASM_DISK_IOSTAT	Displays information about disk I/O statistics for each Oracle ASM client. In a DB instance, only the rows for that instance are shown.
V$ASM_DISK_STAT	Contains the same columns as V$ASM_DISK, but to reduce overhead, does not perform a discovery when it is queried. It only returns information about any disks that are part of mounted disk groups in the storage system. To see all disks, use V$ASM_DISK instead.
V$ASM_DISKGROUP	Describes a disk group (number, name, size related info, state, and redundancy type). This view performs disk discovery every time it is queried.
V$ASM_DISKGROUP_STAT	Contains the same columns as V$ASM_DISKGROUP, but to reduce overhead, does not perform a discovery when it is queried. It does not return information about any disks that are part of mounted disk groups in the storage system. To see all disks, use V$ASM_DISKGROUP instead.
V$ASM_FILE	Contains one row for every Oracle ASM file in every disk group mounted by the Oracle ASM instance.
V$ASM_OPERATION	In an Oracle ASM instance, contains one row for every active Oracle ASM long running operation executing in the Oracle ASM instance. In a DB instance, contains no rows.
V$ASM_TEMPLATE	Contains one row for every template present in every disk group mounted by the Oracle ASM instance.
V$ASM_USER	Contains the effective operating system user names of connected database instances and names of file owners.
V$ASM_USERGROUP	Contains the creator for each Oracle ASM File Access Control group.
V$ASM_USERGROUP_MEMBER	Contains the members for each Oracle ASM File Access Control group.

Tuning Oracle disk I/O: ASM configuration

Tuning Oracle disk I/O: ASM configuration

Automated Storage Management configuration

To turn on ASM facility, you must create a separate ASM instance before you start your database instances. An ASM instance does not require that a DB instance be running; as might be the case when you are initially configuring the components managed by the ASM instance. But to use Automated Storage Management for managing your Oracle database files, you must have both a database instance and an ASM instance running. Automated Storage Management is integrated into the database server; you do not need to install it as a separate product. The Oracle binaries installed for a normal 10g Oracle are used for the ASM instance. Thus there is no separate Oracle Home for ASM. However, to use ASM files, there must be at least one ASM instance configured and started prior to starting a database instance that uses ASM files.

The Database Configuration Assistant (DBCA) or Server Control Utility (SRVCTL) or Oracle Enterprise Manager (OEM) is used in Oracle Database 10g to configure the Automated Storage Management (ASM) features for conventional and Real Application Clusters (RAC) environments.

ASM is used to automate and simplify the optimal layout of data files, control files, and log files. ASM automatically distributes database files across all available disks, and whenever the storage configuration change, the database storage is rebalanced. ASM can also be used to provide redundancy, through the mirroring of database files.

ASM essentially eliminates the management overhead involved with the use of a conventional file system. There is no need to manually place data on disks when using ASM. Also, by allowing the administrator to manage just a few disk groups, the administrator is relieved from managing hundreds or thousands of files. Using ASM, the DBA will use disk groups for setting up a database. After setup, the DBA need only be concerned with disk groups when monitoring and changing disk allocations within the disk groups.

ASM uses the process of breaking each file into multiple extents and spreading the extents evenly across all of the disks in a disk group. Once ASM disk groups are established, the Oracle database automatically allocates storage space from these disk groups for creating and deleting files.

Unneeded data files are automatically deleted with ASM, rather than requiring a manually issued command, as in previous versions. Automated Storage Management enhances database integrity for databases operating on disks that are not extremely reliable.

ASM concepts

ASM employs several basic concepts. ASM operates on disk groups which is a collection of disks. Within the groups, it creates ASM files. Therefore the main building blocks are:

·         ASM disks

·         ASM disk groups

·         ASM files

·         ASM templates

Let us explore these concepts in detail. The following figure gives a glance of the components in ASM instance and relation with database instance.

Components of the ASM instance

ASM disk groups

A disk group is basically one or more ASM disks that are managed as a single logical unit. Any data-structure stored in an ASM disk group is totally contained within that disk group, or self-contained. A database using ASM disks doesn't have to be shutdown in order for a disk to be added or dropped. ASM rebalances the spread of data to ensure an even I/O load to all disks in a disk group when the disk group configuration changes.

We mentioned that any single ASM file is self-contained in a single ASM disk group. However, an ASM disk group can contain files belonging to several databases, and a single database can use storage from multiple ASM disk groups. You can specify a disk group as the default disk group for files created in a database by specifying the disk group in file destination initialization parameters.

ASM divides files into 1MB extents and spreads the extents for each file evenly across all of the disks in a disk group. ASM uses pointers to record extent location instead of using a mathematical function to track the placement of each extent. When the disk group configuration changes, ASM moves individual extents of a file rather than having to move all extents to adhere to a formula based on the number of disks.

For files, such as log files, that require low latency, ASM provides fine-grained (128k) striping to allow larger I/Os to be split and processed in parallel by multiple disks. At file creation time, you can decide whether or not to use fine-grained striping. File type specific templates in the disk group determine the default behavior.

Most installations will probably have two or more disk groups. The reasons for having multiple different disk groups include the following:

·         To group disks of different manufacturers, different sizes or performance characteristics.

·         To group disks with different external redundancy together; for example, JBOD (just a bunch of disks) would generally not be in the same disk group with disks from a RAID 1+0 or RAID5 configuration, but this is possible using ASM.

·         To separate work and recovery areas for a given database.

Note: In any installation, non-ASM managed operating system storage repositories are required, and are used for swap files, execution libraries, and user file systems. The Oracle database and ASM executable files and libraries must reside on the server's operating system file system and cannot reside in an ASM files.

In case of RAC database environment, files for loading into externals tables are still located on non-ASM file system which can be a cluster file system or local file system.

Types of disk groups

There are three types of ASM disk groups:

1.      Normal redundancy

2.      High redundancy

3.      External redundancy

With normal and high redundancy, the disk group template specifies the ASM redundancy attributes for all files in the disk group.

Configuration of ASM high redundancy provides a greater degree of protection. With external redundancy, ASM does not provide any redundancy for the disk group.

In external redundancy, the underlying disks in the disk group must provide redundancy (for example, using a RAID storage array.) The redundancy level or type is specified at the time of creating the disk groups.

Preferred Read Failure Groups

Preferred Read Failure Groups

When you configure Oracle ASM failure groups, it might be more efficient for a node to read from an extent that is closest to the node, even if that extent is a secondary extent. In other words, you can configure Oracle ASM to read from a secondary extent if that extent is closer to the node instead of Oracle ASM reading from the primary copy which might be farther from the node. Using the preferred read failure groups feature is most useful in extended clusters.

To use this feature, Oracle recommends that you configure at least one mirrored extent copy from a disk that is local to a node in an extended cluster. However, a failure group that is preferred for one instance might be remote to another instance in the same Oracle RAC database. The parameter setting for preferred read failure groups is instance specific.

Both the Oracle ASM clients and Oracle ASM require Oracle Database 11g release 1 (11.1) or higher to use preferred read failure groups.

Note:

If you do not specify failure groups for a disk group, each disk in the disk group belongs to its own failure group. Oracle does not recommend that you configure multiple preferred read failure groups in a disk group for an Oracle ASM instance. For any given instance, if you specify multiple failure groups in the same disk group as preferred read, a warning message is written to the alert log.

Configuring and Administering Preferred Read Failure Groups

To configure this feature, set the ASM_PREFERRED_READ_FAILURE_GROUPS initialization parameter to specify a list of failure group names as preferred read disks. For more information about this initialization parameter, refer to "ASM_PREFERRED_READ_FAILURE_GROUPS".

Set the parameter where diskgroup is the name of the disk group and failuregroup is the name of the failure group, separating these variables with a period. Oracle ASM ignores the name of a failure group that you use in this parameter setting if the failure group does not exist in the named disk group. You can append multiple values using commas as a separator as follows:

ASM_PREFERRED_READ_FAILURE_GROUPS = diskgroup.failuregroup,...

In an extended cluster, the failure groups that you specify with settings for the ASM_PREFERRED_READ_FAILURE_GROUPS parameter should only contain disks that are local to the instance. For normal redundancy disk groups, there should be only one failure group on each site of the extended cluster.

If there are multiple mirrored copies and you have set a value for the ASM_PREFERRED_READ_FAILURE_GROUPS parameter, then Oracle ASM first reads the copy that resides on a preferred read disk. If that read fails, then Oracle ASM attempts to read from the next mirrored copy that might not be on a preferred read disk.

Having multiple failure groups on one site can cause the loss of access to the disk group by the other sites if the site containing multiple failure groups fails. In addition, by having multiple failure groups on a site, an extent might not be mirrored to another site. This can diminish the read performance of the failure group on the other site.

For example, for a normal redundancy disk group, if a site contains two failure groups of a disk group, then Oracle ASM might put both mirror copies of an extent on the same site. In this configuration, Oracle ASM cannot protect against data loss from a site failure.

You should configure at most two failure groups on a site for a high redundancy disk group. If there are three sites in an extended cluster, for the same reason previously mentioned, then you should only create one failure group.

For a two-site extended cluster, a normal redundancy disk group only has two failure groups. In this case, you can only specify one failure group as a preferred read failure group for each instance.

You can use views to identify preferred read failure groups, such as the V$ASM_DISK view that shows whether a disk is a preferred read disk by the value in the PREFERRED_READ column. You can also use V$ASM_DISK to verify whether local disks in an extended cluster are preferred read disks. Use the Oracle ASM disk I/O statistics to verify that read operations are using the preferred read disks that you configured.

If a disk group is not optimally configured for an extended cluster, then Oracle ASM records warning messages in the alert logs. To identify specific performance issues with Oracle ASM preferred read failure groups, use the V$ASM_DISK_IOSTAT view. This view displays disk I/O statistics for each Oracle ASM client. You can also query the V$ASM_DISK_IOSTAT view on a database instance. However, this query only shows the I/O statistics for the database instance. In general, optimal preferred read extended cluster configurations balance performance with disk group availability.

Performance and Scalability Considerations for Disk Groups

Performance and Scalability Considerations for Disk Groups

• Determining the Number of Disk Groups
• Performance Characteristics When Grouping Disks
• Oracle ASM Storage Limits

Determining the Number of Disk Groups

Use the following criteria to determine the number of disk groups to create:

• Disks in a given disk group should have similar size and performance characteristics. If you have several different types of disks in terms of size and performance, then create several disk groups that contain similar characteristics.
• Create separate disk groups for your database files and fast recovery area for backup files. This configuration allows fast recovery should a disk group failure occur.

Performance Characteristics When Grouping Disks

Oracle ASM load balances the file activity by uniformly distributing file extents across all of the disks in a disk group. For this technique to be effective it is important that disks in a disk group be of similar performance characteristics. For example, the newest and fastest disks might reside in a disk group reserved for the database work area, and slower drives could reside in a disk group reserved for the fast recovery area.

There might be situations where it is acceptable to temporarily have disks of different sizes and performance characteristics coexist in a disk group. This would be the case when migrating from an old set of disks to a new set of disks. The new disks would be added and the old disks dropped. As the old disks are dropped, their storage is migrated to the new disks while the disk group is online.

Oracle ASM Storage Limits

Oracle ASM provides near unlimited capacity for future growth, but does have some storage limits. For example, Oracle ASM has the following limits on the number of disk groups, disks, and files:

• 63 disk groups in a storage system
• 10,000 Oracle ASM disks in a storage system
• 1 million files for each disk group

Without any Oracle Exadata Storage, Oracle ASM has these storage limits:

• 2 terabytes (TB) maximum storage for each Oracle ASM disk
• 20 petabytes (PB) maximum for the storage system

With all Oracle Exadata Storage, Oracle ASM has these storage limits:

• 4 PB maximum storage for each Oracle ASM disk
• 40 exabytes (EB) maximum for the storage system

The maximum size limit of a disk group equals the maximum disk size multiplied by the maximum number of disks in a disk group (10,000).

The maximum number of disks across all disk groups is 10,000. The 10,000 disks can be in one disk group or distributed across a maximum of 63 disk groups. This is a limitation on the number of Oracle ASM disks, not necessarily the number of spindles. A storage array could group multiple spindles into a LUN that is used as a single Oracle ASM disk. However Oracle ASM is currently limited to 2 TB in a single disk unless using Oracle Exadata storage.

File size limits are dependent on the value of the disk group compatibility attributes. Oracle ASM supports file sizes greater than 128 TB in any redundancy mode when the COMPATIBLE.RDBMS disk group attribute is set greater than10.1.

If COMPATIBLE.RDBMS is set to 10.1, the file size limits are less. For example, with COMPATIBLE.RDBMS equal to 10.1 and the AU size equal to 1 MB, Oracle ASM file size limits are:

• External redundancy: 16 TB
• Normal redundancy: 5.8 TB
• High redundancy: 3.9 TB

Note:

Oracle Database supports data file sizes up to 128 TB depending on the file system. In addition, Oracle Database has a file size limit that is dependent on the DB_BLOCK_SIZE initialization parameter.

Miscellaneous Disk Group Maintenance Enhancements

Miscellaneous Disk Group Maintenance Enhancements

• The CREATE DISKGROUP and ALTER DISKGROUP commands include a new ATTRIBUTE clause (compatible, disk_repair_time, au_size).
• The CHECK clause of the ALTER DISKGROUP command has been simplified so there are only two options, NOREPAIR and REPAIR, available, with NOREPAIR as the default. Summarized errors are displayed, with full error messages writen to the alert log.

·         ALTER DISKGROUP data CHECK; -- Like NOREPAIR

·         ALTER DISKGROUP data CHECK NOREPAIR;

ALTER DISKGROUP data CHECK REPAIR;

• Disk groups can now be mounted in restricted mode, which can improve performance of some maintenance tasks.
• The ALTER DISKGOUP command now includes ONLINE and OFFLINE clauses so disks can be taken offline for repair before being brought back online.

·         -- Individual disks.

·         ALTER DISKGROUP data OFFLINE DISK 'disk_0000', 'disk_0001';

·         ALTER DISKGROUP data ONLINE DISK 'disk_0000', 'disk_0001';

·          

·         -- Failure groups.

·         ALTER DISKGROUP data OFFLINE DISKS IN FAILGROUP 'fg_0000';

·         ALTER DISKGROUP data ONLINE DISKS IN FAILGROUP 'fg_0000';

·          

·         -- Bring online all disks in disk group.

ALTER DISKGROUP data ONLINE ALL;

• Disk groups that can't be mounted by ASM can now be dropped using the FORCE keyword of the DROP DISKGROUP command.

DROP DISKGROUP data FORCE;

Dropping Disk Groups

Dropping Disk Groups

The DROP DISKGROUP statement enables you to delete an ASM disk group and optionally, all of its files. You can specify the INCLUDING CONTENTS clause if you also want to delete any files that might be contained in the disk group. The default is EXCLUDING CONTENTS, which provides syntactic consistency and prevents you from dropping the disk group if it has any contents

The ASM instance must be started and the disk group must be mounted with none of the disk group files open, in order for the DROP DISKGROUP statement to succeed. The statement does not return until the disk group has been dropped.

When you drop a disk group, ASM dismounts the disk group and removes the disk group name from the ASM_DISKGROUPS initialization parameter if a server parameter file is being used. If a text initialization parameter file is being used, and the disk group is mentioned in the ASM_DISKGROUPS initialization parameter, then you must remove the disk group name from the ASM_DISKGROUPS initialization parameter before the next time that you shut down and restart the ASM instance.

The following statement deletes dgroup1:

DROP DISKGROUP dgroup1;

After ensuring that none of the files contained in dgroup1 are open, ASM rewrites the header of each disk in the disk group to remove ASM formatting information. The statement does not specify INCLUDING CONTENTS, so the drop operation will fail if the disk group contains any files.

If you cannot mount a disk group but need to drop it, you can use the FORCE option of the DROP DISKGROUP statement. This command enables you to remove the headers on disks that belong to a disk group that cannot be mounted by any ASM instances as in the following example where disk_group_name is the name of the disk group:

DROP DISKGROUP disk_group_name FORCE

The disk group on which you perform this operation should not be mounted anywhere in the cluster. When you use the FORCE option, the ASM instance does not attempt to verify that a disk group is being used by another ASM instance in the same storage subsystem.

Disk Group Attributes

Disk Group Attributes

Disk group attributes are parameters that are bound to a disk group, rather than an Oracle ASM instance.
Disk group attributes can be set when a disk group is created or altered, unless otherwise noted in the following list.
ACCESS_CONTROL.ENABLED
This attribute can only be set when altering a disk group.
This attribute determines whether Oracle ASM File Access Control is enabled for a disk group.
The value can be true or false. The default is false.
If the attribute is set to true, accessing Oracle ASM files is subject to access control. If false, any user can access every file in the disk group. All other operations behave independently of this attribute.
ACCESS_CONTROL.UMASK
This attribute can only be set when altering a disk group.
This attribute determines which permissions are masked out on the creation of an Oracle ASM file for the user that owns the file, users in the same user group, and others not in the user group. This attribute applies to all files on a disk group.
The values can be combinations of three digits {0|2|6} {0|2|6} {0|2|6}. The default is 066.
Setting to 0 masks out nothing. Setting to 2 masks out write permission. Setting to 6 masks out both read and write permissions.
Before setting the ACCESS_CONTROL.UMASK disk group attribute, you must set the ACCESS_CONTROL.ENABLED attribute to true to enable Oracle ASM File Access Control.

Setting up Oracle ASM File Access Control

ALTER DISKGROUP data1 SET ATTRIBUTE 'access_control.enabled' = 'true';

ALTER DISKGROUP data1 SET ATTRIBUTE 'access_control.umask' = '026';

AU_SIZE
This attribute can only be set when creating a disk group.
Oracle recommends that the allocation unit (AU) size for a disk group be set to 4 megabytes (MB). In addition to this AU size recommendation, the operating system (OS) I/O size should be set to the largest possible size.
Some benefits of a 4 MB allocation unit are:

·         Increased I/O through the I/O subsystem if the I/O size is increased to the AU size.

·         Reduced SGA size to manage the extent maps in the database instance.

·         Faster datafile initialization if the I/O size is increased to the AU size.

·         Increased file size limits.

·         Reduced database open time.

The allocation unit size is specified with the disk group attribute AU_SIZE. The AU size cannot be altered after a disk group is created. Example 4-1 shows how the AU_SIZE is specified with the CREATE DISKGROUP SQL statement.

Example 4-1 Creating the DATA disk group

CREATE DISKGROUP data NORMAL REDUNDANCY

  FAILGROUP controller1 DISK

    '/devices/diska1' NAME diska1,

    '/devices/diska2' NAME diska2,

    '/devices/diska3' NAME diska3,

    '/devices/diska4' NAME diska4

  FAILGROUP controller2 DISK

    '/devices/diskb1' NAME diskb1,

    '/devices/diskb2' NAME diskb2,

    '/devices/diskb3' NAME diskb3,

    '/devices/diskb4' NAME diskb4

  ATTRIBUTE 'au_size'='4M',

    'compatible.asm' = '11.2', 

    'compatible.rdbms' = '11.2',

    'compatible.advm' = '11.2';

In Example 4-1, the NAME clauses enable you to explicitly assign names to the disks rather than the default system-generated names. The system-generated names are in the form diskgroup_nnnn, where nnnn is the disk number for the disk in the disk group. For ASMLib disks, the disk name defaults to the ASMLib name that is the user label of the disk; for example, mydisk is the default Oracle ASM disk name for ORCL:mydisk.
When creating the disk group in Example 4-1, the values of following disk group attributes were explicitly set:

·         AU_SIZE

Specifies the size of the allocation unit for the disk group. For information about allocation unit size and extents, see "Extents".

You can view the value of the AU_SIZE disk group attribute in the ALLOCATION_UNIT_SIZE column of the V$ASM_DISKGROUP view.

·         COMPATIBLE.ASM

Determines the minimum software version for any Oracle ASM instance that uses a disk group. For information about the COMPATIBLE.ASM attribute, see "COMPATIBLE.ASM".

·         COMPATIBLE.RDBMS

Determines the minimum software version for any database instance that uses a disk group. For information about the COMPATIBLE.RDBMS attribute, see "COMPATIBLE.RDBMS".

·         COMPATIBLE.ADVM

Determines whether the disk group can contain Oracle ASM volumes.

CELL.SMART_SCAN_CAPABLE
This attribute is only applicable to Oracle Exadata storage.

COMPATIBLE.ASM

The value for the disk group COMPATIBLE.ASM attribute determines the minimum software version for an Oracle ASM instance that can use the disk group. This setting also affects the format of the data structures for the Oracle ASM metadata on the disk. The format of other file contents is determined by Oracle ASM Dynamic Volume Manager (Oracle ADVM) and the database instance.
For Oracle ASM in Oracle Database 11g, 10.1 is the default setting for the COMPATIBLE.ASM attribute when using the SQL CREATE DISKGROUP statement, the ASMCMD mkdg command, and Oracle Enterprise Manager Create Disk Group page. When creating a disk group with ASMCA, the default setting is 11.2.

COMPATIBLE.RDBMS

The value for the disk group COMPATIBLE.RDBMS attribute determines the minimum COMPATIBLE database initialization parameter setting for any database instance that is allowed to use the disk group. Before advancing the COMPATIBLE.RDBMS attribute, ensure that the values for the COMPATIBLE initialization parameter for all of the databases that access the disk group are set to at least the value of the new setting for COMPATIBLE.RDBMS.
For example, if the COMPATIBLE initialization parameters of the databases are set to either 11.1 or 11.2, then COMPATIBLE.RDBMS can be set to any value between 10.1 and 11.1 inclusively.
For Oracle ASM in Oracle Database 11g, 10.1 is the default setting for the COMPATIBLE.RDBMS attribute when using the SQL CREATE DISKGROUP statement, the ASMCMD mkdg command, ASMCA Create Disk Group page, and Oracle Enterprise Manager Create Disk Group page.

COMPATIBLE.ADVM

The value for the disk group COMPATIBLE.ADVM attribute determines whether the disk group can contain Oracle ASM volumes. The value must be set to 11.2 or higher. Before setting this attribute, the COMPATIBLE.ASM value must be 11.2 or higher. Also, the Oracle ADVM volume drivers must be loaded in the supported environment.
By default, the value of the COMPATIBLE.ADVM attribute is empty until set.
CONTENT.TYPE
The CONTENT.TYPE attribute identifies the disk group type: data, recovery, or system. The type value determines the distance to the nearest neighbor disk in the failure group where Oracle ASM mirrors copies of the data. The default value is data which specifies a distance of 1 to the nearest neighbor disk. A value of recovery specifies a distance of 3 to the nearest neighbor disk and a value of system specifies a distance of 5.
The attribute can be specified when creating or altering a disk group. If CONTENT.TYPE attribute is set or changed using ALTER DISKGROUP, then the new configuration does not take effect until a disk group rebalance is explicitly run.
The CONTENT.TYPE attribute is only valid for disk groups that are set to normal or high redundancy. The COMPATIBLE.ASM attribute must be set to 11.2.0.3 or higher to enable the CONTENT.TYPE attribute for the disk group.
The attribute can be set with SQL, ASMCMD, or ASMCA. For example:

SQL> CREATE DISKGROUP data NORMAL REDUNDANCY

        FAILGROUP controller1 DISK

        '/devices/diska1' NAME diska1,

...

        ATTRIBUTE 

        'compatible.asm' = '11.2.0.3', 

        'content.type' = 'recovery',

...

SQL> ALTER DISKGROUP data SET ATTRIBUTE 'content.type' = 'data';

This attribute is primarily intended for use with Oracle Exadata storage.
DISK_REPAIR_TIME
This attribute can only be set when altering a disk group.

Oracle ASM Fast Mirror Resync

Restoring the redundancy of an Oracle ASM disk group after a transient disk path failure can be time consuming. This is especially true if the recovery process requires rebuilding an entire Oracle ASM failure group. Oracle ASM fast mirror resync significantly reduces the time to resynchronize a failed disk in such situations. When you replace the failed disk, Oracle ASM can quickly resynchronize the Oracle ASM disk extents.

Note:

To use this feature, the disk group compatibility attributes must be set to 11.1 or higher. For more information, refer to "Disk Group Compatibility".

Any problems that make a failure group temporarily unavailable are considered transient failures that can be recovered by the Oracle ASM fast mirror resync feature. For example, transient failures can be caused by disk path malfunctions, such as cable failures, host bus adapter failures, controller failures, or disk power supply interruptions.
Oracle ASM fast resync keeps track of pending changes to extents on an OFFLINE disk during an outage. The extents are resynced when the disk is brought back online.
By default, Oracle ASM drops a disk in 3.6 hours after it is taken offline. You can set the DISK_REPAIR_TIME disk group attribute to delay the drop operation by specifying a time interval to repair the disk and bring it back online. The time can be specified in units of minutes (m or M) or hours (h or H). If you omit the unit, then the default unit is hours. The DISK_REPAIR_TIME disk group attribute can only be set with the ALTER DISKGROUP SQL statement.
If the attribute is not set explicitly, then the default value (3.6h) applies to disks that have been set to OFFLINE mode without an explicit DROP AFTER clause. Disks taken offline due to I/O errors do not have a DROP AFTER clause.
The default DISK_REPAIR_TIME attribute value is an estimate that should be adequate for most environments. However, ensure that the attribute value is set to the amount of time that you think is necessary in your environment to fix any transient disk error, and that you are willing to tolerate reduced data redundancy.
The elapsed time (since the disk was set to OFFLINE mode) is incremented only when the disk group containing the offline disks is mounted. The REPAIR_TIMER column of V$ASM_DISK shows the amount of time left (in seconds) before an offline disk is dropped. After the specified time has elapsed, Oracle ASM drops the disk. You can override this attribute with the ALTER DISKGROUP OFFLINE DISK statement and the DROP AFTER clause.

Note:

If a disk is offlined by Oracle ASM because of an I/O (write) error or is explicitly offlined using the ALTER DISKGROUP... OFFLINE statement without the DROP AFTER clause, then the value specified for the DISK_REPAIR_TIME attribute for the disk group is used.

Altering the DISK_REPAIR_TIME attribute has no effect on offline disks. The new value is used for any disks that go offline after the attribute is updated. You can confirm this behavior by viewing the Oracle ASM alert log.
If an offline disk is taken offline for a second time, then the elapsed time is reset and restarted. If another time is specified with the DROP AFTER clause for this disk, the first value is overridden and the new value applies. A disk that is in OFFLINE mode cannot be dropped with an ALTER DISKGROUP DROP DISK statement; an error is returned if attempted. If for some reason the disk must be dropped (such as the disk cannot be repaired) before the repair time has expired, a disk can be dropped immediately by issuing a second OFFLINE statement with a DROP AFTER clause specifying 0h or 0m.
You can use ALTER DISKGROUP to set the DISK_REPAIR_TIME attribute to a specified hour or minute value, such as 4.5 hours or 270 minutes. For example:

ALTER DISKGROUP data SET ATTRIBUTE 'disk_repair_time' = '4.5h'

ALTER DISKGROUP data SET ATTRIBUTE 'disk_repair_time' = '270m'

After you repair the disk, run the SQL statement ALTER DISKGROUP ONLINE DISK. This statement brings a repaired disk group back online to enable writes so that no new writes are missed. This statement also starts a procedure to copy of all of the extents that are marked as stale on their redundant copies.
If a disk goes offline when the Oracle ASM instance is in rolling upgrade mode, the disk remains offline until the rolling upgrade has ended and the timer for dropping the disk is stopped until the Oracle ASM cluster is out of rolling upgrade mode. See "Using Oracle ASM Rolling Upgrade". Examples of taking disks offline and bringing them online follow.
The following example takes disk DATA_001 offline and drops it after five minutes.

ALTER DISKGROUP data OFFLINE DISK DATA_001 DROP AFTER 5m;

The next example takes the disk DATA_001 offline and drops it after the time period designated by DISK_REPAIR_TIME elapses:

ALTER DISKGROUP data OFFLINE DISK DATA_001;

This example takes all of the disk in failure group FG2 offline and drops them after the time period designated by DISK_REPAIR_TIME elapses. IF you used a DROP AFTER clause, then the disks would be dropped after the specified time:

ALTER DISKGROUP data OFFLINE DISK IN FAILGROUP FG2;

The next example brings all of the disks in failure group FG2 online:

ALTER DISKGROUP data ONLINE DISK IN FAILGROUP FG2;

This example brings only disk DATA_001 online:

ALTER DISKGROUP data ONLINE DISK DATA_001;

This example brings all of the disks in disk group DATA online:

ALTER DISKGROUP data ONLINE ALL;

Querying the V$ASM_OPERATION view while you run any of these types of ALTER DISKGROUP ... ONLINE statements displays the name and state of the current operation that you are performing. For example, the query:

SELECT GROUP_NUMBER, OPERATION, STATE FROM V$ASM_OPERATION;

Displays output similar to the following:

GROUP_NUMBER OPERA STAT 

------------ ----- ---- 

           1 ONLIN RUN 

An OFFLINE operation is not displayed in a V$ASM_OPERATION view query.
IDP.BOUNDARY and IDP.TYPE
These attributes are intended for use with Oracle Exadata storage.
SECTOR_SIZE
This attribute can only be set when creating a disk group.

Specifying the Sector Size for Drives

You can use the optional SECTOR_SIZE disk group attribute with the CREATE DISKGROUP SQL statement to specify disks with the sector size set to the value of SECTOR_SIZE for the disk group. Oracle ASM provides support for 4 KB sector disk drives without negatively affecting performance. The SECTOR_SIZE disk group attribute can be set only during disk group creation.
The values for SECTOR_SIZE can be set to 512, 4096, or 4K if the disks support those values. The default value is platform dependent. The COMPATIBLE.ASM and COMPATIBLE.RDBMS disk group attributes must be set to 11.2 or higher to set the sector size to a value other than the default value.

Note:

Oracle Automatic Storage Management Cluster File System (Oracle ACFS) does not support 4 KB sector drives. There is a performance penalty for Oracle ACFS when using 4 KB sector disk drives in 512 sector emulation mode.

The following validations apply to the sector size disk group attribute.

·         Oracle ASM prevents disks of different sector sizes from being added to the same disk group. This validation occurs during CREATE DISKGROUP, ALTER DISKGROUP ADD DISK, and ALTER DISKGROUP MOUNT operations.

·         If the SECTOR_SIZE attribute is explicitly specified when creating a disk group, then Oracle ASM attempts to verify that all disks discovered through disk search strings have a sector size equal to the specified value. If one or more disks were found to have a sector size different from the specified value, or if Oracle ASM was not able to verify a disk sector size, then the create operation fails.

Oracle ASM also attempts to verify disk sector size during the mount operation and the operation fails if one or more disks have a sector size different than the value of the SECTOR_SIZE attribute.

·         If the SECTOR_SIZE attribute is not specified when creating a disk group and Oracle ASM can verify that all discovered disks have the same sector value, then that value is assumed for the disk group sector size that is created. If the disks have different sector sizes, the create operation fails.

·         When new disks are added to an existing disk group using the ALTER DISKGROUP .. ADD DISK SQL statement, you must ensure that the new disks to be added have the same value as the SECTOR_SIZE disk group attribute. If the new disks have different sector sizes, the alter operation fails.

·         You can determine the sector size value that has either been assumed or explicitly set for a successful disk group creation by querying the V$ASM_ATTRIBUTE view or run the ASMCMD lsattr command. You can also query the SECTOR_SIZE column in the V$ASM_DISKGROUP view.

·         SQL> SELECT name, value FROM V$ASM_ATTRIBUTE 

·              WHERE name = 'sector_size' AND group_number = 1;

·         NAME                        VALUE

·         --------------------------- -----------------------

·         sector_size                 512

·          

·         SQL> SELECT group_number, sector_size FROM V$ASM_DISKGROUP 

·              WHERE group_number = 1;

·          

·         GROUP_NUMBER SECTOR_SIZE

·         ------------ -----------

·                    1         512

·         Not all disks support all of the possible SECTOR_SIZE values. The sector size attribute setting must be compatible with the physical hardware.

As shown in Example 4-3, you can use the SECTOR_SIZE attribute with the CREATE DISKGROUP SQL statement to specify the sector size of the disk drive on which the Oracle ASM disk group is located.

Example 4-3 Creating a disk group of 4K sector size

CREATE DISKGROUP data NORMAL REDUNDANCY

FAILGROUP controller1 DISK

'/devices/diska1',

'/devices/diska2',

'/devices/diska3',

'/devices/diska4'

FAILGROUP controller2 DISK

'/devices/diskb1',

'/devices/diskb2',

'/devices/diskb3',

'/devices/diskb4'

ATTRIBUTE 'compatible.asm' = '11.2', 'compatible.rdbms' = '11.2',

          'sector_size'='4096';

STORAGE.TYPE
The STORAGE.TYPE disk group attribute specifies the type of the disks in the disk group. The possible values are AXIOM, ZFSSA, and OTHER. If the attribute is set to AXIOM or ZFSSA, then all disks in the disk group must be of that type. If the attribute is set to OTHER, then any types of disks can be in the disk group.
If the STORAGE.TYPE disk group attribute is set to AXIOM or ZFSSA, then functionality for Hybrid Columnar Compression (HCC) can be enabled for Pillar Axiom or ZFS storage.