Shulou(Shulou.com)06/01 Report--

Http://www.thinksaas.cn/topics/0/526/526235.html

What is ASM?

ASM, whose full name is Automated Storage Management, or automatic storage management, is a new feature introduced by Oracle in this version of Oracle10g. This is a volume manager provided by Oracle to replace the LVM provided by the operating system. It supports not only single-instance configurations but also multi-instance configurations such as RAC. It will bring great convenience to Oracle database administrators, and ASM can automatically manage disk groups and provide data redundancy and optimization. Especially for the enterprise's extremely large database administrator, the administrator can be freed from the trivial daily tasks of managing hundreds of data files in order to deal with other more important tasks.

Before the version of Oracle 10g, managing hundreds of data files in a large database is a non-technical and boring task for database administrators, which requires database administrators to be familiar with some system-related knowledge of LVM and do a good job of disk specification, LV striping and other related system operations. Using automatic storage management will greatly reduce the workload in this area, and 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 set of disk devices. We can define a disk group as the default disk group for the database, and Oracle automatically manages storage, including creating and deleting data files, and so on. Oracle automatically associates these files with an appropriate database object, so we only need to provide the name of the object when managing these objects, instead of providing a 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 separate set of disks. In this way, the I-map-O equalization of a single disk group is realized. At the same time, ASM also implements striping (Striping) and disk mirroring (Mirroring) to improve the performance and data reliability of Istroke O. Unlike RAID or LVM, ASM is striped and mirrored at the file level, which gives users a lot of freedom to choose. We can configure different storage attributes for different files in the same disk group to achieve different storage methods. 2. What are the new features of ASM in 11g:

2.1Quick resynchronization (ASM Fast Mirror Resync)

"when there is a problem with a short disk path, it can be time-consuming to restore the allowance of the ASM disk group (DISK GROUP), especially if such a restore operation requires relayout of the entire disk group." The new ASM fast disk resynchronization feature significantly reduces the time it takes to resynchronize a bad disk. When you replace a bad disk, ASM can quickly synchronize the extent of ASM disks.

Any problem that makes the disk group temporarily unavailable is considered a temporary failure, which can be restored by the new ASM fast resynchronization feature. Disk path failures, such as interface cable problems, host adapter problems, disk controller problems, or disk power problems, can cause transient failures. By default, when a disk is offline, ASM immediately removes it. The ASM fast resynchronization function can record all the changes in the upper area of the offline disk during the offline period, and when the disk is repaired or online again, the changed extent can be quickly resynchronized to these disks that have just failed.

You can set the DISK_REPAIR_TIME property to prevent the failed disk from being reorganized during the time it is repaired and brought online again. This time can be in minutes (m or M) or hours (h or H). If you do not specify a unit of time, the default unit of time is hours. If the DISK_REPAIR_TIME property is not set, its default value is 3.6h. It is important to note that this default applies when the disk is set to offline mode and the operation statement does not have a DROP AFTER clause. For most of the environment, the default DISK_REPAIR_TIME attribute value of 3.6h should be appropriate.

Note:

With this new feature, the compatibility of ASM disk groups needs to 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 group containing the offline disk is mounted again, the elapsed time (since the disk is set to offline mode) is increased. The REPAIR_TIME column of V$ASM_DISK shows the time remaining before the offline disk is deleted (in seconds). When the specified time arrives, ASM deletes the disk, which can be overwritten with an ALTER DISKGROUP DISK OFFLINE statement with DROP AFTER.

Note:

DROP AFTER is also a new feature of 11g.

If a disk group operated by ALTER DISKGROUP SET ATTRIBUTE DISK_REPAIR_TIME contains offline disks, this property applies only to those disks that are currently in non-offline mode.

When an offline disk is performed offline for the second time, the elapsed time is reset and the calculation starts again. If the disk is DROP AFTER again at another time, the previous value will be overwritten and the new value will take effect. You cannot delete a disk that is offline with the ALTER DISKGROUP DROP DISK statement, so an error will be reported during the operation. If at some point, for example, the disk cannot be repaired, and you need to delete the disk before DISK_REPAIR_TIME arrives, you can execute the OFFLINE statement with the DROP AFTER clause again. DROP AFTER specifies 0H or 0m, which means delete immediately.

You can use ALTER DISKGROUP to set the DISK_REPAIR_TIME property of a disk group, which can be minutes or hours, such as 4.5hours or 270minutes, for example:

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

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

After you repair the disk, run the SQL statement ALTER DISKGROUP DISK ONLINE to bring the disk group back online, and the new read and write operations can be carried out normally. This statement also triggers the resynchronization of the extent changed during disk repair from the redundant data of the disk group to the disks that have just failed. 2.2 ASM rolling upgrade

In ORACLE11g and later versions, you can put the ASM cluster in "rolling upgrade" mode, allowing different versions of ASM nodes to work together. Each node in the "rolling upgrade" mode can be upgraded or patched independently without affecting the use of the database, so it greatly improves the uptime of the database. It is important to note that you can only "roll upgrade" to ORACLE11g and later versions, in other words, you cannot use this feature to upgrade ORACLE10g databases to 11G.

Your environment must also be prepared before rolling upgrades. For example, if you use ORACLE Clusterware software, Clusterware must be fully upgraded to the next version that meets the requirements before you can do a rolling upgrade. Of course, Clusterware upgrades should also be scrolled to ensure high stability and maximum uptime.

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

ALTER SYSTEM START ROLLING MIGRATION TO number

Number consists of version number, release number, update number, port release number, and port update number, separated by commas, such as 11.2.0.0.0.

When running this statement, the instance checks whether the number you specified is compatible with the currently installed version of the software. When the upgrade starts, only the following actions are allowed for the ASM instance:

? Disk group mount and unmount

? Database files open, close, resize and delete

? Restrict access to views and packages that come with ORACLE, and all global views are invalid

After the rolling upgrade starts, any ASM instance can be disabled for software upgrade, and the upgraded ASM instance will automatically rejoin the ASM cluster after startup. When all the instances in the cluster have been upgraded to the latest software version, you can end the rolling upgrade mode.

If a disk is offline during a rolling upgrade of the ASM instance, it will remain offline until the upgrade speed, and the timer that triggers the deletion of the disk will stop until the ASM cluster returns to normal mode.

If there is a problem with the upgrade, you can roll back the node's software to the previous version using the same process. There is a data reorganization operation anywhere in the cluster, and the upgrade will fail, so you must wait for the data reorganization operation to complete before you can start the rolling upgrade. In addition, as long as one node in the cluster is active, the rolling upgrade state is retained.

If a new ASM instance is added when a cluster is undergoing a rolling upgrade, the new instance will be told that the cluster is in rolling upgrade mode. You can query the status of the ASM cluster environment with the following SQL statement:

SELECT SYS_CONTEXT ('sys_cluster_properties',' cluster_state') FROM DUAL

If all instances of the ASM cluster are stopped, then when any ASM instance is restarted, the instance will leave the rolling upgrade mode. If you want to upgrade after all the instances are restarted, you must restart the rolling upgrade operation.

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

ALTER SYSTEM STOP ROLLING MIGRATION

After issuing this statement, ORACLE does the following:

? Verify that all members of the ASM cluster have the same software version. If one or more instances are running in different software versions, this statement will report an error, and the cluster will continue to be in rolling upgrade mode.

? All instances of the cluster are out of the rolling upgrade mode, and the cluster begins to work in full function.

? If you set the ASM_POWER_LIMIT parameter to allow data reprocessing, data reprocessing operations blocked by rolling upgrades will restart. 2.3 added SYSASM permissions and OSASM operating system user groups for ASM administrators

In this version of ORACLE10g, ORACLE does not customize the corresponding roles for ASM administrators. ASM administrators manage with SYSDBA roles. In actual work, ASM administrators and database administrators may be done by two or more different people. Relatively speaking, the definition of permissions is not clear. 11g this new feature introduced SYSASM this new authority is to clarify the interface between ASM administrators and database administrators and to prevent the occurrence of ultra vires operations. Enable ASM administrators to better manage ASM.

This new feature also adds a new OSASM user group for ASM in the operating system. OSASM is specially designed for ASM and can be authorized by the operating system. The authorized members of this group have SYSASM permissions for local connections and can manage ASM with full permissions in the SYSASM role. Initially, only ASM installers are members of this group. In subsequent work, you can add new users to the OSASM user group so that new users have full permissions for ASM management.

It should be noted that in this version of ORACLE11g Release1, members of the system OSDBA group who connect to the database have SYSDBA permissions, and such users can still connect and manage ASM instances, but it is believed that users with SYSDBA permissions in subsequent versions will not be authorized to manage ASM instances.

2.4Enhancement of scalability and performance of ASM

ASM file area management has improved in 11g, which is reflected in the performance improvement and significant reduction in SGA memory used to store the file area. As the size of the ASM file increases, the size of each zone automatically increases, so there is little need for a pointer to the area to describe the file. This new feature of 11g improves performance when accessing 20GB to 128TB-sized ASM files. 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 load of the database and the type of storage system, choosing a large allocation unit may result in a significant performance improvement.

The contents of the ASM file stored by the disk group are made up of N data regions, which are stored on separate disks. Zones contain one or more allocation units (AU). To accommodate the growing size of large files, ASM uses areas of varying sizes.

Varying sizes can support larger ASM files, reduce the use of SGA memory by large databases, and improve the performance of file creation and open operations. The area at the beginning of an ASM file consists of an allocation unit. When the file size increases, if the size exceeds the predefined value, the new zone size also increases to 8 allocation units, and then the new zone size increases to 64 allocation units. For newly created files, this feature takes effect automatically.

When the size of the allocation unit is determined when the disk group is established, it can be 1, 2, 4, 8, 16, 32, and 64MB. When the size of the ASM file ranges from 1 to 20000 regions, the size of each zone is equal to the size of the allocation unit; when the file size exceeds 20000 to 20001 to 40000, the size of the new zone automatically increases to 8 allocation units. And when the ASM file size exceeds 40000 extents, the size of the new zone is automatically increased to 64 allocation units.

Figure 1 shows the disk group containing the block disk, and the file changes from 1AU to 8AU in each zone. In this configuration, ASM does not mirror the file. 2.5 new ASM command line (ASMCMD) commands and options.

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

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

The md_backup and md_restore- commands enable existing disk groups to be re-established with the same disk path, disk name, failed group, attribute, template, and directory structure alias. You can use md_backup to back up the environment of the disk group, and use mk_restore to restore the corresponding disk group if there is a problem.

Remap- you can use this command to remap or reply to bad blocks in normal and high redundancy mode ASM disk groups. ASM reads the corresponding blocks in the ASM image and rewrites them back to an alternative location in the disk group.

2.6 New attributes for disk group compatibility

2.6.1 Diskgroup compatibility Summary

To use some of ASM's new features, you can use two diskgroup compatibility attributes, COMPATIBLE.RDBMS and COMPATIBLE.ASM. These attributes specify the minimum software version required for each of the libraries and ASM to use disk groups. By default, both properties are set to 10.1, and you must advance them if you want to take advantage of the new features.

The compatibility property is set to a previously released version that allows clients to access higher versions of disk groups, for example, clients with Oracle 10g can access Oracle11g's ASM disk groups.

The ASM and Oracle database disk group compatibility property settings determine the minimum version of ASM and Oracle database software that the system can use. For example, if ASM compatibility is 11.1 and Oracle database compatibility is 10.1, then the ASM software version must be at least 11.1 and the Oracle database client software version must be at least 10.1. The two property settings are compatible.asm and compatible.rdbms.

The software version of ASM determines the default compatibility of recently created disk groups. When you create disk groups with CREATE DISKGROUP SQL statements, 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 setting can only increase gradually, and you cannot revert back to a lower compatibility setting.

2.6.2 COMPATIBLE.ASM and COMPATIBLE.RDBMS

The compatibility property setting is done through these two parameters. The COMPATIBLE.ASM attribute determines that any ASM case uses the smallest software version of a disk group. This setting also determines the format of the data structure of the ASM raw data on the data disk. The format of the file content is determined by the database instance. For ASM in the 11g version of Oracle, 10.1 is the default setting. To better complete the disk group compatibility setting, you should set the COMPATIBLE.ASM property before setting the COMPATIBLE.RDBMS.

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

2.6.3 methods for setting disk group compatibility

It is possible to set the compatibility properties of a disk group through two statements called CREATE DISKGROUP or ALTER DISKGROUP.

Specify compatibility properties when establishing a disk group using CREATE DISKGROUP

The following example creates a normal redundant disk group asmdskgrp1,ASM compatibility property set to 10.2, and the database compatibility property defaults (assuming 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'

The following example creates a normal redundant disk group asmdskgrp2,ASM compatibility property set to 11.1, and the database compatibility property defaults (assuming 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 creates a normal redundant disk group asmdskgrp3,ASM compatibility attribute and database compatibility attribute.

CREATE DISKGROUP asmdskgrp3 DISK'/ dev/raw/*'

SET ATTRIBUTE 'compatible.rdbms' =' 11.1', 'compatible.asm' =' 11.1'

Use the ALTER DISKGROUP SQL statement to change compatibility properties for an existing disk group

After the disk group is created, you can use the ALTER DISKGROUP SQL statement to change the compatibility properties. Use the ALTER DISKGROUP SQL statement to ensure that Oracle improves the compatibility of the specified disk group before committing changes. In order for ALTER DISKGROUP to improve disk group compatibility without reducing database and file system functionality, all affected databases and file systems should be online.

For example:

ALTER DISKGROUP asmdskgrp4 SET ATTRIBUTE 'compatible.rdbms' =' 11.1'

ALTER DISKGROUP asmdskgrp5 SET ATTRIBUTE 'compatible.asm' =' 11.1 reading; 2.7 ASM priority mirror read

2.7.1 priority Mirror read New feature Summary

In an extended cluster, this new feature is useful to improve performance if the access of remote nodes is uneven. This results in better storage utilization and lower network load. In Oracle 10g, ASM always reads a primary copy of the mirror zone set, and we know that the purpose of doing this is to disperse the IO and improve performance. For a disk of a disk group, it may be a local disk or a remote disk for a certain node. If the data is read from the master copy, the master copy is also a remote disk, which is obviously not as efficient as the local disk. However, it is impossible to set which disk to read data from in Oracle10g. The parameter ASM_PREFERRED_READ_FAILURE_GROUPS is introduced in 11g, that is, the new feature of ASM priority image reading, which can be completed. This new feature can be described in more detail below.

When you configure the ASM failure group, it causes the node to read data from the zone closest to it, which is probably the most efficient, even if that zone is a secondary zone. In other words, when the secondary zone is close to the node, you can configure ASM to read from a secondary area instead of from a distant primary area. Using priority read failure groups is useful for expanding the cluster.

Using this feature, Oracle recommends that you configure at least one zone copy of the image in the local domain of the extended cluster relative to this node. However, in a RAC database, the failure group that is set for one node to read first may be optional for another node, so don't worry, the parameter settings for each instance to read the failure group first can be specified separately.

Note:

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

2.7.2 configure and manage priority read failure groups

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

For example:

Diskgroup_name1.failure_group_name1,...

Where diskgroup_name represents the name of the disk group and failure_group_name represents the name of the failed group. If the corresponding failure group does not exist in the disk group specified by the setting parameter, ASM ignores the corresponding failure group. You can set multiple values for the ASM_PREFERRED_READ_FAILURE_GROUPS parameter separated by commas.

For example:

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

2.8Fast rebalancing of ASM

The rebalancing operation occurs when the disk group is in restricted mode, it also eliminates the communication of locking and unlocking extent map information between ASM cases in the Oracle RAC environment, thus improving the overall rebalancing throughput.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.