一、ASM中的failure group介绍：
ASM提供了3种冗余方法。
external redundancy表示Oracle不帮你管理镜像，功能由外部存储系统实现，比如通过RAID技术。
normal redundancy（默认方式）表示Oracle提供2路镜像来保护数据。
high redundancy表示Oracle提供3路镜像来保护数据。
什么又是ASM failure group呢？
Oracle通过failure group来提供数据的高可用性。ASM使用的镜像算法并不是镜像整个disk，而是作extent级的镜像。所以很明显如果为各个failure group使用不同容量的disk是不明智的，因为这样在Oracle分配下一个extent的时候可能就会出现问题。在normal redundancy模式下，ASM环境中每分配一个extent都会有一个primary copy和一个second copy，ASM的算法保证了second copy和primary copy一定是在不同的failure group中，这就是failure group的意义。通过这个算法，ASM保证了即使一个failure group中的所有disk都损坏了，数据也是毫发无伤的。
Oracle在分配extent的时候，所有failure group中的这个将拥有相同数据的extent称为一个extent set，当Oracle将数据写入文件的时候，primary copy可能在任何一个failure group中，而second copy则在另外的failure group中，当Oracle读取数据的时候，除非是primary copy不可用，否则将优先从primary copy中读取数据，通过这种写入无序，读取有序的算法，Oracle保证了数据读取尽量分布在多个disk中。
因为公用一个硬件模块的磁盘很可能会同时损坏或者失效，所以通常我们在设计failure group时，应该把一个大的盘阵中在一个tray中的磁盘放在一个failure group中，这样我们就可以拿走一个tray，失效这个failure group，然后换上新的tray和磁盘，这跟RAID的思想是一样的。
ASM的冗余方式一经设定就无法更改，如果我们想把normal redundancy改为high redundancy就只能是创建一个新的failure group，然后把旧failure group中的文件通过RMAN或者DBMS_FILE_TRANSFER的方法移动到新failure group中去。
以上内容属于他山之石。
为了测试ASM的failgroup,这里用了8块10G的磁盘，四块是通过openfiler共享过来的，另外四块是vmware本地添加的。
| 控制器1 | 物理磁盘名 | ASM对应的磁盘名 |
| 1 0 0 0 | /dev/sdg | VOL06 |
| 1 0 1 0 | /dev/sdh | VOL07 |
| 1 0 2 0 | /dev/sdi | VOL08 |
| 1 0 3 0 | /dev/sdj | VOl09 |
| 控制器2 | 物理磁盘名 | ASM对应的磁盘名 |
| 2 0 0 0 | /dev/sdk | VOL10 |
| 2 0 1 0 | /dev/sdl | VOL11 |
| 2 0 2 0 | /dev/sdm | VOL12 |
| 2 0 3 0 | /dev/sdn | VOL13 |
这个控制器号，在系统上可以执行rescan-scsi-bus.sh程序和执行oracleasm scandisks。rescan-scsi-bus.sh程序属于sg3_utils软件包。
二、创建ASM磁盘组：
创建之前，确保监听程序已经开启。
这里将VOL10-VOL13加入controller2,VOL06-VOL09加入controller1里。完成之后，查看刚创建的卷组failover是否存在：
查看磁盘信息：
如果在创建ASM磁盘组时没有显式指定，failure groups也是始终会创建的。在这种情况下，每个disk都属于一个failure group，在创建磁盘组的时候，failure group也会默认创建，名称就是disk的名字。如上图所示。
接着，在failover上面创建一个数据库，待会用于测试。在创建的时候，数据文件的存放位置选择ASM的failover磁盘组。
创建数据库完成，当前db04实例已经启动，接着模拟磁盘故障，看对数据库会造成什么影响：
删除controller1上的一个磁盘，然后再扫描下磁盘。
SCSI 1:0在系统中对应的是/dev/sdg,在asm中对应的是VOL06。完了后再执行sql语句查看磁盘状态是否有变化。
使用oracleasm scandisks后，它自动清除了VOL06。
看到了吧，VOL06的Path值为空了，测试下数据库是否还能读写：
数据库可读可写。
下来模拟整个failgroup坏掉。将controller2上的所有磁盘删掉：
Hard Disk 10至Hard Disk 13就是控制器2上的磁盘，对应系统中的/dev/sd{k,l,m,n},点击remove删除即可。
首先在系统中执行rescan-scsi-bus.sh程序，然后执行oracleasm scandisks。
结果：
然后再查看v$asm_disk视图：
接着测试数据库是否能读写：
看到了吧，并没有对oracle数据库造成什么影响的。重启下ASM实例，然后在查看v$asm_disk视图：
启动数据库实例：
启动么问题，数据库也可读可写。
总结：此实验的目的是假如两个盘柜中的一个down掉，不会影响应用的使用。
