ANBOB™

oracle ASM 从12c后引入了诸多特性，如FLEX ASM、Increased ASM storage limits、ASM instance V$ACTIVE_SESSION_HISOTRY 、ASM Disk Scrubbing外，最近发现还有一个关于ASM DISK rebalance 的增强EXPLAIN WORK FOR命令。12c 中新的 EXPLAIN WORK FOR 语句测量给定 ASM rebalance所需的工作量，并将结果输入 V$ASM_ESTIMATE 动态视图中。可以根据从动态视图获得的输出来调整 POWER 限制，以改进rebalance操作。

SQL> EXPLAIN WORK FOR ALTER DISKGROUP DG_DATA ADD DISK data_001;

SQL> SELECT est_work FROM V$ASM_ESTIMATE;

SQL> EXPLAIN WORK SET STATEMENT_ID='ADD_DISK' FOR ALTER DISKGROUP DG_DATA ADD DISK data_001;

SQL> SELECT est_work FROM V$ASM_ESTIMATE WHERE STATEMENT_ID = 'ADD_DISK’;

Est_work 列提供rebalance操作期间移动的AU的信息。

ASM rebalance

ASM rebalance实际分为三步 planning, extents relocation 和compacting. 时间主要花费在 extents relocation ，这也是关注的重点，如果narmal冗余的DISKGROUP，有1个disk已出现故障，而如果partner FG再出故障就可能会diskgroup unmount并且可能会丢失数据，这时你希望知道rebalance多久完成。

 select INST_ID, OPERATION, STATE, POWER, SOFAR, EST_WORK, EST_RATE, EST_MINUTES from GV$ASM_OPERATION

GV$ASM_OPERATION给我们提供了EST_MINUTES 估算剩余时间，但并不是很准确。SOFAR（到目前为止移动的AU数量），ASM ALERT LOG和正在做ARBn的操作系统进程的trace会显示正在操作的信息，如果pstack打印ARBn进程的堆栈也可以看到kfgbRebalExecute – kfdaExecute – kffRelocate当前的阶段。而如果EST_MINUTES变为0后rebalance并不会立即结束，会进入compacting阶段，它是为过去的HDD准备的，做数据盘道外迁减少读数据时的速率，SSD并不适用。如果此时pstack会显示kfdCompact kfdExecute,从内部VIEW X$KFGMG 显示 REBALST_KFGMG=2（压缩）

select NUMBER_KFGMG, OP_KFGMG, ACTUAL_KFGMG, REBALST_KFGMG from X$KFGMG;

第三阶段compacting需要多长时间并不重要，因为一旦重新平衡（extents relocation）的第二阶段完成，所有数据都将完全冗余，并且我们不会因伙伴磁盘故障而面临磁盘组卸除的风险。

EXPLAIN WORK

oracle中像explain plan可以估执行计划，不是实际执行，同样在做XTTS导出metadata新版本也可以估算时间，对业务的影响，可见是在online系列维护特性外，让我们对“offline”的维护有个预判，好指定维护计划。在 12C 之前，了解磁盘组级别的磁盘添加/删除等昂贵操作需要多长时间的唯一方法是实际执行该操作，因此无法事先预测这将花费多少时间。在 12c ASM 中DBA 可以使用 ESTIMATE WORK 命令给出正确的DISK名称生成工作计划。从 V$ASM_ESTIMATE 视图中查询可以根据系统当前的工作负载了解该操作所需的时间。 此功能允许 DBA 在实际对系统造成负担之前规划操作时考虑系统负载影响。同时12c后v$asm_operation更加详细

SELECT PASS, STATE, EST_MINUTES FROM V$ASM_OPERATION;

打赏

微信扫一扫，打赏作者吧～