ASM 翻译系列第三十三弹:REQUIRED_MIRROR_FREE_MB的含义

原作者:Bane Radulovic

译者: 陈亚军

审核: 魏兴华

DBGeeK社区联合出品

原文链接:http://asmsupportguy.blogspot.sg/2014/09/requiredmirrorfreemb.html

REQUIRED_MIRROR_FREE_MB

REQUIRED_MIRROR_FREE_MB和USABLE_FILE_MB是V$ASM_DISKGROUP[_STAT]视图中非常有趣的两列。Oracle Support部门收到的很多问题是关于这两列的意义以及它们的值是怎么计算的。我本打算写些文章介绍一下,但是我意识到我不可能比Harald van Breederode做的更出色。因此我征得了他的同意来直接参考他的文章,所以还是请欣赏他的大作吧。

https://prutser.wordpress.com/2013/01/03/demystifying-asm-required_mirror_free_mb-and-usable_file_mb/

How much space can I use

既然已经解释了REQUIRED_MIRROR_FREE_MB和USABLE_FILE_MB,我想补充说明的是ASM不会阻止你使用所有可用空间(NORMAL冗余模式下总空间的1/2或者HIGH冗余模式下总空间的1/3)。但是一旦你使用完了所有磁盘组空间,将没有剩余空间用来扩展或者新增任何其他文件,在这种情况下,如果有磁盘出现故障,同样不会有剩余空间用来让数据重新满足需要的冗余度--直到故障的磁盘被替换并且rebalance完成。

Exadata with ASM version 11gR2

在安装了11.2 ASM版本的Exadata中,REQUIRED_MIRROR_FREE_MB等于磁盘组中最大的failgroup的大小(在真实的Exadata环境中,所有的failgroup默认都是相同的大小)。为了验证这个说法,让我们来看一个安装了11.2 ASM的Exadata的情况。

和大部分的Exadata安装一样,这里有3个磁盘组。

[grid@exadb01 ~]$ sqlplus / as sysasm
SQL*Plus: Release 11.2.0.4.0 Production on [date]
SQL> select NAME, GROUP_NUMBER from v$asm_diskgroup_stat;
NAME      GROUP_NUMBER
--------- ------------
DATA                 1
DBFS_DG              2
RECO                 3
SQL>

出于列举这个例子的目的,我们将会看下DBFS_DG这个磁盘组。通常情况下DBFS_DG的每个failgroup有10个磁盘。为了验证REQUIRED_MIRROR_FREE_MB就是最大的failgroup的大小,这里我drop掉了部分磁盘。

SQL> select FAILGROUP, count(NAME) "Disks", sum(TOTAL_MB) "MB"
from v$asm_disk_stat
where GROUP_NUMBER=2
group by FAILGROUP
order by 3;
FAILGROUP       Disks         MB
---------- ---------- ----------
EXACELL04           7     180096
EXACELL01           8     205824
EXACELL02           9     231552
EXACELL03          10     257280
SQL>

注意最大的failgroup的总大小为257280 MB。

最后,我们发现REQUIRED_MIRROR_FREE_MB就是最大的failgroup的大小:

SQL> select NAME, TOTAL_MB, FREE_MB, REQUIRED_MIRROR_FREE_MB, USABLE_FILE_MB
from v$asm_diskgroup_stat
where GROUP_NUMBER=2;
NAME         TOTAL_MB    FREE_MB REQUIRED_MIRROR_FREE_MB USABLE_FILE_MB
---------- ---------- ---------- ----------------------- --------------
DBFS_DG        874752     801420                  257280         272070
SQL>

ASM中使用如下公式计算USABLE_FILE_MB:

USABLE_FILE_MB = (FREE_MB - REQUIRED_MIRROR_FREE_MB) / 2

得到的结果为:272070 MB

Exadata with ASM version 12cR1

在安装12cR1版本ASM的Exadata中,REQUIRED_MIRROR_FREE_MB等于磁盘组中最大的磁盘的大小。

这里是一个来自安装了12.1.0.2.0 ASM的Exadata系统的例子。

[grid@exadb03 ~]$ sqlplus / as sysasm
SQL*Plus: Release 12.1.0.2.0 Production on [date]
SQL> select NAME, GROUP_NUMBER from v$asm_diskgroup_stat;
NAME     GROUP_NUMBER
-------- ------------
DATA                1
DBFS_DG             2
RECO                3
SQL>

同样的,我把DBFS_DG磁盘组中的failgroups设置成不同的大小。

SQL> select FAILGROUP, count(NAME) "Disks", sum(TOTAL_MB) "MB"
from v$asm_disk_stat
where GROUP_NUMBER=2
group by FAILGROUP
order by 3;
FAILGROUP       Disks         MB
---------- ---------- ----------
EXACELL05           8     238592
EXACELL07           9     268416
EXACELL06          10     298240
SQL>

最大的failgroup的总大小为298240 MB,但是这一次REQUIRED_MIRROR_FREE_MB的大小为29824 MB:

SQL> select NAME, TOTAL_MB, FREE_MB, REQUIRED_MIRROR_FREE_MB, USABLE_FILE_MB
from v$asm_diskgroup_stat
where GROUP_NUMBER=2;  2    3
NAME         TOTAL_MB    FREE_MB REQUIRED_MIRROR_FREE_MB USABLE_FILE_MB
---------- ---------- ---------- ----------------------- --------------
DBFS_DG        805248     781764                   29824         375970
SQL>

正如我们看到的,这是磁盘组中最大的磁盘的大小:

SQL> select max(TOTAL_MB) from v$asm_disk_stat where GROUP_NUMBER=2;
MAX(TOTAL_MB)
-------------
        29824
SQL>

USABLE_FILE_MB的大小通过同样的公式计算获得:

USABLE_FILE_MB = (FREE_MB - REQUIRED_MIRROR_FREE_MB) / 2

结果为:375970 MB

Conclusion

REQUIRED_MIRROR_FREE_MB和USABLE_FILE_MB是为了帮助DBA和存储管理员来规划磁盘组的容量和冗余度而设计的。在ASM中,它们的值只作为参考,并不具有强制性。

在12cR1 ASM版本的Exadata中,REQUIRED_MIRROR_FREE_MB等于磁盘组中最大的磁盘的大小,设计就是这样的,反映了该领域的经验:磁盘才是发生故障的组件,而不是整个存储节点。

译者注:真实的环境中,整个存储节点整体坏掉的可能性比较小,一般都是瞬时的故障如断电,因此整个存储出问题后,一般能及时修复,而磁盘一般故障后会直接坏掉,大多数情况不可修复,磁盘故障的概率要比整体存储节点故障的概率高很多。

原文发布于微信公众号 - 沃趣科技(woqutech)

原文发表时间:2017-02-24

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏数据和云

案发现场:被注入的软件及 ORA-600 16703 灾难的恢复

最近帮助一个客户恢复数据库,遇到了如下这个问题。让我们再一次惊醒于数据安全,如果不做好防范,问题总是会来得猝不及防。

2254
来自专栏技术点滴

黑客常用WinAPI函数整理

黑客常用WinAPI函数整理 之前的博客写了很多关于Windows编程的内容,在Windows环境下的黑客必须熟练掌握底层API编程。为了使读者对黑客常用的Wi...

1846
来自专栏数据和云

【循序渐进Oracle】Oracle的物理备份(上)

编辑手记:备份重于一切,我们必需知道,系统总是要崩溃的,没有有效的备份只是等哪一天死!今天你备份了吗?我们一起来回顾Oracle的物理备份,本文摘自《循序渐进O...

3448
来自专栏个人分享

Spark 1.4连接mysql诡异的问题及解决

这个问题就很诡异了。。数据源连接也没错啊,毕竟在hive的metastore也是用的这个啊。。最终只能在启动spark-shell的时候同时引入jar包了= =

1562
来自专栏乐沙弥的世界

Oracle 基于用户管理恢复的处理

Oracle支持多种方式来管理数据文件的备份与恢复来保证数据库的可靠与完整。除了使用RMAN工具以及第三方备份与恢复工具之外,基于

542
来自专栏张戈的专栏

[svn: E155004]svn update报database is locked错误的解决办法

今天突然发现项目更新脚本在拉代码的时候抛出了一个如下错误: svn: E155004: Working copy '/home/svn/***/trunk/st...

1.1K8
来自专栏乐沙弥的世界

只读表空间的备份与恢复

--====================== --  只读表空间的备份与恢复 --====================== 一、只读表空间的特性...

882
来自专栏耕耘实录

一个简单的Linux系统加固方案

版权声明:本文为耕耘实录原创文章,各大自媒体平台同步更新。欢迎转载,转载请注明出处,谢谢。

1212
来自专栏沃趣科技

复制状态与变量记录表 | performance_schema全方位介绍

不知不觉中,performance_schema系列快要接近尾声了,今天将带领大家一起踏上系列第六篇的征程(全系共7个篇章),在这一期里,我们将为大家全面讲解p...

1713
来自专栏乐沙弥的世界

Oracle 阻塞(blocking blocked)

   阻塞是DBA经常碰到的情形,尤其是不良的应用程序设计的阻塞将导致性能严重下降直至数据库崩溃。对DBA而言,有必要知道如何定位到当前系统有哪些阻塞,到底谁是...

822

扫码关注云+社区

领取腾讯云代金券