New Features of Oracle ASM 11g

1. What is ASM?

ASM is called Automatic Storage Management (Automatic Storage Management). It is a new feature launched by Oracle 10 Gb. This is a volume manager provided by Oracle to replace the LVM provided by the operating system. It not only supports single-instance configuration, but also supports multi-instance configuration such as RAC. It will bring great convenience to the Oracle database administrator. ASM can automatically manage the disk groups and provide data redundancy and optimization. Especially for large database administrators of enterprises, administrators can be freed from the trivial daily tasks of managing hundreds of data files to process other and more important transactions.

Before the Oracle 10 GB version, managing hundreds of thousands of data files in a large database was neither technical nor boring for database administrators, this requires the database administrator to be familiar with the LVM related knowledge of the system and perform related system operations such as disk specification and LV strip. The use of Automatic Storage Management will greatly reduce the workload in this regard. The database administrator only needs to manage a few disk groups. A disk group is a logical unit managed by ASM and consists of a group of disk devices. We can define a disk group as the default disk group for the database. Oracle automatically manages the storage, including creating and deleting data files. Oracle automatically associates these files with a suitable database object, so that we only need to provide the object name when managing these objects, instead of providing the detailed file name as before.

ASM provides many useful storage technologies, such as RAID and LVM logical volume management. Like these technologies, ASM allows you to create a separate disk group on a group of Independent Disks. In this way, I/O balancing is achieved for a single disk group. At the same time, ASM also implements strip Striping and disk image Mirroring) to improve I/O performance and data reliability. Unlike RAID or LVM, ASM is a file-level implementation of strip and image. Such implementation gives users great freedom of choice, you can configure different storage attributes for different files in the same disk group to implement different storage methods.

Ii. What new features does ASM have in 11G?

1. Fast Re-Sync ASM Fast Mirror Resync)

When a short DISK path problem occurs, it takes a lot of time to restore the disk group of the asm disk group. In particular, this recovery operation requires you to relay the entire disk group. The new feature of ASM fast disk re-synchronization can significantly reduce the time required to re-synchronize a bad disk. When you replace the bad disk, ASM can quickly synchronize the extent of the ASM disk.

Any problem that temporarily makes the disk group unavailable is considered to be a temporary failure, which can be recovered after ASM quickly resynchronizes new features. Disk path failure, such as interface line problems, host adapter problems, disk controller problems, or disk power problems can cause transient failure. By default, when a disk is offline, ASM will immediately remove it. The ASM fast synchronization function is enough to record all the changes in the disk's upper zone during the offline period of the offline disk. When the disk is repaired or brought online again, during this period, the changed extent can be quickly synchronized to those disks that have just expired.

You can set the DISK_REPAIR_TIME attribute so that the failed disk will not be reorganized during the time when it is repaired or brought online again. This time can be in the unit of minute m or M), hour h or H. If you do not specify the time unit, the default time unit is hour. If DISK_REPAIR_TIME is not set, the default value is 3.6 hours. Note that this default value applies when the disk is set to offline mode and the operation statement does not have the drop after clause. In most cases, the default attribute value of DISK_REPAIR_TIME in 3.6 hours should be appropriate.

Note:

With this new feature, the compatibility of the ASM disk group must be set to 11.1 or higher.

Example:

Create diskgroup asmdskgrp1 DISK '/dev/raw /*'

Set attribute 'compatible. rdbms '= '11. 1', 'compatible. asm' = '11. 1 ';

Only when the disk that contains the offline disk is mounted again and the elapsed time is from the disk to the offline mode) is increased, the REPAIR_TIME column of V $ ASM_DISK shows the remaining time unit of the offline disk before it is deleted. When the specified time arrives, ASM deletes the disk, you can use the alter diskgroup disk offline statement with drop after to overwrite this attribute.

Note:

Drop after is also a new feature of 11g.

If a disk operated by the alter diskgroup set attribute DISK_REPAIR_TIME operation contains offline disks, this ATTRIBUTE takes effect only for non-Offline disks currently.

When an offline disk is offline for the second time, the elapsed time is reset and the computation starts again. If the disk is dropped AFTER at another time, the previous value will be overwritten and the new value will take effect. You cannot use the alter diskgroup drop disk statement to delete an offline DISK. In this case, an error is returned. If the disk cannot be repaired at a certain time, for example, when the disk needs to be deleted before DISK_REPAIR_TIME arrives, you can run the OFFLINE statement with the drop after clause again, drop after specifies 0 h or 0 M, which means to delete immediately.

You can use alter diskgroup to set the DISK_REPAIR_TIME attribute of the disk group, which can be minute or hour, for example, 4.5 hours or 270 minutes. For example:

Alter diskgroup dg01 set attribute 'disk _ repair_time '= '4. 5h'

Alter diskgroup dg01 set attribute 'disk _ repair_time '= '70m'

After you fix the DISK, run the alter diskgroup disk online SQL statement to restore the DISK group to the ONLINE status. All new read/write operations can be performed normally, this statement also triggers the re-synchronization of extent changed during the disk service period from redundant data in the disk group to those disks that have just expired.

2. ASM rolling upgrade

In ORACLE11g and later versions, you can set the ASM cluster to the "rolling upgrade" mode to allow different versions of ASM nodes to work together. In the rolling upgrade mode, each node can be upgraded or patched independently without affecting the database usage. This greatly improves the normal running time of the database. Note that you can only perform "rolling upgrade" for ORACLE11g and later versions. In other words, you cannot use this function to upgrade ORACLE10g databases to 11G.

Before performing a rolling upgrade, make sure your environment is ready. For example, if you use the ORACLE Clusterware software, you must complete the upgrade to the next version that meets the requirements before rolling the upgrade. Of course, you should also use the rolling method when upgrading Clusterware to ensure higher stability and the maximum normal running time.

Before patching or upgrading the ASM software at a node, you must set the ASM cluster to the rolling upgrade mode, which allows you to start upgrading and operating your environment in multiple software versions, the statement is as follows:

Alter system start rolling migration to number;

Number is composed of the version number, Release number, update number, port release number, and port UPDATE number, separated by commas (,), for example, 11.2.0.0.0.

When running this statement, the instance checks whether the number you specified is compatible with the installed software version. After the upgrade, the following operations are sufficient for the ASM instance:

* Mount and detach a disk

* Open, close, and reconfigure the size and deletion of database files.

* Restrict access to the views and packages that come with ORACLE. All Global Views are invalid.

After the rolling upgrade starts, you can upgrade the software by dropping any ASM instance. After the upgraded ASM instance is started, it is automatically added to the ASM cluster. After all the instances in the cluster are upgraded to the latest software version, you can end the rolling upgrade mode.

If a disk is offline during rolling upgrade of the ASM instance, the disk remains offline until the upgrade is completed, the disk deletion record is stopped when the ASM cluster returns to normal mode.

If a problem occurs after the upgrade, you can use the same process to roll back the node software to the previous version. The cluster has a data reorganization operation, and the upgrade will fail. Therefore, you must wait until the data reorganization operation is complete to start rolling upgrade. In addition, as long as one node in the cluster is active, the rolling upgrade status is retained.

If a new ASM instance is added when a cluster is performing rolling upgrade, the new instance is notified that the cluster is in rolling upgrade mode, you can use the following SQL statement to query the status of the ASM cluster environment:

SELECT SYS_CONTEXT 'sys _ cluster_properties ', 'Cluster _ state') from dual;

If all the instances in the ASM cluster are stopped, the instance will be out of the rolling upgrade mode when any ASM instance is restarted. To upgrade an instance after it is restarted, you must restart the rolling upgrade operation.

After the rolling upgrade is complete, run the following SQL:

Alter system stop rolling migration;

After this statement is issued, ORACLE performs the following operations:

* Check whether the software versions of all the members of the ASM cluster are the same. If one or more instances run in different software versions, this statement reports an error and the cluster continues to be in the rolling upgrade mode.

* Remove all instances of the cluster from the rolling upgrade mode, and the cluster starts to work fully.

* If the ASM_POWER_LIMIT parameter is set to allow data refresh, the data refresh operation that is blocked due to rolling upgrade will start again.

3. Added SYSASM permissions and OSASM operating system user groups to the ASM administrator.

In ORACLE10g, ORACLE does not customize the corresponding roles for the ASM administrator. The ASM administrator manages the tasks with the SYSDBA role, in actual work, the ASM administrator and the database administrator may be two or several different people, and the permission definition is relatively unclear. 11g this new feature introduces SYSASM. This new permission aims to clarify the interfaces between the ASM administrator and the database administrator, prevent unauthorized operations, and enable the ASM administrator to better manage the ASM.

This new feature also adds an OSASM user group to the operating system. The OSASM group is specially designed for ASM and can be authorized by the operating system, the authorized members of this group have the SYSASM permission for local connection and can perform full-Permission ASM management with the SYSASM role. At first, only the ASM installer is a member of this group. In subsequent work, you can add new users to the OSASM user group so that new users have all permissions for ASM management.

Note that in the ORACLE11g Release1 version, members of the OSDBA Group of the system can still connect to and manage ASM instances according to SYSDBA permissions, however, we believe that users with SYSDBA permissions in subsequent versions will not be authorized to manage the ASM instance.

4. Improved ASM scalability and Performance

The management of the ASM file area has been improved at 11 GB, reflecting the performance improvement and significant reduction in the SGA memory used to store the file area. When the size of the ASM file increases, the size of each partition will automatically increase. Therefore, there will be a small number of pointer description files pointing to the partition. When accessing an ASM file of 20 GB to TB size, this new feature of 11 GB will improve the performance. Of course, such files are usually used by very large databases (VLDBs.

In addition, when you create a new disk group, you now have multiple allocation unit size options, such as 1, 2, 4, 8, 16, 32, and 64 MB ). Depending on the database load and storage system type, selecting a large allocation unit may significantly improve the performance.

The content of the ASM file stored in the disk group is composed of N data partitions, which are stored on Independent Disks. The partition contains one or more allocation units (AU ). To adapt to the increasing size of files, ASM uses a variable size area.

The variable size area supports larger ASM files, reduces the usage of SGA memory by large databases, and improves the performance of File Creation and opening operations. A zone starting with an ASM file is composed of a distribution unit. When the file size increases, if the size exceeds the pre-defined value, the new partition size will also increase to 8 allocation units, and then the new partition size will increase to 64 allocation units. This feature automatically takes effect for newly created files.

The size of the allocation unit is determined when the disk group is created. It can be 1, 2, 4, 8, 16, 32, or 64 MB. When the size range of the ASM file is between 1 and 20,000 zones, the size of each partition is equal to the size of the allocation unit. When the file size exceeds 20,000, the range is from 20,001 to 40,000, the size of the new partition is automatically increased to 8 allocation units. When the file size of the new ASM exceeds 40,000, the size of the new partition is automatically increased to 64 allocation units.

Figure 1 shows the change of the disk group containing a self-block disk. The file changes from 1AU to 8AU in each zone. In this configuration, ASM does not make a file image.

Figure 1 Comparison of ASM files in a disk group

5. New ASM command line ASMCMD) command and option.

ASMCMD has the following four new commands: lsdsk, md_backup, md_restore, and remap. In addition, you can use the ls and lsdg commands with new options. The following describes the four new ASM commands:

Lsdsk-whether or not there is an ASM real column running, this command can list information about the ASM disk. This command is useful when the system administrator or storage administrator wants to check which disks are used by the ASM instance.

The md_backup and md_restore commands allow you to re-create an existing disk group with the same disk path, disk name, failure group, attributes, template, and directory structure alias. You can use md_backup to back up the disk group environment and use mk_restore to restore the corresponding disk group when a problem occurs.

Remap-you can use this command to Remap or reply to Bad blocks in the ASM disk in normal and high redundancy modes. ASM reads the corresponding blocks in a copy of the ASM image, write these blocks back to an alternative position in the disk group.

6. New Attributes of disk group compatibility

1) disk group compatibility Overview

To use some new features of ASM, you can use the compatibility attributes of the two disk groups, COMPATIBLE. RDBMS and COMPATIBLE. ASM. These attributes specify the minimum software version required by the database and ASM to use the disk group respectively. By default, both attributes are set to 10.1. to use new features, you must promote these attributes.

Setting the compatibility attribute to an earlier version allows the client to access a later version of the disk group. For example, the Oracle 10g client can access the Oracle 11g ASM disk.

The Compatibility attribute settings of the ASM and Oracle Database disk determine the minimum version of the ASM and Oracle database software that can be used by the system. For example, if the ASM compatibility is 11.1 and the Oracle database compatibility is 10.1, the ASM software version must be at least 11.1, And the Oracle database customer software version must be at least 10.1. The two attribute settings are compatible. asm and compatible. rdbms.

The software version of ASM determines the default compatibility of the recently created disk groups. When you CREATE a disk group using the create diskgroup SQL statement, you can ignore the disk group compatibility settings. In addition, you can use the alter diskgroup SQL statement to change the compatibility settings for an existing disk group. The disk group compatibility settings can only increase gradually. You cannot restore a lower compatibility setting.

2) COMPATIBLE. ASM and COMPATIBLE. RDBMS

These two parameters are used to set the compatibility attribute. The COMPATIBLE. ASM attribute determines whether an ASM instance uses the smallest software version of a disk group. This setting also determines the data structure format of the original ASM data on the data disk. The format of the file content is determined by the database instance. For ASM in Oracle 11g version, 10.1 is the default value. To better complete the disk group compatibility settings, set the COMPATIBLE. ASM Attribute before COMPATIBLE. RDBMS.

The value of the COMPATIBLE. RDBMS attribute of all disk groups used by the database must be smaller than or equal to the value set by the database's COMPATIBLE initial parameter. for ASM and 10.1 in Oracle 11g versions, they are also the default value of the COMPATIBLE. RDBMS attribute. For example, if the database compatibility initialization parameter is set to 11.1.0, COMPATIBLE. RDBMS can only be set to any value between 10.1 and 11.1.

3) how to set the disk group compatibility

You may use the create diskgroup or alter diskgroup statement to set the compatibility attribute of the disk group.

Specify the compatibility attribute when creating a disk group using CREATE DISKGROUP

In the following example, a normal redundant disk asmdskgrp1 is created, and the ASM compatibility attribute is set to 10.2. For the database compatibility attribute, the default value is assumed that COMPATIBLE. RDBMS is less than or equal to 10.2 by default ):

Create diskgroup asmdskgrp1 DISK '/dev/raw /*'

Set attribute 'compatible. asm '= '10. 2 ';

In the following example, a normal redundant disk asmdskgrp2 is created, and the ASM compatibility attribute is set to 11.1. For database compatibility attributes, the default value is assumed that COMPATIBLE. RDBMS is less than or equal to 11.1 by default ):

Create diskgroup asmdskgrp2 DISK '/dev/raw /*'

Set attribute 'compatible. asm '= '11. 2 ';

The following example shows how to create a normal redundant disk asmdskgrp3. The attributes of ASM compatibility and database compatibility are 11.1:

Create diskgroup asmdskgrp3 DISK '/dev/raw /*'

Set attribute 'compatible. rdbms '= '11. 1', 'compatible. asm' = '11. 1 ';

Use the alter diskgroup SQL statement to change the compatibility attribute of an existing disk group.

After a disk group is created, you can use the alter diskgroup SQL statement to change the compatibility attribute. Before using the alter diskgroup SQL statement to submit changes, ensure that Oracle can improve the compatibility of the specified disk group. To enable alter diskgroup to improve disk group compatibility without reducing database and file system functions, all affected databases and file systems should be online.

Example:

Alter diskgroup asmdskgrp4 set attribute 'compatible. rdbms '= '11. 1 ';

Alter diskgroup asmdskgrp5 set attribute 'compatible. asm '= '11. 1 ';

7. Master image reading in ASM

1) preferentially read the new feature summary from the image

In an extended cluster, if remote node access is unbalanced, this new feature is useful for improving performance. This results in better storage utilization and reduced network load. In Oracle 10 Gb, ASM reads the primary copy of an image set. We know that this is done to distribute IO and improve performance. For a disk in a disk group, a node may be a local disk or a remote disk. If data is read from the master copy, the master copy is a remote disk, obviously there is no local disk with high efficiency. However, in Oracle10g, the data cannot be read from which disk. In 11g, The ASM_PREFERRED_READ_FAILURE_GROUPS parameter is introduced, that is, the ASM priority image read new features, this new feature can be further described as follows.

When you configure the ASM failure group, it enables the node to read data from the zone closest to it. This may be the most efficient, even if that zone is a secondary zone. In other words, when the secondary area is closer to the node, you can configure ASM to read from a secondary area rather than from a distant primary area. The use of the read-ahead failure group is very useful for extended clusters.

Using this feature, we recommend that you copy at least one image partition on the local disk of the extended cluster relative to this node. However, in a RAC database, a failure group set to give priority to reading data for one node may be selected for another node, so don't worry, the parameter settings of each instance read-ahead failure group can be specified separately.

Note:

By default, when you create a disk group, each disk in the disk group belongs to a failed group. Oracle does not recommend that you configure more than one failed read group for each instance using the disk group. If you configure more than one failed read group for each instance, the Oracle alter log will write a warning message.

2) configure and manage the failed read group with priority

To configure this new feature, you need to set the ASM_PREFERRED_READ_FAILURE_GROUPS parameter, which is a list of failure groups. This parameter is usually used in the Cluster's ASM instance, it is also valid in the ASM instance of the cluster, and each instance is set to a different value. Its default value is NULL. The parameter format is as follows:

Example:

Diskgroup_name1.failure_group_name1 ,...

Diskgroup_name indicates the name of the disk group, and failure_group_name indicates the name of the failure group. If no corresponding failure group exists in the specified disk group, ASM ignores the corresponding failure group. You can use commas to separate multiple values as the ASM_PREFERRED_READ_FAILURE_GROUPS parameter.

Example:

ASM_PREFERRED_READ_FAILURE_GROUPS = diskgroup_name.failure_group_name, diskgroup_name1.failure_group_name1...

8. Fast ASM rebalancing

The rebalancing operation occurs when the disk group is in the restricted mode. In addition to locking and unlocking the extent map information in the Oracle RAC environment, it also eliminates the message communication between the ASM instances, this improves the overall rebalancing throughput.

Oracle video tutorial follow: http://u.youku.com/user_video/id_UMzAzMjkxMjE2.html