ORACLE10g版本推出时，为了简化RAC中存储端的配置，ORACLE新推出了ASM(Automatic Storage Management --自动存储管理)特性，该特性拥有易管理，高自动性，并且，拥有号称超越裸设备IO性能。升级到11gR2版本后，又被正名为传说中的ASMFS，这也说明了ORACLE对这一特性的重视程度。

　　因此从今天起，三思决定花个三二分钟时间，跟大学一块学学关于ASM的那点儿事儿，另注，本文操作的数据库版本为10gR2。

1、About ASM 实例

　　ASM 实例与 ORACLE 实例差不多，都是 由 sga 和一堆后台进程组成，从功能上来看，区别在于oracle实例管理的是数据库，而asm实例只是管理asm盘阵。

　　通过Oracle EM或DBCA都可以对asm进行一些配置，不过三思觉着管理asm括弧实例的最佳工具仍是sql*plus，在进入sql*plus前也需要设置ORACLE_SID的环境变量，该环境变量通常是+ASM[node#] 。

　　ASM 实例没有数据字典之类的东东存储用户系统，因此最常见的连接认证方式就是操作系统认证as sysdba进入(OSDBA组的用户)。如果是通过远程连接的话( 比如远程通过tnsnames或OEM管理)，也可以使用密钥文件进行验证，该密钥文件直数据库的密钥文件在命名规则及使用规则上完全一模一样。如果使用dbca建库的话，默认就会创建asm的密钥文件，当然也可以自行手动通过orapwd命令进行创建，与数据库的密钥文件有所不同的是，asm 的密钥文件对应的用户只有一个----sys。

提示：什么是 ASMLib ！

即ASM support Library，是由ORACLE提供的简化管理操作系统管理的API 。

1.1、启动 / 关闭 ASM 实例

　　ASM 实例与DB实例高度相似，启动和停止实例的命令也一模一样，就启动来说，也同样拥有 NOMOUNT/MOUNT/OPEN /FORCE 几种状态。

· NOMOUNT ：仅启动实例；

· MOUNT 、OPEN：启动实例并加载磁盘，注意加载的是磁盘组(如果当前未创建或配置任何磁盘组，则提示敬告信息)，OPEN选项对于ASM实例无意义，等同于MOUNT。

· FORCE ：相当于先执行shutdown abort，然后再startup。

　　演示如下(注意别忘了先设置操作系统环境变量ORACLE_SID)，先启动到NOMOUNT：

[oracle@jssdbn1 ~]$ export ORACLE_SID=+ASM1

[oracle@jssdbn1 ~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.4.0 - Production on Wed May 19 08:34:22 2010

Copyright (c) 1982, 2007, Oracle. All Rights Reserved.

Connected to an idle instance.

SQL> startup nomount

ASM instance started

Total System Global Area 130023424 bytes

Fixed Size 2082208 bytes

Variable Size 102775392 bytes

ASM Cache 25165824 bytes

SQL> select name,state from v$asm_diskgroup;

NAME STATE

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

ASMDISK1 DISMOUNTED

ASMDISK2 DISMOUNTED

SQL> select instance_name,status from v$instance;

INSTANCE_NAME STATUS

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

+ASM1 STARTED

　　加载磁盘组，注意，不是alter database哟：

SQL> alter diskgroup all mount;

Diskgroup altered.

SQL> select name,state from v$asm_diskgroup;

NAME STATE

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

ASMDISK1 MOUNTED

ASMDISK2 MOUNTED

　　这样，该ASM就可以提供存储服务了。

　　提示一点，在10g版本中，ASM是依赖于CSS守护进程的，因此在启动ASM 实例前要确保css守护进程已经启动 。 CSS(Cluster Synchronization Services) 守护进程 用来维持ASM 及客户端数据库实例间的一致性 同步 ，如果是通过dbca建库的话，那么CSS守护进程默认即会启动(跟随系统reboot)。

　　检查css守护进程是否启动非常 简单 ，直接使用crsctl check cssd即可，如果启动的话会收到"CSS appears healthy"的返回消息，例如：

[oracle@jssdbn1 ~]$ crsctl check cssd

CSS appears healthy

　　关闭ASM实例，简单了，NORMAL/IMMEDIATE/TRANSACTIONAL/ABORT几个选项的定义与关闭普通数据库实例完全一模一样！例如：

SQL> shutdown immediate

ASM diskgroups dismounted

ASM instance shutdown

1.2、关于ASM实例的初始化参数

　　ASM 实例的初始化参数形式上与数据库的初始化参数相同，也分spfile和pfile，操作方式也完全相同，只不过具体的参数及参数值略有差异，大多数数据库的初始化参数在这里也能见到，并且某些参数意义都完全相同，同样也有一些参数虽然见到了，不过并不需要设置，这个可以理解，毕竟asm只有实例，相对比数据库的初始化参数要简单的多了，还有一些参数则是数据库初始化参数中没有的。比如ASM开头的那几个初始化参数，俺争取把差异的部分都列出来写明了。

　　ASM 实例在内存占用这块还是比较轻量级的，基本上有个100m空间就很充足了 ，因此内存这块相关参数就不说了，下面说说几个ASM实例特别需要的参数。

　　首先，初始化参数中的INSTANCE_TYPE，该参数必须被设置为ASM，如：

INSTANCE_TYPE=ASM

　　标识要启动的实例是ASM，而不是数据库实例(数据库实例对应类型为RDBMS)。

　　与ASM相关的初始化参数有三个：

· ASM_POWER_LIMIT ：指定磁盘rebalance的程度，有0-11个级别，默认值为1，指定的级别越高，则rebalance的操作就会越快被完成(当然这也意味着这个时间段内将占用更多的资源)，指定级别较低的话，虽然rebalance操作会耗时更久，但对当前系统的IO及负载影响会更少，这中间的度需要DBA根据实际情况衡量。另外，这个参数指定的只是一个默认值，在操作过程中，即可以随便动态修改，也可以在语句级命令行时指定power，覆盖该默认值。

提示：关于rebalance操作，如果你没接触过，还不明白是什么意思，没关系，继续往下看！

· ASM_DISKSTRING ：用最简单的话说，就是设置ASM启动时检查的磁盘，该选项可以同时指定多个值，并且支持通配符。比如说，只检查/dev/dsk/下的设备，可以设置该参数如下：/dev/dsk/*，默认情况下该参数为空，为空的话，表示ASM将查找系统中所有ASM拥有读写权限的设备。

· ASM_DISKGROUPS ：指定实例启动或alter diskgroup all mount语句时要加载的磁盘组，如果为空的话，那么实际就仅启动到NOMOUNT状态了。如果是使用SPFILE的话，该参数一般不需要手动修改，ASM能够自动更新该初始化参数中的值。

　　修改 ASM 实例初始化参数文件的命令规则与数据库初始化参数完全相同 ，比如说：

SQL> alter system set asm_power_limit=5 sid='*';

System altered.　

2、管理ASM磁盘

　　本节简单给大家描述下关于ASM磁盘组的管理操作，关于ASM磁盘组的管理其实非常简单(也非常少)，主要是由于10gR2中这个东西透明 度不够 ，ORACLE提供的功能有限，因此我们能够做的操作就更加有限了，因此决定随便写个几百W字大家凑和着看看就得了，不深入了。

　　OK ，下面步入正题。

　　ASM 磁盘组的管理方式呢也比较多，比如像DBCA、EM、SQL*PLUS等均可操作(不同工具 易用性不同，不过 功能也有差异)，除此之外ORACLE还专门提供了ASMCMD命令行方式，像操作文件系统一样来操作磁盘组。本节操作主要使用sql*plus命令行工具，关于asmcmd命令行中的命令，感兴趣的朋友可以期待本文外传~~~

　　在管理ASM之前不得不提与ASM相关的动态性能视图，这些视图将对我们后面的操作起到重要作用，查询数据库中ASM相关视图可以通过下列SQL语句：

　　这其中，V$ASM_ALIAS视图中记录文件别名信息，V$ASM_CLIENT返回当前连接的客户端实例信息，V$ASM_DISK*相关视图中记录的是ASM管理的磁盘及磁盘组信息，V$ASM_OPERATION记录当前磁盘的操作信息，例如：

　　在真正开始操作ASM之前呢，我觉着还是有必要先描述一下关于ASM磁盘总的原则供参考。

添加或删除磁盘的影响

　　当发生添加/删除磁盘组中磁盘的操作时，ASM能够自动平衡。对于普通的删除操作(无force选项)，被删除的磁盘在该上数据被有效处理前并不会立刻释放，同样，新增磁盘时，在重分配工作完成前，该盘也不会承担I/O负载的工作。

ASM 如何处理磁盘故障

　　ASM 中的磁盘组在三思看来可以分成两类：普通磁盘组和failure磁盘组，后者又与ASM的冗余方式有所关联。普通磁盘组就是标准的存储单元，ASM可以向其可访问的磁盘组中读写数据，failure磁盘组是为了提高数据的高可用性。ASM中的磁盘冗余策略非常简单，概要成三类：外部冗余、标准冗余和高度冗余，其中前者与failure磁盘组无关，如果设置了后者，那么该磁盘组就必须拥有failure磁盘组。听起来像在说failure磁盘组是普通磁盘组的子集，其实差不多可以这么理解，外部冗余的话磁盘属于磁盘组，内部冗余的话，磁盘属于磁盘组的同时，还属于某个(并且只能是一个)failure磁盘组。

　　比如说对于标准冗余(Normal Redundancy)，ASM要求该磁盘组至少要拥有两个failure磁盘组，即提供双倍镜像保护，对于同一份数据(ASM中镜像单位不是磁盘，也不是块，而是一种AU的单位，该单位大小默认是1M)将有主从两份镜像，并且ASM通过算法来自动确保主、从镜像不会存在于同一份failure磁盘组，这样就保障了就算整个failure磁盘组都损坏，数据也不会丢失。至于高度冗余(High Redundancy)就更安全了，它至少需要三个failure磁盘组，也就是一份AU有一主多从的镜像，理论上将更加安全。

　　如果磁盘发生损坏，那么损坏的磁盘默认自动offlice并被drop掉，不过该磁盘所在的磁盘组仍将保持MOUNT状态，如果该盘有镜像的话，那么应用不会有影响，镜像盘将自动实现接管--只要不是所有failure磁盘组都损坏掉，否则的话，该磁盘组将自动DISMOUNT。举个例子吧，某标准冗余的failure组有6个盘(对应6个裸设备)，假如说此时坏了一块盘，没关系，操作继续，坏了那块会被自动dropped，剩下的5块盘仍然能够负担起正常的读写操作。

ASM 扩展性

• 最多支持63个磁盘组；
• 最多支持10000个磁盘；
• 最大支持4pb/磁盘；
• 最大支持40 exabyte/ASM存储；
• 最大支持1百W个文件/磁盘组；
• 外部冗余时单个文件最大35tb，标准冗余时单个文件最大5.8tb，高冗余度时单个文件最大3.9tb

2.1 添加磁盘组

　　DBCA 中创建磁盘组想必大家都很熟悉了，对，不过是点两下鼠标，SQL*PLUS下操作也很简单，主要是使用CREATE DISKGROUP语句，该语句的语法如下：

　　语法很简单，大多数都是可选项：

• 首先要指定的就是磁盘组名称(diskgroup_name)；
• 指定冗余度，有三个选择：HIGH(高度冗余>三路)、NORMAL(标准冗余--双路)和EXTERNAL(外部存储冗余)；
• 选择是否指定FAILGROUP(如果选择非external则必须指定)；
• 指定该磁盘组中的成员(对应的LUN)，在指定成员时一般ASM能够自动检测出磁盘的容量，不过如果DBA基于某些方面的考虑，希望限制ASM使用的空间的话，也可以在指定成员过程中，顺便指定大小(只要指定的大小不超出磁盘实际容量)，在添加成员时，ASM也会自动检查磁盘头以确定该磁盘是否被加入到其它的磁盘组中，当发现该盘已加入其它磁盘组的话，你可以通过FORCE选项来强制修改该盘所属磁盘组。

2.2 修改磁盘组

　　事物总是在变化中前进，这是事物的一般规律，磁盘组也不例外，在其创建完之后，保不齐什么时候可能就需要加或删个磁盘，或者修改某个盘的大小(如果还有机会改的话)。这时候你就需要ALTER DISKGROUP语句了，ALTER DISKGROUP语句的语法太简单(灵活)了，因此这里三思就不列了，后面通过几个实际应用的示例来说明其语法规则。

　　ASM 最好的一点就是，不管你是加还是删磁盘组中的磁盘，它都能自动进行平衡，确保该磁盘组中每块盘存储的数据量平均，以实现最优化的IO性能，并且这一过程不会对数据造成影响

2.2.1 添加磁盘

　　比如，添加一个磁盘到磁盘组asmdisk1，语句如下：

　　事实上，alter diskgroup添加磁盘时，也可以使用通配符，比如添加所有raw_a0开头的设备，可执行语句如下：

　　再比如添加raw_a5,raw_a6,raw_a7，可以执行语句如下：

　　总之非常灵活，大家可以根据实际情况自行尝试以简化操作。这也属于优化着干活的范畴嘛。

　　注意哟，语句虽然执行了，不过ASM需要自动平均磁盘组中的数据，这必然需要消耗一定的时间(视数据量多少)，默认情况下ALTER DISKGROUP语句并不会等待所有工作全部完成才返回控制权，

　　要监控后台进行的操作，可以通过V$ASM_OPERATION视图查询。

　　如果希望ALTER DISKGROUP语句完成所有工作才返回的话，可以在执行时附加REBALANCE WAIT子句，这样该语句就会等待自动平衡的操作，直接所有操作完成才返回结果，当然在等待期间，如果你改主意了不愿意继续等待，CTRL+C中断即可获得控制权，而平衡的操作不受影响，会在后台继续进行。

2.2.2 删除磁盘

　　虽然删除磁盘也涉及到数据库的重新平衡，因此删除跟添加还有点儿不同，就是当删除磁盘时，当ASM发现怎么平衡都平衡不过来时(比如剩下的磁盘空间不足以存放所有数据时)，删除操作也会失败。这种情况要么先删数据，要么取消删除的操作。

　　简单举个例子，比如说删除asmdisk2磁盘组中的asmdisk2_0001磁盘，操作如下：

　　不知道算不算是优点，由于前面提到的ASM自动平衡的特性，上述语句返回后并不代表磁盘已经被删除，此时后台可能由于正忙碌地执行着IO重平衡的工作，因此如果在这个当口，DBA忽然意识到操作失误，其实磁盘并不需要被删除，那也可以马上通过alter diskgroup dgname undrop disks语句来取消删除的操作，例如：

　　只要删除操作还没有真正完成，任何就会被取消，否则的话，上述语句也挽回不了什么了，如果希望挽回，那DBA只能再通过ADD语句将该磁盘重新加入到磁盘组了。

2.2.3 修改磁盘大小

　　ASM 中的磁盘也可以被RESIZE--扩大或缩小，不过需要注意的是，扩大的话，要确保该磁盘对应的裸卷确实有足够的空间去扩大(比如该卷原有20g，创建时仅用了10g，则最大可扩大到20g-块头占用的nM空间)；缩小的话，要确保缩小后剩余的空间仍以放的下当前磁盘上已存在的数据，不然操作就会报错。

　　具体的操作是很简单的，例如将磁盘组asmdisk2的磁盘asmdisk2_0000的磁盘空间调整为1000m(原为8189m)，操作如下：

2.2.4 手动平衡磁盘组

　　一般情况下ASM都会自动对其下的磁盘组进行平衡，不过ORACLE也提供了手动平衡磁盘组的方式，通过alter diskgroup ... power 语句。前面提到过磁盘组的平衡度有0到11多个级别，默认是按照ASM_POWER_LIMIT初始化参数中设置的值，手动平衡的话，设置的平衡度可以与初始化参数中并不相同，例如，设置磁盘组平衡度为5，语句如下：

　　手动平衡磁盘组可能涉及大量的工作，该操作可能费时较久，因此DBA在执行该语句时，一定要注意该操作对IO性能的影响。

　　另外再次强调，上述语句将很快返回diskgroup altered的提示，但这并不表示操作真正完成，它只是反馈语句提交而已，查看磁盘后台的操作，可以通过v$asm_operator视图，或者在语句执行时增加wait子句，这样ASM将会等到操作真正完成时，才返回提示信息。

2.3 mount/unmount 磁盘组

　　只有被mount的磁盘组才能被数据库使用并执行add/drop等磁盘操作，ASM中的磁盘组默认会在ASM实例启动时自动加载，当然也可以手动通过命令行语句mount/unmount磁盘组。

　　查询ASM实例中创建的磁盘组可以通过V$ASM_DISKGROUP视图查看，例如：

　　当前两个磁盘组均为MOUNT状态，要将其置为UNMOUNT，执行语句如下，例如将ASMDISK2磁盘组UNMOUNT：

　　注意哟，UNMOUNT磁盘组的话务必慎重操作，要确保UNMOUNT的磁盘组中保存的文件对应的数据库当前未启动，而且该操作也会直接导致数据库SHUTDOWN。

　　再将其置回MOUNT状态，操作如下：

2.4 管理目录及文件

　　ASM 磁盘组中文件和目录的管理自动化水平相当高，应该说基本上完全不需要DBA参与，它自己就能玩的很好，当然，如果你非要动动手，那也是可以的。

2.4.1 管理磁盘组目录

　　创建新目录：

　　修改目录名：

　　删除目录名：

　　实际上，ASM中目录和文件的管理，也可以通过ASMCMD命令行方式进行，该命令行进入之后，是一个类似文件系统的管理界面，ORACLE提供了一些最基础的，如cd、ls、mkdir、rm等等几个有限的操作命令，如果对这部分内容感兴趣，可以参考官方文档中的介绍，或者搭个环境实践操作，可用命令很少且简单，熟悉Linux/Unix的话极易上手。

2.4.2 管理别名(Alias Names)

　　别名就是外号，比如说当系统自动产生的名称太过复杂不怎么好记，DBA可以通过别名，为它创建一个简单化的名称，而又不会对其现有名称造成任何影响。ASM中创建别名是通过alter diskgroup的alias子句实现，支持增加/修改/删除等多项操作。V$ASM_ALIAS视图中可以查询到当前实例中创建的别名。

　　例如，增加别名：

　　修改别名：

　　删除别名：

　　不管是添加/删除或是修改别名，对原有文件路径均不会有影响。

2.4.3 删除磁盘组中文件/别名

　　破坏总是最简单的，当然我不是说删除就一定是破坏，不过从严谨的角度讲，删除这样的操作要少做(没说不做)，做前得再三确认，三思而行并留有备份，即使做错了，还有恢复的可能。

　　当然啦，ASM中遇到删除文件这样需求的机率很低，但也不是完全没有，比如说执行了数据库不完全恢复操作后，某部分数据文件就不再需要，而恢复操作不会处理这部分文件，为合理利用空间，就会需要DBA手动删除这类文件，真遇到这样的需求，表急，语法也是黑简单的呐，例如，删除磁盘组2上的别名temp01：

　　没错，即能删文件也能删别名，只不过如果删除的是文件的话，其关联的别名(Alias)也会被自动删除。

2.4.4 删除磁盘组

　　太简单了，语法：drop diskgroup gpname即可！不演示了！需要注意一点，如果删除的diskgroup非空的话，直接执行上述语句会报错，这时候可以通过附加including contents子句，来自动删除该磁盘组中包含的文件。删除磁盘组的操作会自动修改spfile中ASM_DISKGROUPS初始化参数的值(如果使用了SPFILE的话)

本文出自：http://space.itpub.net/?uid-7607759-action-viewspace-itemid-664212