Oracle ASM Rebalance执行过程是怎样的

这篇文章主要讲解了“Oracle ASM Rebalance执行过程是怎样的”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“Oracle ASM Rebalance执行过程是怎样的”吧！磁盘组的rebalance什么时候能完成？这没有一个具体的数值，但ASM本身已经给你提供了一个估算值（GV$ASM_OPERATION.EST_MINUTES），想知道rebalance完成的精确的时间，虽然不能给出一个精确的时间，但是可以查看一些rebalance的操作细节，让你知道当前rebalance是否正在进行中，进行到哪个阶段，以及这个阶段是否需要引起你的关注。
理解rebalance
rebalance操作本身包含了3个阶段-planning, extents relocation 和 compacting，就rebalance需要的总时间而言，planning阶段需要的时间是非常少的，你通常都不用去关注这一个阶段，第二个阶段extent relocation一般会占取rebalance阶段的大部分时间，也是我们最为需要关注的阶段，最后我们也会讲述第三阶段compac免费主机域名ting阶段在做些什么。
首先需要明白为什么会需要做rebalance，如果你为了增加磁盘组的可用空间，增加了一块新磁盘或者为了调整磁盘的空间，例如resizing或者删除磁盘，你可能也不会太去关注rebalance啥时候完成。但是，如果磁盘组中的一块磁盘损坏了，这个时候你就有足够的理由关注rebalance的进度了，假如，你的磁盘组是normal冗余的，这个时候万一你损坏磁盘的partner磁盘也损坏，那么你的整个磁盘组会被dismount，所有跑在这个磁盘组上的数据库都会crash，你可能还会丢失数据。在这种情况下，你非常需要知道rebalance什么时候完成，实际上，你需要知道第二个阶段extent relocation什么时候完成，一旦它完成了，整个磁盘组的冗余就已经完成了（第三个阶段对于冗余度来说并不重要，后面会介绍）。
Extents relocation
为了进一步观察extents relocation阶段，我删除了具有默认并行度的磁盘组上的一块磁盘：
下面视图GV$ASMOPERATION的ESTMINUTES字段给出了估算值的时间，单位为分钟，这里给出的估算时间为9分钟。 免费主机域名
大约过了1分钟后，EST_MINUTES的值变为了0分钟：
有些时候EST_MINUTES的值可能并不能给你太多的证据，我们还可以看到SOFAR（截止目前移动的UA数）的值一直在增加，恩，不错，这是一个很好的一个观察指标。ASM的alert日志中也显示了删除磁盘的操作，以及OS ARB0进程的ID，ASM用它用来做所有的rebalance工作。更重要的，整个过程之中，没有任何的错误输出：
因此ASM预估了9分钟的时间来完成rebalance，但实际上只使用了2分钟的时候,因此首先能知道rebalance正在做什么非常重要，然后才能知道rebalance什么时候能完成。注意，估算的时间是动态变化的，可能会增加或减少，这个依赖你的系统负载变化，以及你的rebalance的power值的设置，对于一个非常大容量的磁盘组来说，可能rebalance会花费你数小时甚至是数天的时间。
ARB0进程的跟踪文件也显示了，当前正在对哪一个ASM文件的extent的在进行重分配，也是通过这个跟踪文件，我们可以知道ARB0确实是在干着自己的本职工作，没有偷懒。
注意，跟踪目录下的arb0的跟踪文件可能会有很多，因此我们需要知道arb0的OS是进程号，是哪一个arb0在实际做rebalance的工作，这个信息在ASM实例执行rebalance操作的时候，alert文件中会有显示。我们还可以通过操作系统命令pstack来跟踪ARB0进程，查看具体它在做什么，如下，它向我们显示了，ASM正在重分配extent（在堆栈中的关键函数 kfgbRebalExecute – kfdaExecute – kffRelocate):
Compacting
在下面的例子里，我们来看下rebalance的compacting阶段，我把上面删除的磁盘加回来，同时设置rebalance的power为2：
ASM给出的rebalance的估算时间为6分钟：
大约10秒后，EST_MINUTES的值变为0.
这个时候我们在ASM的alert日志中观察到：
上面的输出意味着ASM已经完成了rebalance的第二个阶段，开始了第三个阶段compacting，如果我说的没错，通过pstack工具可以看到kfdCompact()函数，下面的输出显示，确实如此:
通过tail命令查看ARB0的跟踪文件，发现relocating正在进行，而且一次只对一个条目进行relocating。（这是正进行到compacting阶段的另一个重要线索）：
compacting过程中，V$ASM_OPERATION视图的EST_MINUTES字段会显示为0（也是一个重要线索）：
固态表X$KFGMG的REBALST_KFGMG字段会显示为2，代表正在compacting。
一旦compacting阶段完成，ASM的alert 日志中会显示stopping process ARB0 和rebalance completed:
一旦extents relocation完成，所有的数据就已经满足了冗余度的要求，不再会担心已经失败磁盘的partern磁盘再次失败而出现严重故障。
Changing the power
Rebalance的power可以在磁盘组rebalance过程中动态的更改，如果你认为磁盘组的默认级别太低了，可以去很容易的增加它。但是增加到多少呢？这个需要你根据你系统的IO负载，IO吞吐量来定。一般情况下，你可以先尝试增加到一个保守的值，例如5，过上十分钟看是否有所提升，以及是否影响到了其他业务对IO的使用，如果你的IO性能非常强，那么可以继续增加power的值，但是就我的经验来看，很少能看到power 的设置超过30后还能有较大提升的。测试的关键点在于，你需要在你生产系统的正常负载下去测试，不同的业务压力，不同的存储系统，都可能会让rebalance时间产生较大的差异。 感谢各位的阅读，以上就是“Oracle ASM Rebalance执行过程是怎样的”的内容了，经过本文的学习后，相信大家对Oracle ASM Rebalance执行过程是怎样的这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是云技术，小编将为大家推送更多相关知识点的文章，欢迎关注！

相关推荐: linux7静默安装11GR2 RAC的方法是什么

这篇文章主要介绍“linux7静默安装11GR2 RAC的方法是什么”，在日常操作中免费主机域名，相信很多人在linux7静默安装11GR2 RAC的方法是什么问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”linux7静默安装1…