标签归档：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上可用的空闲空间问题，实际上，由于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 … 继续阅读 →