今天下午部门里的几个达人针对ASM发生了激烈的争论，其实观点上大同小异，只是表达上理解的有点偏差

    ASM实例其实就是一个LVM，负责对OS一级磁盘的管理，这里把磁盘说成lun更准确点，因为磁盘容易让人理解

    为最底层的存储上的铁疙瘩，而ASM只会认识LUN，至于这个LUN下面由多少个小盘组成，怎么做stripe是不关心的，

    在这点上几位大牛的观点是一致的，但还是吵了半天

    ASM完成的是一个翻译工作，他本身并不负责到LUN上获取数据来返回给oracle用户进程，因为要这么操作的话，

    ASM必须针对前面的oracle进程，建立对应的服务进程来服务，而ASM实例启动后，进程数量不会发生大的数量，

    如果是以这么少的进程服务于前台所有的IO请求，肯定会成为瓶颈，通过实际的fuser观察，用户进程查询时，

    也是自己的进程关联上/dev下的设备，在这个过程中，ASM会将oracle请求的文件号，块号翻译成他所管理的LUN

    上的对应地址，转交给oracle用户进程，用户拿了这些地址，再去LUN上做IO请求，这些请求如何到达最末端的

    真实磁盘，oracle不关心，也管不着

    最后一个问题，既然是由oracle进程自己去请求这些数据块，那ASM的访问就应该是串行的，因为一个进程同时只能做一个

    事情，这点上我觉得应该还是并行访问，因为用户进程可以批量的发送IO请求，不会等待这个IO完成了，再发送下一个IO，

    一批IO下去，各个磁盘自觉认领，我等你们大家的结果就可以了，最后返回给上层，继续发IO请求，周而复始

建议继续学习：

1. ASM使用AIX raw disk的问题    (阅读：3661)
2. Oracle ASM存储方式浅析    (阅读：3059)
3. ASM装载磁盘组时ORA-15063错误处理    (阅读：2464)
4. ASM中如何配置多个控制文件    (阅读：2327)
5. ASM的争论    (阅读：2108)
6. 用ASM和iSCSI实现的另类HA方案    (阅读：1910)
7. ASM的优点总结–关于日志文件调整    (阅读：1405)
8. ASM HEADER 备份与恢复    (阅读：1337)