原文链接： http://www.dbaleet.org/exadata_faq_who_stoled_my_space/
在Exadata安装完成以后，几乎每个客户都会问到一个问题：
” 我们公司购买的是你们的Exadata X2-2 1/4配， 使用的是600G高性能盘。现在有3个存储节点，每个节点有12个盘。 这样计算那么我应该得到这么多空间： 600G×12×3=21600GB， 也就是说裸盘一共有大约21.6TB的空间。然后使用了ASM做了normal冗余，最后得到净可用空间应该在10.8TB，扣掉一点开销，我认为最后可用空间应该在10个TB左右, 当初你们的销售告诉我们能用的空间也是10个T, 为什么现在我在ASM中看到可用空间只有6.5TB, 是不是弄错了呀,难道选成了High冗余呀? 什么? 没有? 难道是你们每个盘都预留了一点空间? 这样不行呀, 空间本来对于我们本来就非常紧张, 这个结果对于我们来说是不可接受的!”
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 NORMAL N 512 4096 4194304 15593472 15220648 5197824 5011412 0 N DATA_DM01/
MOUNTED NORMAL N 512 4096 4194304 894720 893464 298240 297612 0 Y DBFS_DG/
MOUNTED NORMAL N 512 4096 4194304 3896064 3879104 1298688 1290208 0 N RECO_DM01/
事实上，这个对Exadata最常见的一个误区。本人被各种客户问到同样的问题不下10遍！ 可见问题往往不是出在客户那里，而是Oracle在某个环节出现了一点小问题。我们来迅速看一下，客户说的情况，首先不假思索，迅速找到Exadata X2-2的datasheet。对于1/4配,我简单的截一个关于可用空间的图。如下：
可以看到，在Exadata的datasheet中提到的1/4配高性能的Exadata的裸磁盘空间确实是21.6TB， 而可用空间为9.5TB，非常接近10TB。并且标明了一个很小的注释3和4。
3. For raw capacity, 1 GB = 1 billion bytes. Capacity calculated using normal space terminology of 1 TB = 1024 * 1024 * 1024* 1024 bytes. Actual formatted capacity is less.
4 Actual space available for a database after mirroring (ASM normal redundancy) while also providing adequate space (one disk on Quarter and Half Racks and two disks on a Full Rack) to reestablish the mirroring protection after a disk failure.
实际上3和4已经能说明部分问题了，但早期并没有这两个注脚，且这两个小的注脚加到Exadata datasheet的时间并不长。3很明显说明磁盘的容量是按照磁盘厂商是按照1TB=1000 * 1000 * 1000* 1000 bytes， 而操作系统则是按照1TB=1024 * 1024 * 1024* 1024 bytes计算。4是说会1/4配会预留1个磁盘空间做冗余保证能顺利进行re-mirroring。 来看进一步的解释：
造成这个结果，主要是以下几个方面的因素导致的：
1. 硬盘厂商和操作系统计算的单位并不一致，操作系统的单位进制为1024，而硬盘厂商的单位进制为1000. 所以600G的盘实际上只有600×1000×1000×1000/1024/1024/1024=558G， 每个cell有12块盘，1/4配一共有3个cell节点，所以一共有36块558G的盘。所以实际总大小为20116G=19.65TB，这个所以19.65T才是实际真实可用的裸磁盘空间。
2. 每个cell的前两个盘各自预留了30G的partition用来安装操作系统，所以实际可用空间为20116G-30G×2×3=19936GB=19.47TB
3. 从注脚4可知，实际上Exadata还预留了一部分空间用于可以进行re-mirroring, 这部分空间大小在1/4配中接近一块盘的容量（1/4配的开销过大），除去ASM的normal redundancy， 实际可用的磁盘容量不到9.5TB。 具体计算方式为(19936G-600G)/2/1024= 9.44TB.
关于这里的Req_mir_free_MB和Usable_file_MB的含义参看文档：
Req_mir_free_MB Amount of space that must be available in the disk group to restore full redundancy after the most severe failure that can be tolerated by the disk group. This is the REQUIRED_MIRROR_FREE_MB column from the V$ASM_DISKGROUP view.
Usable_file_MB Amount of free space, adjusted for mirroring, that is available for new files. From the V$ASM_DISKGROUP view.
假设有这么一种场景：一个cell节点宕掉完全不可用， 如果此时使用的空间在这个Usable_file_MB以下，那么这个时候ASM能正常的完成rebalance， 如果超过了这个阈值，则会因为空间不足，剩余的两个cell节点无法完成rebalance。那么就表示有一部分数据此时只保留了一份（Normal正常情况下，所有的数据都有两份），并且无法完成rebalance。 这个时候如果另外两个节点中出现了坏盘，那么则有可能导致数据的丢失。
所以Usable_file_MB这个值只是一个在安全范围内能正常使用的空间。
实际上cell的可用空间在9T左右（用户可自行测试）， 只是如果超过了6.5T， 那么Usable_file_MB会变为负数，也就是说此时如果一个cell宕机就会导致前面描述现象发生。
另外值得注意的是1/4配是无法使用为high redundancy 模式的， 因为1/4有3个cell节点，每个cell节点对应一个failure group。 使用high redundancy 模式需要有5个votedisk， 每个votedisk需要放置于不同的failure group， 也就是至少需要1/2配你才能使用高冗余的模式。
以上。
Leave a Reply