设为首页 加入收藏

TOP

Oracle ASM Rebalance执行过程(一)
2017-01-20 08:15:04 】 浏览:432
Tags: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阶段的大部分时间,也是我们最为需要关注的阶段,最后我们也会讲述第三阶段compacting阶段在做些什么。


首先需要明白为什么会需要做rebalance,如果你为了增加磁盘组的可用空间,增加了一块新磁盘或者为了调整磁盘的空间,例如resizing或者删除磁盘,你可能也不会太去关注rebalance啥时候完成。但是,如果磁盘组中的一块磁盘损坏了,这个时候你就有足够的理由关注rebalance的进度了,假如,你的磁盘组是normal冗余的,这个时候万一你损坏磁盘的partner磁盘也损坏,那么你的整个磁盘组会被dismount,所有跑在这个磁盘组上的数据库都会crash,你可能还会丢失数据。在这种情况下,你非常需要知道rebalance什么时候完成,实际上,你需要知道第二个阶段extent relocation什么时候完成,一旦它完成了,整个磁盘组的冗余就已经完成了(第三个阶段对于冗余度来说并不重要,后面会介绍)。


Extents relocation


为了进一步观察extents relocation阶段,我删除了具有默认并行度的磁盘组上的一块磁盘:
SQL> show parameter power


NAME? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? TYPE? ? ? ? ? ? ? ? ? VALUE
------------------------------------ ---------------------- ------------------------------
asm_power_limit? ? ? ? ? ? ? ? ? ? ? integer? ? ? ? ? ? ? ? 1


14:47:35 SQL> select group_number,disk_number,name,state,path,header_status from v$asm_disk where group_number=5;


GROUP_NUMBER DISK_NUMBER NAME? ? ? ? ? ? ? ? STATE? ? ? ? ? ? ? ? PATH? ? ? ? ? ? ? ? HEADER_STATUS
------------ ----------- -------------------- -------------------- -------------------- --------------------
? ? ? ? ? 5? ? ? ? ? 0 TESTDG_0000? ? ? ? ? NORMAL? ? ? ? ? ? ? /dev/raw/raw7? ? ? ? MEMBER
? ? ? ? ? 5? ? ? ? ? 2 TESTDG_0002? ? ? ? ? NORMAL? ? ? ? ? ? ? /dev/raw/raw13? ? ? MEMBER
? ? ? ? ? 5? ? ? ? ? 1 TESTDG_0001? ? ? ? ? NORMAL? ? ? ? ? ? ? /dev/raw/raw12? ? ? MEMBER
? ? ? ? ? 5? ? ? ? ? 3 TESTDG_0003? ? ? ? ? NORMAL? ? ? ? ? ? ? /dev/raw/raw14? ? ? MEMBER


14:48:38 SQL> alter diskgroup testdg drop disk TESTDG_0000;


Diskgroup altered.



下面视图GV$ASMOPERATION的ESTMINUTES字段给出了估算值的时间,单位为分钟,这里给出的估算时间为9分钟。
14:49:04 SQL> select inst_id, operation, state, power, sofar, est_work, est_rate, est_minutes from gv$asm_operation where group_number=5;


? INST_ID OPERATION? ? ? ? ? ? STATE? ? ? ? ? ? ? ? ? ? POWER? ? ? SOFAR? EST_WORK? EST_RATE EST_MINUTES
---------- -------------------- -------------------- ---------- ---------- ---------- ---------- -----------
? ? ? ? 1 REBAL? ? ? ? ? ? ? ? RUN? ? ? ? ? ? ? ? ? ? ? ? ? 1? ? ? ? ? 4? ? ? 4748? ? ? ? 475? ? ? ? ? 9


?


大约过了1分钟后,EST_MINUTES的值变为了0分钟:
14:50:22 SQL> select inst_id, operation, state, power, sofar, est_work, est_rate, est_minutes from gv$asm_operation where group_number=5;


? INST_ID OPERATION? ? ? ? ? ? STATE? ? ? ? ? ? ? ? ? ? POWER? ? ? SOFAR? EST_WORK? EST_RATE EST_MINUTES
---------- -------------------- -------------------- ---------- ---------- ---------- ---------- -----------
? ? ? ? 1 REBAL? ? ? ? ? ? ? ? RUN? ? ? ? ? ? ? ? ? ? ? ? ? 1? ? ? 3030? ? ? 4748? ? ? 2429? ? ? ? ? 0



有些时候EST_MINUTES的值可能并不能给你太多的证据,我们还可以看到SOFAR(截止目前移动的UA数)的值一直在增加,恩,不错,这是一个很好的一个观察指标。ASM的alert日志中也显示了删除磁盘的操作,以及OS ARB0进程的ID,ASM用它用来做所有的rebalance工作。更重要的,整个过程之中,没有任何的错误输出:
SQL> alter diskgroup testdg drop disk TESTDG_0000
NOTE: GroupBlock outside rolling migration privileged region
NOTE: requesting all-instance membership refresh for group=5
Tue Jan 10 14:49:01 2017
GMON updating for reconfiguration, group 5 at 222 for pid 42, osid 6197
NOTE: group 5 PST updated.
Tue Jan 10 14:49:01 2017
NOTE: membership refresh pending for group 5/0x97f863e8 (TESTDG)
GMON querying group 5 at 223 for pid 18, osid 5012
SUCCESS: refreshed members

首页 上一页 1 2 3 4 5 下一页 尾页 1/5/5
】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
上一篇定位数据在ASM中的位置 下一篇Oracle服务安装后sqlplus命令提示..

最新文章

热门文章

Hot 文章

Python

C 语言

C++基础

大数据基础

linux编程基础

C/C++面试题目