asm初级知识

至11gr2

仅有以下的文件类型可以存放在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

 虚拟数据盘区 Virtual Data Extent是几个data extent的集合，这些data Extent中包含了相同的数据。 镜像Mirror是在虚拟Extent级别实现的。每一个虚拟extent为文件块提供一个盘区地址空间。每一个写入到文件块均是写入到一个虚拟 extent中每一个Online在线的data extent中。 每一个对文件块的读取也是被重定位到一个虚拟extent中的主镜像extent (primary Extent)，除非primary extent所在Disk被OFFLINE了。  对于没有冗余度(即external redundancy disk group上的FILE)的文件而言，一个虚拟Extent实际就是一个data Extent。

 

粗粒度条带化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。

 

 

关于元数据：

每一个文件，在ASM中都有一个专门的索引号，也就是编号，ASM文件索引号从1开始。其中，前255个，也就是1至255号文件，都是元文件。256之后的是其他各种文件。 

元文件中包含了各种ASM的配置、各类数据文件信息还有目录、别名等等信息，都是在元文件中的。所有V$ASM_开头视图的信息，都来自元文件中。

其中，1号文件包含所有文件的磁盘占用信息，包括元文件、甚至1号文件自身的空间分布信息，也都是在1号文件内部。每个文件在它里面占用一个块（4096字节，元数据块大小为4K）的空间。

从256号文件开始，是数据库的各类文件。假设你放在ASM上的第一个文件是一个控制文件A，第二个文件是一个数据文件B。哪么控制文件A在ASM中的索引号是256，数据文件B的索引号是257。

1号文件总是开始在0号磁盘2号AU，记住这个位置：0号盘2号AU。这是ASM中定位文件的起点，它的作用，有点相当于磁盘上的引导区，在电脑开机后负责将OS启动起来。

1 号文件在最少情况下，至少有两个AU。上面我们提到过了，在1号文件中，每个文件占用一个元数据块，存放自身的空间分布信息。每个元数据块大小是4K，一 个AU是1M，哪么，每个AU中，可以存储256个文件的空间分布信息。这其中，0号盘2号AU中，全是元文件的信息。再具体一点，0号盘2号AU，第一 个元数据块被系统占用，从第二个块开始，到255为止，共255个元数据块，对应索引号1至255的文件。其实，也就是全部的元文件了。也就是说0号盘2 号AU，保存了全部元文件的空间分布信息。

 

 

asm 加磁盘： alter diskgroup Data add disk ‘/dev/asm-disk5′

asm 减磁盘： alter diskgroup Data drop disk DATA_0001

 

被加载的磁盘必须在整个集群中可被发现

关于force选项：

 如果add disk指定的磁盘的disk header发现了其他diskgroup的信息或者操作系统的一些信息，则需要alter diskgroup Data add disk ‘/dev/asm-disk5′ force ; 加入FORCE选项。实际使用中尽可能避免使用FORCE选项。

 drop disk命令可能较短时间内返回，但是diskgroup必须完成rebalance后这个磁盘才能被挪作他用。rebalance将读取即将被drop 掉disk的数据，并拷贝这些数据到其他磁盘上。FORCE选项可以用于避免读取该正被drop的磁盘。该FORCE选项当磁盘发生失败或磁盘确实需要立即被挪用。原来那些需要被拷贝的extent，使用FORCE选项后会从冗余的备份中读取，所以external redundancy不支持使用FORCE选项。当然如果使用FORCE选项最后会导致在NORMAL/HIGH冗余的Diskgroup下造成数据丢失 的话，则FORCE选项也将不可用

 

 

 

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_power_limit这个参数决定rebalance的速度（默认1）（0~11）值越大，rebalance越快

可以在语句中指定该值

alter diskgroup drop DATA_0001 rebalance power 10;

 

可以在v$asm_operation中看到rebalance情况

至11gr2

仅有以下的文件类型可以存放在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

 虚拟数据盘区 Virtual Data Extent是几个data extent的集合，这些data Extent中包含了相同的数据。 镜像Mirror是在虚拟Extent级别实现的。每一个虚拟extent为文件块提供一个盘区地址空间。每一个写入到文件块均是写入到一个虚拟 extent中每一个Online在线的data extent中。 每一个对文件块的读取也是被重定位到一个虚拟extent中的主镜像extent (primary Extent)，除非primary extent所在Disk被OFFLINE了。  对于没有冗余度(即external redundancy disk group上的FILE)的文件而言，一个虚拟Extent实际就是一个data Extent。

 

粗粒度条带化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。

 

 

关于元数据：

每一个文件，在ASM中都有一个专门的索引号，也就是编号，ASM文件索引号从1开始。其中，前255个，也就是1至255号文件，都是元文件。256之后的是其他各种文件。 

元文件中包含了各种ASM的配置、各类数据文件信息还有目录、别名等等信息，都是在元文件中的。所有V$ASM_开头视图的信息，都来自元文件中。

其中，1号文件包含所有文件的磁盘占用信息，包括元文件、甚至1号文件自身的空间分布信息，也都是在1号文件内部。每个文件在它里面占用一个块（4096字节，元数据块大小为4K）的空间。

从256号文件开始，是数据库的各类文件。假设你放在ASM上的第一个文件是一个控制文件A，第二个文件是一个数据文件B。哪么控制文件A在ASM中的索引号是256，数据文件B的索引号是257。

1号文件总是开始在0号磁盘2号AU，记住这个位置：0号盘2号AU。这是ASM中定位文件的起点，它的作用，有点相当于磁盘上的引导区，在电脑开机后负责将OS启动起来。

1 号文件在最少情况下，至少有两个AU。上面我们提到过了，在1号文件中，每个文件占用一个元数据块，存放自身的空间分布信息。每个元数据块大小是4K，一 个AU是1M，哪么，每个AU中，可以存储256个文件的空间分布信息。这其中，0号盘2号AU中，全是元文件的信息。再具体一点，0号盘2号AU，第一 个元数据块被系统占用，从第二个块开始，到255为止，共255个元数据块，对应索引号1至255的文件。其实，也就是全部的元文件了。也就是说0号盘2 号AU，保存了全部元文件的空间分布信息。

 

 

asm 加磁盘： alter diskgroup Data add disk ‘/dev/asm-disk5′

asm 减磁盘： alter diskgroup Data drop disk DATA_0001

 

被加载的磁盘必须在整个集群中可被发现

关于force选项：

 如果add disk指定的磁盘的disk header发现了其他diskgroup的信息或者操作系统的一些信息，则需要alter diskgroup Data add disk ‘/dev/asm-disk5′ force ; 加入FORCE选项。实际使用中尽可能避免使用FORCE选项。

 drop disk命令可能较短时间内返回，但是diskgroup必须完成rebalance后这个磁盘才能被挪作他用。rebalance将读取即将被drop 掉disk的数据，并拷贝这些数据到其他磁盘上。FORCE选项可以用于避免读取该正被drop的磁盘。该FORCE选项当磁盘发生失败或磁盘确实需要立即被挪用。原来那些需要被拷贝的extent，使用FORCE选项后会从冗余的备份中读取，所以external redundancy不支持使用FORCE选项。当然如果使用FORCE选项最后会导致在NORMAL/HIGH冗余的Diskgroup下造成数据丢失 的话，则FORCE选项也将不可用

 

 

 

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_power_limit这个参数决定rebalance的速度（默认1）（0~11）值越大，rebalance越快

可以在语句中指定该值

alter diskgroup drop DATA_0001 rebalance power 10;

 

可以在v$asm_operation中看到rebalance情况

 

 

资料来源

http://www.askmaclean.com/archives/know-oracle-asm-basic-html.html

http://www.itpub.net/thread-1597605-1-1.html