一、关于oracle 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。
二、启动和关闭oracle实例：
前些日子，装完oralce配置完asm后一切正常，当重新启动后就发现了oracle起不来，报如下错误：
ORA-01078: failure in processing system parameters
ORA-01565: error in identifying file '+ORADATA/db01/spfiledb01.ora'
ORA-17503: ksfdopn:2 Failed to open file +ORADATA/db01/spfiledb01.ora
ORA-15077: could not locate ASM instance serving a required diskgroup
ORA-01565: error in identifying file '+ORADATA/db01/spfiledb01.ora'
ORA-17503: ksfdopn:2 Failed to open file +ORADATA/db01/spfiledb01.ora
ORA-15077: could not locate ASM instance serving a required diskgroup
检查了一下，并非'+ORADATA/db01/spfiledb01.ora'文件不存在，而是由于ASM磁盘组没起来导致的。启动asm磁盘组有两种方法，一是使用dbca工具，二是从命令行启动。
1、dbca启动：
当启动dbca后，在出现的画面上选择 “Configure Automatic Storage Management”选项，下一步，就会启动ASM磁盘组并挂载磁盘组。
2、命令行启动：
首先要知道asm实例名，否则只能从DBCA启动了。这里的实例名是+ASM,操作如下：
在执行之前注意别忘了先设置操作系统环境变量ORACLE_SID。
现在已经启动到nomount状态了，查看磁盘组状态，可以使用以下命令查看：
查看ASM实例名：
ASM 实例与DB实例高度相似，启动和停止实例的命令也一模一样，就启动来说，也同样拥有 NOMOUNT/MOUNT/OPEN /FORCE 几种状态。
- NOMOUNT ：仅启动实例；
- MOUNT 、OPEN：启动实例并加载磁盘，注意加载的是磁盘组(如果当前未创建或配置任何磁盘组，则提示敬告信息)，OPEN，选项对于ASM实例无意义等同于MOUNT。
- FORCE ：相当于先执行shutdown abort，然后再startup。
使磁盘组处于mount状态：
查看磁盘组状态：
使用ps -ef|grep ora可以查看asm进程：
到此，就可以正常启动oracle数据库实例了：
在oracle 10g版本中，ASM是依赖于CSS守护进程的，因此在启动ASM 实例前要确保css守护进程已经启动。CSS(Cluster Synchronization Services) 守护进程 用来维持ASM 及客户端数据库实例间的一致性 同步，如果是通过dbca建库的话，那么CSS守护进程默认即会启动(跟随系统reboot)。
检查css守护进程是否启动非常简单 ，直接使用crsctl check cssd即可，如果启动的话会收到"CSS appears healthy"的返回消息：
关闭ASM实例：
NORMAL/IMMEDIATE/TRANSACTIONAL/ABORT几个选项的定义与关闭普通数据库实例完全一模一样。
如果oracle数据库实例开启了，关闭asm实例时会报如下错误：
关闭oracle数据库实例后才能关闭ASM实例。
三、ASM实例的初始化参数：
ASM 实例的初始化参数形式上与数据库的初始化参数相同，也分spfile和pfile，操作方式也完全相同，只不过具体的参数及参数值略有差异，大多数数据库的初始化参数在这里也能见到，并且某些参数意义都完全相同，同样也有一些参数虽然见到了，不过并不需要设置，这个可以理解，毕竟asm只有实例，相对比数据库的初始化参数要简单的多了，还有一些参数则是数据库初始化参数中没有的。比如ASM开头的那几个初始化参数，这里把差异的部分都列出说明。
ASM 实例在内存占用这块还是比较轻量级的，基本上有个100m空间就很充足了 ，因此内存这块相关参数就不说了，下面说说几个ASM实例特别需要的参数。
首先，初始化参数中的INSTANCE_TYPE，该参数必须被设置为ASM(见粉红色部分)：
+ASM.asm_diskgroups='ORADATA'#Manual Mount
*.asm_diskgroups='ORADATA'
*.background_dump_dest='/u01/app/oracle/admin/+ASM/bdump'
*.core_dump_dest='/u01/app/oracle/admin/+ASM/cdump'
*.instance_type='asm'
*.large_pool_size=12M
*.remote_login_passwordfile='SHARED'
*.user_dump_dest='/u01/app/oracle/admin/+ASM/udump'
*.asm_diskgroups='ORADATA'
*.background_dump_dest='/u01/app/oracle/admin/+ASM/bdump'
*.core_dump_dest='/u01/app/oracle/admin/+ASM/cdump'
*.instance_type='asm'
*.large_pool_size=12M
*.remote_login_passwordfile='SHARED'
*.user_dump_dest='/u01/app/oracle/admin/+ASM/udump'
标识要启动的实例是ASM，而不是数据库实例(数据库实例对应类型为RDBMS)。
与ASM相关的初始化参数有三个：
- ASM_POWER_LIMIT ：指定磁盘rebalance的程度，有0-11个级别，默认值为1，指定的级别越高，则rebalance的操作就会越快被完成(当然这也意味着这个时间段内将占用更多的资源)，指定级别较低的话，虽然rebalance操作会耗时更久，但对当前系统的IO及负载影响会更少，这中间的度需要DBA根据实际情况衡量。另外，这个参数指定的只是一个默认值，在操作过程中，即可以随便动态修改，也可以在语句级命令行时指定power，覆盖该默认值。
- ASM_DISKSTRING ：用最简单的话说，就是设置ASM启动时检查的磁盘，该选项可以同时指定多个值，并且支持通配符。比如说，只检查/dev/dsk/下的设备，可以设置该参数如下：/dev/dsk/*，默认情况下该参数为空，为空的话，表示ASM将查找系统中所有ASM拥有读写权限的设备。
- ASM_DISKGROUPS ：指定实例启动或alter diskgroup all mount语句时要加载的磁盘组，如果为空的话，那么实际就仅启动到NOMOUNT状态了。如果是使用SPFILE的话，该参数一般不需要手动修改，ASM能够自动更新该初始化参数中的值。
修改 ASM 实例初始化参数文件的命令规则与数据库初始化参数完全相同 ，例如：
四、管理ASM磁盘：
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能够自动平衡。对于普通的删除操作(无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。
