oracle 前五月,五月 – 2014 – 世间所有相遇都是久别重逢 - Lunar的oracle实验室

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： 完整的代码可在这里下载