6. DISK
使用ASM的第一个步骤当然是准备磁盘了，这个步骤可能需要与SA和存储管理员配合完成。磁盘可以是存储划分的LUN分区、裸设备、块设备，可以被使用的磁盘必须有大小的限制：最大2^32MB即4096T，最小4MB，不管磁盘使用什么方式提供、有多大，需要记住的是必须能够让Oracle用户访问，需要配置正确的访问权限，扫描可以使用哪些磁盘有2种方式：shallow and deep，前者只是简单的检查是否有使用权限，后者将实际的打开文件操作进行检查。在RAC环境中，并不要求同一个disk在所有节点都具有一致的名称，因为ASM使用的是磁盘名称，只要能够被实例发现并扫描即可。
ASM DISKHeader会有如下状态：
Former-从磁盘组移除的磁盘
Candidate-表示磁盘可以被添加到磁盘组
Member-作为磁盘组的一部分存在
Provisioned-和Candidate类似同样作为候选磁盘可以被添加到磁盘组，一般是使用ASMLIB创建的
关于磁盘设备的配置还需要注意的一个是多路径的问题，在Linux下有内置的驱动软件，Device Mapper-设备映射，ASM本身并不支持多路径，只是调用DM返回的成功代码并使用，使用 DM 多路径功能的优点包括：
Ø 检测路径故障并将 I/O 重新路由至其他可用路径
Ø 在路径恢复后重新验证有故障的路径，根据路径状态和错误条件重新配置路径使用
Ø 利用多个可用路径使性能最大化
Ø 将多个设备节点统一为单个逻辑多路径设备节点
Ø 识别新的多路径 LU 并自动配置新的多路径节点
Ø 在 /dev/mapper/ 下为 DM 设备提供永久的设备名称
7. DISKGROUP
磁盘组-DISKGROUP是ASM最总要的组件部分，也是ASM最高级别的组件结构了，类似于LVM或者其他的存储管理组，不同的是ASM磁盘组是无法被用户直接访问的，必须通过ASM实例和相关工具来管理访问,在文件级别实现条带化和镜像，通过extents map来映射文件块，并在所有磁盘上均匀分布以分散I/O压力。
要被磁盘组使用的磁盘必须满足一下条件：不能是其他磁盘组的成员、不能含有残留的ASM File header信息、不能含有残留的Oracle File header信息，虽然可以使用force选项强制添加到磁盘组，但是不建议使用。
建议在同一个时间内配置上有的磁盘组，这样将会减少重复扫描配置工作，成功创建磁盘组之后，相关的创建日期、磁盘组名称、冗余类型等信息将被存储到SGA当中，同时也写入到磁盘组内的每个磁盘的disk header，通过视图V$ASM_DISK也可以查询相关信息，此后每次挂载磁盘组的时候会重新读取和验证disk header内的信息。
磁盘组在成功mount之后，磁盘组名称、实例名称和ORACLE_HOME等组合信息将会被CSS注册成一条用于DB实例可以连接的TNS连接串信息。
一个磁盘组可以被多个数据库共享，即同一个磁盘组可以包含多个数据库的文件，这样可以提高存储利用率并提高性能。虽然理论上支持，但是不建议一个DB使用多个ASM实例的存储，另外为了减少管理的复杂性，Oracle建议每个ASM实例不要创建超过2个的磁盘组：DATABASE area和Flash recovery area，前者存放数据库的数据文件，后者存放备份文件和控制文件、在线日志文件、归档日志、闪回日志等，会虽如此，但是我想不会有很多人使用FRA存放在ASM中吧，毕竟多了ASM这一层，多了个隐含的炸弹。
虽然ASM本身不包含任何数据库的元数据信息，但是包含着磁盘组的重要信息，元数据在磁盘和ASM SGA中存在着。有两个非常重要的结构数据：COD-Continuing Operation Directory和ACD-Active Change Directory。
COD记录着ASM的操作改变信息，比如磁盘或者数据文件的增加删除操作，COD同时也记录操作失败的信息，在成功操作之后反馈或在失败操作之后回滚并提示错误。
ACD类似于数据库的Redo Log，记录着操作过程的所有改变，用于在ASM实例崩溃或者操作失败的情况下进行恢复。比如，如果一个rebalance操作过程中ASM崩溃，ASM实例重启后会根据COD和ACD重启rebalance操作。ASM实例没有包含像数据库一样的物理文件，因此无需进行相关备份操作，ASM自己实现了高可用性。
8. Redundancy and Failure Groups
ASM提供了自己特有的冗余机制，这就是故障组，故障组可以看成是磁盘组的子集，用于保护可能出现的磁盘故障带来的数据的丢失。
ASM使用特有的extents级别镜像而不是磁盘镜像，这可以省略了热备盘的配置，当ASM分配了一个extent，也会将该extent拷贝到另一个磁盘镜像，并确保主extent和extent镜像不会存放在同一个故障组，鉴于这个原因，故障组最好保持同样的大小，避免由此带来的extents copy镜像失败问题，extents分为primary和second，往所有disk写入，优先读取primary extents。在在磁盘组创建的时候指定冗余级别，之后无法修改，如果需要修改必须创建一个新的磁盘组，并通过RMAN或者DBMS_FILE_TRANSFER工具包迁移到新的磁盘组。
磁盘组冗余有3个级别：
NORMALREDUNDANCY，正常级别，必须配置至少2个failure磁盘组；
HIGHREDUNDANCY，高级别，必须配置至少3个failure磁盘组；
EXTENRNALREDUNDANCY，外部冗余级别，无需failure磁盘组。
实际的生产配置中基本上使用的硬件存储级别的冗余保护，因此均是使用第3种即外部冗余配置ASM磁盘组，这也是Oracle的建议配置。
9. Database Instances and ASM Instances
数据库实例作为ASM实例的一个客户端，数据库与ASM总是在同一个节点内进行通信的，因此数据库必须与ASM部署在同一台主机上，即使是RAC环境下也不会出现数据库实例访问远程ASM实例的情况，ASM可以被单机和RAC数据库同时使用。这就意味允许ASM和RDBMS存在混合版本的情况，减少了由于多个版本而需要增加的部署，只是会根据RDBMS和ASM之间的最低版本来使用RDBMS和ASM的特性。
使用ASM的数据库对数据库使用者而言是透明的无需关心的，截止到10g版本为止，需要关心的是外部表，由于外部表是ASCII文件，因此外部表无法存放在ASM当中。注意ASM不能存放可执行文件、OCR和Voting磁盘和非Oracle的文件。
当数据库实例启动之后，数据库实例就作为ASM实例的客户端运行，通过V$ASM_CLIENT就可以查看ASM实例被那些客户端使用。
v$asm_client视图：
GROUP_NUMBER-磁盘组ID，与V$ASM_DISKGROUP视图关联
INSTANCE_NAME-连接的数据库实例的实例名称
DB_NAME-连接的数据库实例的数据库名称
STATUS-状态：CONNECTED、DISCONNECTED和BROKEN，其中BROKEN表示数据库实例与ASM实例异常中断了
COMPATIBLE_VERSION：兼容版本信息，在ASM查询得到的是RDBMS实例的版本信息；在RDBMS上查询得到的是ASM实例的版本信息
ASM实例主要进程：
ASMB-与RDBMS实例连接和通信
RBAL-Relalance，负责调度磁盘组的reblance操作
ABRn-是RBAL的一组子进程，负责真正完成reblance活动
相较于没有使用ASM的RDBMS实例，会多出3个进程：RBAL、ASMB和A00x或O00x。
ASMB-Automatic Storage Management Background，这个进程透过磁盘组名称等相关信息连接CSS，并获得ASM连接串与ASM实例通信，同时定期交换并更新之间的信息，也即心跳机制
RBAL-Relalance，执行磁盘组的磁盘打开操作
O00x -在10GR2之前该进程名称是A00x，一组从属进程，用于连接ASM实例，x取值范围为1-10。这组进程只是起到连接的作用，在没有连接请求的时候不工作。
如果需要关闭ASM实例，需要首先关闭所有连接到ASM上的RDBMS，之后正常关闭ASM实例，如果在ASM实例执行SHUTDOWN IMMEDIATE或者ABORT关闭，那么所有连接到ASM的数据库实例将abort中断。
在单ASM实例的情况下，如果实例失败，在重新打开之后完成实例恢复；在RAC环境中，如果一个节点的ASM实例失败，那么剩余存活的ASM实例可以自动帮忙恢复失败的实例。
另外还需要考虑在RDBMS实例参数进行调整，Oracle官方如下建议：
Processes= Add 16
Large_pool = Add additional 600k
Shared_pool可以通过相关公式计算得出需要而外增加的值，Oracle建议采用如下公式调整相关参数：
select sum(bytes)/(1024*1024*1024) as"Size-Gb" from v$datafile
union all
select sum(bytes)/(1024*1024*1024) from v$logfilea, v$log b where a.group#=b.group#
union all
select sum(bytes)/(1024*1024*1024) fromv$tempfile where status='ONLINE';
通过上述查询得出数据文件大小，每100Gb为单位，针对3种不同的冗余级别：external需要2M/100Gb、Normal需要4M/100Gb、High需要6M/100Gb。
10. 存储管理和分配
ASM使用AU-allocation unit作为分配单元，缺省大小是1M，这也是extent的大小，有两种规格的条带化：coarse对应1M和fine对应128k，前者适合存放数据文件、临时文件等，后者适合存放需要高响应的比如日志文件、控制文件和参数文件等，因为细粒度的条带化适合并行操作。
每个ASM磁盘头都包含在相关的分配信息表，分配信息表包含着AU描述区域，每个条目对应一个AU，AU描述区域含有file number和extent number，数据库文件被分为file extents，每个file extent对应一个AU，数据库文件使用file extent map来关联查找对应的disk number和au number，指向其所在asm disk的位置。
11. 数据平衡与分布
不同于传统的卷组管理方式，ASM可以在线动态的调整、平衡和重新分布数据，并且总是在所有文件上进行平衡分布，依赖RBAL后台进程来实现，该过程不是移动全部的extents来达到该目的，比如有个数据文件包含20个extents，现有2个disk，每个disk包含10个extents，如果此时增加了2个disk到该group，只会移动10个extents到新磁盘上，这是因为ASM实在extent级别上进行条带化的，重新平衡分布之后每个disk包含5个extents。
ASM进行重新平衡分布操作大致过程：
对磁盘组进行增加或者删除磁盘操作，然后触发RBAL进程准备进行重新分布操作，RBAL将会计算执行操作的大概时间，而后ARBx进程将会实际执行该操作，ARBx进程的数量由参数asm_power_limit控制，默认是1，可以在操作命令中临时指定，取值范围1-11，11表示最快的完成，注意该值可以取值为0，表示不进行操作，而是在后期在进行手工操作平衡动作，建议取值max（驱动器数量*2，11）。COD区域也会被更新以反映执行操作，随后就是实际的移动操作了。在此过程中不会对性能造成太大的影响，因为每次只移动一个extent/AU；默认情况下重新平衡操作的结果不是即时反馈到操作命令的，也就是说执行命令之后立即获得释放，当然也可以通过WAIT选项改变这个情况，另外可以通过视图V$ASM_OPERATION可以查看正在进行的操作状态。
以下是结合相关选项的一条命令：
alter diskgroup data add disk '/dev/raw/raw1'rebalance power 2 wait;
12. 文件和别名
数据库文件存放在非ASM和ASM实例中，本质上对数据是没有任何区别，只是ASM中的数据文件无法通过操作系统命令如ls、df、dd、mv或者cp进行操作，要实现在ASM和非ASM之间或ASM之间移动数据文件只能通过RMAN或者DBMS_FILE_TRANSFER工具包进行操作。ASM存放的数据文件不同于传统的格式，而是采用OMF的Fully Qualified FileName (FQFN)-完全限定名称，比如"+GTDG1/gt10g/datafile/gtlions.258.3"，格式定义如下：
第1段为diskgroup名称，这里是GTDG1
第2段为DB_UNIQUE_NAME定义的dbname，这里是gt10g
第3段为file_type文件类型，这里是datafile，预定义的还有很多：CONTROLFILE/DATAFILE/TEMPFILE/ONLINELOG/ARCHIVELOG/BACKUPSET/FLASHBACK
第4段分为两部分，前面为file_type_tag，这里是gtlions，为表空间名称，针对在线日志则表示为GROUP_3，其中3表示GROUP ID；后面为file.incarnation，用来确保唯一文件
这里涉及到OMF，全称是Oracle Manager Files，使用OMF不仅规范和简化了文件存储的方式，而且更让人喜欢的一个特性是在dataabse执行删除文件的时候可以自动的删除相关的物理文件，如果不是使用OMF，你需要在OS层面执行删除文件操作；如果是用ASM，那么你需要通过ASMCMD相关命令进行操作物理文件操作；设置DB_CREATE_FILE_DEST和DB_RECOVERY_FILE_DEST两个参数即可启用OMF特性。
-The End-