仅有以下的文件类型可以存放在ASM Diskgroup中：
- Control File
- Datafile
- Temporary data file
- Online Redo Log
- Archive Log
- RMAN backup
- Datafile Copy
- SPFILE
- Disaster Recovery Configuration
- Flashback Log
- Change Tracking Bitmap
- DataPump? Dumpset
粗粒度条带化Coarse Grain Striping
粗粒度条带化就是对虚拟data Extent的简单联接。类似于传统卷管理器使用1MB作为stripe size。
细粒度条带化Fine Grain Striping
细粒度与粗粒度的区别在于，文件块不是线性地布局在每一个虚拟Extent上，而是文件将以1/8个虚拟Extent成长，由此文件块被在 diskgroup内以1/8的条带化深度分布。 由此当该文件的block size 为8k，则block 0~15在虚拟Virtual Extent 0上面，而block 16-31 在Vritual Extent 1上面，blocks 112-127在vritual extent 7， block 128-143在block 0-15之后仍在virtual extent 0上
Disk Partners
Disk Partnership是一种基于2个磁盘之间的对称关系，存在于high 或 normal的redundancy diskgroup中。Diskgroup中的Disk与同一个Diskgroup内的其他几个disk组成结伴关系。ASM会自动创建和维护这种关系。 镜像拷贝数据仅仅在已经与主数据镜像primary data extent组成partners关系的磁盘上分配。
Disk partnering用来减少由于同时2个磁盘故障导致的数据丢失的概率。原因在于当ASM配置中使用了较多的磁盘时(例如上千个)，如果如果数据镜像是 随机寻找次级磁盘来存放镜像拷贝，当2个磁盘丢失时有较大概率丢失数据。原因是如果采取随机存放镜像数据的话，出现数据的 primary和镜像数据同时存在于2个正好失败的磁盘上的概率是很高的。 如果我们不采取disk partnering，2个磁盘失败所造成的数据丢失的概率大大增加。
Disk partnering策略限制了用来保护某个磁盘数据拷贝的磁盘数目。ASM为一个磁盘限制了disk partners的总数为8。 这个数目越小，则双磁盘同时失败造成数据丢失概率越小。 但是这个数目越小，也会造成其他不便。所以ORACLE ASM研发团队最终选择了8这个数字。
ASM从本disk所在Failure group之外的FG 中挑选partners disk，由于一个ASM DISK有多个partners，所以其多个partners disk可能有的在同一个failure Group中。Partners被尽可能多的选择在不同的Failure Group中，这样做的目的也很明确，提高磁盘失败时的容错能力。askmaclean.com
如果一个ASM DISK失败了，其保护的extents可以通过其partners来重建。由于有多个partners所以其额外的I/O负载是在多个ASM disk中均衡损耗的。 这减少了修复故障的失败时间，因为更多的磁盘参与进来，可以获得更高的I/O吞吐量，所以加快了重构丢失数据镜像的速度。Partners被尽可能多的选 择在不同的Failure Group中，这样做可以让重建丢失磁盘的负载均匀分布在尽可能多的硬盘资源上。 以上这些考虑均是基于同时不会有2个failgroup同时失败这个前提假设。
注意Partnering不是分区partitioning，Partnering仅仅是一种对称关系。如果Disk A将Disk B列出partner，则相对地Disk B也将Disk A列为partner。 但是partnering不是一种临时的关系。 同时假设disk A 和 Disk B是partners, 而Disk B和Disk C也是partners, 但这并不代表A和C是partners。
实际如果对partnering relationship有足够的传递性则可能表现为分区，如下图中的例子。但是分区仅仅是partnering可以提供的一种可能性。
partitioning分区仅仅是Partnering的特殊表现，Partnering本身已经能够保证在Disk磁盘以不规则的几何安排方式 组织时仍能同一负载均衡，其移除了当额外的容量需要增加到现有系统时的许多限制。当然这仍不能保证在所有配置下都很完美，但ASM会基于现有给定的配置采 取最佳的方案。
ASM mirror 保护
ASM mirror 镜像保护可避免因丢失个别磁盘而丢失数据。每一个文件均有自己的ASM镜像策略属性， 对于该文件所辖的所有virtual extent来说同样基于该镜像策略。文件创建时会设置这个镜像策略属性，今后都无法修改。 ASM镜像要比操作系统镜像磁盘要来的灵活一些，至少它可以在文件级别指定需要的冗余度。
ASM mirror区分镜像extent的primary和secondary拷贝，但在更新extent时会同时写所有的拷贝镜像。 ASM总是先尝试读取primary 拷贝，仅当primary拷贝不可用时去读取secondary拷贝。
ASM metadata
Asm Metadata是存在于ASM disk header用以存放ASM Diskgroup 控制信息的数据，Metadata包括了该磁盘组中有哪些磁盘，多少可用的空间，其中存放的File的名字，一个文件有哪些Extent等等信息。
由于Asm metadata就存放在ASM DISK HEADER，所以ASM disk group是自解释的。所有的metadata元数据均存放在一个个metadata block中(默认block size 4096)。这些信息包括该metadata block的类型以及其逻辑位置。同样有checksum信息来确认block是否被损坏。所有的metadata block均是4k大小。实际使用时ASM实例会缓存这些ASm metadata。
Rebalance
rebalance diskgroup将在diskgroup范围内将数据在其DISK上移动，以保证文件们均匀分布在diskgroup中的所有磁盘上，同时也会考虑到每一个ASM DISK的大小。 当文件均匀地分布在所有磁盘上，则各个磁盘的使用量也会很接近。如此以保证负载均衡。rebalance的算法既不基于I/O统计信息也不基于其他统计结 果； 完全取决于Diskgroup中disk的大小。
一旦diskgroup中发生了一些存储配置变化 例如disk add/drop/resize均会自动触发一次rebalance。power参数将决定有多少slave进程并发参数数据移动。所有的slave进程 均从发生rebalance的实力启动并工作。rebalance可以手动调控，即便已经在进行一次rebalance中了，也可以指定其他节点上的实例 做rebalance，只要管路员想要这样做。如果实例意外crash，那么未结束的rebalance将自动重新启动。
注意rebalance中的每一次extent 移动均会与数据库实例做协调，因为数据库实例可能同时需要读取或者写这个 extent，所以数据库在rebalance 同时能正常工作。 其对数据库的影响一般较小，原因是同一时间只有一个extent被锁定以便移动，且仅仅是阻塞写入
仅有以下的文件类型可以存放在ASM Diskgroup中：
- Control File
- Datafile
- Temporary data file
- Online Redo Log
- Archive Log
- RMAN backup
- Datafile Copy
- SPFILE
- Disaster Recovery Configuration
- Flashback Log
- Change Tracking Bitmap
- DataPump? Dumpset
粗粒度条带化Coarse Grain Striping
粗粒度条带化就是对虚拟data Extent的简单联接。类似于传统卷管理器使用1MB作为stripe size。
细粒度条带化Fine Grain Striping
细粒度与粗粒度的区别在于，文件块不是线性地布局在每一个虚拟Extent上，而是文件将以1/8个虚拟Extent成长，由此文件块被在 diskgroup内以1/8的条带化深度分布。 由此当该文件的block size 为8k，则block 0~15在虚拟Virtual Extent 0上面，而block 16-31 在Vritual Extent 1上面，blocks 112-127在vritual extent 7， block 128-143在block 0-15之后仍在virtual extent 0上
Disk Partners
Disk Partnership是一种基于2个磁盘之间的对称关系，存在于high 或 normal的redundancy diskgroup中。Diskgroup中的Disk与同一个Diskgroup内的其他几个disk组成结伴关系。ASM会自动创建和维护这种关系。 镜像拷贝数据仅仅在已经与主数据镜像primary data extent组成partners关系的磁盘上分配。
Disk partnering用来减少由于同时2个磁盘故障导致的数据丢失的概率。原因在于当ASM配置中使用了较多的磁盘时(例如上千个)，如果如果数据镜像是 随机寻找次级磁盘来存放镜像拷贝，当2个磁盘丢失时有较大概率丢失数据。原因是如果采取随机存放镜像数据的话，出现数据的 primary和镜像数据同时存在于2个正好失败的磁盘上的概率是很高的。 如果我们不采取disk partnering，2个磁盘失败所造成的数据丢失的概率大大增加。
Disk partnering策略限制了用来保护某个磁盘数据拷贝的磁盘数目。ASM为一个磁盘限制了disk partners的总数为8。 这个数目越小，则双磁盘同时失败造成数据丢失概率越小。 但是这个数目越小，也会造成其他不便。所以ORACLE ASM研发团队最终选择了8这个数字。
ASM从本disk所在Failure group之外的FG 中挑选partners disk，由于一个ASM DISK有多个partners，所以其多个partners disk可能有的在同一个failure Group中。Partners被尽可能多的选择在不同的Failure Group中，这样做的目的也很明确，提高磁盘失败时的容错能力。askmaclean.com
如果一个ASM DISK失败了，其保护的extents可以通过其partners来重建。由于有多个partners所以其额外的I/O负载是在多个ASM disk中均衡损耗的。 这减少了修复故障的失败时间，因为更多的磁盘参与进来，可以获得更高的I/O吞吐量，所以加快了重构丢失数据镜像的速度。Partners被尽可能多的选 择在不同的Failure Group中，这样做可以让重建丢失磁盘的负载均匀分布在尽可能多的硬盘资源上。 以上这些考虑均是基于同时不会有2个failgroup同时失败这个前提假设。
注意Partnering不是分区partitioning，Partnering仅仅是一种对称关系。如果Disk A将Disk B列出partner，则相对地Disk B也将Disk A列为partner。 但是partnering不是一种临时的关系。 同时假设disk A 和 Disk B是partners, 而Disk B和Disk C也是partners, 但这并不代表A和C是partners。
实际如果对partnering relationship有足够的传递性则可能表现为分区，如下图中的例子。但是分区仅仅是partnering可以提供的一种可能性。
partitioning分区仅仅是Partnering的特殊表现，Partnering本身已经能够保证在Disk磁盘以不规则的几何安排方式 组织时仍能同一负载均衡，其移除了当额外的容量需要增加到现有系统时的许多限制。当然这仍不能保证在所有配置下都很完美，但ASM会基于现有给定的配置采 取最佳的方案。
ASM mirror 保护
ASM mirror 镜像保护可避免因丢失个别磁盘而丢失数据。每一个文件均有自己的ASM镜像策略属性， 对于该文件所辖的所有virtual extent来说同样基于该镜像策略。文件创建时会设置这个镜像策略属性，今后都无法修改。 ASM镜像要比操作系统镜像磁盘要来的灵活一些，至少它可以在文件级别指定需要的冗余度。
ASM mirror区分镜像extent的primary和secondary拷贝，但在更新extent时会同时写所有的拷贝镜像。 ASM总是先尝试读取primary 拷贝，仅当primary拷贝不可用时去读取secondary拷贝。
ASM metadata
Asm Metadata是存在于ASM disk header用以存放ASM Diskgroup 控制信息的数据，Metadata包括了该磁盘组中有哪些磁盘，多少可用的空间，其中存放的File的名字，一个文件有哪些Extent等等信息。
由于Asm metadata就存放在ASM DISK HEADER，所以ASM disk group是自解释的。所有的metadata元数据均存放在一个个metadata block中(默认block size 4096)。这些信息包括该metadata block的类型以及其逻辑位置。同样有checksum信息来确认block是否被损坏。所有的metadata block均是4k大小。实际使用时ASM实例会缓存这些ASm metadata。
Rebalance
rebalance diskgroup将在diskgroup范围内将数据在其DISK上移动，以保证文件们均匀分布在diskgroup中的所有磁盘上，同时也会考虑到每一个ASM DISK的大小。 当文件均匀地分布在所有磁盘上，则各个磁盘的使用量也会很接近。如此以保证负载均衡。rebalance的算法既不基于I/O统计信息也不基于其他统计结 果； 完全取决于Diskgroup中disk的大小。
一旦diskgroup中发生了一些存储配置变化 例如disk add/drop/resize均会自动触发一次rebalance。power参数将决定有多少slave进程并发参数数据移动。所有的slave进程 均从发生rebalance的实力启动并工作。rebalance可以手动调控，即便已经在进行一次rebalance中了，也可以指定其他节点上的实例 做rebalance，只要管路员想要这样做。如果实例意外crash，那么未结束的rebalance将自动重新启动。
注意rebalance中的每一次extent 移动均会与数据库实例做协调，因为数据库实例可能同时需要读取或者写这个 extent，所以数据库在rebalance 同时能正常工作。 其对数据库的影响一般较小，原因是同一时间只有一个extent被锁定以便移动，且仅仅是阻塞写入
