数据库管理-第三十九期 ASM变了（20221016）

第三十九期 ASM变了

体验完了7天多么的慢（虽然感冒调休了一天），这一期的文章也是在新的一体机测试过程中与MOS后台一体机组小姐姐沟通时发现的。
技术向，知道写了些啥。

1 现象

首先这是以前贯穿N多期出了很多问题的那台一体机，X8-2，版本是19.6。

接下来是后面来的那台已经投入生产的X8M，版本是19.13。
从以上两台一体机可以发现，Req_mir_free_MB=20926464，Total_MB=376676352，Req_mir_free_MB/Total_MB≈5.556%。

而来到新的还在测试的X9M-2，版本来到19.16。Req_mir_free_MB=72636825，Total_MB=484245504，Req_mir_free_MB/Total_MB≈15%。而这台一体机目前除了数据库本身数据和少量测试数据，大约仅1TB，按照以前计算三副本来看，本来是150TB可用空间，而现在仅有135TB左右，这10%的Req_mir_free_MB增长在X9M-2 1/4配置上让人直观感觉少了将近15TB，不爽！

2 这个是问题么？

其实这个一开始我也没发现，也是MOS小姐姐告诉我的，其他地方在升级19.16之后发现了可用空间骤降了十几TB，已经有不少地方反馈了。小姐姐怀疑是一个BUG，我也配合开了个SR反馈，看原厂开发是如何反馈。
然而，开发直接回复了一个文档Understanding ASM Capacity and Reservation of Free Space in Exadata (Doc ID 1551288.1)，里面具体内容就不赘述了，主要是下面的内容：

还有相关在19.6修复的Bug 32166950 - CORRECT VALUE OF REQUIRED_MIRROR_FREE_MB AND USABLE_FILE_MB FOR EXADATA SYSTEMS的描述。也就是说以前现在5%左右的Req_mir_free_MB其实是错误的，实际在小于5个存储节点的情况下会占用15%，5个存储节点以上则会占用9%。

我和小姐姐的第一反应就是什么鬼！！！！这么多个版本过去了，从12.2到19.15，到这个时候才仅在新版本处理了？？？！！！

3 会影响什么？

其实，用一体机的地方，容量往往都会预留很多的，存储节点的扩容也会及时跟上的。但是也会出现扩容还没跟上，空间比较吃紧，还剩几TB，结果版本一升级Usable_file_MB一下子就变成负数了，虽然Doc ID 1551288.1强调不会对实际可用容量造成影响，但是还是有一定概率造成无法创建新的数据文件的问题，所以如果你的一体机的存储容量比较吃紧，如无必要请慎重升级到19.16及以上版本。
另一个方面则是在容量规划上，就拿我那台用于大数据的X8M-2，如果后续需要升级，那么当前的使用规划和扩容规划可能都会受到一定影响。

4 八卦一下

这个事情是听到某省份的一台一体机，存储配置没有选择三副本而是选择的两副本，结果在同一个时间点两个存储节点的两块磁盘都挂了（应该不是同时挂的），发现的时候数据库已无法运行，一个ASM磁盘组无法mount，经过排查，坏掉的这两块盘正好互为副本，这买彩票必中的运气也是没谁了。最重要的是，这台一体机木有备份，木有容灾，这就意味着除非恢复磁盘数据否则数据无法恢复，然而万幸的是，这台一体机用于开发测试，也算是不幸中的万幸了，但也会影响开发测试进度。
我认为，这两块磁盘再统一个时间点一起挂掉的概率很低，应该是一块挂掉以后并没有发现，另一块挂掉以后影响才展现出来。所以无论有多么完备的高可用、备份、容灾规划，日常巡检、告警监控都是需要做好的，因为你无论有多少个9，你与100%总归差了那一点点，而且很多问题的出现预先都是有征兆的。

总结

本期主要还是分享最近遇到的一些东西。
老规矩，知道写了些啥。