czmmiao
czmmiao

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 Cloud Storage page on the Oracle Technology Network Web site at http://www.oracle.com/technetwork/database/cloud-storage/index.html for more information about Oracle ASM

Disk Group Attributes

Disk group attributes are parameters that are bound to a disk group, rather than an Oracle ASM instance.

Disk group attributes can be set when a disk group is created or altered, unless otherwise noted in the following list.

  • ACCESS_CONTROL.ENABLED

    This attribute can only be set when altering a disk group.

    For information about the ACCESS_CONTROL.ENABLED attribute, see "Setting Disk Group Attributes for Oracle ASM File Access Control".

  • ACCESS_CONTROL.UMASK

    This attribute can only be set when altering a disk group.

    For information about the ACCESS_CONTROL.UMASK attribute, see "Setting Disk Group Attributes for Oracle ASM File Access Control".

  • AU_SIZE

    This attribute can only be set when creating a disk group.

    For information about allocation unit size and extents, see "Allocation Units", "Extents", and "Specifying the Allocation Unit Size". For an example of the use of the AU_SIZE attribute, see Example 4-1, "Creating the DATA disk group".

  • CELL.SMART_SCAN_CAPABLE

    This attribute is only applicable to Oracle Exadata storage.

    See Also:

    Oracle Exadata documentation

  • COMPATIBLE.ASM

    For information about the COMPATIBLE.ASM attribute, see "COMPATIBLE.ASM".

  • COMPATIBLE.RDBMS

    For information about the COMPATIBLE.RDBMS attribute, see "COMPATIBLE.RDBMS".

  • COMPATIBLE.ADVM

    For information about the COMPATIBLE.ADVM attribute, see "COMPATIBLE.ADVM" and "Overview of Oracle ASM Dynamic Volume Manager".

  • CONTENT.TYPE

    The CONTENT.TYPE attribute identifies the disk group type: data, recovery, or system. The type value determines the distance to the nearest neighbor disk in the failure group where Oracle ASM mirrors copies of the data. The default value is data which specifies a distance of 1 to the nearest neighbor disk. A value of recovery specifies a distance of 3 to the nearest neighbor disk and a value of system specifies a distance of 5.

    The attribute can be specified when creating or altering a disk group. If CONTENT.TYPE attribute is set or changed using ALTER DISKGROUP, then the new configuration does not take effect until a disk group rebalance is explicitly run.

    The CONTENT.TYPE attribute is only valid for disk groups that are set to normal or high redundancy. The COMPATIBLE.ASM attribute must be set to 11.2.0.3 or higher to enable the CONTENT.TYPE attribute for the disk group.

    The attribute can be set with SQL, ASMCMD, or ASMCA. For example:

    SQL> CREATE DISKGROUP data NORMAL REDUNDANCY
        FAILGROUP controller1 DISK
        '/devices/diska1' NAME diska1,
...
        ATTRIBUTE 
        'compatible.asm' = '11.2.0.3', 
        'content.type' = 'recovery',
...

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

    This attribute is primarily intended for use with Oracle Exadata storage.

    See Also:

    Oracle Exadata documentation

  • DISK_REPAIR_TIME

    This attribute can only be set when altering a disk group.

    For information about the DISK_REPAIR_TIME attribute, see "Oracle ASM Fast Mirror Resync".

  • IDP.BOUNDARY and IDP.TYPE

    These attributes are intended for use with Oracle Exadata storage.

    See Also:

    Oracle Exadata documentation

  • SECTOR_SIZE

    This attribute can only be set when creating a disk group.

    For information about the SECTOR_SIZE attribute, see "Specifying the Sector Size for Drives".

  • STORAGE.TYPE

    The STORAGE.TYPE disk group attribute specifies the type of the disks in the disk group. The possible values are AXIOM, ZFSSA, and OTHER. If the attribute is set to AXIOM or ZFSSA, then all disks in the disk group must be of that type. If the attribute is set to OTHER, then any types of disks can be in the disk group.

    If the STORAGE.TYPE disk group attribute is set to AXIOM or ZFSSA, then functionality for Hybrid Columnar Compression (HCC) can be enabled for Pillar Axiom or ZFS storage.

    Note:

    ZFS storage must be added through Direct NFS (dNFS) and Pillar Axiom storage must be added as SCSI/Fiber Channel.

    To set the STORAGE.TYPE attribute, the COMPATIBLE.ASM and COMPATIBLE.RDBMS disk group attributes must be set to 11.2.0.3 or higher. For information about disk group compatibility attributes, refer to "Disk Group Compatibility".

    The STORAGE.TYPE attribute can be set when creating a disk group or when altering a disk group. The attribute cannot be set when clients are connected to the disk group. For example, the attribute cannot be set when an Oracle ADVM volume is enabled on the disk group.

    The attribute is not visible in the V$ASM_ATTRIBUTE view or with the ASMCMD lsattr command until the attribute has been set.

    See Also:

    Oracle Database Concepts for more information about Hybrid Columnar Compression. Hybrid Columnar Compression is a feature of certain Oracle storage systems.

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 V$ASM_ATTRIBUTE view and the ASMCMD lsattr command. For an example of the use of the V$ASM_ATTRIBUTE view, see Example 6-1. For information about the lsattr command, see "lsattr".

Creating Disk Groups

This section contains information about creating disk groups. You can use the CREATE DISKGROUP SQL statement to create a disk group.

This section contains the following topics:

Using the CREATE DISKGROUP SQL Statement

The CREATE DISKGROUP 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 CREATE DISKGROUP " 1DATA", 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 NORMAL REDUNDANCY (2-way mirroring by default for most file types) or HIGH REDUNDANCY (3-way mirroring for all files). Specify EXTERNAL REDUNDANCY if you do not want mirroring by Oracle ASM. For example, you might choose EXTERNAL REDUNDANCY 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 "Mirroring, Redundancy, and Failure Group Options".

  • 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 NAME 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 "Mirroring, Redundancy, and Failure Group Options".

  • Optionally specify the type of failure group.

    For information about QUORUM and REGULAR failure groups, refer to "Oracle Cluster Registry and Voting Files in Oracle ASM Disk Groups".

  • Optionally specify disk group attributes, such as 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 SIZE 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 NAME clause. Disk names are available in the V$ASM_DISK 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 FORCE only when adding a disk that was dropped with FORCE. If a disk is dropped with NOFORCE, then you can add it with NOFORCE. 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 FORCE 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 FORCE option to add a previously used disk to a disk group; you might cause another disk group to become unusable.

The CREATE DISKGROUP statement mounts the disk group for the first time, and adds the disk group name to the ASM_DISKGROUPS 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 ASM_DISKGROUPS initialization parameter before you shut down and restart the Oracle ASM instance. You can also create disk groups with Oracle Enterprise Manager. Refer to "Creating Disk Groups".

See Also:

The CREATE DISKGROUP SQL statement in the Oracle Database SQL Language Reference

Example: Creating a Disk Group

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

Controller 1:


/devices/diska1
/devices/diska2
/devices/diska3
/devices/diska4

Controller 2:
/devices/diskb1
/devices/diskb2
/devices/diskb3
/devices/diskb4

The SQL statement in Example 4-1 creates a disk group named data with normal redundancy consisting of two failure groups controller1 or controller2 with four disks in each failure group. The data 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 NAME clauses enable you to explicitly assign names to the disks rather than the default system-generated names. The system-generated names are in the form diskgroup_nnnn, where nnnn is the disk number for the disk in the disk group. For ASMLib disks, the disk name defaults to the ASMLib name that is the user label of the disk; for example, mydisk is the default Oracle ASM disk name for ORCL:mydisk.

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

  • AU_SIZE

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

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

  • COMPATIBLE.ASM

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

  • COMPATIBLE.RDBMS

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

  • COMPATIBLE.ADVM

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

In Example 4-2, the fra 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 example assumes that diskc1 through diskc9 are present in the /devices 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 http://www.oracle.com/technetwork/topics/linux/asmlib/index-101839.html

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 data disk group is used for the storage of the database data files and the fra 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 data 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 data disk group is the disk group used for storing Oracle Cluster Registry (OCR) and voting files 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 fra disk group for storing the fast recovery area files.

    Create the fra disk group to hold the fast recovery area files.

    At this time, you can also update the data 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 fra 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 data disk group

    • Store fast recovery area files in the fra 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 of a 4 MB allocation unit are:

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

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

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

  • Increased file size limits.

  • Reduced database open time.

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

Specifying the Sector Size for Drives

You can use the optional SECTOR_SIZE disk group attribute with the CREATE DISKGROUP SQL statement to specify disks with the sector size set to the value of SECTOR_SIZE for the disk group. Oracle ASM provides support for 4 KB sector disk drives without negatively affecting performance. The SECTOR_SIZE disk group attribute can be set only during disk group creation.

The values for SECTOR_SIZE can be set to 512, 4096, or 4K if the disks support those values. The default value is platform dependent. The COMPATIBLE.ASM and COMPATIBLE.RDBMS disk group attributes must be set to 11.2 or higher to set the sector size to a value other than the default value.

Note:

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

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

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

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

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

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

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

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

    SQL> SELECT name, value FROM V$ASM_ATTRIBUTE 
     WHERE name = 'sector_size' AND group_number = 1;
NAME                        VALUE
--------------------------- -----------------------
sector_size                 512

SQL> SELECT group_number, sector_size FROM V$ASM_DISKGROUP 
     WHERE group_number = 1;

GROUP_NUMBER SECTOR_SIZE
------------ -----------
           1         512

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

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

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

CREATE DISKGROUP data NORMAL REDUNDANCY
FAILGROUP controller1 DISK
'/devices/diska1',
'/devices/diska2',
'/devices/diska3',
'/devices/diska4'
FAILGROUP controller2 DISK
'/devices/diskb1',
'/devices/diskb2',
'/devices/diskb3',
'/devices/diskb4'
ATTRIBUTE 'compatible.asm' = '11.2', 'compatible.rdbms' = '11.2',
          'sector_size'='4096';

See Also:

Oracle Cluster Registry and Voting Files in Oracle ASM Disk Groups

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

Voting files 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. A quorum failure group is not considered when determining redundancy requirements in respect to storing user data. However, a quorum failure group counts when mounting a disk group. For information about failure groups, see "Oracle ASM Failure Groups".

You can manage and monitor OCR and voting files with the following:

  • The CRSCTL and ocrconfig command-line tools

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

  • CREATE/ALTER DISKGROUP SQL Statements

    The SQL keywords QUORUM and REGULAR enable the specification of disk and failure groups when creating or altering disk groups.

    See Example 4-4.

  • V$ASM views

    The FAILGROUP_TYPE column in both the V$ASM_DISK and V$ASM_DISK_STAT views specifies failure group type. The value for this column is REGULAR for regular failure groups and QUORUM for quorum failure groups.

    The VOTING_FILE column in both the V$ASM_DISK and V$ASM_DISK_STAT views specifies whether a disk contains a voting file. The value for this column is either Y if the disk contains a voting file or N if not.

    Note that the value of USABLE_FILE_MB in V$ASM_DISKGROUP and V$ASM_DISKGROUP_STAT does not consider any free space that is present in QUORUM disks because that space is not available for client data files.

    See "Views Containing Oracle ASM Disk Group Information".

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

You can use these keywords before the keyword FAILGROUP if a failure group is being explicitly specified. If the failure group is implicitly implied, you can use these keywords (QUORUM/REGULAR) before the keyword DISK. When failure groups are explicitly specified, it is an error to specify these keywords (QUORUM/REGULAR) immediately before the keyword DISK. REGULAR 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-4 shows the creation of a disk group with a QUORUM failure group. For Oracle Clusterware files a minimum of three disk devices or three failure groups is required with a normal redundancy disk group. A QUORUM failure group is not considered when determining redundancy requirements in respect to storing user data.

The COMPATIBLE.ASM disk group compatibility attribute must be set to 11.2 or greater to store OCR or voting files in a disk group.

Example 4-4 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 ALTER DISKGROUP 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 ALTER DISKGROUP statement are recommended. Grouping operations in a single ALTER DISKGROUP statement can reduce rebalancing operations.

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

Use the REBALANCE WAIT clause to cause the ALTER DISKGROUP statement processing to wait until the rebalance operation is complete before returning. This is especially useful in scripts. The statement also accepts a REBALANCE NOWAIT 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 CTRL-C on most platforms. This causes the statement to return immediately with the message ORA-01013: user requested cancel of current operation, and then to continue the operation asynchronously. Typing CTRL-C 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 REBALANCE POWER 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:

See Also:

The ALTER DISKGROUP SQL statement in the Oracle Database SQL Language Reference

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 COMPATIBLE.ASM and COMPATIBLE.ADVM must be set to 11.2 or higher for the disk group. See "Disk Group Compatibility Attributes".

The ALTER DISKGROUP VOLUME SQL statements enable you to manage Oracle ADVM volumes, including the functionality to add, modify, resize, disable, enable, and drop volumes. The following are examples of the ALTER DISKGROUP VOLUME statement.

Example 4-5 Managing volumes with ALTER DISKGROUP VOLUME statements

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 ALTER DISKGROUP statement. Instead you must use the acfsutil size 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".

See Also:

The ALTER DISKGROUP SQL statement in the Oracle Database SQL Language Reference

Adding Disks to a Disk Group

You can use the ADD clause of the ALTER DISKGROUP statement to add a disk or a failure group to a disk group. You can use the same syntax with the ALTER DISKGROUP statement that you use to add a disk or failure group with the CREATE DISKGROUP statement. For an example of the CREATE DISKGROUP 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"Adding Disks to a Disk Group with SQL Statements". You can also add disks to a disk group with Oracle Enterprise Manager, described in "Adding Disks to Disk Groups".

Adding Disks to a Disk Group with SQL Statements

The statements presented in this example demonstrate the interactions of disk discovery with the ADD DISK operation.

Assume that disk discovery identifies the following disks in directory /devices:


/devices/diska1 -- member of data1
/devices/diska2 -- member of data1
/devices/diska3 -- member of data1
/devices/diska4 -- member of data1
/devices/diska5 -- candidate disk
/devices/diska6 -- candidate disk
/devices/diska7 -- candidate disk
/devices/diska8 -- candidate disk

/devices/diskb1 -- member of data1
/devices/diskb2 -- member of data1
/devices/diskb3 -- member of data1
/devices/diskb4 -- member of data2

/devices/diskc1 -- member of data2
/devices/diskc2 -- member of data2
/devices/diskc3 -- member of data3
/devices/diskc4 -- candidate disk

/devices/diskd1 -- candidate disk
/devices/diskd2 -- candidate disk
/devices/diskd3 -- candidate disk
/devices/diskd4 -- candidate disk
/devices/diskd5 -- candidate disk
/devices/diskd6 -- candidate disk
/devices/diskd7 -- candidate disk
/devices/diskd8 -- candidate disk

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

The following statement would fail because /devices/diska1 - /devices/diska4 already belong to the disk group data1.

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

The following statement successfully adds disks /devices/diska5 through /devices/diska8 to data1. Because no FAILGROUP clauses are included in the ALTER DISKGROUP statement, each disk is assigned to its own failure group. The NAME 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, /devices/diska4 belongs to disk group data1 and /devices/diskb4 belongs to disk group data2.

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

The following statement would successfully add /devices/diskd1 through /devices/diskd8 to disk group data1. 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 /devices/diskc3 was previously a member of a disk group that no longer exists, then you could use the FORCE option to add the disk as a member of another disk group. For example, the following use of the FORCE clause enables /devices/diskc3 to be added to data2, even though it is a current member of data3. For this statement to succeed, data3 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 DROP DISK clause of the ALTER DISKGROUP statement. You can also drop all of the disks in specified failure groups using the DROP DISKS IN FAILGROUP 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 ALTER DISKGROUP 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 ALTER DISKGROUP ... DROP DISK SQL statement returns to SQL prompt before the drop and rebalance operations are complete. Do not reuse, remove, or disconnect the dropped disk until the HEADER_STATUS column for this disk in the V$ASM_DISK view changes to FORMER. You can query the V$ASM_OPERATION 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 FORCE clause for the drop operation, the disk is dropped even if Oracle ASM cannot read or write to the disk. You cannot use the FORCE flag when dropping a disk from an external redundancy disk group.

Caution:

A DROP FORCE 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 DROP FORCE with caution.

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

The statements in Example 4-6 demonstrate how to drop disks from the disk group data1 described in "Adding Disks to a Disk Group with SQL Statements". The first example drops diska5 from disk group data1. The second example drops diska5 from disk group data1, and also illustrates how multiple actions are possible with one ALTER DISKGROUP statement.

Example 4-6 Dropping disks from disk groups

ALTER DISKGROUP data1 DROP DISK diska5;

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 enables 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 COMPATIBLE.ASM and COMPATIBLE.RDBMS disk group attributes must be set to 11.2 or higher to use Intelligent Data Placement.

Intelligent Data Placement can be managed with the ALTER DISKGROUP ADD or MODIFY TEMPLATE SQL statements and the ALTER DISKGROUP MODIFY FILE SQL statement.

  • The ALTER DISKGROUP TEMPLATE SQL statement includes a disk region clause for setting hot/mirrorhot or cold/mirrorcold regions in a template:

    ALTER DISKGROUP data ADD TEMPLATE datafile_hot
  ATTRIBUTE ( 
    HOT
    MIRRORHOT);

  • The ALTER DISKGROUP ... MODIFY FILE SQL statement that sets disk region attributes for hot/mirrorhot or cold/mirrorcold 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".

To display information about Intelligent Data Placement regions, see "Viewing Disk Region Information" and "iostat".

Resizing Disks in Disk Groups

The RESIZE clause of ALTER DISKGROUP 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 SIZE 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.

The following example resizes all of the disks in failure group failgrp1 of disk group data1. If the new size is greater than disk capacity, the statement fails.

Example 4-7 Resizing disks in disk groups

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

Undropping Disks in Disk Groups

The UNDROP DISKS clause of the ALTER DISKGROUP 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 DROP DISKGROUP statement, or for disks that are being dropped using the FORCE clause.

The following example cancels the dropping of disks from disk group data1:

Example 4-8 Undropping disks in disk groups

ALTER DISKGROUP data1 UNDROP DISKS;

Manually Rebalancing Disk Groups

You can manually rebalance the files in a disk group using the REBALANCE clause of the ALTER DISKGROUP 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 POWER clause of the ALTER DISKGROUP ... REBALANCE statement specifies the degree of parallelism, and thus the speed of the rebalance operation. It can be set to a minimum value of 0 which halts a rebalancing operation until the statement is either implicitly or explicitly re-run. A higher value increases the speed of the rebalance operation.

The default rebalance power is set by the ASM_POWER_LIMIT initialization parameter. The range of values for the POWER clause is the same for the ASM_POWER_LIMIT initialization parameter. For information about the ASM_POWER_LIMIT initialization parameter, refer to "ASM_POWER_LIMIT".

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

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

To cause the ALTER DISKGROUP...REBALANCE command to wait until the rebalance operation is complete before returning, add the WAIT keyword to the REBALANCE clause. The wait functionality is especially useful in scripts. The command also accepts a NOWAIT keyword, which invokes the default behavior of conducting the rebalance operation asynchronously. You can interrupt a rebalance running in wait mode by typing CTRL-C on most platforms. This causes the command to return immediately with the message ORA-01013: user requested cancel of current operation, and then 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 ALTER DISKGROUP...REBALANCE 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. If you have initiated multiple rebalances on different disk groups on a single node, then Oracle processes these operations in parallel on additional nodes if available; otherwise the rebalances are performed serially on the single node. You can explicitly 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 REBALANCE clause (with its associated POWER and WAIT/NOWAIT keywords) can also be used in ALTER DISKGROUP 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.

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

Example 4-9 Manually rebalancing a disk group

ALTER DISKGROUP data2 REBALANCE POWER 5 WAIT;

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

Tuning Rebalance Operations

If the POWER clause is not specified in an ALTER DISKGROUP statement, or when rebalance is implicitly run by adding or dropping a disk, then the rebalance power defaults to the value of the ASM_POWER_LIMIT 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.

Oracle ASM tries to keep a rebalance I/O for each unit of power. Each I/O requires PGA memory for the extent involved in the relocation.

The default value of 1 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 V$ASM_OPERATION view provides information for adjusting ASM_POWER_LIMIT and the resulting power of rebalance operations. The V$ASM_OPERATION view also gives an estimate in the EST_MINUTES 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.

The range of values for the POWER clause is the same for the ASM_POWER_LIMIT initialization parameter. For information about the ASM_POWER_LIMIT initialization parameter, refer to "ASM_POWER_LIMIT".

For more information about rebalancing disk groups, refer to "Manually Rebalancing Disk Groups".

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 ASM_DISKSTRING 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 ASM_DISKSTRING initialization parameter.

Disk discovery also occurs when you:

  • Run the following SQL statements

    • Mount a disk group with ALTER DISKGROUP ... MOUNT

    • Online a disk with ALTER DISKGROUP ... ONLINE DISK

    • Add a disk to a disk group with CREATE or ALTER DISKGROUP...ADD DISK

    • Resize a disk in a disk group with ALTER DISKGROUP...RESIZE DISK

    • Query with SELECT ... FROM V$ASM_DISKGROUP or V$ASM_DISK 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 V$ASM_DISK 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 MEMBER. Disks that were discovered, but that have not yet been assigned to a disk group, have a status of either CANDIDATE or PROVISIONED. Disks that previously belonged to a disk group and were dropped cleanly from the disk group have a status of FORMER.

The PROVISIONED 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 asmtool or asmtoolg 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-10 shows a SQL query on V$ASM_DISK that displays the header status of a group of disks.

Example 4-10 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 V$ASM_DISK 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 ASM_DISKSTRING 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 CANDIDATE, PROVISIONED, or FORMER header status. These disks with a CANDIDATE, PROVISIONED, or FORMER status can be added to Oracle ASM disk groups without using the FORCE flag.

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

  • MEMBER disks can usually be added to a disk group by specifying the FORCE 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 ADD DISK or CREATE DISKGROUP command, then the command fails. To correct the error, adjust the ASM_DISKSTRING 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 ASM_DISKSTRING 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 ASM_DISKSTRING 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 ASM_DISKSTRING.

In many cases, the default value (NULL) 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 ASM_DISKSTRING before adding a disk so that the new disk is discovered through this parameter.

The default value of ASM_DISKSTRING 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 ASM_DISKSTRING. 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 NORMAL or HIGH 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 REDUNDANCY_LOWERED column in the V$ASM_FILE view 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 V$ASM_DISKGROUP view contains the following columns that contain information to help you manage capacity:

  • REQUIRED_MIRROR_FREE_MB 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.

  • USABLE_FILE_MB indicates the amount of free space, adjusted for mirroring, that is available for new files to restore redundancy after a disk failure. USABLE_FILE_MB is computed by subtracting REQUIRED_MIRROR_FREE_MB 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 USABLE_FILE_MB equals roughly 2 GB. You can then add a file that is up to 2 GB.

  • TOTAL_MB 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 TOTAL_MB column would be about 99 GB.

  • FREE_MB is the unused capacity of the disk group in megabytes, without considering any data imbalance. There may be situations where the value in the FREE_MB column shows unused capacity but because one Oracle ASM disk 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 FREE_MB column.

    With fine grain striping using 128 KB, the storage is preallocated to be eight times the AU size. 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 TOTAL_MB and FREE_MB 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 REQUIRED_MIRROR_FREE_MB 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 data disk group, the calculation is as follows:

(FREE_MB - REQUIRED_MIRROR_FREE_MB) / 2 = USABLE_FILE_MB

(3768 - 1024) / 2 = 2744 / 2 = 1372

Negative Values of USABLE_FILE_MB

Due to the relationship between FREE_MB, REQUIRED_MIRROR_FREE_MB, and USABLE_FILE_MB, USABLE_FILE_MB can become negative. Although this is not necessarily a critical situation, it does mean that:

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

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

If USABLE_FILE_MB 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:

Mirroring, Redundancy, and Failure Group Options

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 causes 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.

    A file specified with HIGH redundancy (three-way mirroring) in a NORMAL redundancy disk group provides additional protection from a bad disk sector, not protection from a disk failure.

  • 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 a database instance or when an Oracle ASM instance encounters a write error itself, the 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 remap 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 remap 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 11.1 or higher. For more information, refer to "Disk Group Compatibility".

Any problems that make a failure group temporarily unavailable are considered transient failures that can be recovered by the Oracle ASM fast mirror resync feature. For example, transient failures can be caused by disk path malfunctions, such as cable failures, host bus adapter failures, controller failures, or disk power supply interruptions.

Oracle ASM fast resync keeps track of pending changes to extents on an OFFLINE disk during an outage. The extents are resynced when the disk is brought back online.

By default, Oracle ASM drops a disk in 3.6 hours after it is taken offline. You can set the DISK_REPAIR_TIME disk group attribute to delay the drop operation by specifying a time interval to repair the disk and bring it back online. The time can be specified in units of minutes (m or M) or hours (h or H). If you omit the unit, then the default unit is hours. The DISK_REPAIR_TIME disk group attribute can only be set with the ALTER DISKGROUP SQL statement.

If the attribute is not set explicitly, then the default value (3.6h) applies to disks that have been set to OFFLINE mode without an explicit DROP AFTER clause. Disks taken offline due to I/O errors do not have a DROP AFTER clause.

The default DISK_REPAIR_TIME attribute value is an estimate that should be adequate for most environments. However, ensure that the attribute value is set to the amount of time that you think is necessary in your environment to fix any transient disk error, and that you are willing to tolerate reduced data redundancy.

The elapsed time (since the disk was set to OFFLINE mode) is incremented only when the disk group containing the offline disks is mounted. The REPAIR_TIMER column of V$ASM_DISK shows the amount of time left (in seconds) before an offline disk is dropped. After the specified time has elapsed, Oracle ASM drops the disk. You can override this attribute with the ALTER DISKGROUP OFFLINE DISK statement and the DROP AFTER clause.

Note:

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

Altering the DISK_REPAIR_TIME attribute has no effect on offline disks. The new value is used for any disks that go offline after the attribute is updated. You can confirm this behavior by viewing the Oracle ASM alert log.

If an offline disk is taken offline for a second time, then the elapsed time is reset and restarted. If another time is specified with the DROP AFTER clause for this disk, the first value is overridden and the new value applies. A disk that is in OFFLINE mode cannot be dropped with an ALTER DISKGROUP DROP DISK statement; an error is returned if attempted. If for some reason the disk must be dropped (such as the disk cannot be repaired) before the repair time has expired, a disk can be dropped immediately by issuing a second OFFLINE statement with a DROP AFTER clause specifying 0h or 0m.

You can use ALTER DISKGROUP to set the DISK_REPAIR_TIME attribute to a specified hour or minute value, such as 4.5 hours or 270 minutes. For example:

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

After you repair the disk, run the SQL statement ALTER DISKGROUP ONLINE DISK. This statement brings a repaired disk group back online to enable writes so that no new writes are missed. This statement also starts a procedure to copy of all of the extents that are marked as stale on their redundant copies.

If a disk goes offline when the Oracle ASM instance is in rolling upgrade mode, the disk remains offline until the rolling upgrade has ended and the timer for dropping the disk is stopped until the Oracle ASM cluster is out of rolling upgrade mode. See "Using Oracle ASM Rolling Upgrade". Examples of taking disks offline and bringing them online follow.

The following example takes disk DATA_001 offline and drops it after five minutes.

ALTER DISKGROUP data OFFLINE DISK DATA_001 DROP AFTER 5m;

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

ALTER DISKGROUP data OFFLINE DISK DATA_001;

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

ALTER DISKGROUP data OFFLINE DISK IN FAILGROUP FG2;

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

ALTER DISKGROUP data ONLINE DISK IN FAILGROUP FG2;

This example brings only disk DATA_001 online:

ALTER DISKGROUP data ONLINE DISK DATA_001;

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

ALTER DISKGROUP data ONLINE ALL;

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

SELECT GROUP_NUMBER, OPERATION, STATE FROM V$ASM_OPERATION;

Displays output similar to the following:

GROUP_NUMBER OPERA STAT 
------------ ----- ---- 
           1 ONLIN RUN

An OFFLINE operation is not displayed in a V$ASM_OPERATION view query.

See Also:

Oracle Database SQL Language Reference for information about ALTER DISKGROUP and CREATE DISKGROUP

Preferred Read Failure Groups

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

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

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

Note:

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

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 ASM_PREFERRED_READ_FAILURE_GROUPS initialization parameter to specify a list of failure group names as preferred read disks. For more information about this initialization parameter, refer to "ASM_PREFERRED_READ_FAILURE_GROUPS".

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

ASM_PREFERRED_READ_FAILURE_GROUPS = diskgroup.failuregroup,...

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

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

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

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

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

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

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

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

See Also:

Oracle Database Reference for details about the V$ASM* 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.

For information about creating disk groups for a new installation, refer to "Creating Disk Groups for a New Oracle Installation".

Performance Characteristics When Grouping Disks

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

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

Oracle ASM Storage Limits

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

  • 63 disk groups in a storage system

  • 10,000 Oracle ASM disks in a storage system

  • 1 million files for each disk group

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

  • 2 terabytes (TB) maximum storage for each Oracle ASM disk

  • 20 petabytes (PB) maximum for the storage system

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

  • 4 PB maximum storage for each Oracle ASM disk

  • 40 exabytes (EB) maximum for the storage system

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

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

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

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

  • External redundancy: 16 TB

  • Normal redundancy: 5.8 TB

  • High redundancy: 3.9 TB

Note:

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

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 an Oracle 10g client to access a disk group created with Oracle ASM 11g.

The disk group attributes that determine compatibility are COMPATIBLE.ASM, COMPATIBLE.RDBMS. and COMPATIBLE.ADVM. The COMPATIBLE.ASM and COMPATIBLE.RDBMS 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 COMPATIBLE.ADVM attribute determines whether the Oracle ASM Dynamic Volume Manager feature can create an volume in a disk group.

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

You can set and update disk group attributes with the ASMCMD setattr command. For information about the ASMCMD setattr command, see "setattr".

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 COMPATIBLE.ASM 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 COMPATIBLE.ASM attribute determines the minimum software version for an Oracle ASM instance that can use the disk group. This setting also affects the format of the data structures for the Oracle ASM metadata on the disk. The format of other file contents is determined by Oracle ASM Dynamic Volume Manager (Oracle ADVM) and the database instance.

For Oracle ASM in Oracle Database 11g, 10.1 is the default setting for the COMPATIBLE.ASM attribute when using the SQL CREATE DISKGROUP statement, the ASMCMD mkdg command, and Oracle Enterprise Manager Create Disk Group page. When creating a disk group with ASMCA, the default setting is 11.2.

COMPATIBLE.RDBMS

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

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

For Oracle ASM in Oracle Database 11g, 10.1 is the default setting for the COMPATIBLE.RDBMS attribute when using the SQL CREATE DISKGROUP statement, the ASMCMD mkdg command, ASMCA Create Disk Group page, and Oracle Enterprise Manager Create Disk Group page.

Note:

The database initialization parameter COMPATIBLE 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 COMPATIBLE initialization parameter.

COMPATIBLE.ADVM

The value for the disk group COMPATIBLE.ADVM attribute determines whether the disk group can contain Oracle ASM volumes. The value must be set to 11.2 or higher. Before setting this attribute, the COMPATIBLE.ASM value must be 11.2 or higher. Also, the Oracle ADVM volume drivers must be loaded in the supported environment.

By default, the value of the COMPATIBLE.ADVM attribute is empty until set.

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 CREATE DISKGROUP or ALTER DISKGROUP 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 (ASMCMD), 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 '11.1' or '11.2'; 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) (database initialization parameter COMPATIBLE is set to 11.2) and the Oracle ASM release is 11g release 2 (11.2). The COMPATIBLE.ASM and COMPATIBLE.RDBMS disk group attributes are set to the default value of 10.1 for a disk group.

    The Oracle ASM disk group functionality remains at 10g.

  • The database release is 10g and the Oracle ASM release is 11.2. COMPATIBLE.ASM is set to 11.2 and COMPATIBLE.RDBMS is set to 10.1 for a disk group.

    The disk group features enabled for this combination of attribute settings are shown in Table 4-3.

  • The database release is 11.2 (database initialization parameter COMPATIBLE is set to 11.2) and the Oracle ASM release is 11.2. All the disk group compatibility attributes are set to 11.2 for a disk group.

    The disk group features enabled for this combination of attribute settings are shown in Table 4-3.

Using CREATE DISKGROUP with Compatibility Attributes

You can specify the compatibility settings for a disk group with the CREATE DISKGROUP statement when creating the disk group.

The following example creates a normal redundancy disk group data1 with the Oracle ASM compatibility set to 11.2 and the RDBMS compatibility set to the default (the COMPATIBLE.RDBMS 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 data2 with the ASM, RDBMS, and ADVM compatibility set to 11.2:

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 ALTER DISKGROUP SQL statement to change the compatibility attributes. The ALTER DISKGROUP 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 ALTER DISKGROUP to ensure that advancing compatibility does not reduce the database and file system access. When advancing disk group compatibility, you must advance the COMPATIBLE.ASM attribute before the COMPATIBLE.RDBMS or COMPATIBLE.ADVM 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 ALTER DISKGROUP statement.

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

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

The following example advances the COMPATIBLE.RDBMS and COMPATIBLE.ADVM compatibility attributes of the disk group data3 to 11.2. This example assumes that the value of COMPATIBLE.ASM is set to 11.2.

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

Viewing Compatibility Attribute Settings

You can view the disk group compatibility settings in the V$ASM_ATTRIBUTE view. However, the V$ASM_ATTRIBUTE view does not display any rows when the COMPATIBLE.ASM value is set to 10.1. Instead you can determine the values for the COMPATIBLE.ASM and COMPATIBLE.RDBMS disk group compatibility attributes with the COMPATIBILITY and DATABASE_COMPATIBILITY columns of the V$ASM_DISKGROUP view.

See Example 6-1, "Viewing disk group attributes with V$ASM_ATTRIBUTE" for an example querying the V$ASM_ATTRIBUTE view.

You can also display the disk group compatibility attributes with the ASMCMD command lsattr. For information about lsattr, 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 V$ASM_ATTRIBUTE 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 files 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

ASM_POWER_LIMIT value up to 1024

>= 11.2.0.2

n/a

n/a

Encryption, replication, security, tagging on Linux systems

>= 11.2.0.2

n/a

>= 11.2.0.2

Encryption, replication, security, tagging on Windows systems

>= 11.2.0.3

n/a

>= 11.2.0.3

Read-write snapshots

>= 11.2.0.3

n/a

>= 11.2.0.3

The following list applies to Table 4-3.

  • If encryption is configured for the first time on Oracle ASM 11g release 2 version 11.2.0.3 on Linux or if encryption parameters must be changed or a new volume encryption key must be created following a software upgrade to Oracle ASM 11g release 2 version 11.2.0.3 on Linux, then the disk group compatibility attributes for ASM and ADVM must be set to 11.2.0.3.

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

  • The value of COMPATIBLE.ASM must always be greater than or equal to the value of COMPATIBLE.RDBMS and COMPATIBLE.ADVM.

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

  • For information about the rebalancing process and the ASM_POWER_LIMIT initialization parameter, refer to "ASM_POWER_LIMIT".

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 files 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 files

  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 CREATE DISKGROUP 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 DROP DISKGROUP INCLUDING CONTENTS 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 COMPATIBLE.RDBMS settings when the AU_SIZE 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 COMPATIBILE.RDBMS attribute to 11.1 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 COMPATIBLE.RDBMS 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 oracle1 and oracle2.

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 "Setting 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 ALTER DISKGROUP SET PERMISSION and ALTER DISKGROUP SET OWNERSHIP in "Using SQL Statements to Manage 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 ALTER DISKGROUP ADD USERGROUP in "Using SQL Statements to Manage Oracle ASM File Access Control".

Setting Disk Group Attributes for Oracle ASM File Access Control

To manage Oracle ASM File Access Control for a disk group, you must set the ACCESS_CONTROL.ENABLED and ACCESS_CONTROL.UMASK disk group attributes. You can set the attributes by altering the disk group with the ALTER DISKGROUP SQL statement or you can set the attributes with the ASMCMD setattr command. For information about the ASMCMD setattr command, see "setattr".

When you set up file access control on an existing disk group, the files previously created remain accessible by everyone, unless you run the ALTER DISKGROUP SET PERMISSION SQL statement or the ASMCMD chmod command to restrict the permissions. For information about the ASMCMD chmod command, see "chmod".

The COMPATIBLE.ASM and COMPATIBLE.RDBMS disk group attributes must be set to 11.2 or higher to enable Oracle ASM File Access Control. For information about disk group compatibility attributes, see "Disk Group Compatibility".

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

  • ACCESS_CONTROL.ENABLED

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

    The value can be true or false. The default is false.

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

  • ACCESS_CONTROL.UMASK

    This attribute determines which permissions are masked out on the creation of an Oracle ASM file for the user that owns the file, users in the same user group, and others not in the user group. This attribute applies to all files on a disk group.

    The values can be combinations of three digits {0|2|6} {0|2|6} {0|2|6}. The default is 066.

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

    Before setting the ACCESS_CONTROL.UMASK disk group attribute, you must set the ACCESS_CONTROL.ENABLED attribute to true to enable Oracle ASM File Access Control.

Example 4-11 shows how to enable Oracle ASM File Access Control for a disk group using SQL*Plus. In this example, the permissions setting is 026 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-11 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 ALTER DISKGROUP 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:

  • ALTER DISKGROUP ADD USERGROUP ... WITH MEMBER

    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 MEMBER clause must be in the disk group, as shown by V$ASM_USER, or the command returns an error. Any users authenticated as SYSASM or SYSDBA 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';

  • ALTER DISKGROUP DROP USERGROUP

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

  • ALTER DISKGROUP MODIFY USERGROUP ADD MEMBER

    Adds users to the specified user group. The users must be in the disk group, as shown by V$ASM_USER, 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';

  • ALTER DISKGROUP MODIFY USERGROUP DROP MEMBER

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

  • ALTER DISKGROUP ADD USER

    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 V$ASM_USER, 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 ADD USER 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';

  • ALTER DISKGROUP DROP USER

    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 CASCADE 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 DROP USER command fails, and no files are deleted.

    SQL>  ALTER DISKGROUP DATA DROP USER 'oracle1';

  • ALTER DISKGROUP SET PERMISSION

    Modifies permissions of an Oracle ASM file. Setting read only permission to a file that has read write permission revokes the write 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';

  • ALTER DISKGROUP SET OWNERSHIP

    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 run 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';

See Also:

The ALTER DISKGROUP SQL statement in the Oracle Database SQL Language Reference

Mounting and Dismounting Disk Groups

Disk groups that are specified in the ASM_DISKGROUPS 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 GROUP_NUMBER column of the V$ASM views.

When you want to mount or dismount disk groups manually, use the ALTER DISKGROUP...MOUNT or ALTER DISKGROUP...DISMOUNT statement. You can mount or dismount disk groups by name, or specify ALL.

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

In a clustered Oracle ASM environment in RESTRICTED 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 data1:

ALTER DISKGROUP data1 MOUNT;

Mounting Disk Groups Using the FORCE Option

Oracle ASM provides a MOUNT FORCE option with ALTER DISKGROUP 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 FORCE option is to fail to mount a disk group that has damaged or missing disks.

The MOUNT FORCE 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 MOUNT FORCE 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 DISK_REPAIR_TIME 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 ALTER DISKGROUP OFFLINE statement. For more information about setting the DISK_REPAIR_TIME 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 MOUNT FORCE 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 FORCE option causes the MOUNT command to fail. This discourages unnecessary and improper use of the feature.

The following example shows how to use the FORCE option to force the mount of the data1 disk group:

ALTER DISKGROUP data1 MOUNT FORCE

See Also:

The Oracle Database SQL Language Reference for additional information about the ALTER DISKGROUP statement and the FORCE option

Checking the Internal Consistency of Disk Group Metadata

You can check the internal consistency of disk group metadata using the ALTER DISKGROUP statement with the CHECK 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 CHECK DISK GROUP clause verifies all of the metadata directories. Oracle ASM displays summary errors and writes the details about the errors in an alert log. The CHECK 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 REPAIR | NOREPAIR clause specifies whether Oracle ASM should attempt to repair errors that are found during the check. The default is NOREPAIR. Use the NOREPAIR 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 data1 disk group:

ALTER DISKGROUP data1 CHECK ALL;

See Also:

The Oracle Database SQL Language Reference for additional information about the CHECK clause syntax

Dropping Disk Groups

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

The 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 DROP DISKGROUP 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 ASM_DISKGROUPS initialization parameter if a server parameter file is being used. If a text initialization parameter file is being used, and the disk group is mentioned in the ASM_DISKGROUPS initialization parameter, then you must remove the disk group name from the ASM_DISKGROUPS initialization parameter before the next time that you shut down and restart the Oracle ASM instance.

The following statement deletes data1:

DROP DISKGROUP data1;

After ensuring that none of the files contained in data1 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 INCLUDING CONTENTS, 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 INCLUDING CONTENTS 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 V$ASM_VOLUME view. For an example of a query on the V$ASM_VOLUME view, see Example 6-16. 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 FORCE option of the DROP DISKGROUP statement. This command enables you to remove the headers on disks that belong to a disk group that cannot be mounted by any 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 FORCE 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 FORCE option with extreme caution.

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

Renaming Disks Groups

The renamedg 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 renamedg on the disk group.

renamedg 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:


renamedg {-help | help=true}

renamedg
     [phase={ one|two |both } ] dgname=diskgroup
     newdgname=newdiskgroup [config=configfile]
     [ asm_diskstring=discoverystring, discoverystring ... ]
     [ clean={true|false} ] [ check={true|false} ]
     [ confirm={true|false}] [ verbose={ true|false} ]
     [ keep_voting_files={true|false}]

  • phase={one|two|both}

    Specifies the phase to be run. Allowed values are one, two, or both. This argument is optional. The default is both.

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

  • dgname=diskgroup

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

  • newdgname=newdiskgroup

    Specifies the new name for the disk group.

  • config=configfile

    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 renamedg_config and is located in the directory in which the command is run. The single quotations may be required on some platforms.

  • asm_diskstring=discoverystring, discoverystring ...

    Specifies the Oracle ASM discovery strings. The asm_diskstring 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.

  • clean={true|false}

    Specifies whether to tolerate errors that are otherwise ignored. The default is true.

  • check={true|false}

    Specifies a boolean value that is used in the second phase. If true, 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 false.

  • confirm={true|false}

    Specifies a boolean value that is used in the second phase. If false, 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 false. If check is set to true, then the value of this parameter is redundant.

  • verbose={true|false}

    Specifies verbose execution when verbose=true. The default is false.

  • keep_voting_files={true|false}

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

Note:

renamedg does not update resources, nor does renamedg 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 two. The status of the old disk group resource can be checked with the Oracle Clusterware Control (CRSCTL) crsctl stat res -t command and then manually deleted with the Server Control Utility (SRVCTL) srvctl remove diskgroup command.

Example 4-12 shows several examples of the use of renamedg. The first example renames the data disk group to new_data using a disk string to locate the disks and the verbose option is enabled. The second example only creates a configuration file during the completion of phase one of the renamedg operation. The third example runs phase two of the renamedg operation using a configuration file generated from a phase one execution of renamedg.

Example 4-12 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

参考至：http://docs.oracle.com/cd/E11882_01/server.112/e18951/asmdiskgrps.htm#OSTMG137

如有错误，欢迎指正

邮箱:[email protected]

你可能感兴趣的:(oracle)

  • MySQl篇（SQL - 基本介绍）（持续更新迭代） wclass-zhengge mysqlsql数据库
    目录一、简介二、SQL方言（分页查询为例）1.简介2.SQL方言大比拼2.1.Oracle2.1.1.使用ROWNUM实现分页查询2.1.2.使用ROW_NUMBER()实现分页查询2.2.MySQL2.3.PostgreSQL三、语法规范四、注释五、MySQL脚本中的标点符号一、简介1、SQL是结构化查询语言（StructureQueryLanguage），专门用来操作/访问关系型数据库的通用语
  • 梧桐数据库（WuTongDB）：数据库技术中都有哪些常见的优化器 鲁鲁517 梧桐数据库梧桐数据库
    以下是一些常见的数据库优化器：1.CBO（Cost-BasedOptimizer）应用场景：广泛应用于关系型数据库中，如Oracle、PostgreSQL、MySQL等。工作原理：通过计算不同执行计划的代价（如CPU、I/O等资源消耗），选择最低代价的执行计划。代表数据库：Oracle、PostgreSQL、MySQL。特点：CBO使用统计信息（如表大小、索引分布）来评估查询的代价。2.RBO（R
  • 解决mysql漏洞 Oracle MySQL Server远程安全漏洞(CVE-2015-0411) dieweidong5625 数据库运维java
    有时候会检测到服务器有很多漏洞，而大部分漏洞都是由于服务的版本过低的原因，因为官网出现漏洞就会发布新版本来修复这个漏洞，所以一般情况下，我们只需要对相应的软件包进行升级到安全版本即可。通过查阅官网信息，OracleMySQLServer远程安全漏洞(CVE-2015-0411)，受影响系统：OracleMySQLServer/usr/databases.sql//先备份原有所有数据，防止数据丢失。
  • MySQL内存结构 san.hang 数据库数据结构与算法
    实际上MySQL内存的组成和Oracle类似，也可以分为SGA（系统全局区）和PGA（程序缓存区）。mysql>showvariableslike"%buffer%";一、SGA1.innodb_buffer_bool用来缓存Innodb表的数据、索引、插入缓冲、数据字典等信息。2.innodb_log_buffer事务在内存中的缓冲，即redlogbuffer的大小3.querycache高速查
  • Oracle（125）如何执行不完全恢复？ 辞暮尔尔-烟火年年 Oracleoracle数据库
    不完全恢复（IncompleteRecovery）是指将Oracle数据库恢复到一个特定时间点、SCN（系统变更号）或取消点，而不是恢复到最近的备份后的最新状态。以下是详细的步骤和代码示例，展示如何执行不完全恢复。准备工作备份控制文件：确保你有控制文件的备份。备份数据文件：确保你有数据文件的备份。备份归档日志：确保你有最新的归档日志。不完全恢复的基本步骤关闭数据库：确保数据库处于关闭状态。启动数据
  • Oracle EBS中AR模块的财务流程概览 六月雨滴 EBSoracle
    应收账款(AR)模块是OracleE-BusinessSuite(EBS)中另一个重要的财务管理模块，主要用于管理企业销售过程中的账款回收。下面是AR模块中的一些关键财务流程及其详细说明：1.销售订单管理创建销售订单：当客户下单时，销售人员在系统中创建销售订单。订单确认：确认销售订单的详细信息，包括商品、数量、价格等。订单履行：确保仓库有足够的库存来满足订单需求。2.发票生成发票创建：根据销售订单
  • oracle数据库安装和配置详细讲解 程序员小羊！ 运维数据库oracle
    大家好，我是程序员小羊！前言：Oracle数据库是全球广泛使用的关系型数据库管理系统(RDBMS)，提供高性能、可靠性、安全性和可扩展性，广泛应用于企业关键任务系统。下面详细介绍如何在CentOS系统上安装和配置Oracle数据库。1.前提条件1.1硬件要求内存：最小1GB，推荐2GB以上。硬盘：至少10GB的可用空间，视具体应用需求而定。1.2软件要求操作系统：CentOS7或CentOS8（确
  • oracle实验-RMAN的PIPE接口 congqingm32098 数据库
    RMAN的PIPE接口RMAN除了支持交互式和批处理式，还支持一种PIPE的接口，通过这种PIPE接口，可以在ORACLE中将各种命令发送给RMAN。首先，以PIPE方式启动RMAN，其中P1是管道的名称：F:>RMANPIPEP1TARGET/@TESTNOCATALOG恢复管理器:版本9.2.0.4.0-ProductionCopyright(c)1995,2002,OracleCorpora
  • ORACLE查看索引是否有效 清水 索引oracle
    SELECTSTATUSFROMUSER_INDEXESWHEREINDEX_NAME='索引名';VALID——索引有效
  • Java 学习路线：语言、框架、中间件与数据库 高危型 java
    Java是一门功能强大、应用广泛的编程语言，适用于企业级应用、Web开发、大数据处理、Android开发等各种场景。这里为大家介绍了一下我认为较为合适的学习路线一、Java基础1.1Java语言基础1.1.1安装JDK和IDE安装JDK：下载JDK：访问Oracle官网，下载最新的JavaDevelopmentKit（JDK）。安装JDK：按照操作系统要求安装JDK并配置环境变量。Windows上
  • 微服务开发实战(七) 禅大师
    PostgreSQL下载安装在程序开发中，需要使用到数据库。目前.NETCore支持MSSQLServer，MySQL，PostgreSQL，Oracle等多种数据库。在本教程中，使用的是免费开源、跨平台、功能完善、性能强大的PostgreSQL数据库。可以直接访问官方网站https://www.postgresql.org/下载安装，或者从第三方网站https://www.openscg.com
  • Oracle数据库中的Oracle Label Security是什么 2401_85812026 javascript开发语言ecmascript
    OracleLabelSecurity（OLS）是Oracle数据库中的一个强大特性，它提供了基于标签的行级安全性控制。通过OLS，组织可以实施细粒度的数据访问控制，确保用户只能访问他们被授权的数据。OracleLabelSecurity的工作原理OLS通过定义一系列的标签和安全策略来控制对数据库中数据的访问。每个数据行都会被分配一个或多个标签，而用户或应用程序的会话也会被分配一个标签。当用户尝试
  • 数据库管理的利器Navicat —— 全面测评与热门产品推荐 界面开发小八哥 数据库Navicat数据库开发sqlmysql
    在数据库管理领域，Navicat无疑是一款深受欢迎的软件。作为一个强大的数据库管理和开发工具，它支持多种数据库类型，包括MySQL、MariaDB、MongoDB、SQLServer、Oracle、PostgreSQL等。本文将全面测评Navicat的核心功能，同时推荐几款热门的Navicat产品。Navicat的主要特点1.跨平台支持：Navicat支持Windows、Mac和Linux平台，可
  • 通过DBeaver连接Phoenix操作hbase 不想做咸鱼的王富贵
    通过DBeaver连接Phoenix操作hbase前言本文介绍常用一种通用数据库工具Dbeaver，DBeaver可通过JDBC连接到数据库，可以支持几乎所有的数据库产品，包括：MySQL、PostgreSQL、MariaDB、SQLite、Oracle、Db2、SQLServer、Sybase、MSAccess、Teradata、Firebird、Derby等等。商业版本更是可以支持各种NoSQ
  • PMSJ寻平面设计师之甲骨文公司(Oracle） 全球区块链企业动态
    1977年6月.LarryEllison与BobMiner和EdOates在硅谷共同创办了一家名为软件开发实验室（SoftwareDevelopmentLaboratories，SDL）的计算机公司（ORACLE公司的前身）.Ellison和Miner预见到数据库软件的巨大潜力.于是.SDL开始策划构建可商用的关系型数据库管理系统（RDBMS）.很快他们就弄出来一个产品雏形.或者具体的说.更像一个
  • linux安装Oracle所需pdksh包下载 Amor风信子 linuxoracle
    linux安装Oracle所需pdksh包下载：pdksh-5.2.14-37.el5.x86_64.rpm的下载提取码：msoe直接安装即可：rpm-ivhpdksh-5.2.14-37.el5.x86_64.rpm如果安装失败则尝试强制安装，强制安装命令：rpm-ivh*****.rpm--nodeps--force例如;rpm-ivhpdksh-5.2.14-37.el5.x86_64.rp
  • Spring 源码学习(九) Transaction 事务 带鱼真好吃
    spring系列转载自掘金VipAugushttps://juejin.cn/user/2348212565601415/postsSpringTransaction事务的使用和实现原理前言业务系统的数据，一般最后都会落入到数据库中，例如MySQL、Oracle等主流数据库，不可避免的，在数据更新时，有可能会遇到错误，这时需要将之前的数据更新操作撤回，避免错误数据。Spring的声明式事务能帮我们
  • Java初级学习路线概要~ 艾伦~耶格尔 Java初级java学习开发语言intellij-ideajdk
    前言如果你刚刚开始学习Java，掌握基础知识是关键。本文将提供一个详细的Java初级学习路线，帮助各位看官从基础开始，逐步掌握Java编程语言的核心概念。1.Java语言基础1.1Java简介-**Java介绍**：Java是一种广泛使用的编程语言，以其跨平台特性和面向对象设计而著名。-**应用场景**：Web应用、桌面应用、移动应用等。1.2环境搭建**安装JDK**：从[Oracle官网](h
  • Oracle分区表之MODIFY 使用在线重定义对集合表进行分区 IT皮特 oracle数据库
    您可以使用联机重新定义将未分区的集合表复制到已分区的集合表格，Oracle数据库将行插入集合表格中的相应分区。示例4-41说明了如何对Objects列中的嵌套表执行此操作；类似的例子适用于XMLType表或列中的有序集合类型表。在copy_table_dependents操作期间，您指定0或false用于复制索引和约束，因为您希望保留新定义的集合表的索引和约束。但是，集合表及其分区的名称与临时表的
  • Online Conversion of a Non-Partitioned Table to a Partitioned Table in Oracle Database 12c Release 2 IT皮特 数据库oracle
    从12.2开始，通过MODIFYTABLE可以在线实现普通表转分区表。一、创建测试表：DROPTABLEt1PURGE;CREATETABLEt1(idNUMBER,descriptionVARCHAR2(50),created_dateDATE,CONSTRAINTt1_pkPRIMARYKEY(id));CREATEINDEXt1_created_date_idxONt1(created_da
  • ‘pip‘ 不是内部或外部命令，也不是可运行的程序或批处理文件。 逆天小北鼻 pythonpip
    因为python13不支持pipinstallcx_Oracle，卸载了python13，重新安装python10，导致cmd命令不识别pip，和python10，(;´༎ຶД༎ຶ`)记录一种临时方案如果你的命令行界面（cmd）不识别pip命令，这通常意味着pip的可执行文件路径没有被添加到系统的环境变量中，或者环境变量的设置没有正确生效。重新检查pip的安装路径在命令行中运行以下Python代码
  • oracle用户管理 sinat_38878030
    第二章Oracle用户管理【目标】1.掌握用户的创建、删除、修改2.掌握基本的权限管理3.了解数据字典及基本操作【内容】一、用户的创建、删除、修改u创建用户语法：createuser用户名identifiedby密码;注：在oracle中创建用户只能由管理员或者具有管理员的权限的用户创建。案例：新建用户abc新建的用户是没有任何权限的，包括连接数据库的权限。新创建的用户是没有任何权限的，直接登录会
  • Oracle 用户及角色 介绍 iteye_3158 数据库
    一.用户管理1.1建立用户（数据库验证）CREATEUSERDAVEIDENTIFIEDBYpwdDEFAULTTABLESPACEusersTEMPORARYTABLESPACEtempQUOTA5mONusers;1.2修改用户ALTERUSERDAVEQUOTA0ONSYSTEM;1.3删除用户DROPUSERDAVE;DROPUSERDAVECASCADE;1.4显示用户信息SELECT*
  • Oracle中的系统权限和对象权限 杨天赐 OracledeleteinsertoracleOracleORACLEreferenceReference数据库
    Oracle中的系统权限和对象权限系统权限的定义:系统权限（systemprivilege）：指在系统级控制数据库的存取和使用的机制，即执行某种SQL语句的能力。如，是否能启动、停止数据库，是否能修改数据库参数，是否能连接到数据库，是否能创建、删除、更改方案对象（如表、索引、视图、过程）等。它一般是针对某一类方案对象或非方案对象的某种操作的全局性能力。提示”没有系统权限的用户实际上是个连登录能力都
  • MYSQL，SQL SERVER，ORICLE的区别 Codefengfeng mysql数据库
    1.MySQL是由瑞典MySQLAB公司开发的产品，开源免费，占用内存很小，是大学阶段学习的主要对象，常见版本为mysql5.7和mysql8.02.SQLSERVER主要由微软开发，需付费购买后使用，占用内存中等3.ORICLE主要由ORACLE公司（甲骨文）开发，需要付费购买后使用，占用内存最大
  • Oracle用户 Baijinwen DataBase
    一：用户用户名密码描述SYS用户指定数据库管理帐户SYSMANOEM_TEMP企业管理器帐户SYSTEM用户指定数据库管理帐户OUTLNOUTLN拥有connect和resource角色FLOWS_FILES该账户拥有oracleapplicationexpress上传的文件MDSYSMDSYSoracle空间数据媒体管理员ORDSYSORDSYSimage管理员EXFSYSEXFSYS表达式过滤
  • Oracle用户、权限、角色管理 一心只为学 oracle数据库运维服务器
    一、用户管理1、创建用户1.1创建用户user1，密码为123456，指定默认表空间为user1_tbs,临时表空间为user1_temp#user1_tbs表空间和user1_temp临时表空间需要提前创建好。#创建表空间user1_tbsSQL>createtablespaceuser1_tbsdatafile'/u01/app/oracle/oradata/ORCL/datafile/use
  • Oracle数据库中的Oracle Real Application Clusters是什么 2401_85812053 数据库oracle
    OracleRealApplicationClusters（简称OracleRAC）是Oracle数据库的一个关键特性，它允许多个数据库实例同时访问和管理同一个数据库。这种架构设计的目的是为了提高数据库系统的可扩展性、可用性和性能。OracleRAC的核心特点包括：高可用性：如果任何一个节点发生故障，其他节点可以继续处理请求，从而保持应用程序的连续运行。数据库实例之间的负载均衡可以自动进行，减少单
  • javaspringboot教程，5214页PDF的进阶架构师学习笔记 2401_84415534 程序员pdf学习笔记
    一、电面：自我介绍项目情况：对你来说影响最大的一个项目（该面试中有关项目问题都针对该项目展开）？为什么会想做这个项目？这个项目的ideal是谁提出来的？项目中如何实现的大数据的传输和存储项目中哪一部分最难攻克？如何攻克？基础知识考察：模块化的好处Htttp协议hashmap和concurrenthashmap区别及两者的优缺点对MySQL的了解，和oracle的区别对设计模式的看法和认知有哪些设计
  • Oracle 12c 及以上版本补丁更新说明及下载方法 zd1320732 oracleoracle12c补丁更新
    参考下面的文章，会对补丁更新的流程有一定的了解。https://www.modb.pro/db/27255RU（ReleaseUpdates）是每一个季度的版本升级。包括：最新的BUG修复最新的安全漏洞补丁最新添加的功能以19c为例，对应的升级版本升级路线是（19.1.0.0.0->19.2.0.0.0->19.3.0.0.0…）到现在是19.8.0.0.0RUR是对RU的修订版本，包括：最新的B
  • 强大的销售团队背后 竟然是大数据分析的身影 蓝儿唯美 数据分析
    Mark Roberge是HubSpot的首席财务官，在招聘销售职位时使用了大量数据分析。但是科技并没有挤走直觉。 大家都知道数理学家实际上已经渗透到了各行各业。这些热衷数据的人们通过处理数据理解商业流程的各个方面，以重组弱点，增强优势。 Mark Roberge是美国HubSpot公司的首席财务官，HubSpot公司在构架集客营销现象方面出过一份力——因此他也是一位数理学家。他使用数据分析
  • Haproxy+Keepalived高可用双机单活 bylijinnan 负载均衡keepalivedhaproxy高可用
    我们的应用MyApp不支持集群，但要求双机单活（两台机器：master和slave）： 1.正常情况下，只有master启动MyApp并提供服务 2.当master发生故障时，slave自动启动本机的MyApp，同时虚拟IP漂移至slave，保持对外提供服务的IP和端口不变 F5据说也能满足上面的需求，但F5的通常用法都是双机双活，单活的话还没研究过 服务器资源 10.7
  • eclipse编辑器中文乱码问题解决 0624chenhong eclipse乱码
    使用Eclipse编辑文件经常出现中文乱码或者文件中有中文不能保存的问题，Eclipse提供了灵活的设置文件编码格式的选项，我们可以通过设置编码 格式解决乱码问题。在Eclipse可以从几个层面设置编码格式：Workspace、Project、Content Type、File 本文以Eclipse 3.3（英文）为例加以说明： 1. 设置Workspace的编码格式： Windows-&g
  • 基础篇--resources资源 不懂事的小屁孩 android
    最近一直在做java开发，偶尔敲点android代码，突然发现有些基础给忘记了，今天用半天时间温顾一下resources的资源。 String.xml    字符串资源   涉及国际化问题  http://www.2cto.com/kf/201302/190394.html   string-array
  • 接上篇补上window平台自动上传证书文件的批处理问卷 酷的飞上天空 window
    @echo off : host=服务器证书域名或ip，需要和部署时服务器的域名或ip一致 ou=公司名称, o=公司名称 set host=localhost set ou=localhost set o=localhost set password=123456 set validity=3650 set salias=s
  • 企业物联网大潮涌动：如何做好准备？ 蓝儿唯美 企业
    物联网的可能性也许是无限的。要找出架构师可以做好准备的领域然后利用日益连接的世界。 尽管物联网（IoT）还很新，企业架构师现在也应该为一个连接更加紧密的未来做好计划，而不是跟上闸门被打开后的集成挑战。“问题不在于物联网正在进入哪些领域，而是哪些地方物联网没有在企业推进，” Gartner研究总监Mike Walker说。 Gartner预测到2020年物联网设备安装量将达260亿，这些设备在全
  • spring学习——数据库（mybatis持久化框架配置） a-john mybatis
    Spring提供了一组数据访问框架，集成了多种数据访问技术。无论是JDBC，iBATIS(mybatis)还是Hibernate，Spring都能够帮助消除持久化代码中单调枯燥的数据访问逻辑。可以依赖Spring来处理底层的数据访问。 mybatis是一种Spring持久化框架，要使用mybatis，就要做好相应的配置： 1，配置数据源。有很多数据源可以选择，如：DBCP，JDBC，aliba
  • Java静态代理、动态代理实例 aijuans Java静态代理
    采用Java代理模式，代理类通过调用委托类对象的方法，来提供特定的服务。委托类需要实现一个业务接口，代理类返回委托类的实例接口对象。 按照代理类的创建时期，可以分为：静态代理和动态代理。 所谓静态代理：　指程序员创建好代理类，编译时直接生成代理类的字节码文件。 所谓动态代理：　在程序运行时，通过反射机制动态生成代理类。   一、静态代理类实例： 1、Serivce.ja
  • Struts1与Struts2的12点区别 asia007 Struts1与Struts2
    1) 在Action实现类方面的对比：Struts 1要求Action类继承一个抽象基类；Struts 1的一个具体问题是使用抽象类编程而不是接口。Struts 2 Action类可以实现一个Action接口，也可以实现其他接口，使可选和定制的服务成为可能。Struts 2提供一个ActionSupport基类去实现常用的接口。即使Action接口不是必须实现的，只有一个包含execute方法的P
  • 初学者要多看看帮助文档 不要用js来写Jquery的代码 百合不是茶 jqueryjs
    解析json数据的时候需要将解析的数据写到文本框中,  出现了用js来写Jquery代码的问题;   1, JQuery的赋值  有问题    代码如下: data.username 表示的是:  网易            $("#use
  • 经理怎么和员工搞好关系和信任 bijian1013 团队项目管理管理
            产品经理应该有坚实的专业基础，这里的基础包括产品方向和产品策略的把握，包括设计，也包括对技术的理解和见识，对运营和市场的敏感，以及良好的沟通和协作能力。换言之，既然是产品经理，整个产品的方方面面都应该能摸得出门道。这也不懂那也不懂，如何让人信服？如何让自己懂？就是不断学习，不仅仅从书本中，更从平时和各种角色的沟通
  • 如何为rich:tree不同类型节点设置右键菜单 sunjing contextMenutreeRichfaces
    组合使用target和targetSelector就可以啦，如下： <rich:tree id="ruleTree" value="#{treeAction.ruleTree}" var="node" nodeType="#{node.type}" selectionChangeListener=&qu
  • 【Redis二】Redis2.8.17搭建主从复制环境 bit1129 redis
    开始使用Redis2.8.17 Redis第一篇在Redis2.4.5上搭建主从复制环境，对它的主从复制的工作机制，真正的惊呆了。不知道Redis2.8.17的主从复制机制是怎样的，Redis到了2.4.5这个版本，主从复制还做成那样，Impossible is nothing! 本篇把主从复制环境再搭一遍看看效果，这次在Unbuntu上用官方支持的版本。   Ubuntu上安装Red
  • JSONObject转换JSON--将Date转换为指定格式 白糖_ JSONObject
    项目中，经常会用JSONObject插件将JavaBean或List<JavaBean>转换为JSON格式的字符串，而JavaBean的属性有时候会有java.util.Date这个类型的时间对象，这时JSONObject默认会将Date属性转换成这样的格式：   {"nanos":0,"time":-27076233600000,
  • JavaScript语言精粹读书笔记 braveCS JavaScript
    【经典用法】：   //①定义新方法 Function .prototype.method=function(name, func){ this.prototype[name]=func; return this; } //②给Object增加一个create方法，这个方法创建一个使用原对
  • 编程之美-找符合条件的整数 用字符串来表示大整数避免溢出 bylijinnan 编程之美
    import java.util.LinkedList; public class FindInteger { /** * 编程之美 找符合条件的整数 用字符串来表示大整数避免溢出 * 题目：任意给定一个正整数N，求一个最小的正整数M(M>1)，使得N*M的十进制表示形式里只含有1和0 * * 假设当前正在搜索由0，1组成的K位十进制数
  • 读书笔记 chengxuyuancsdn 读书笔记
    1、Struts访问资源 2、把静态参数传递给一个动作 3、<result>type属性 4、s:iterator、s:if c:forEach 5、StringBuilder和StringBuffer 6、spring配置拦截器 1、访问资源 (1)通过ServletActionContext对象和实现ServletContextAware,ServletReque
  • [通讯与电力]光网城市建设的一些问题 comsci 问题
          信号防护的问题,前面已经说过了,这里要说光网交换机与市电保障的关系       我们过去用的ADSL线路,因为是电话线,在小区和街道电力中断的情况下,只要在家里用笔记本电脑+蓄电池,连接ADSL,同样可以上网........     
  • oracle 空间RESUMABLE daizj oracle空间不足RESUMABLE错误挂起
    空间RESUMABLE操作  转 Oracle从9i开始引入这个功能，当出现空间不足等相关的错误时，Oracle可以不是马上返回错误信息，并回滚当前的操作，而是将操作挂起，直到挂起时间超过RESUMABLE TIMEOUT，或者空间不足的错误被解决。 这一篇简单介绍空间RESUMABLE的例子。 第一次碰到这个特性是在一次安装9i数据库的过程中，在利用D
  • 重构第一次写的线程池 dieslrae 线程池 python
    最近没有什么学习欲望,修改之前的线程池的计划一直搁置,这几天比较闲,还是做了一次重构,由之前的2个类拆分为现在的4个类. 1、首先是工作线程类:TaskThread,此类为一个工作线程,用于完成一个工作任务,提供等待(wait),继续(proceed),绑定任务(bindTask)等方法 #!/usr/bin/env python # -*- coding:utf8 -*-
  • C语言学习六指针 dcj3sjt126com c
    初识指针，简单示例程序： /* 指针就是地址，地址就是指针 地址就是内存单元的编号 指针变量是存放地址的变量 指针和指针变量是两个不同的概念 但是要注意： 通常我们叙述时会把指针变量简称为指针，实际它们含义并不一样 */ # include <stdio.h> int main(void) { int * p; // p是变量的名字， int *
  • yii2 beforeSave afterSave beforeDelete dcj3sjt126com delete
    public function afterSave($insert, $changedAttributes) { parent::afterSave($insert, $changedAttributes); if($insert) { //这里是新增数据 } else { //这里是更新数据 } }  
  • timertask shuizhaosi888 timertask
    java.util.Timer timer = new java.util.Timer(true); // true 说明这个timer以daemon方式运行（优先级低， // 程序结束timer也自动结束），注意，javax.swing // 包中也有一个Timer类，如果import中用到swing包， // 要注意名字的冲突。 TimerTask task = new
  • Spring Security（13）——session管理 234390216 sessionSpring Security攻击保护超时
    session管理 目录   1.1     检测session超时 1.2     concurrency-control 1.3     session 固定攻击保护         
  • 公司项目NODEJS实践0.3[ mongo / session ...] 逐行分析JS源代码 mongodbsessionnodejs
        http://www.upopen.cn   一、前言         书接上回，我们搭建了WEB服务端路由、模板等功能，完成了register 通过ajax与后端的通信，今天主要完成数据与mongodb的存取，实现注册 / 登录 /
  • pojo.vo.po.domain区别 LiaoJuncai javaVOPOJOjavabeandomain
    　　POJO = "Plain Old Java Object"，是MartinFowler等发明的一个术语，用来表示普通的Java对象，不是JavaBean, EntityBean 或者 SessionBean。POJO不但当任何特殊的角色，也不实现任何特殊的Java框架的接口如，EJB， JDBC等等。 　　 　　即POJO是一个简单的普通的Java对象，它包含业务逻辑
  • Windows Error Code OhMyCC windows
    0 操作成功完成. 1 功能错误. 2 系统找不到指定的文件. 3 系统找不到指定的路径. 4 系统无法打开文件. 5 拒绝访问. 6 句柄无效. 7 存储控制块被损坏. 8 存储空间不足, 无法处理此命令. 9 存储控制块地址无效. 10 环境错误. 11 试图加载格式错误的程序. 12 访问码无效. 13 数据无效. 14 存储器不足, 无法完成此操作. 15 系
  • 在storm集群环境下发布Topology roadrunners 集群stormtopologyspoutbolt
    storm的topology设计和开发就略过了。本章主要来说说如何在storm的集群环境中，通过storm的管理命令来发布和管理集群中的topology。   1、打包 打包插件是使用maven提供的maven-shade-plugin，详细见maven-shade-plugin。 <plugin> <groupId>org.apache.maven.
  • 为什么不允许代码里出现“魔数” tomcat_oracle java
    　　在一个新项目中，我最先做的事情之一，就是建立使用诸如Checkstyle和Findbugs之类工具的准则。目的是制定一些代码规范，以及避免通过静态代码分析就能够检测到的bug。 　　迟早会有人给出案例说这样太离谱了。其中的一个案例是Checkstyle的魔数检查。它会对任何没有定义常量就使用的数字字面量给出警告，除了-1、0、1和2。 　　很多开发者在这个检查方面都有问题，这可以从结果
  • zoj 3511 Cake Robbery(线段树) 阿尔萨斯 线段树
    题目链接：zoj 3511 Cake Robbery 题目大意：就是有一个N边形的蛋糕，切M刀，从中挑选一块边数最多的，保证没有两条边重叠。 解题思路：有多少个顶点即为有多少条边，所以直接按照切刀切掉点的个数排序，然后用线段树维护剩下的还有哪些点。 #include <cstdio> #include <cstring> #include <vector&
按字母分类： ABCDEFGHIJKLMNOPQRSTUVWXYZ其他