标签归档:exadata Req_mir_free_MB

Exadata上,ASM的Req_mir_free_MB 是如何得到的?

Exadata上,ASM的Req_mir_free_MB 是如何得到的? 首先,我们都知道,可通过v$asm_diskgroup来查看required_mirror_free_mb: 这里看到,实际上lsdg的输出跟v$asm_diskgroup是一致的(注意,早起的数据库版本由于rebalance时的bug,可能造成显示不一致,例如 Bug 7699985) 由于Exadata上,没有外部冗余,数据完全通过ASM镜像,那么就要考虑当磁盘故障或者cell故障时的数据保护,需要相应的根据Normal Redundancy或者High Redundancy来考虑分别两种情况: 1,在Normal Redundancy时,要考虑1块磁盘损坏或者1个cell不能启动时,如果修复时间超过缺省的3.6小时,需要使用现有系统中可用磁盘空间做Rebalance 2,在HighRedundancy时,要考虑2块磁盘损坏或者2个cell不能启动时,如果修复时间超过缺省的3.6小时,需要使用现有系统中可用磁盘空间做Rebalance Oracle根据内部算法,使用一个调解因子做系数,比如,不同版本的Oracle,评估方法不同: 如果数据库是11.2.0.3或者11.2.0.4,那么这个调解因子为1.10,如果是低于这个版本的数据库,调解因子是1.5(具体该因子的算法尚未知道) 对于每一个磁盘组,他们需要调解的空间大小(即,预留空间)=v$asm_diskgroup.required_mirror_free_mb * 调解因子 然后根据不同的镜像(Normal或者High),以及不同的Exadata配置(1/8,1/4、1/2,满配)再分别乘以一个系数,下面的代码根据每个磁盘组的最大的failgroup的大小来确定需要保留的空间: 然后,计算出来总共的需要“预留的空间”按照不同配置的Exadata乘以一个比例,就是我们这看到的 REQUIRED_MIRROR_FREE_MB: 对于Normal Redundancy: 对于High Redundancy: 完整的代码可在这里下载

发表在 ASM, FAQ, 内部机制 | 标签为 , , | 留下评论

Exadata和非Exadata平台上,ASM的可用空间如何计算?

曾经很多次,有客户问到ASM上可用的空闲空间问题,实际上,由于ASM带有3中冗余设置方式,分别应对不同场景的数据冗余情况,因此,通常在Exadata上的选择和非Exadata上的选择是不同的。 . 在非Exadata的环境中,通常我们会使用RAID,比如RAID10,因此ASM中使用External Redundancy,例如: ASMCMD> lsdg State Type Rebal Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Voting_files Name MOUNTED EXTERN N 512 4096 1048576 51200 45862 0 45862 0 N CFARCH1/ MOUNTED EXTERN N 512 4096 1048576 51200 47653 … 继续阅读

发表在 ASM, FAQ, 内部机制 | 标签为 , , | 2 条评论