登录  
 加关注
查看详情
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

飞哥的技术博客

世上无难事,只怕有心人!

 
 
 

日志

 
 
 
 

oracle database storage administrator's guide 11gR2-4  

2009-10-18 16:55:07|  分类: Oracle |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

4 Administering Oracle ASM Disk Groups

This chapter describes how to administer Oracle Automatic Storage Management (Oracle ASM) disk groups. This information includes how to create, alter, drop, mount, and dismount Oracle ASM disk groups. The database instances that use Oracle ASM can continue operating while you administer disk groups.

The examples in this chapter use SQL statements. These examples assume that SQL*Plus is run from the Oracle grid home where Oracle ASM is installed and the Oracle environmental variables are set to this home. The examples also assume that the Oracle ASM instance is running. This chapter contains the following topics:

For information about starting up an Oracle ASM instance, refer to "Starting Up an Oracle ASM Instance".

For information about administering Oracle ASM disk groups with Oracle Enterprise Manager, refer to Chapter 9, "Administering Oracle ASM with Oracle Enterprise Manager".

For information about administering Oracle ASM disk groups with Oracle ASM Configuration Assistant (ASMCA), refer to Chapter 11, "Oracle ASM Configuration Assistant".

For information about administering Oracle ASM disk groups with ASMCMD, refer to Chapter 12, "Oracle ASM Command-Line Utility".

See Also:

The Oracle ASM home page for more information about Oracle ASM best practices at: DE<http://www.oracle.com/technology/products/database/asm/index.htmlDE<

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.

In addition to the disk group attributes listed in this section, template attributes are also assigned to a disk group. For information about template attributes, see "Managing Disk Group Templates".

You can display disk group attributes with the DE<V$ASM_ATTRIBUTEDE< view and the ASMCMD DE<lsattrDE< command. For an example of the use of the DE<V$ASM_ATTRIBUTEDE< view, see Example 6-1. For information about the DE<lsattrDE< command, see "lsattr".

Creating Disk Groups

This section contains information about creating disk groups. You can use the DE<CREATEDE< DE<DISKGROUPDE< SQL statement to create a disk group.

This section contains the following topics:

Using the CREATE DISKGROUP SQL Statement

The DE<CREATE DISKGROUPDE< SQL statement is used to create disk groups. When creating a disk group, you:

  • Assign a unique name to the disk group.

    The specified disk group name is not case sensitive and is always converted to uppercase when stored internally.

    Note:

    Oracle does not recommend using identifiers for database object names that must be quoted. While these quoted identifiers may be valid as names in the SQL CREATE statement, such as DE<CREATEDE< DE<DISKGROUPDE< "DE<1DATADE<", the names may not be valid when using other tools that manage the database object.
  • Specify the redundancy level of the disk group.

    For Oracle ASM to mirror files, specify the redundancy level as DE<NORMAL REDUNDANCYDE< (2-way mirroring by default for most file types) or DE<HIGH REDUNDANCYDE< (3-way mirroring for all files). Specify DE<EXTERNAL REDUNDANCYDE< if you do not want mirroring by Oracle ASM. For example, you might choose DE<EXTERNAL REDUNDANCYDE< to use storage array protection features.

    After a disk group is created, you cannot alter the redundancy level of the disk group. To change the redundancy level, you must create another disk group with the appropriate redundancy and then move the files to the new disk group.

    Oracle recommends that you create failure groups of equal size to maintain space balance and even distribution of mirror data.

    For more information about redundancy levels, refer to "Oracle ASM Mirroring and Failure Groups".

  • Specify the disks that are to be formatted as Oracle ASM disks belonging to the disk group.

    The disks can be specified using operating system dependent wildcard characters in search strings that Oracle ASM then uses to find the disks. You can specify names for the disks with the DE<NAMEDE< clause or use the system-generated names.

  • Optionally specify the disks as belonging to specific failure groups.

    For information about failure groups, refer to "Understanding Oracle ASM Concepts" and "Oracle ASM Mirroring and Failure Groups".

  • Optionally specify the type of failure group.

    For information about DE<QUROUMDE< and DE<REGULARDE< failure groups, refer to "Oracle Cluster Registry and Voting Files in Oracle ASM Disk Groups".

  • Optionally specify disk group attributes, such software compatibility or allocation unit size.

Oracle ASM programmatically determines the size of each disk. If for some reason this is not possible, or to restrict the amount of space used on a disk, you can specify a DE<SIZEDE< clause for each disk. Oracle ASM creates operating system–independent names for the disks in a disk group that you can use to reference the disks in other SQL statements. Optionally, you can provide your own name for a disk using the DE<NAMEDE< clause. Disk names are available in the DE<V$ASM_DISKDE< view.

Note:

A disk cannot belong to multiple disk groups.

The Oracle ASM instance ensures that any disk in a newly created disk group is addressable and is not currently a member of another disk group. You must use DE<FORCEDE< only when adding a disk that was dropped DE<FORCEDE<. If a disk is dropped DE<NOFORCEDE<, then use can add it DE<NOFORCEDE<. For example, a disk might have failed and was dropped from its disk group. After the disk is repaired, it is no longer part of any disk group, but Oracle ASM still recognizes that the disk had been a member of a disk group. You must use the DE<FORCEDE< flag to include the disk in a new disk group. In addition, the disk must be addressable, and the original disk group must not be mounted. Otherwise, the operation fails.

Note:

Use caution when using the DE<FORCEDE< option to add a previously used disk to a disk group; you might cause another disk group to become unusable.

The DE<CREATE DISKGROUPDE< statement mounts the disk group for the first time, and adds the disk group name to the DE<ASM_DISKGROUPSDE< initialization parameter if a server parameter file is being used. If a text initialization parameter file is being used and you want the disk group to be automatically mounted at instance startup, then you must remember to add the disk group name to the DE<ASM_DISKGROUPSDE< initialization parameter before the next time that you shut down and restart the Oracle ASM instance. You can also create disk groups with Oracle Enterprise Manager. Refer to "Creating Disk Groups".

Example: Creating a Disk Group

The following examples assume that the DE<ASM_DISKSTRINGDE< initialization parameter is set to the 'DE</devices/*DE<' string. Oracle ASM disk discovery identifies disks in the DE</devicesDE< directory, including the following disks:

Controller 1:


DE</devices/diska1DE<
DE</devices/diska2DE<
DE</devices/diska3DE<
DE</devices/diska4DE<

Controller 2:
DE</devices/diskb1DE<
DE</devices/diskb2DE<
DE</devices/diskb3DE<
DE</devices/diskb4DE<

The SQL statement in Example 4-1 creates a disk group named DE<dataDE< with normal redundancy consisting of two failure groups DE<controller1DE< or DE<controller2DE< with four disks in each failure group. The DE<dataDE< disk group is typically used to store database data files.

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 DE<NAMEDE< 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 DE<diskgroup_nnnnDE<, where DE<nnnnDE< 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, DE<mydiskDE< is the default Oracle ASM disk name for DE<ORCL:mydiskDE<.

When creating the disk group in Example 4-1, the values of following disk group attributes were explicitly set:

  • DE<AU_SIZEDE<

    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 DE<AU_SIZEDE< disk group attribute in the DE<ALLOCATION_UNIT_SIZEDE< column of the DE<V$ASM_DISKGROUPDE< view.

  • DE<COMPATIBLEDE<.DE<ASMDE<

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

  • DE<COMPATIBLEDE<.DE<RDBMSDE<

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

  • DE<COMPATIBLEDE<.DE<ADVMDE<

    Determines whether the disk group can contain Oracle ASM volumes. For information about the DE<COMPATIBLE.ADVMDE< attribute, see "COMPATIBLE.ADVM".

In Example 4-2, the DE<fraDE< disk group (typically created for the fast recovery area) is created with the default disk group attribute values. Names are not specified for the Oracle ASM disks and failure groups are not explicitly specified. This examples assumes that DE<diskc1DE< through DE<diskc9DE< are present in the DE</devicesDE< directory.

Example 4-2 Creating the FRA Disk Group

CREATE DISKGROUP fra NORMAL REDUNDANCY    DISK '/devices/diskc*';  

See Also:

For information about using ASMLIB when creating disk groups, refer to the Oracle ASMLib page on the Oracle Technology Network Web site at DE<http://www.oracle.com/technology/tech/linux/asmlib/index.htmlDE<

Creating Disk Groups for a New Oracle Installation

This section describes the basic procedure to follow when creating disk groups during a new installation of Oracle Restart and Oracle Database. This information also applies to an Oracle grid infrastructure installation.

The procedure assumes that the DE<dataDE< disk group is used for the storage of the database data files and the DE<fraDE< disk group is used for storage of the fast recovery area files. Detailed information about installation with Oracle Universal Installer (OUI) and database creation with Database Configuration Assistant (DBCA) is available in the installation guides for your specific operating system.

  1. Install Oracle Restart with OUI, following the screen prompts.

    During the installation, create the DE<dataDE< disk group for storing database files such as the data and control files.

    This OUI process is similar to creating a disk group with Oracle ASM Configuration Assistant (ASMCA). For information about using ASMCA to create disk groups, see "Managing Disk Groups With Oracle ASM Configuration Assistant".

    Note that the DE<dataDE< disk group is the disk group used for storing Oracle Cluster Registry (OCR) and voting disks in an Oracle grid infrastructure installation. See "Oracle Cluster Registry and Voting Files in Oracle ASM Disk Groups"

  2. After Oracle Restart is installed, use ASMCA to create the DE<fraDE< disk group for storing the fast recovery area files.

    Create the DE<fraDE< disk group to hold the fast recovery area files.

    At this time, you can also update the DE<dataDE< disk group if necessary. For information about using ASMCA to create or alter disk groups, see "Managing Disk Groups With Oracle ASM Configuration Assistant".

    You can also create the DE<fraDE< disk group with SQL*Plus or ASMCMD commands run from the Oracle Restart home. For information, see "Using the CREATE DISKGROUP SQL Statement" and "mkdg".

    See Also:

  3. Install the Oracle Database software with OUI, following the screen prompts.

  4. After the database software has been installed, run DBCA to create a database, following the screen prompts.

    During the creation of the database, make the appropriate selections to use Oracle ASM for storage of data files and fast recovery area files. When prompted:

    • Store database data files in the DE<dataDE< disk group

    • Store fast recovery area files in the DE<fraDE< disk group

See Also:

Specifying the Allocation Unit Size

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 with 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 DE<AU_SIZEDE<. The AU size cannot be altered after a disk group is created. Example 4-1 shows how the DE<AU_SIZEDE< is specified with the DE<CREATEDE< DE<DISKGROUPDE< SQL statement.

For applications that can benefit from large I/O sizes, you can increase the DE<DB_FILE_MULTIBLOCK_READ_COUNTDE< initialization parameter to 4 MB from the default of 1 MB. Ensure that the application is thoroughly tested with this new setting as this change could adversely affect stable optimized plans and future optimizer plan generation.

To change the DE<DB_FILE_MULTIBLOCK_READ_COUNTDE< setting, use the DE<ALTERDE< DE<SYSTEMDE< SQL statement, as shown in Example 4-3. This example assumes an 8 K block size.

Example 4-3 Altering the DB_FILE_MULTIBLOCK_READ_COUNT Setting

SQL> ALTER SYSTEM SET db_file_multiblock_read_count=512 scope=both sid=*  

See Also:

Oracle Database Reference for more information about the DE<DB_FILE_MULTIBLOCK_READ_COUNTDE< initialization parameter

Specifying the Sector Size for Drives

The optional DE<SECTOR_SIZEDE< disk group attribute can be used with the DE<CREATEDE< DE<DISKGROUPDE< SQL statement to specify disks with the sector size set to the value of DE<SECTOR_SIZEDE< for the disk group. Oracle ASM provides support for 4 KB sector disk drives without negatively affecting performance. The DE<SECTOR_SIZEDE< disk group attribute can be set only during disk group creation.

The values for DE<SECTOR_SIZEDE< can be 512, 4096, or 4K. The default value is platform dependent. The DE<COMPATIBLE.ASMDE< and DE<COMPATIBLE.RDBMSDE< 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 DE<CREATEDE< DE<DISKGROUPDE<, DE<ALTERDE< DE<DISKGROUPDE< DE<ADDDE< DE<DISKDE<, and DE<ALTERDE< DE<DISKGROUPDE< DE<MOUNTDE< operations.

  • If the DE<SECTOR_SIZEDE< 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 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 DE<SECTOR_SIZEDE< attribute.

  • If the DE<SECTOR_SIZEDE< 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 DE<ALTERDE< DE<DISKGROUPDE< .. DE<ADDDE< DE<DISKDE< SQL statement, you must ensure that the new disks to be added have the same value as the DE<SECTOR_SIZEDE< 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 DE<V$ASM_ATTRIBUTEDE< view or run the ASMCMD DE<lsattrDE< command. You can also query the DE<SECTOR_SIZEDE< column in the DE<V$ASM_DISKGROUPDE< view.

    SQL> SELECT name, value FROM V$ASM_ATTRIBUTE        WHERE  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  

As shown in Example 4-4, you can use the DE<SECTOR_SIZEDE< attribute with the DE<CREATEDE< DE<DISKGROUPDE< SQL statement to specify the sector size of the disk drive on which the Oracle ASM disk group is located.

Example 4-4 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';  

See Also:

Oracle Cluster Registry and Voting Files in Oracle ASM Disk Groups

You can store Oracle Cluster Registry (OCR) and the voting file in Oracle ASM disk groups. The voting file and OCR are two important components of Oracle Clusterware.

The voting file helps you to manage information about node membership. OCR is a system that manages cluster and Oracle Real Application Clusters (Oracle RAC) database configuration information. A quorum failure group is a special type of failure group and disks in these failure groups do not contain user data and are not considered when determining redundancy requirements. For information about failure groups, see "Oracle ASM Failure Groups".

You can manage and monitor this feature with the following:

  • The CRSCTL and DE<ocrconfigDE< command-line tools

    The CRSCTL and DE<ocrconfigDE< commands enable the placement of OCR storage and Cluster Synchronization Services (CSS) voting disks inside the disk groups managed by Oracle ASM.

  • DE<CREATEDE</DE<ALTERDE< DE<DISKGROUPDE< SQL Statements

    The SQL keywords DE<QUORUMDE< and DE<REGULARDE< enable the specification of disk and failure groups when creating or altering disk groups.

    See Example 4-5.

  • DE<V$ASMDE< views

    The DE<FAILGROUP_TYPEDE< column in both the DE<V$ASM_DISKDE< and DE<V$ASM_DISK_STATDE< views specifies failure group type. The value for this column is DE<REGULARDE< for regular failure groups and DE<QUORUMDE< for quorum failure groups.

    The DE<VOTING_FILEDE< column in both the DE<V$ASM_DISKDE< and DE<V$ASM_DISK_STATDE< views specifies whether a disk contains a voting disk. The value for this column is DE<YDE< if the disk contains a voting disk or DE<NDE< otherwise.

    Note that the value of DE<USABLE_FILE_MBDE< in DE<V$ASM_DISKGROUPDE< and DE<V$ASM_DISKGROUP_STATDE< does not consider any free space that is present in DE<QUORUMDE< disks because that space is not available for client data files.

    See "Views Containing Oracle ASM Disk Group Information".

The DE<QUORUMDE< and DE<REGULARDE< keywords provide an additional qualifier for failure group or disk specifications when creating or altering a disk group. DE<QUORUMDE< disks (or disks in DE<QUORUMDE< failure groups) cannot have client data files, whereas DE<REGULARDE< disks (or disks in non-quorum failure groups) have no such restriction.

These keywords can be used before the keyword DE<FAILGROUPDE< if a failure group is being explicitly specified. If the failure group is implicitly implied, these keywords (DE<QUORUMDE</DE<REGULARDE<) can be used before the keyword DE<DISKDE<. When failure groups are explicitly specified, it is an error to specify these keywords (DE<QUORUMDE</DE<REGULARDE<) immediately before the keyword DE<DISKDE<. DE<REGULARDE< is the default failure group type.

When performing operations on existing disks or failure groups, the qualifier specified in the SQL must match the qualifier that was specified when the disks or failure groups were added to the disk group.

Example 4-5 shows the creation of a disk group with a DE<QUORUMDE< failure group. For Oracle Clusterware files a minimum of three disk devices or three failure groups are required with a normal redundancy disk group. Also, a DE<QUORUMDE< failure group does not count toward redundancy requirements.

The DE<COMPATIBLE.ASMDE< disk group compatibility attribute must be set to DE<11.2DE< or greater to store OCR or voting disk data in a disk group.

Example 4-5 Using the QUORUM Keyword

CREATE DISKGROUP ocr_data NORMAL REDUNDANCY     FAILGROUP fg1 DISK '/devices/diskg1'     FAILGROUP fg2 DISK '/devices/diskg2'     QUORUM FAILGROUP fg3 DISK '/devices/diskg3'     ATTRIBUTE 'compatible.asm' = '11.2.0.0.0';  

See Also:

Altering Disk Groups

You can use the DE<ALTERDE< DE<DISKGROUPDE< SQL statement to alter a disk group configuration. You can add, resize, or drop disks while the database remains online. Whenever possible, multiple operations in a single DE<ALTERDE< DE<DISKGROUPDE< statement are recommended.

Oracle ASM automatically rebalances when the configuration of a disk group changes. By default, the DE<ALTERDE< DE<DISKGROUPDE< statement does not wait until the operation is complete before returning. Query the DE<V$ASM_OPERATIONDE< view to monitor the status of this operation.

Use the DE<REBALANCEDE< DE<WAITDE< clause to cause the DE<ALTERDE< DE<DISKGROUPDE< statement processing to wait until the rebalance operation is complete before returning. This is especially useful in scripts. The statement also accepts a DE<REBALANCEDE< DE<NOWAITDE< clause that invokes the default behavior of conducting the rebalance operation asynchronously in the background.

You can interrupt a rebalance running in wait mode by typing DE<CTRL-CDE< on most platforms. This causes the statement to return immediately with the message DE<ORA-01013: user requested cancel of current operationDE<, and then to continue the operation asynchronously. Typing DE<CTRL-CDE< does not cancel the rebalance operation or any disk add, drop, or resize operations.

To control the speed and resource consumption of the rebalance operation, you can include the DE<REBALANCEDE< DE<POWERDE< clause in statements that add, drop, or resize disks. Refer to "Manually Rebalancing Disk Groups" for more information about this clause.

This section contains the following topics:

Managing Volumes in a Disk Group

You can create an Oracle ASM Dynamic Volume Manager (Oracle ADVM) volume in a disk group. The volume device associated with the dynamic volume can then be used to host an Oracle ACFS file system.

The compatibility parameters DE<COMPATIBLE.ASMDE< and DE<COMPATIBLE.ADVMDE< must be set to 11.2 or higher for the disk group. See "Disk Group Compatibility Attributes".

The DE<ALTERDE< DE<DISKGROUPDE< DE<VOLUMEDE< SQL statements enable you to manage Oracle ADVM volumes, including the functionality to add, resize, disable, enable, and drop volumes. For example:

SQL> ALTER DISKGROUP data ADD VOLUME volume1 SIZE 10G;  Diskgroup altered.    SQL> ALTER DISKGROUP data RESIZE VOLUME volume1 SIZE 15G;  Diskgroup altered.    SQL> ALTER DISKGROUP data DISABLE VOLUME volume1;  Diskgroup altered.    SQL> ALTER DISKGROUP data ENABLE VOLUME volume1;  Diskgroup altered.    SQL> ALTER DISKGROUP ALL DISABLE VOLUME ALL;  Diskgroup altered.    SQL> ALTER DISKGROUP data DROP VOLUME volume1;  Diskgroup altered.  

If the volume is hosting an Oracle ACFS file system, then you cannot resize that volume with the SQL DE<ALTERDE< DE<DISKGROUPDE< statement. Instead you must use the DE<acfsutilDE< DE<sizeDE< command. For information, see "acfsutil size".

For information about Oracle ADVM, see "Overview of Oracle ASM Dynamic Volume Manager". For information about managing Oracle ADVM volumes with ASMCMD, see "ASMCMD Volume Management Commands". For information about managing Oracle ADVM volumes with ASMCA, see "Managing Oracle ADVM Volumes With Oracle ASM Configuration Assistant". For information about managing Oracle ADVM volumes with Oracle Enterprise Manager, see "Managing Oracle ACFS with Oracle Enterprise Manager".

Adding Disks to a Disk Group

You can use the DE<ADDDE< clause of the DE<ALTER DISKGROUPDE< statement to add a disk or a failure group to a disk group. The same syntax that you use to add a disk or failure group with the DE<CREATEDE< DE<DISKGROUPDE< statement can be used with the DE<ALTER DISKGROUPDE< statement. For an example of the DE<CREATEDE< DE<DISKGROUPDE< SQL statement, refer to Example 4-1. After you add new disks, the new disks gradually begin to accommodate their share of the workload as rebalancing progresses.

Oracle ASM behavior when adding disks to a disk group is best illustrated through"Example: Adding Disks to a Disk Group". You can also add disks to a disk group with Oracle Enterprise Manager, described in "Adding Disks to Disk Groups".

Example: Adding Disks to a Disk Group

The statements presented in this example demonstrate the interactions of disk discovery with the DE<ADDDE< DE<DISKDE< operation.

Assume that disk discovery identifies the following disks in directory DE</devicesDE<:


DE</devices/diska1DE< -- member of DE<data1DE<
DE</devices/diska2DE< -- member of DE<data1DE<
DE</devices/diska3DE< -- member of DE<data1DE<
DE</devices/diska4DE< -- member of DE<data1DE<
DE</devices/diska5DE< -- candidate disk
DE</devices/diska6DE< -- candidate disk
DE</devices/diska7DE< -- candidate disk
DE</devices/diska8DE< -- candidate disk

DE</devices/diskb1DE< -- member of DE<data1DE<
DE</devices/diskb2DE< -- member of DE<data1DE<
DE</devices/diskb3DE< -- member of DE<data1DE<
DE</devices/diskb4DE< -- member of DE<data2DE<

DE</devices/diskc1DE< -- member of DE<data2DE<
DE</devices/diskc2DE< -- member of DE<data2DE<
DE</devices/diskc3DE< -- member of DE<data3DE<
DE</devices/diskc4DE< -- candidate disk

DE</devices/diskd1DE< -- candidate disk
DE</devices/diskd2DE< -- candidate disk
DE</devices/diskd3DE< -- candidate disk
DE</devices/diskd4DE< -- candidate disk
DE</devices/diskd5DE< -- candidate disk
DE</devices/diskd6DE< -- candidate disk
DE</devices/diskd7DE< -- candidate disk
DE</devices/diskd8DE< -- candidate disk

You can query the DE<V$ASM_DISKDE< view to display the status of Oracle ASM disks. See "Views Containing Oracle ASM Disk Group Information".

The following statement would fail because DE</devices/diska1DE< - DE</devices/diska4DE< belong to the disk group DE<dataDE<.

ALTER DISKGROUP data1 ADD DISK       '/devices/diska*';  

The following statement would successfully add disks DE</devices/diska5DE< through DE</devices/diska8DE< to DE<data1DE<. Because no DE<FAILGROUPDE< clauses are included in the DE<ALTER DISKGROUPDE< statement, each disk is assigned to its own failure group. The DE<NAMEDE< clauses assign names to the disks, otherwise they would have been assigned system-generated names.

ALTER DISKGROUP data1 ADD DISK       '/devices/diska5' NAME diska5,       '/devices/diska6' NAME diska6,       '/devices/diska7' NAME diska7,       '/devices/diska8' NAME diska8;  

The following statement would fail because the search string matches disks that are contained in other disk groups. Specifically, DE</devices/diska4DE< belongs to disk group DE<data1DE< and DE</devices/diskb4DE< belongs to disk group DE<data2DE<.

ALTER DISKGROUP data1 ADD DISK       '/devices/disk*4';  

The following statement would successfully add DE</devices/diskd1DE< through DE</devices/diskd8DE< to disk group DE<data1DE<. This statement runs with a rebalance power of 5, and does not return until the rebalance operation is complete.

ALTER DISKGROUP data1 ADD DISK        '/devices/diskd*'         REBALANCE POWER 5 WAIT;  

If DE</devices/diskc3DE< was previously a member of a disk group that no longer exists, then you could use the DE<FORCEDE< option to add them as members of another disk group. For example, the following use of the DE<FORCEDE< clause enables DE</devices/diskc3DE< to be added to DE<data2DE<, even though it is a current member of DE<data3DE<. For this statement to succeed, DE<data3DE< cannot be mounted.

ALTER DISKGROUP data2 ADD DISK       '/devices/diskc3' FORCE;  

Dropping Disks from Disk Groups

To drop disks from a disk group, use the DE<DROPDE< DE<DISKDE< clause of the DE<ALTER DISKGROUPDE< statement. You can also drop all of the disks in specified failure groups using the DE<DROPDE< DE<DISKSDE< DE<INDE< DE<FAILGROUPDE< clause.

When a disk is dropped, the disk group is rebalanced by moving all of the file extents from the dropped disk to other disks in the disk group. A drop disk operation might fail if not enough space is available on the other disks. The best approach is to perform both the add and drop operation with the same DE<ALTERDE< DE<DISKGROUPDE< statement. This has the benefit of rebalancing data extents only one time and ensuring that there is enough space for the rebalance operation to succeed.

Caution:

The DE<ALTERDE< DE<DISKGROUPDE<DE<...DE<DE<DROPDE< DE<DISKDE< statement returns before the drop and rebalance operations are complete. Do not reuse, remove, or disconnect the dropped disk until the DE<HEADER_STATUSDE< column for this disk in the DE<V$ASM_DISKDE< view changes to DE<FORMERDE<. You can query the DE<V$ASM_OPERATIONDE< view to determine the amount of time remaining for the drop/rebalance operation to complete. For more information, refer to the Oracle Database SQL Language Reference and the Oracle Database Reference.

If you specify the DE<FORCEDE< clause for the drop operation, the disk is dropped even if Oracle ASM cannot read or write to the disk. You cannot use the DE<FORCEDE< flag when dropping a disk from an external redundancy disk group.

Caution:

A DE<DROPDE< DE<FORCEDE< operation leaves data at reduced redundancy until the subsequent rebalance operation completes. This increases your exposure to data loss if there is a subsequent disk failure during rebalancing. Use DE<DROPDE< DE<FORCEDE< with caution.

You can also drop disks from a disk group with Oracle Enterprise Manager. See "Dropping Disks from Disk Groups".

Example: Dropping Disks from Disk Groups

The statements in this example demonstrate how to drop disks from the disk group DE<data1DE< described in "Example: Adding Disks to a Disk Group".

The following example drops DE<diska5DE< from disk group DE<data1DE<.

ALTER DISKGROUP data1 DROP DISK diska5;  

The following example drops DE<diska5DE< from disk group DE<data1DE<, and also illustrates how multiple actions are possible with one DE<ALTER DISKGROUPDE< statement.

ALTER DISKGROUP data1 DROP DISK diska5       ADD FAILGROUP failgrp1 DISK '/devices/diska9' NAME diska9;  

Intelligent Data Placement

Intelligent Data Placement enables you to specify disk regions on Oracle ASM disks for best performance. Using the disk region settings, you can ensure that frequently accessed data is placed on the outermost (hot) tracks which have greater speed and higher bandwidth. In addition, files with similar access patterns are located physically close, reducing latency. Intelligent Data Placement also allows the placement of primary and mirror extents into different hot or cold regions.

Intelligent Data Placement settings can be specified for a file or in disk group templates. The disk region settings can be modified after the disk group has been created. The disk region setting can improve I/O performance by placing more frequently accessed data in regions furthest from the spindle, while reducing your cost by increasing the usable space on a disk.

Intelligent Data Placement works best for the following:

  • Databases with data files that are accessed at different rates. A database that accesses all data files in the same way is unlikely to benefit from Intelligent Data Placement.

  • Disk groups that are more than 25% full. If the disk group is only 25% full, the management overhead is unlikely to be worth any benefit.

  • Disks that have better performance at the beginning of the media relative to the end. Because Intelligent Data Placement leverages the geometry of the disk, it is well suited to JBOD (just a bunch of disks). In contrast, a storage array with LUNs composed of concatenated volumes masks the geometry from Oracle ASM.

The DE<COMPATIBLE.ASMDE< and DE<COMPATIBLE.RDBMSDE< disk group attributes must be set to 11.2 or higher to use Intelligent Data Placement.

Intelligent Data Placement can be managed with the DE<ALTERDE< DE<DISKGROUPDE< DE<ADDDE< or DE<MODIFYDE< DE<TEMPLATEDE< SQL statements and the DE<ALTERDE< DE<DISKGROUPDE< DE<MODIFYDE< DE<FILEDE< SQL statement.

  • The DE<ALTERDE< DE<DISKGROUPDE< DE<TEMPLATEDE< SQL statement includes a disk region clause for setting DE<hotDE</DE<mirrorhotDE< or DE<coldDE</DE<mirrorcoldDE< regions in a template:

    ALTER DISKGROUP data ADD TEMPLATE datafile_hot    ATTRIBUTE (       HOT      MIRRORHOT);  
  • The DE<ALTERDE< DE<DISKGROUPDE< ... DE<MODIFYDE< DE<FILEDE< SQL statement that sets disk region attributes for DE<hotDE</DE<mirrorhotDE< or DE<coldDE</DE<mirrorcoldDE< regions:

    ALTER DISKGROUP data MODIFY FILE '+data/orcl/datafile/users.259.679156903'    ATTRIBUTE (       HOT      MIRRORHOT);  

    When you modify the disk region settings for a file, this action applies to new extensions of the file, but existing file contents are not affected until a rebalance operation. To apply the new Intelligent Data Placement policy for existing file contents, you can manually initiate a rebalance. A rebalance operation uses the last specified policy for the file extents. For information on the rebalance operation, see "Manually Rebalancing Disk Groups".

Oracle ASM Configuration Assistant (ASMCA) supports Intelligent Data Placement with template creation during disk group alterations. See "Managing Disk Groups With Oracle ASM Configuration Assistant".

Oracle Enterprise Manager supports Intelligent Data Placement from the Templates page launched from the disk group page. See "Managing Disk Group Templates with Oracle Enterprise Manager".

For information about Intelligent Data Placement details in views, see "Viewing Disk Region Information".

Resizing Disks in Disk Groups

The DE<RESIZEDE< clause of DE<ALTER DISKGROUPDE< enables you to perform the following operations:

  • Resize all disks in the disk group

  • Resize specific disks

  • Resize all of the disks in a specified failure group

If you do not specify a new size in the DE<SIZEDE< clause then Oracle ASM uses the size of the disk as returned by the operating system. The new size is written to the Oracle ASM disk header and if the size of the disk is increasing, then the new space is immediately available for allocation. If the size is decreasing, rebalancing must relocate file extents beyond the new size limit to available space below the limit. If the rebalance operation can successfully relocate all extents, then the new size is made permanent, otherwise the rebalance fails.

Example: Resizing Disks in Disk Groups

The following example resizes all of the disks in failure group DE<failgrp1DE< of disk group DE<data1DE<. If the new size is greater than disk capacity, the statement fails.

ALTER DISKGROUP data1        RESIZE DISKS IN FAILGROUP failgrp1 SIZE 100G;  

Undropping Disks in Disk Groups

The DE<UNDROP DISKSDE< clause of the DE<ALTER DISKGROUPDE< statement enables you to cancel all pending drops of disks within disk groups. If a drop disk operation has completed, then this statement cannot be used to restore it. This statement cannot be used to restore disks that are being dropped as the result of a DE<DROP DISKGROUPDE< statement, or for disks that are being dropped using the DE<FORCEDE< clause.

Example: Undropping Disks in Disk Groups

The following example cancels the dropping of disks from disk group DE<data1DE<:

ALTER DISKGROUP data1 UNDROP DISKS;  

Manually Rebalancing Disk Groups

You can manually rebalance the files in a disk group using the DE<REBALANCEDE< clause of the DE<ALTER DISKGROUPDE< statement. This would normally not be required, because Oracle ASM automatically rebalances disk groups when their configuration changes. You might want to do a manual rebalance operation to control the speed of what would otherwise be an automatic rebalance operation.

The DE<POWERDE< clause of the DE<ALTER DISKGROUP...REBALANCEDE< statement specifies the degree of parallelism, and thus the speed of the rebalance operation. It can be set to a value from 0 to 11. A value of 0 halts a rebalancing operation until the statement is either implicitly or explicitly re-run. The default rebalance power is set by the DE<ASM_POWER_LIMITDE< initialization parameter. See "Tuning Rebalance Operations" for more information.

The power level of an ongoing rebalance operation can be changed by entering the rebalance statement with a new level.

The DE<ALTER DISKGROUP...REBALANCEDE< command by default returns immediately so that you can issue other commands while the rebalance operation takes place asynchronously in the background. You can query the DE<V$ASM_OPERATIONDE< view for the status of the rebalance operation.

To cause the DE<ALTER DISKGROUP...REBALANCEDE< command to wait until the rebalance operation is complete before returning, add the DE<WAITDE< keyword to the DE<REBALANCEDE< clause. This is especially useful in scripts. The command also accepts a DE<NOWAITDE< keyword, which invokes the default behavior of conducting the rebalance operation asynchronously. You can interrupt a rebalance running in wait mode by typing DE<CTRL-CDE< on most platforms. This causes the command to return immediately with the message DE<ORA-01013: user requested cancel of current operationDE<, and then to continue the rebalance operation asynchronously.

Additional rules for the rebalance operation include the following:

  • An ongoing rebalance command is restarted if the storage configuration changes either when you alter the configuration, or if the configuration changes due to a failure or an outage. Furthermore, if the new rebalance fails because of a user error, then a manual rebalance may be required.

  • The DE<ALTER DISKGROUP...REBALANCEDE< statement runs on a single node even if you are using Oracle Real Application Clusters (Oracle RAC).

  • Oracle ASM can perform one disk group rebalance at a time on a given instance. Therefore, if you have initiated multiple rebalances on different disk groups, then Oracle processes this operation serially. However, you can initiate rebalances on different disk groups on different nodes in parallel.

  • Rebalancing continues across a failure of the Oracle ASM instance performing the rebalance.

  • The DE<REBALANCEDE< clause (with its associated DE<POWERDE< and DE<WAIT/NOWAITDE< keywords) can also be used in DE<ALTER DISKGROUPDE< commands that add, drop, or resize disks.

    Note:

    Oracle restarts the processing of an ongoing rebalance operation if the storage configuration changes. If the next rebalance operation fails because of a user error, then a manual rebalance may be required.

Example: Manually Rebalancing a Disk Group

The following example manually rebalances the disk group DE<data2DE<. The command does not return until the rebalance operation is complete.

ALTER DISKGROUP data2 REBALANCE POWER 5 WAIT;  

For more information about rebalancing operations, refer to "Tuning Rebalance Operations".

Tuning Rebalance Operations

If the DE<POWERDE< clause is not specified in an DE<ALTERDE< DE<DISKGROUPDE< statement, or when rebalance is implicitly run by adding or dropping a disk, then the rebalance power defaults to the value of the DE<ASM_POWER_LIMITDE< initialization parameter. You can adjust the value of this parameter dynamically.

The higher the power limit, the more quickly a rebalance operation can complete. Rebalancing takes longer with lower power values, but consumes fewer processing and I/O resources which are shared by other applications, such as the database.

The default value of DE<1DE< minimizes disruption to other applications. The appropriate value is dependent on your hardware configuration, performance requirements, and availability requirements

If a rebalance is in progress because a disk is manually or automatically dropped, then increasing the power of the rebalance shortens the time frame during which redundant copies of that data on the dropped disk are reconstructed on other disks.

The DE<V$ASM_OPERATIONDE< view provides information for adjusting DE<ASM_POWER_LIMITDE< and the resulting power of rebalance operations. The DE<V$ASM_OPERATIONDE< view also gives an estimate in the DE<EST_MINUTESDE< column of the amount of time remaining for the rebalance operation to complete. You can see the effect of changing the rebalance power by observing the change in the time estimate.

See Also:

"Manually Rebalancing Disk Groups" for more information.

Oracle ASM Disk Discovery

Disk discovery is the mechanism used to find the operating system names for disks Oracle ASM can access. It is used to find all the disks that comprise a disk group to be mounted, the disks an administrator wants to add to a disk group, or the disks the administrator might consider adding to a disk group. This section contains the following topics:

For additional information about disk discovery and the DE<ASM_DISKSTRINGDE< initialization parameter, refer to "ASM_DISKSTRING".

How A Disk is Discovered

When an Oracle ASM instance is initialized, Oracle ASM discovers and examines the contents of all of the disks that are in the paths that you designated with values in the DE<ASM_DISKSTRINGDE< initialization parameter.

Disk discovery also occurs when you:

  • Run the following SQL statements

    • Mount a disk group with DE<ALTERDE< DE<DISKGROUPDE< ... DE<MOUNTDE<

    • Online a disk with DE<ALTERDE< DE<DISKGROUPDE< ... DE<ONLINEDE< DE<DISKDE<

    • Add a disk to a disk group with DE<CREATEDE< or DE<ALTERDE< DE<DISKGROUPDE<...DE<ADDDE< DE<DISKDE<

    • Resize a disk in a disk group with DE<ALTERDE< DE<DISKGROUPDE<...DE<RESIZEDE< DE<DISKDE<

    • Query with DE<SELECTDE< ... DE<FROMDE< DE<V$ASM_DISKGROUPDE< or DE<V$ASM_DISKDE< views

  • Run Oracle Enterprise Manager or Oracle ASM Configuration Assistant (ASMCA) operations that invoke the SQL statements previously listed

  • Run ASMCMD commands that perform the same operations as the SQL statements previously listed

After Oracle ASM successfully discovers a disk, the disk appears in the DE<V$ASM_DISKDE< view. Disks that belong to a disk group, that is, disks that have a disk group name in the disk header, show a header status of DE<MEMBERDE<. Disks that were discovered, but that have not yet been assigned to a disk group, have a status of either DE<CANDIDATEDE< or DE<PROVISIONEDDE<. Disks that previously belonged to a disk group and were dropped cleanly from the disk group have a status of DE<FORMERDE<.

The DE<PROVISIONEDDE< status implies that an additional platform-specific action has been taken by an administrator to make the disk available for Oracle ASM. For example, on Windows computers, the administrator might have used DE<asmtoolDE< or DE<asmtoolgDE< to stamp the disk with a header. On Linux computers, the administrator might have used ASMLIB to prepare the disk for Oracle ASM.

Example 4-6 shows a SQL query on DE<V$ASM_DISKDE< that displays the header status of a group of disks.

Example 4-6 Querying V$ASM_DISK for Header Status

SQL> SELECT name, header_status, path FROM V$ASM_DISK        WHERE path LIKE '/devices/disk0%'    NAME      HEADER_STATUS PATH  --------- ------------- ---------------------            FORMER        /devices/disk02            FORMER        /devices/disk01            CANDIDATE     /devices/disk07  DISK06    MEMBER        /devices/disk06  DISK05    MEMBER        /devices/disk05  DISK04    MEMBER        /devices/disk04  DISK03    MEMBER        /devices/disk03  7 rows selected.  

See Also:

Oracle Database Reference for information about the header status of an Oracle ASM disk that is displayed in the DE<V$ASM_DISKDE< view

Disk Discovery Rules

The rules for discovering Oracle ASM disks are as follows:

  • Oracle ASM can discover up to 10,000 disks. That is, if more than 10,000 disks match the DE<ASM_DISKSTRINGDE< initialization parameter, then Oracle ASM discovers only the first 10,000.

  • Oracle ASM only discovers disk partitions. Oracle ASM does not discover partitions that include the partition table.

  • From the perspective of the installation, candidate disks are those that have the DE<CANDIDATEDE<, DE<PROVISIONEDDE<, or DE<FORMERDE< header status. These disks with a DE<CANDIDATEDE<, DE<PROVISIONEDDE<, or DE<FORMERDE< status can be added to Oracle ASM disk groups without using the DE<FORCEDE< flag.

  • When adding a disk, the DE<FORCEDE< option must be used if Oracle ASM recognizes that the disk was managed by Oracle. Such a disk appears in the DE<V$ASM_DISKDE< view with a status of DE<FOREIGNDE<. In this case, you can only add the disk to a disk group by using the DE<FORCEDE< keyword.

  • DE<MEMBERDE< disks can usually be added to a disk group by specifying the DE<FORCEDE< flag, if the disks are not part of a currently mounted disk group.

In addition, Oracle ASM identifies the following configuration errors during discovery:

  • Multiple paths to the same disk

    In this case, if the disk is part of a disk group, then disk group mount fails. If the disk is being added to a disk group with the DE<ADD DISKDE< or DE<CREATE DISKGROUPDE< command, then the command fails. To correct the error, adjust the DE<ASM_DISKSTRINGDE< value so that Oracle ASM does not discover multiple paths to the same disk. Or if you are using multipathing software, then ensure that you include only the pseudo-device name in the DE<ASM_DISKSTRINGDE< value. See "Oracle ASM and Multipathing".

  • Multiple Oracle ASM disks with the same disk header

    This can be caused by having copied one disk onto another. In this case, the disk group mount operation fails.

Improving Disk Discovery Time

The value for the DE<ASM_DISKSTRINGDE< initialization parameter is an operating system–dependent value that Oracle ASM uses to limit the set of paths that the discovery process uses to search for disks. When a new disk is added to a disk group, each Oracle ASM instance that has the disk group mounted must be able to discover the new disk using its DE<ASM_DISKSTRINGDE<.

In many cases, the default value (DE<NULLDE<) is sufficient. Using a more restrictive value might reduce the time required for Oracle ASM to perform discovery, and thus improve disk group mount time or the time for adding a disk to a disk group. Oracle may dynamically change the DE<ASM_DISKSTRINGDE< before adding a disk so that the new disk is discovered through this parameter.

The default value of DE<ASM_DISKSTRINGDE< might not find all disks in all situations. If your site is using a third-party vendor ASMLIB, then the vendor might have discovery string conventions that you must use for DE<ASM_DISKSTRINGDE<. In addition, if your installation uses multipathing software, then the software might place pseudo-devices in a path that is different from the operating system default. See "Oracle ASM and Multipathing" and consult the multipathing vendor documentation for details.

Managing Capacity in Disk Groups

When Oracle ASM provides redundancy, such as when you create a disk group with DE<NORMALDE< or DE<HIGHDE< redundancy, you must have sufficient capacity in each disk group to manage a re-creation of data that is lost after a failure of one or two failure groups. After one or more disks fail, the process of restoring redundancy for all data requires space from the surviving disks in the disk group. If not enough space remains, then some files might end up with reduced redundancy.

Reduced redundancy means that one or more extents in the file are not mirrored at the expected level. For example, a reduced redundancy file in a high redundancy disk group has at least one file extent with two or fewer total copies of the extent instead of three. For unprotected files, data extents could be missing altogether. Other causes of reduced redundancy files are disks running out of space or an insufficient number of failure groups. The DE<REDUNDANCY_LOWEREDDE< column in the DE<V$ASM_FILEDE< view DE<DE<provides information about files with reduced redundancy.

The following guidelines help ensure that you have sufficient space to restore full redundancy for all disk group data after the failure of one or more disks.

  • Normal redundancy disk group - It is best to have enough free space in your disk group to tolerate the loss of all disks in one failure group. The amount of free space should be equivalent to the size of the largest failure group.

  • High redundancy disk group - It is best to have enough free space to cope with the loss of all disks in two failure groups. The amount of free space should be equivalent to the sum of the sizes of the two largest failure groups.

    Note:

    When you lose multiple disks from multiple failure groups, then you could lose both the primary and the redundant copies of your data. In addition, if you do not have enough capacity to restore redundancy, then Oracle ASM can continue to operate. However, if another disk fails, then the system may not be able to tolerate additional failures.

The DE<V$ASM_DISKGROUPDE< view contains the following columns that contain information to help you manage capacity:

  • DE<REQUIRED_MIRROR_FREE_MBDE< indicates the amount of space that must be available in a disk group to restore full redundancy after the worst failure that can be tolerated by the disk group without adding additional storage. This requirement ensures that there are sufficient failure groups to restore redundancy. Also, this worst failure refers to a permanent failure where the disks must be dropped, not the case where the disks go offline and then back online.

    The amount of space displayed in this column takes the effects of mirroring into account. The value is computed as follows:

    • Normal redundancy disk group with more than two failure groups

      The value is the total raw space for all of the disks in the largest failure group. The largest failure group is the one with the largest total raw capacity. For example, if each disk is in its own failure group, then the value would be the size of the largest capacity disk.

    • High redundancy disk group with more than three failure groups

      The value is the total raw space for all of the disks in the two largest failure groups.

  • DE<USABLE_FILE_MBDE< indicates the amount of free space, adjusted for mirroring, that is available for new files to restore redundancy after a disk failure. DE<USABLE_FILE_MBDE< is computed by subtracting DE<REQUIRED_MIRROR_FREE_MBDE< from the total free space in the disk group and then adjusting the value for mirroring. For example, in a normal redundancy disk group where by default the mirrored files use disk space equal to twice their size, if 4 GB of actual usable file space remains, then DE<USABLE_FILE_MBDE< equals roughly 2 GB. You can then add a file that is up to 2 GB.

  • DE<TOTAL_MBDE< is the total usable capacity of a disk group in megabytes. The calculations for data in this column take the disk header overhead into consideration. The disk header overhead depends on the number of Oracle ASM disks and Oracle ASM files. This value is typically about 1% of the total raw storage capacity. For example, if the total LUN capacity provisioned for Oracle ASM is 100 GB, then the value in the DE<TOTAL_MBDE< column would be about 99 GB.

  • DE<FREE_MBDE< is the unused capacity of the disk group in megabytes, without considering any data imbalance. There may be situations where the value in the DE<FREE_MBDE< column shows unused capacity but because one Oracle ASM disks is full, database writes fail because of the imbalance in the disk group. Ensure that you initiate a manual rebalance to force even data distribution which results in an accurate presentation of the values in the DE<FREE_MBDE< column.

    With fine grain striping using 128 KB, the storage is preallocated to be eight times the AU size. Therefore, the data file size may appear slightly larger on Oracle ASM than on a local file system because of the preallocation.

    When you use Oracle ASM normal or high redundancy, the disk space utilization becomes more complex to measure because it depends on several variables.

    Note:

    The values in the DE<TOTAL_MBDE< and DE<FREE_MBDE< columns best describe space usage when you do not configure Oracle ASM mirroring, that is, when you use external redundancy.

The results from the following query show capacity metrics for a normal redundancy disk group that consists of six 1 GB (1024 MB) disks, each in its own failure group:

SQL> SELECT name, type, total_mb, free_mb, required_mirror_free_mb,        usable_file_mb FROM V$ASM_DISKGROUP;    NAME         TYPE     TOTAL_MB    FREE_MB REQUIRED_MIRROR_FREE_MB USABLE_FILE_MB  ------------ ------ ---------- ---------- ----------------------- --------------  DATA         NORMAL       6144       3768                    1024           1372  

The DE<REQUIRED_MIRROR_FREE_MBDE< column shows that 1 GB of extra capacity must be available to restore full redundancy after one or more disks fail. The first three numeric columns in the query results are raw numbers. That is, they do not take redundancy into account. Only the last column is adjusted for normal redundancy. In the query output example for the DE<dataDE< disk group, the calculation is as follows:

DE<FREE_MBDE< DE<-DE< DE<REQUIRED_MIRROR_FREE_MBDE< DE<=DE< DE<2DE< DE<*DE< DE<USABLE_FILE_MBDE<

DE<3768 - 1024 = 2 * 1372 = 2744DE<

Negative Values of USABLE_FILE_MB

Due to the relationship between DE<FREE_MBDE<, DE<REQUIRED_MIRROR_FREE_MBDE<, and DE<USABLE_FILE_MBDE<, DE<USABLE_FILE_MBDE< can become negative. Although this is not necessarily a critical situation, it does mean that:

  • Depending on the value of DE<FREE_MBDE<, you may not be able to create new files.

  • The next failure might result in files with reduced redundancy.

If DE<USABLE_FILE_MBDE< becomes negative, it is strongly recommended that you add more space to the disk group as soon as possible.

Oracle ASM Mirroring and Disk Group Redundancy

This section contains the following topics:

Oracle ASM Mirroring and Failure Groups

If you specify mirroring for a file, then Oracle ASM automatically stores redundant copies of the file extents in separate failure groups. Failure groups apply only to normal and high redundancy disk groups. You can define the failure groups for each disk group when you create or alter the disk group.

There are three types of disk groups based on the Oracle ASM redundancy level. Table 4-1 lists the types with their supported and default mirroring levels. The default mirroring levels indicate the mirroring level with which each file is created unless a different mirroring level is designated.

Table 4-1 Mirroring Options for Oracle ASM Disk Group Types

Disk Group Type Supported Mirroring Levels Default Mirroring Level

External redundancy

Unprotected (none)

Unprotected

Normal redundancy

Two-way, three-way, unprotected (none)

Two-way

High redundancy

Three-way

Three-way


The redundancy level controls how many disk failures are tolerated without dismounting the disk group or losing data. Each file is allocated based on its own redundancy, but the default comes from the disk group.

The redundancy levels are:

  • External redundancy

    Oracle ASM does not provide mirroring redundancy and relies on the storage system to provide RAID functionality. Any write error cause a forced dismount of the disk group. All disks must be located to successfully mount the disk group.

  • Normal redundancy

    Oracle ASM provides two-way mirroring by default, which means that all files are mirrored so that there are two copies of every extent. A loss of one Oracle ASM disk is tolerated. You can optionally choose three-way or unprotected mirroring.

  • High redundancy

    Oracle ASM provides triple mirroring by default. A loss of two Oracle ASM disks in different failure groups is tolerated.

If there are not enough online failure groups to satisfy the file mirroring (redundancy attribute value) specified in the disk group file type template, Oracle ASM allocates as many mirrors copies as possible and subsequently allocates the remaining mirrors when sufficient online failure groups are available. For information about specifying Oracle ASM disk group templates, see "Managing Disk Group Templates".

Failure groups enable the mirroring of metadata and user data. System reliability can diminish if your environment has an insufficient number of failure groups.

This section contains these topics:

Oracle ASM Failure Groups

Failure groups are used to store mirror copies of data. When Oracle ASM allocates an extent for a normal redundancy file, Oracle ASM allocates a primary copy and a secondary copy. Oracle ASM chooses the disk on which to store the secondary copy so that it is in a different failure group than the primary copy. Each copy is on a disk in a different failure group so that the simultaneous failure of all disks in a failure group does not result in data loss.

A failure group is a subset of the disks in a disk group, which could fail at the same time because they share hardware. The failure of common hardware must be tolerated. Four drives that are in a single removable tray of a large JBOD (Just a Bunch of Disks) array should be in the same failure group because the tray could be removed making all four drives fail at the same time. Drives in the same cabinet could be in multiple failure groups if the cabinet has redundant power and cooling so that it is not necessary to protect against failure of the entire cabinet. However, Oracle ASM mirroring is not intended to protect against a fire in the computer room that destroys the entire cabinet.

There are always failure groups even if they are not explicitly created. If you do not specify a failure group for a disk, then Oracle automatically creates a new failure group containing just that disk, except for disk groups containing disks on Oracle Exadata cells.

A normal redundancy disk group must contain at least two failure groups. A high redundancy disk group must contain at least three failure groups. However, Oracle recommends using several failure groups. A small number of failure groups, or failure groups of uneven capacity, can create allocation problems that prevent full use of all of the available storage.

Failure groups can be specified as regular or quorum failure groups. For information about quorum failure groups, see "Oracle Cluster Registry and Voting Files in Oracle ASM Disk Groups".

See Also:

Oracle Exadata documentation for information about Oracle Exadata failure groups

How Oracle ASM Manages Disk Failures

Depending on the redundancy level of a disk group and how you define failure groups, the failure of one or more disks could result in either of the following:

  • The disks are first taken offline and then automatically dropped. In this case, the disk group remains mounted and serviceable. In addition, because of mirroring, all of the disk group data remains accessible. After the disk drop operation, Oracle ASM performs a rebalance to restore full redundancy for the data on the failed disks.

  • The entire disk group is automatically dismounted, which means loss of data accessibility.

Guidelines for Using Failure Groups

The following are guidelines for using failure groups:

  • Each disk in a disk group can belong to only one failure group.

  • Failure groups should all be of the same size. Failure groups of different sizes may lead to reduced availability.

  • Oracle ASM requires at least two failure groups to create a normal redundancy disk group and at least three failure groups to create a high redundancy disk group.

Failure Group Frequently Asked Questions

This section discusses frequently asked questions about failure group under the following topics:

How Many Failure Groups Should I Create?

Choosing the number of failure groups to create depends on the types of failures that must be tolerated without data loss. For small numbers of disks, such as fewer than 20, it is usually best to use the default failure group creation that puts every disk in its own failure group.

Using the default failure group creation for small numbers of disks is also applicable for large numbers of disks where your main concern is disk failure. For example, a disk group might be configured from several small modular disk arrays.If the system must continue operating when an entire modular array fails, then a failure group should consist of all of the disks in one module. If one module fails, then all of the data on that module is relocated to other modules to restore redundancy. Disks should be placed in the same failure group if they depend on a common piece of hardware whose failure must be tolerated with no loss of availability.

How are Multiple Failure Groups Recovered after Simultaneous Failures?

A simultaneous failure can occur if there is a failure of a piece of hardware used by multiple failure groups. This type of failure usually forces a dismount of the disk group if all disks are unavailable.

When Should External, Normal, or High Redundancy Be Used?

Oracle ASM mirroring runs on the database server and Oracle recommends to off load this processing to the storage hardware RAID controller by using external redundancy. You can use normal redundancy in the following scenarios:

  • Storage system does not have RAID controller

  • Mirroring across storage arrays

  • Extended cluster configurations

In general, Oracle ASM mirroring is the Oracle alternative to third party logical volume managers. Oracle ASM mirroring eliminates the deployment of additional layers of software complexity in your Oracle database environment.

Oracle ASM Recovery from Read and Write I/O Errors

Read errors can be the result of a loss of access to the entire disk or media corruptions on an otherwise a healthy disk. Oracle ASM tries to recover from read errors on corrupted sectors on a disk. When a read error by the database or Oracle ASM triggers the Oracle ASM instance to attempt bad block remapping, Oracle ASM reads a good copy of the extent and copies it to the disk that had the read error.

  • If the write to the same location succeeds, then the underlying allocation unit (sector) is deemed healthy. This might be because the underlying disk did its own bad block reallocation.

  • If the write fails, Oracle ASM attempts to write the extent to a new allocation unit on the same disk. If this write succeeds, the original allocation unit is marked as unusable. If the write fails, the disk is taken offline.

One unique benefit on Oracle ASM-based mirroring is that the database instance is aware of the mirroring. For many types of logical corruptions such as a bad checksum or incorrect System Change Number (SCN), the database instance proceeds through the mirror side looking for valid content and proceeds without errors. If the process in the database that encountered the read can obtain the appropriate locks to ensure data consistency, it writes the correct data to all mirror sides.

When encountering a write error, a database instance sends the Oracle ASM instance a disk offline message.

  • If database can successfully complete a write to at least one extent copy and receive acknowledgment of the offline disk from Oracle ASM, the write is considered successful.

  • If the write to all mirror side fails, database takes the appropriate actions in response to a write error such as taking the tablespace offline.

When the Oracle ASM instance receives a write error message from an database instance or when an Oracle ASM instance encounters a write error itself, Oracle ASM instance attempts to take the disk offline. Oracle ASM consults the Partner Status Table (PST) to see whether any of the disk's partners are offline. If too many partners are offline, Oracle ASM forces the dismounting of the disk group. Otherwise, Oracle ASM takes the disk offline.

The ASMCMD DE<remapDE< command was introduced to address situations where a range of bad sectors exists on a disk and must be corrected before Oracle ASM or database I/O. For information about the DE<remapDE< command, see "remap".

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 DE<11.1DE< 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 DE<OFFLINEDE< 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 DE<DISK_REPAIR_TIMEDE< 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 (DE<mDE< or DE<MDE<) or hours (DE<hDE< or DE<HDE<). If you omit the unit, then the default unit is hours. The DE<DISK_REPAIR_TIMEDE< disk group attribute can only be set with the DE<ALTERDE< DE<DISKGROUPDE< SQL statement.

If the attribute is not set explicitly, then the default value (DE<3.6hDE<) applies to disks that have been set to DE<OFFLINEDE< mode without an explicit DE<DROPDE< DE<AFTERDE< clause. Disks taken offline due to I/O errors do not have a DE<DROPDE< DE<AFTERDE< clause.

The default DE<DISK_REPAIR_TIMEDE< 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 DE<OFFLINEDE< mode) is incremented only when the disk group containing the offline disks is mounted. The DE<REPAIR_TIMEDE< column of DE<V$ASM_DISKDE< 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 an DE<ALTERDE< DE<DISKGROUPDE< DE<DISKDE< DE<OFFLINEDE< statement and the DE<DROPDE< DE<AFTERDE< clause.

Note:

If a disk is offlined by Oracle ASM because of an I/O (write) error or is explicitly offlined using the DE<ALTERDE< DE<DISKGROUPDE<... DE<OFFLINEDE< statement without the DE<DROPDE< DE<AFTERDE< clause, then the value that is specified for the DE<DISK_REPAIR_TIMEDE< attribute for the disk group is used. If this attribute value is changed with the DE<ALTERDE< DE<DISKGROUPDE<... DE<SETDE< DE<ATTRIBUTEDE< DE<'disk_repair_time'DE< statement before this offlined disk is dropped, then the new (current) value of the attribute is used by the Oracle ASM disk offline functionality but the elapsed time is not reset. 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 DE<DROPDE< DE<AFTERDE< clause for this disk, the first value is overridden and the new value applies. A disk that is in DE<OFFLINEDE< mode cannot be dropped with an DE<ALTERDE< DE<DISKGROUPDE< DE<DROPDE< DE<DISKDE< 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 DE<OFFLINEDE< statement with a DE<DROPDE< DE<AFTERDE< clause specifying DE<0hDE< or DE<0mDE<.

You can use DE<ALTERDE< DE<DISKGROUPDE< to set the DE<DISK_REPAIR_TIMEDE< 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 DE<ALTERDE< DE<DISKGROUPDE< DE<DISKDE< DE<ONLINEDE<. 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 DE<DATA_001DE< offline and drops it after five minutes.

ALTER DISKGROUP data OFFLINE DISK DATA_001 DROP AFTER 5m;  

The next example takes the disk DE<DATA_001DE< offline and drops it after the time period designated by DE<DISK_REPAIR_TIMEDE< elapses:

ALTER DISKGROUP data OFFLINE DISK DATA_001;  

This example takes all of the disk in failure group DE<FG2DE< offline and drops them after the time period designated by DE<DISK_REPAIR_TIMEDE< elapses. IF you used a DE<DROPDE< DE<AFTERDE< clause, then the disks would be dropped after the specified time:

ALTER DISKGROUP data OFFLINE DISKS IN FAILGROUP FG2;  

The next example brings all of the disks in failure group DE<FG2DE< online:

ALTER DISKGROUP data ONLINE DISKS IN FAILGROUP FG2;  

This example brings only disk DE<DATA_001DE< online:

ALTER DISKGROUP data ONLINE DISK DATA_001;  

This example brings all of the disks in disk group DE<DATADE< online:

ALTER DISKGROUP data ONLINE ALL;  

Querying the DE<V$ASM_OPERATIONDE< view while you are running any of these types of DE<ALTERDE< DE<DISKGROUPDE< ... DE<ONLINEDE< 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 DE<OFFLINEDE< operation is not displayed in a DE<V$ASM_OPERATIONDE< view query.

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 preferred read failure groups 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.

See Also:

Oracle Real Application Clusters Administration and Deployment Guide for information about configuring preferred read disks in extended clusters

Configuring and Administering Preferred Read Failure Groups

To configure this feature, set the DE<ASM_PREFERRED_READ_FAILURE_GROUPSDE< 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 DE<diskgroupDE< is the name of the disk group and DE<failuregroupDE< 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:

DE<ASM_PREFERRED_READ_FAILURE_GROUPSDE< DE<=DE< DE<diskgroupDE<.DE<failuregroupDE<,...

In an extended cluster, the failure groups that you specify with settings for the DE<ASM_PREFERRED_READ_FAILURE_GROUPSDE< 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 DE<ASM_PREFERRED_READ_FAILURE_GROUPSDE< 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 DE<V$ASM_DISKDE< view that shows whether a disk is a preferred read disk by the value in the DE<PREFERRED_READDE< column. You can also use DE<V$ASM_DISKDE< 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 DE<V$ASM_DISK_IOSTATDE< view. This view displays disk I/O statistics for each Oracle ASM client. You can also query the DE<V$ASM_DISK_IOSTATDE< 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.

See Also:

Oracle Database Reference for details about the DE<V$ASMDE<* dynamic performance views

Performance and Scalability Considerations for Disk Groups

This section discusses the following considerations for evaluating disk group performance:

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 co-existing 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).

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 DE<COMPATIBLE.RDBMSDE< disk group attribute is set greater thanDE<10.1DE<.

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

  • External redundancy: 35 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 DE<DB_BLOCK_SIZEDE< initialization parameter.

For information about Oracle ASM disk group compatibility attributes, see "Disk Group Compatibility". For information about Oracle ASM file size limits, see Table 4-4.

Disk Group Compatibility

This section describes disk group compatibility under the following topics:

Overview of Disk Group Compatibility

Advancing the disk group compatibility settings enables you to use the new Oracle ASM features that are available in a later release. For example, a disk group with the disk group compatibility attributes set to 11.2 can take advantage of new Oracle 11g release 2 (11.2) features, such as Oracle ASM volumes in disk groups and Oracle ASM File Access Control. See Table 4-3 for the features enabled for combinations of compatibility attribute settings.

The disk group compatibility feature also enables environments to interoperate when they use disk groups from both Oracle Database 10g and Oracle Database 11g. For example, disk group compatibility settings that are set to Oracle Database 10g enable a 10g database client to access a disk group created with Oracle ASM 11g.

The disk group attributes that determine compatibility are DE<COMPATIBLE.ASMDE<, DE<COMPATIBLE.RDBMSDE<. and DE<COMPATIBLE.ADVMDE<. The DE<COMPATIBLE.ASMDE< and DE<COMPATIBLE.RDBMSDE< attribute settings determine the minimum Oracle Database software version numbers that a system can use for Oracle ASM and the database instance types respectively. For example, if the Oracle ASM compatibility setting is 11.2, and RDBMS compatibility is set to 11.1, then the Oracle ASM software version must be at least 11.2, and the Oracle Database client software version must be at least 11.1. The DE<COMPATIBLE.ADVMDE< attribute determines where the Oracle ASM Dynamic Volume Manager feature can be used to create Oracle ASM volumes in disk groups.

When you create a disk group, you can specify the disk group compatibility attribute settings in the DE<CREATEDE< DE<DISKGROUPDE< SQL statement. The DE<ALTERDE< DE<DISKGROUPDE< SQL statement can update the compatible attribute settings for existing disk groups. If not specified when using the DE<CREATEDE< DE<DISKGROUPDE< SQL statement, DE<10.1DE< is the default setting for both the DE<COMPATIBLE.ASMDE< and DE<COMPATIBLE.RDBMSDE< attributes for Oracle ASM in Oracle Database 11g. The DE<COMPATIBLE.ADVMDE< attribute is empty if it is not set. See Table 4-2 for examples of valid combinations of compatible attribute settings.

Notes:

  • The disk group compatibility settings determine whether your environment can use the latest Oracle ASM features.

  • The disk group compatibility settings can only be advanced; you cannot revert to a lower compatibility setting. See "Reverting Disk Group Compatibility".

  • The DE<COMPATIBLE.ASMDE< attribute must be advanced before advancing other disk group compatibility attributes and its value must be greater than or equal to the value of other disk group compatibility attributes.

Disk Group Compatibility Attributes

The disk group compatibility attributes specify the disk group compatibility settings for Oracle ASM and database instances. These attributes are described under the following topics:

COMPATIBLE.ASM

The value for the disk group DE<COMPATIBLEDE<.DE<ASMDE< 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, DE<10.1DE< is the default setting for the DE<COMPATIBLE.ASMDE< attribute when using the SQL DE<CREATEDE< DE<DISKGROUPDE< statement, the ASMCMD DE<mkdgDE< command, and Oracle Enterprise Manager Create Disk Group page. When creating a disk group with ASMCA, the default setting is DE<11.2DE<.

COMPATIBLE.RDBMS

The value for the disk group DE<COMPATIBLE.RDBMSDE< attribute determines the minimum DE<COMPATIBLEDE< database initialization parameter setting for any database instance that is allowed to use the disk group. Before advancing the DE<COMPATIBLEDE<.DE<RDBMSDE< attribute, ensure that the values for the DE<COMPATIBLEDE< initialization parameter for all of the databases that access the disk group are set to at least the value of the new setting for DE<COMPATIBLEDE<.DE<RDBMSDE<.

For example, if the DE<COMPATIBLEDE< initialization parameters of the databases are set to either DE<11.1DE< or DE<11.2DE<, then DE<COMPATIBLE.RDBMSDE< can be set to any value between DE<10.1DE< and DE<11.1DE< inclusively.

For Oracle ASM in Oracle Database 11g, DE<10.1DE< is the default setting for the DE<COMPATIBLEDE<.DE<RDBMSDE< attribute when using the SQL DE<CREATEDE< DE<DISKGROUPDE< statement, the ASMCMD DE<mkdgDE< command, ASMCA Create Disk Group page, and Oracle Enterprise Manager Create Disk Group page.

Note:

The database initialization parameter DE<COMPATIBLEDE< enables you to use a new release of Oracle Database, while at the same time guaranteeing backward compatibility with an earlier release. See Oracle Database Reference for more information about the DE<COMPATIBLEDE< initialization parameter.

COMPATIBLE.ADVM

The value for the disk group DE<COMPATIBLE.ADVMDE< 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 DE<COMPATIBLE.ASMDE< value must be 11.2 or higher. Also, the Oracle ADVM volume drivers must be loaded.

By default, the value of the DE<COMPATIBLE.ADVMDE< attribute is empty until set.

For more information about Oracle ADVM, see "Overview of Oracle ASM Dynamic Volume Manager".

Setting Disk Group Compatibility Attributes

This section discusses the settings of the disk group compatibility attributes and how to set the attribute values with the DE<CREATEDE< DE<DISKGROUPDE< or DE<ALTERDE< DE<DISKGROUPDE< SQL statement.

This section contains these topics:

You can also set the disk group compatibility settings with Oracle Enterprise Manager, Oracle ASM command-line utility (ASCMD), and Oracle ASM Configuration Assistant (ASMCA). See Chapter 9, "Administering Oracle ASM with Oracle Enterprise Manager", Chapter 11, "Oracle ASM Configuration Assistant", and Chapter 12, "Oracle ASM Command-Line Utility".

Note:

Advancing the values for disk group compatibility attributes is an irreversible operation. See "Reverting Disk Group Compatibility".

See Also:

Oracle Database SQL Language Reference for more information about the disk group compatibility SQL statements

Valid Combinations of Compatibility Attribute Settings

When setting the values for the disk group attributes, specify at least the major and minor versions of a valid Oracle Database release number. For example, you can specify compatibility as DE<'11.1'DE< or DE<'11.2'DE<; Oracle assumes that any missing version number digits are zeros.

Table 4-2 shows some valid combinations of the disk group compatibility attributes and the valid Oracle ASM and database instance versions for each combination.

Table 4-2 Examples of Disk Group Compatibility Attribute Settings

COMPATIBLE.ASM COMPATIBLE.RDBMS COMPATIBLE.ADVM ASM Instance Version COMPATIBLE Setting for RDBMS Instance

10.1

10.1

n/a

>= 10.1

>= 10.1

11.1

10.1

n/a

>= 11.1

>= 10.1

11.2

11.1

11.2

>= 11.2

>= 11.1

11.2

11.2

11.2

>= 11.2

>= 11.2


These are some possible combinations of Oracle ASM and database releases:

  • The database release is 11g release 2 (11.2) (DE<COMPATIBLEDE< set to DE<11.2DE<) and the Oracle ASM release is 11g release 2 (11.2). The DE<COMPATIBLE.ASMDE< attribute is set to DE<10.1DE< and the Oracle ASM functionality remains at 10g.

  • The database release is 10g and the Oracle ASM release is 11.1. Both the DE<COMPATIBLE.ASMDE< and DE<COMPATIBLE.RDBMSDE< disk group attributes are set to the default value of DE<10.1DE<. The Oracle ASM disk group functionality remains at 10g.

  • The database release is 10g and the Oracle ASM release is 11.2. DE<COMPATIBLE.ASMDE< is set to DE<11.2DE< and DE<COMPATIBLE.RDBMSDE< is set to DE<10.1DE<. The Oracle ASM disk group attributes are displayed in the DE<V$ASM_ATTRIBUTEDE< view. Additional disk group functionality is described in Table 4-3.

  • The database release is 11.2 (DE<COMPATIBLEDE< set to DE<11.2DE<) and the Oracle ASM release is 11.2. All the disk group compatibility attributes are set to DE<11.2DE<. The Oracle ASM disk group attributes are displayed in the DE<V$ASM_ATTRIBUTEDE< view. Additional disk group functionality is described in Table 4-3.

Using CREATE DISKGROUP with Compatibility Attributes

You can specify the compatibility settings for a disk group with the DE<CREATEDE< DE<DISKGROUPDE< statement when creating the disk group.

The following example creates a normal redundancy disk group DE<data1DE< with the Oracle ASM compatibility set to DE<11.2DE< and the RDBMS compatibility set to the default (the DE<COMPATIBLE.RDBMSDE< default is less than or equal to 11.2):

CREATE DISKGROUP data1 DISK '/dev/sd*'          ATTRIBUTE 'compatible.asm' = '11.2';  

The following example creates a normal redundancy disk group DE<data2DE< with the ASM, RDBMS, and ADVM compatibility set to DE<11.2DE<:

CREATE DISKGROUP data2 DISK '/dev/sd*'          ATTRIBUTE 'compatible.asm' = '11.2', 'compatible.rdbms' = '11.2',                   'compatible.advm' = '11.2';  

Using ALTER DISKGROUP with Compatibility Attributes

After a disk group has been created, you can use the DE<ALTERDE< DE<DISKDE<DE<GROUPDE< SQL statement to change the compatibility attributes. The DE<ALTERDE< DE<DISKDE<DE<GROUPDE< SQL statement ensures that Oracle can advance the compatibility of the specified disk group before committing the change.

All of the affected databases and file systems should be online when running DE<ALTERDE< DE<DISKGROUPDE< to ensure that advancing compatibility does not reduce the database and file system access. When advancing disk group compatibility, you must advance the DE<COMPATIBLEDE<.DE<ASMDE< attribute before the DE<COMPATIBLEDE<.DE<RDBMSDE< or DE<COMPATIBLE.ADVMDE< attribute to ensure a valid combination of compatible attribute settings as shown in Table 4-2. You can advance only one compatibility attribute in a single DE<ALTERDE< DE<DISKGROUPDE< statement.

The following example advances the Oracle ASM compatibility for disk group DE<data3DE< to DE<11.2DE<. An Oracle ASM instance must be at release DE<11.2DE< or higher to access the DE<data3DE< disk group.

ALTER DISKGROUP data3 SET ATTRIBUTE 'compatible.asm' = '11.2';  

The following example advances the RDBMS and ADVM compatibility of the disk group DE<data3DE< to DE<11.2DE<. This example assumes that the ASM compatibility value is set to DE<11.2DE<.

ALTER DISKGROUP data3 SET ATTRIBUTE 'compatible.rdbms' = '11.2',                                         'compatible.advm' = '11.2';  

Viewing Compatibility Attribute Settings

You can view the disk group compatibility settings in the DE<V$ASM_ATTRIBUTEDE< view. However, the DE<V$ASM_ATTRIBUTEDE< view does not display any rows when the DE<COMPATIBLE.ASMDE< value is set to DE<10.1DE<. Instead you can determine the values for the DE<COMPATIBLE.ASMDE< and DE<COMPATIBLE.RDBMSDE< disk group compatibility attributes with the DE<COMPATIBILITYDE< and DE<DATABASE_COMPATIBILITYDE< columns of the DE<V$ASM_DISKGROUPDE< view.

See Example 6-1, "Viewing Disk Group Attributes With V$ASM_ATTRIBUTE" for an example querying the DE<V$ASM_ATTRIBUTEDE< view.

You can also display the disk group compatibility attributes with the ASMCMD command DE<lsattrDE<. For information about DE<lsattrDE<, see "lsattr".

See Also:

Features Enabled By Disk Group Compatibility Attribute Settings

Table 4-3 describes the features enabled by valid combinations of the disk group compatibility attribute settings.

Table 4-3 Features Enabled by Disk Group Compatibility Attribute Settings

Disk Group Features Enabled COMPATIBLE.ASM COMPATIBLE.RDBMS COMPATIBLE.ADVM

Support for larger AU sizes (32 or 64 MB)

>= 11.1

>= 11.1

n/a

Attributes are displayed in the DE<V$ASM_ATTRIBUTEDE< view

>= 11.1

n/a

n/a

Fast mirror resync

>= 11.1

>= 11.1

n/a

Variable size extents

>= 11.1

>= 11.1

n/a

Exadata storage

>= 11.1.0.7

>= 11.1.0.7

n/a

Intelligent Data Placement

>= 11.2

>= 11.2

n/a

OCR and voting disks in a disk group

>= 11.2

n/a

n/a

Sector size set to nondefault value

>= 11.2

>= 11.2

n/a

Oracle ASM SPFILE in a disk group

>= 11.2

n/a

n/a

Oracle ASM File Access Control

>= 11.2

>= 11.2

n/a

Volumes in disk groups

>= 11.2

n/a

>= 11.2


The following list applies to Table 4-3.

  • Oracle ASM features not explicitly listed in Table 4-3 do not require advancing the disk group compatibility attribute settings.

  • The value of DE<COMPATIBLE.ASMDE< must always be greater than or equal to the value of DE<COMPATIBLE.RDBMSDE<.

  • A value of not applicable (n/a) means that the setting of the attribute has no effect on the feature.

Reverting Disk Group Compatibility

Advancing the values for disk group compatibility attributes is an irreversible operation. If you advance the disk group compatibility settings, you cannot change the values back to the previous settings. To revert to the previous values, you must create a new disk group with the old compatibility attribute settings and then restore the database files that were in the disk group to the new disk group.

When you revert to a new disk group with the old compatibility attribute settings, the latest Oracle ASM features might not be available. For example, if you revert the disk group compatibility to a pre-11.2 value, Oracle ACFS functionality is not available.

For example, you could perform the following procedure to revert a disk group to previous compatibility settings:

  1. If the Oracle ASM SPFILE is in the disk group, move this SPFILE out of the disk group:

    1. Connect with SQL*Plus to the Oracle ASM instance.

    2. Create a PFILE in the file system.

      For example:

      SQL> CREATE PFILE '$ORACLE_HOME/dbs/asmspfile.ora' FROM SPFILE  
  2. If the OCR and voting disks are in the disk group, move them out of this disk group.

    See Also:

    The Oracle Clusterware Administration and Deployment Guide for information about administering OCR and voting disks
  3. Back up any files that must be saved.

    1. Back up the database files.

    2. If an Oracle ACFS file system is mounted on an Oracle ADVM volume on the disk group, the operating system files in the file system must be backed up or copied to a location outside the file system mount point.

  4. Create a new disk group using SQL DE<CREATEDE< DE<DISKGROUPDE< specifying the previous values for the disk group attribute settings.

    For information about creating a disk group, see "Using the CREATE DISKGROUP SQL Statement".

  5. Restore the database files into the newly created disk group using Recovery Manager (RMAN).

    For information about moving data files between disk groups, see "Moving Data Files Between Oracle ASM Disk Groups Using RMAN".

  6. Drop the disk group with the advanced disk group compatibility settings using SQL DE<DROPDE< DE<DISKGROUPDE< DE<INCLUDINGDE< DE<CONTENTSDE< to remove the disk group and its contents.

    This SQL statement also removes any Oracle ACFS file system and its contents.

    For information about dropping a disk group, see "Dropping Disk Groups".

Considerations When Setting Disk Group Compatibility in Replicated Environments

If you advance disk group compatibility, then you could enable the creation of files that are too large to be managed by a previous Oracle database release. You must be aware of the file size limits because replicated sites cannot continue using the software from a previous release to manage these large files. The disk group compatibility settings should be the same for all replicated environments.

Table 4-4 shows the maximum Oracle ASM file sizes supported for DE<COMPATIBLE.RDBMSDE< settings when the DE<AU_SIZEDE< attribute is set to one megabyte for a disk group.

Table 4-4 Maximum Oracle ASM File Sizes for Disk Groups With AU_SIZE Equal to 1 MB

Redundancy COMPATIBLE.RDBMS = 10.1 COMPATIBLE.RDBMS >= 11.1

External

16 TB

140 PB

Normal

5.8 TB

23 PB

High

3.9 TB

15 PB


Table 4-4 shows that Oracle Database 10g can only support a file size of up to 16 TB for external redundancy. If you advance the DE<COMPATIBILE.RDBMSDE< attribute to DE<11.1DE< or greater, then a file can grow beyond 16 TB. However, the larger size causes the file to be unusable in a replicated and disaster recovery site if the disaster recovery site has a disk group DE<COMPATIBLE.RDBMSDE< setting that is incompatible with the larger size.

For information about Oracle ASM storage sizes, see "Oracle ASM Storage Limits".

See Also:

Managing Oracle ASM File Access Control for Disk Groups

Oracle ASM File Access Control provides optional protection for the content of Oracle ASM disk groups from accidental access by unauthorized Oracle ASM clients, such as an unauthorized database.

To set up Oracle ASM File Access Control, you must designate separate operating system groups as described in "Using Separate Operating System Groups for Oracle ASM Users". Oracle ASM File Access Control is available for Linux and UNIX computers only.

You can manage Oracle ASM file access control with ASMCMD commands, Oracle Enterprise Manager, and SQL statements.

This section contains these topics:

For information about managing Oracle ASM File Access Control with ASMCMD commands, see "ASMCMD File Access Control Commands".

For information about managing Oracle ASM File Access Control with Oracle Enterprise Manager, see "Managing Oracle ASM File Access Control with Oracle Enterprise Manager".

For information about views that provide details about Oracle ASM file access control, see "Viewing Oracle ASM File Access Control Information".

For information about controlling accessing to Oracle ASM instances, see "Authentication for Accessing Oracle ASM Instances".

About Oracle ASM File Access Control

Oracle ASM File Access Control restricts the access of files to specific Oracle ASM clients that connect as SYSDBA. An Oracle ASM client is typically a database, which is identified as the user that owns the database instance home. Oracle ASM File Access Control uses this user name to identify a database. Oracle ASM File Access Control restricts access based on the operating system effective user identification number of a database owner. For example, in Table 3-2, "Separated Operating System Groups and Privileges for Oracle ASM Users" the databases are identified as DE<oracle1DE< and DE<oracle2DE<.

Oracle ASM uses file access control to determine the additional privileges that are given to a database that has been authenticated AS SYSDBA on the Oracle ASM instance. These additional privileges include the ability to modify and delete certain files, aliases, and user groups.

You can set up user groups to specify the list of databases that share the same access permissions to Oracle ASM files. User groups are lists of databases and any database that authenticates AS SYSDBA can create a user group. However, only the creator of a group can delete it or modify its membership list.

Each Oracle ASM file has three categories of privileges: owner, group, and other. Each category can have no permission, read-only permission, or read-write permission.

The file owner is usually the creator of the file and can assign permissions for the file in any of the owner, group, or other categories. The owner can also change the group associated with the file.

When administering Oracle ASM File Access Control, Oracle recommends that you connect as SYSDBA to the database instance that is the owner, or planned owner, of the files in the disk group.

To set up Oracle ASM File Access Control for files in a disk group, perform the following steps:

  1. Alter a new or existing disk group to set the Oracle ASM File Access Control disk group attributes.

    For a newly-created disk group, you should set the disk group attributes before creating any files in the disk group.

    See "Using SQL Statements to Set Disk Group Attributes for Oracle ASM File Access Control".

  2. For files that exist in a disk group before setting the Oracle ASM File Access Control disk group attributes, you must explicitly set the permissions and ownership on those existing files.

    Ensure that the user exists before setting ownership or permissions on a file. The file must be closed before setting the ownership or permissions.

    See DE<ALTERDE< DE<DISKGROUPDE< DE<SETDE< DE<PERMISSIONDE< and DE<ALTERDE< DE<DISKGROUPDE< DE<SETDE< DE<OWNERSHIPDE< in "Using SQL Statements to Set Disk Group Attributes for Oracle ASM File Access Control".

  3. Optionally, you can create user groups that are groups of database users that share the same access permissions to Oracle ASM files.

    See DE<ALTERDE< DE<DISKGROUPDE< DE<ADDDE< DE<USERGROUPDE< in "Using SQL Statements to Set Disk Group Attributes for Oracle ASM File Access Control".

Using SQL Statements to Set Disk Group Attributes for Oracle ASM File Access Control

To manage Oracle ASM File Access Control for a disk group, you must set the DE<ACCESS_CONTROL.ENABLEDDE< and DE<ACCESS_CONTROL.UMASKDE< disk group attributes when altering the disk group with the DE<ALTERDE< DE<DISKGROUPDE< SQL statement.

When you set up file access control on an existing disk group, the files previously created remain accessible by everyone, unless you run the DE<ALTERDE< DE<DISKGROUPDE< DE<SETDE< DE<PERMISSIONDE< SQL statement to restrict the permissions.

The DE<COMPATIBLE.ASMDE< and DE<COMPATIBLE.RDBMSDE< disk group attributes must be set to 11.2 or higher to enable Oracle ASM File Access Control.

The disk group attributes that control Oracle ASM File Access Control are the following:

  • DE<ACCESS_CONTROL.ENABLEDDE<

    This attribute determines whether Oracle ASM File Access Control is enabled for a disk group.

    The value can be DE<trueDE< or DE<falseDE<. The default is DE<falseDE<.

    If the attribute is set to DE<trueDE<, accessing Oracle ASM files is subject to access control. If DE<falseDE<, any user can access every file in the disk group. All other operations behave independently of this attribute.

  • DE<ACCESS_CONTROL.UMASKDE<

    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 {DE<0DE<|DE<2DE<|DE<6DE<} {DE<0DE<|DE<2DE<|DE<6DE<} {DE<0DE<|DE<2DE<|DE<6DE<}. The default is DE<066DE<.

    Setting to DE<0DE< masks out nothing. Setting to DE<2DE< masks out write permission. Setting to DE<6DE< masks out both read and write permissions.

    Before setting the DE<ACCESS_CONTROL.UMASKDE< disk group attribute, you must set the DE<ACCESS_CONTROL.ENABLEDDE< attribute to DE<trueDE< to enable Oracle ASM File Access Control.

Example 4-7 shows how to enable Oracle ASM File Access Control for a disk group with SQL*Plus. In this example, the permissions setting is DE<026DE< which enables read-write access for the owner, read access for users in the group, and no access to others not in the group

Example 4-7 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';  

Using SQL Statements to Manage Oracle ASM File Access Control

You can use the DE<ALTERDE< DE<DISKGROUPDE< SQL statement to manage file access control for Oracle ASM disk groups. These SQL statements are available for both database and Oracle ASM instances.

The SQL statements that support disk group access control are:

  • DE<ALTERDE< DE<DISKGROUPDE< DE<ADDDE< DE<USERGROUPDE< ... DE<WITHDE< DE<MEMBERDE<

    Adds an Oracle ASM user group to a disk group. The user group name is limited to a maximum of 30 characters. The databases identified in the DE<MEMBERDE< clause must be in the disk group, as shown by DE<V$ASM_USERDE<, or the command returns an error. Any users authenticated as DE<SYSASMDE< or DE<SYSDBADE< can create new user groups. For example:

    SQL> SELECT group_number, os_name FROM V$ASM_USER;    GROUP_NUMBER OS_NAME  ------------ ----------------------------------------------------------------             1 oracle1             1 oracle2  ...    SQL> ALTER DISKGROUP data ADD USERGROUP 'test_grp1'        WITH MEMBER 'oracle1','oracle2';  
  • DE<ALTERDE< DE<DISKGROUPDE< DE<DROPDE< DE<USERGROUPDE<

    Drops an Oracle ASM user group from a disk group. Dropping a group might leave some files without a valid group. For those files to have a valid group, you must manually update the group associated with those files to a valid group.

    SQL> ALTER DISKGROUP data DROP USERGROUP 'test_grp1';  
  • DE<ALTERDE< DE<DISKGROUPDE< DE<MODIFYDE< DE<USERGROUPDE< DE<ADDDE< DE<MEMBERDE<

    Adds users to the specified user group. The users must be in the disk group, as shown by DE<V$ASM_USERDE<, or the command returns an error. Only the creator of the group or the Oracle ASM administrator can modify group membership.

    SQL> ALTER DISKGROUP data MODIFY USERGROUP 'test_grp2' ADD MEMBER 'oracle2';  
  • DE<ALTERDE< DE<DISKGROUPDE< DE<MODIFYDE< DE<USERGROUPDE< DE<DROPDE< DE<MEMBERDE<

    Removes users from the specified user group. If a member is not in the user group, then an error is returned. Only the creator of the group or the Oracle ASM administrator can modify group membership.

    SQL> ALTER DISKGROUP data MODIFY USERGROUP 'test_grp2' DROP MEMBER 'oracle2';  
  • DE<ALTERDE< DE<DISKGROUPDE< DE<ADDDE< DE<USERDE<

    Adds operating system (OS) users to an Oracle ASM disk group, so that these users can have access privileges on the disk group. The users must be existing operating system users, and their user names must have a corresponding operating system user ID or system ID. If a user exists in the disk group, as shown by DE<V$ASM_USERDE<, then the command records an error and continues to add other users, if any.

    The operating system user of a running database instance is automatically added to a disk group when the database instance accesses that disk group and creates files. However, for a database instance to read files in a disk group without creating any files, then you must use the DE<ADDDE< DE<USERDE< clause to add that database user to the disk group. Also, you can use this clause to add a database user to an existing disk group immediately after setting the Oracle ASM File Access Control disk group attributes and before creating new files.

    SQL>  ALTER DISKGROUP DATA ADD USER 'oracle1';  
  • DE<ALTERDE< DE<DISKGROUPDE< DE<DROPDE< DE<USERDE<

    Drops operating system users from an Oracle ASM disk group. If a user is not in the disk group, then this command records an error and continues to drop other users, if any.

    If the user owns any files on the same Oracle ASM disk group, then this command fails with an error, unless the DE<CASCADEDE< keyword is specified. If the latter case, then the user is deleted, along with all the files that the user owns.

    If any files owned by the user are currently open, then the DE<DROPDE< DE<USERDE< command fails, and no files are deleted.

    SQL>  ALTER DISKGROUP DATA DROP USER 'oracle1';  
  • DE<ALTERDE< DE<DISKGROUPDE< DE<SETDE< DE<PERMISSIONDE<

    Modifies permissions of an Oracle ASM file. Setting DE<readDE< DE<onlyDE< permission to a file that has DE<readDE< DE<writeDE< permission revokes the DE<writeDE< permission. Only the file owner or the Oracle ASM administrator can change the permissions of a file. You cannot change the permissions on an open file.

    SQL> ALTER DISKGROUP data SET PERMISSION OWNER=read write, GROUP=read only,       OTHER=none FOR FILE '+data/controlfile.f';  
  • DE<ALTERDE< DE<DISKGROUPDE< DE<SETDE< DE<OWNERSHIPDE<

    Changes the owner or group of a file to the specified user or user group name, respectively. If the specified user or user group name does not exist, this command fails with an error. Only the owner of the file or the Oracle ASM administrator can issue this command, and only the Oracle ASM administrator can change the owner. Also, the user group name must exist, and the owner of the file must be a member of that group. You cannot change the ownership of an open file.

    SQL> ALTER DISKGROUP data SET OWNERSHIP OWNER='oracle1', GROUP='test_grp1'       FOR FILE '+data/controlfile.f';  

Mounting and Dismounting Disk Groups

Disk groups that are specified in the DE<ASM_DISKGROUPSDE< initialization parameter are mounted automatically at Oracle ASM instance startup. This makes them available to all database instances running on the same node as Oracle ASM. The disk groups are dismounted at Oracle ASM instance shutdown. Oracle ASM also automatically mounts a disk group when you initially create it, and dismounts a disk group if you drop it.

When a disk group is mounted, a disk group number is chosen. This number may change across disk group mounts. A disk group number is not recorded in any persistent structure, but the current value can be viewed in the DE<GROUP_NUMBERDE< column of the V$ASM views.

When you want to mount or dismount disk groups manually, use the DE<ALTER DISKGROUP...MOUNTDE< or DE<ALTER DISKGROUP...DISMOUNTDE< statement. You can mount or dismount disk groups by name, or specify DE<ALLDE<.

If you try to dismount a disk group that contains open files, the statement fails, unless you also specify the DE<FORCEDE< clause.

In a clustered Oracle ASM environment in DE<RESTRICTEDDE< mode, a disk group is mounted in single-instance exclusive mode. No other Oracle ASM instance in that cluster can mount that disk group. In this mode the disk group is not usable by any Oracle ASM client. Use this mode to perform a fast rebalance.

The following SQL statement dismounts all disk groups that are currently mounted to the Oracle ASM instance:

ALTER DISKGROUP ALL DISMOUNT;  

The following SQL statement mounts disk group DE<data1DE<:

ALTER DISKGROUP data1 MOUNT;  

Mounting Disk Groups Using the FORCE Option

Oracle ASM provides a DE<MOUNTDE< DE<FORCEDE< option with DE<ALTERDE< DE<DISKGROUPDE< to enable Oracle ASM disk groups to be mounted in normal or high redundancy modes even though some Oracle ASM disks may be unavailable to the disk group at mount time. The default behavior without the DE<FORCEDE< option is to fail to mount a disk group that has damaged or missing disks.

The DE<MOUNTDE< DE<FORCEDE< option is useful in situations where a disk is temporarily unavailable and you want to mount the disk group with reduced redundancy while you correct the situation that caused the outage.

To successfully mount with the DE<MOUNTDE< DE<FORCEDE< option, Oracle ASM must be able to find at least one copy of the extents for all of the files in the disk group. In this case, Oracle ASM can successfully mount the disk group, but with potentially reduced redundancy.

The disks that Oracle ASM cannot access are placed in an offline mode. Oracle ASM then begins timing the period that these disks are in an offline mode. If the disk offline time period exceeds the timer threshold set by DE<DISK_REPAIR_TIMEDE< disk group attribute, then those disks are permanently dropped from the disk group. You can change the offline timer after a disk is put in an offline state by using the DE<ALTERDE< DE<DISKGROUPDE< DE<OFFLINEDE< statement. For more information about setting the DE<DISK_REPAIR_TIMEDE< disk group attribute, see "Oracle ASM Fast Mirror Resync".

Note:

An Oracle ASM instance mounts an incomplete disk group differently depending on the specified compatibility. See "Features Enabled By Disk Group Compatibility Attribute Settings".

In clustered Oracle ASM environments, if an Oracle ASM instance is not the first instance to mount the disk group, then using the DE<MOUNTDE< DE<FORCEDE< statement fails. This is because the disks have been accessed by another instance and the disks are not locally accessible.

If all disks are available, then using the DE<FORCEDE< option causes the DE<MOUNTDE< command to fail. This discourages unnecessary and improper use of the feature.

The following example shows how to use the DE<FORCEDE< option to force the mount of the DE<data1DE< disk group:

ALTER DISKGROUP data1 MOUNT FORCE  

See Also:

The Oracle Database SQL Language Reference for additional information about the DE<ALTERDE< DE<DISKGROUPDE< statement and the DE<FORCEDE< option

Checking the Internal Consistency of Disk Group Metadata

You can check the internal consistency of disk group metadata using the DE<ALTERDE< DE<DISKGROUPDE< statement with the DE<CHECKDE< keyword. You can use this statement to check specific files in a disk group, specific disks or all disks in a disk group, or specific failure groups within a disk group. The disk group must be mounted to perform these checks.

By default, the DE<CHECKDE< DE<DISKDE< DE<GROUPDE< clause verifies all of the metadata directories. Oracle ASM displays summary errors and writes the details about the errors in an alert log. The DE<CHECKDE< keyword performs the following operations:

  • Verifies the consistency of the disk

  • Cross checks all of the file extent maps and allocation tables for consistency

  • Checks that the alias metadata directory and file directory are linked correctly

  • Verifies that the alias directory tree is linked correctly

  • Checks that Oracle ASM metadata directories do not have unreachable allocated blocks

The DE<REPAIRDE< DE<|DE< DE<NOREPAIRDE< clause specifies whether Oracle ASM should attempt to repair errors that are found during the check. The default is DE<NOREPAIRDE<. Use the DE<NOREPAIRDE< clause to receive alerts about inconsistencies and to suppress Oracle ASM from resolving the errors automatically. The following example statement checks for consistency in the metadata for all disks in the DE<data1DE< disk group:

ALTER DISKGROUP data1 CHECK ALL;  

See Also:

The Oracle Database SQL Language Reference for additional information about the DE<CHECKDE< clause syntax

Dropping Disk Groups

The DE<DROPDE< DE<DISKGROUPDE< statement enables you to delete an Oracle ASM disk group and optionally, all of its files. You can specify the DE<INCLUDINGDE< DE<CONTENTSDE< clause if you also want to delete all files that are contained in the disk group. The default is DE<EXCLUDINGDE< DE<CONTENTSDE<, which provides syntactic consistency and prevents you from dropping the disk group if it has any contents

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

When you drop a disk group, Oracle ASM dismounts the disk group and removes the disk group name from the DE<ASM_DISKGROUPSDE< 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 DE<ASM_DISKGROUPSDE< initialization parameter, then you must remove the disk group name from the DE<ASM_DISKGROUPSDE< initialization parameter before the next time that you shut down and restart the Oracle ASM instance.

The following statement deletes DE<data1DE<:

DROP DISKGROUP data1;  

After ensuring that none of the files contained in DE<data1DE< are open, Oracle ASM rewrites the header of each disk in the disk group to remove Oracle ASM formatting information. The statement does not specify DE<INCLUDING CONTENTSDE<, so the drop operation fails if the disk group contains any files.

If an Oracle Automatic Storage Management Cluster File System (Oracle ACFS) file system is mounted on a volume contained in the disk group, then the file system must be dismounted. If the file system has been registered, then it must be deregistered. The DE<INCLUDINGDE< DE<CONTENTSDE< clause must be used to drop this disk group. All data in the file system is destroyed. To view the volumes and mount paths associated with a disk group, you can query the DE<V$ASM_VOLUMEDE< view. For an example of a query on the DE<V$ASM_VOLUMEDE< view, see Example 6-14. For information about deregistering and dismounting Oracle ACFS file systems, see "Deregistering, Dismounting, and Disabling Volumes and Oracle ACFS File Systems".

If you cannot mount a disk group but must drop it, you can use the DE<FORCEDE< option of the DE<DROPDE< DE<DISKGROUPDE< statement. This command enables you to remove the headers on disks that belong to a disk group that cannot be mounted by any Oracle ASM instances as shown in the following example:

DROP DISKGROUP data1 FORCE  

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

Note:

Use the DE<FORCEDE< option with extreme caution.

You can also drop a disk group with Oracle Enterprise Manager. See "Dropping Disk Groups".

Renaming Disks Groups

The DE<renamedgDE< tool enables you to change the name of a cloned disk group. The disk group must be dismounted on all nodes in the cluster before running DE<renamedgDE< on the disk group.

DE<renamedgDE< renames a disk group using a two-step process:

  1. Phase one

    This phase generates a configuration file to be used in phase two.

  2. Phase two

    This phase uses the configuration file to perform the renaming of the disk group.

The syntax is:


DE<renamedgDE< {DE<-helpDE< | DE<help=trueDE<}

DE<renamedgDE<
DE<    DE< [DE<phaseDE<={ DE<oneDE<|DE<twoDE< |DE<bothDE< } ] DE<dgname=DE<DE<diskgroupDE<
DE<    DE< DE<newdgname=DE<DE<newdiskgroupDE< [DE<config=DE<DE<configfileDE<]
DE<    DE< [ DE<asm_diskstring=DE<DE<discoverystringDE<DE<,DE< DE<discoverystringDE< ... ]
DE<    DE< [ DE<clean=DE<{DE<trueDE<|DE<falseDE<} ] [ DE<check=DE<{DE<trueDE<|DE<falseDE<} ]
DE<    DE< [ DE<confirm=DE<{DE<trueDE<|DE<falseDE<}] [ DE<verbose=DE<{ DE<trueDE<|DE<falseDE<} ]
DE<    DE< [ DE<keep_voting_files=DE<{DE<trueDE<|DE<falseDE<}]
  • DE<phase=DE<{DE<oneDE<|DE<twoDE<|DE<bothDE<}

    Specifies the phase to be executed. Allowed values are DE<oneDE<, DE<twoDE<, or DE<bothDE<. This argument is optional. The default is DE<bothDE<.

    Typically you would run both phases. If a problem occurs during the second phase, then you can re-run phase DE<twoDE< using the generated configuration file.

  • DE<dgname=DE<DE<diskgroupDE<

    Specifies the name of the disk group that to be renamed.

  • DE<newdgname=DE<DE<newdiskgroupDE<

    Specifies the new name for the disk group.

  • DE<config=DE<DE<configfileDE<

    Specifies the path to the configuration file to be generated during phase one or specifies the path to the configuration file to be used during phase two.

    This argument is optional. The default configuration file is named DE<renamedg_configDE< and is located in the directory in which the command is executed. The single quotations may be required on some platforms.

  • DE<asm_diskstring=DE<DE<discoverystringDE<DE<,DE< DE<discoverystringDE< ...

    Specifies the Oracle ASM discovery strings. The DE<asm_diskstringDE< value must be specified if the Oracle ASM disks are not in the default location for the platform. The single quotations may be required on some platforms, usually when wildcard characters are specified.

  • DE<clean=DE<{DE<trueDE<|DE<falseDE<}

    Specifies whether to tolerate errors that are otherwise ignored. The default is DE<trueDE<.

  • DE<check=DE<{DE<trueDE<|DE<falseDE<}

    Specifies a boolean value that is used in the second phase. If DE<trueDE<, then the tool prints the list of changes that are to be made to the disks. No writes are issued. It is an optional parameter that defaults to DE<falseDE<.

  • DE<confirm=DE<{DE<trueDE<|DE<falseDE<}

    Specifies a boolean value that is used in the second phase. If DE<falseDE<, then the tool prints the changes that are to be made and seeks confirmation before actually making the changes. It is an optional value that defaults to DE<falseDE<. If check is set to DE<trueDE<, then the value of this parameter is redundant.

  • DE<verbose=DE<{DE<trueDE<|DE<falseDE<}

    Specifies verbose execution when DE<verbose=trueDE<. The default is DE<falseDE<.

  • DE<keep_voting_files=DE<{DE<trueDE<|DE<falseDE<}

    Specifies whether voting files are kept in the renamed disk group. The default is DE<falseDE< which deletes the voting files from the renamed disk group.

Note:

DE<renamedgDE< does not update resources, nor does DE<renamedgDE< update any file references within the database. Because of this behavior, the original disk group resource is not automatically deleted after the completion of phase DE<twoDE<. The status of the old disk group resource can be checked with the Oracle Clusterware Control (CRSCTL) DE<crsctlDE< DE<statDE< DE<resDE< DE<-tDE< command and then manually deleted with the Server Control Utility (SRVCTL) DE<srvctlDE< DE<removeDE< DE<diskgroupDE< command.

Example 4-8 shows several examples of the use of DE<renamedgDE<. The first example renames the DE<dataDE< disk group to DE<new_dataDE< using a disk string to locate the disks and the DE<verboseDE< option is enabled. The second example only creates a configuration file during the completion of phase DE<oneDE< of the DE<renamedgDE< operation. The third example runs phase DE<twoDE< of the DE<renamedgDE< operation using a configuration file generated from a phase DE<oneDE< execution of DE<renamedgDE<.

Example 4-8 Using renamedg

$ renamedg dgname=data newdgname=new_data asm_diskstring='/devices/disk*'        verbose=true    $ renamedg phase=one dgname=data newdgname=new_data        asm_diskstring='/devices/disk*' config=/tmp/data2.conf verbose=true    $ renamedg phase=two dgname=data newdgname=new_data config=/tmp/data2.conf        verbose=true  



引文来源  Administering Oracle ASM Disk Groups
  评论这张
 
阅读(1437)| 评论(0)

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018