Test Case:: 12C ASM New feature (Doc ID 1571975.1)

Test Case:: 12C ASM New feature (Doc ID 1571975.1)

APPLIES TO:

Oracle Database - Enterprise Edition - Version 12.1.0.1 and later
Information in this document applies to any platform.

PURPOSE

This document is a discussion of a few 12C ASM new features with examples:  本文以示例的形式讨论了一些12C ASM新功能

1. Failgroup_repair_time
2. Online disk replace
3. Estimate Work
4. V$ASM_OPERATION view

DETAILS

1. FAILGROUP_REPAIR_TIME

For versions <= 11g, we had disk_repair_time, from 12C onwards we have failgroup_repair_time at the ASM level.  Because failure group outages are more likely to be transient in nature and because replacing all the disks in a failure group is a much more expensive operation than replacing a single disk, it would typically make sense for failure groups to have a larger repair time to ensure that all the disks do not get dropped automatically in the event of a failure group outage.

对于<= 11g的版本，我们有 disk_repair_time，从12C开始，我们在ASM级别上有 failgroup_repair_time。由于故障组中断本质上更可能是瞬态的，并且更换故障组中的所有磁盘比更换单个磁盘要贵得多，因此故障组通常需要更长的维修时间来确保故障组中断时不会自动删除所有磁盘。

By default, the value of this diskgroup level attribute is 24Hours.  To set this attribute at ASM diskgroup level, one must set compatible.asm and compatible.rdbms greater than or equal to 11.1.0.0.

默认情况下，此磁盘组级别属性的值为24Hours。要在ASM磁盘组级别上设置此属性，必须将compatible.asm和compatible.rdbms设置为大于或等于11.1.0.0。

 

Test Case:  测试用例

## Newly created diskgroup,  新创建的磁盘组

SQL> create diskgroup test_failgroup normal redundancy failgroup A disk '/dev/sde2','/dev/sdh2'
2 failgroup B disk '/dev/sdb4','/dev/sdi1';

Diskgroup created.

## Tried to set this attribute on same diskgroup,  --试图在同一磁盘组上设置此属性

SQL> alter diskgroup test_failgroup set attribute 'failgroup_repair_time'='3H';
alter diskgroup test_failgroup set attribute 'failgroup_repair_time'='3H'
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15242: could not set attribute failgroup_repair_time
ORA-15221: ASM operation requires compatible.asm of 11.1.0.0.0 or higher   <<<<<< --compatible.asm

## Validated both attribute of this diskgroup,it remained same to support backward compatibilities.  验证了该磁盘组的两个属性，它保持相同以支持向后兼容性

SQL> select NAME ,COMPATIBILITY,DATABASE_COMPATIBILITY from v$asm_diskgroup where name='TEST_FAILGROUP';

NAME                             COMPATIBILITY       DATABASE_COMPATIBILITY
-------------------------- ------------------- ----------------------------
TEST_FAILGROUP                      10.1.0.0.0                   10.1.0.0.0 

## Changed only compatible.asm  仅更改了compatible.asm

SQL> ALTER DISKGROUP TEST_FAILGROUP SET ATTRIBUTE 'COMPATIBLE.ASM'='11.1.0.0';

Diskgroup altered.

SQL> select NAME ,COMPATIBILITY,DATABASE_COMPATIBILITY from v$asm_diskgroup where name='TEST_FAILGROUP';

NAME                             COMPATIBILITY       DATABASE_COMPATIBILITY
-------------------------- ------------------- ----------------------------
TEST_FAILGROUP                      11.1.0.0.0                   10.1.0.0.0 

SQL> alter diskgroup test_failgroup set attribute 'failgroup_repair_time'='3H';
alter diskgroup test_failgroup set attribute 'failgroup_repair_time'='3H'
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15242: could not set attribute failgroup_repair_time
ORA-15283: ASM operation requires compatible.rdbms of 11.1.0.0.0 or higher  <<<<<<<<<<<<<<<< --compatible.rdbms

## Now set compatible.rdbms to 11.1.0.0  现在将compatible.rdbms设置为11.1.0.0

SQL> ALTER DISKGROUP TEST_FAILGROUP SET ATTRIBUTE 'COMPATIBLE.RDBMS'='11.1.0.0';

Diskgroup altered.

SQL> select NAME ,COMPATIBILITY,DATABASE_COMPATIBILITY from v$asm_diskgroup where name='TEST_FAILGROUP';

NAME                             COMPATIBILITY       DATABASE_COMPATIBILITY
-------------------------- ------------------- ----------------------------
TEST_FAILGROUP                      11.1.0.0.0                   11.1.0.0.0

## Then tried to set this parameter at diskgroup level  然后尝试在磁盘组级别设置此参数

SQL> alter diskgroup test_failgroup set attribute 'failgroup_repair_time'='3H';

Diskgroup altered.

## Validate this change,

SQL> select group_number,name,value from v$asm_attribute where group_number=4 and name like 'failgroup%';

GROUP_NUMBER                     NAME                   VALUE
------------ ------------------------ -----------------------
           4    failgroup_repair_time                      3H

2. Online disk replace  在线更换磁盘

If an ASM disk becomes offline and cannot be repaired, administrators need the ability to replace the disk. In versions of ASM prior to 12c, there was no replace command.  Rather, administrators had to drop the faulty disk and then add a new one back into the disk group which causes an ASM level rebalance.  Depending on multiple internal and external factors, reblance can be time consuming.  如果ASM磁盘脱机且无法修复，则管理员需要能够更换该磁盘。在12c之前的ASM版本中，没有replace命令。而是，管理员必须删除故障磁盘，然后将新的磁盘添加回磁盘组，这会导致ASM级别的重新平衡。根据多个内部和外部因素，重新平衡可能很耗时。

In 12c, ASM allows DBAs to simply replace an offline disk using one fast and efficient operation.  There is no need for any additional reorganization or rebalancing across the rest of the disk group.  在12c中，ASM允许DBA使用一种快速而有效的操作简单地替换脱机磁盘。无需对其余磁盘组进行任何其他重组或重新平衡

• ASM diskgroup level attribute compatible.asm should be of 12.1.0.0 for this feature  此功能的ASM磁盘组级别属性compatible.asm应为12.1.0.0
• Replacing disk should bad in true sense , ASM will not replace online disk.  从实际意义上讲，更换磁盘应该是不好的，ASM不会替换在线磁盘。
• The replacement disk takes the same name as the original disk and becomes part of the same failure group as the original disk.  备用磁盘与原始磁盘具有相同的名称，并成为与原始磁盘相同的故障组的一部分。
• Then replacing good disk should be sized equal or greater than replacing bad disk.Else replace will fail.  然后替换好磁盘的大小应等于替换坏磁盘的大小，否则替换将失败

Test case:  测试用例：

## Tried to replace a disk with compatible.asm 10.1.0.0  尝试将磁盘替换为compatible.asm 10.1.0.0

SQL> alter diskgroup test_failgroup replace disk TEST_FAILGROUP_0002 with '/dev/sdg1';
alter diskgroup test_failgroup replace disk TEST_FAILGROUP_0002 with '/dev/sdg1'
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15221: ASM operation requires compatible.asm of 12.1.0.0.0 or higher   <<<<<<<<<<<--compatible.asm

 

## Tried to remove online disk  尝试删除在线磁盘

SQL> alter diskgroup test_failgroup replace disk TEST_FAILGROUP_0002 with '/dev/sdg1';
alter diskgroup test_failgroup replace disk TEST_FAILGROUP_0002 with '/dev/sdg1'
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15145: ASM disk 'TEST_FAILGROUP_0002' is online and cannot be replaced.    <<<<<<<<<<<


## To replace this disk ,for testing purpose ,change the permission of that disk .  
--要更换该磁盘，出于测试目的，请更改该磁盘的权限

SQL> !chmod 000 /dev/sdb4

SQL> alter diskgroup test_failgroup replace disk TEST_FAILGROUP_0002 with '/dev/sdg1';

Diskgroup altered.

## From alert log file ,

Tue Jul 30 12:29:34 2013
GMON updating disk modes for group 4 at 39 for pid 42, osid 9205
NOTE: group TEST_FAILGROUP: updated PST location: disk 0000 (PST copy 0)
NOTE: group TEST_FAILGROUP: updated PST location: disk 0003 (PST copy 1)
Tue Jul 30 12:29:34 2013
NOTE: PST update grp = 4 completed successfully
NOTE: initiating PST update: grp 4 (TEST_FAILGROUP), dsk = 2/0x0, mask = 0x7d, op = assign
Tue Jul 30 12:29:34 2013
GMON updating disk modes for group 4 at 40 for pid 42, osid 9205
NOTE: group TEST_FAILGROUP: updated PST location: disk 0000 (PST copy 0)
NOTE: group TEST_FAILGROUP: updated PST location: disk 0003 (PST copy 1)
Tue Jul 30 12:29:34 2013
NOTE: PST update grp = 4 completed successfully
Tue Jul 30 12:29:34 2013
NOTE: Voting File refresh pending for group 4/0x60869f8 (TEST_FAILGROUP)
NOTE: Attempting voting file refresh on diskgroup TEST_FAILGROUP
Tue Jul 30 12:29:34 2013
SUCCESS: alter diskgroup test_failgroup replace disk TEST_FAILGROUP_0002 with '/dev/sdg1'
Tue Jul 30 12:29:34 2013
NOTE: starting rebalance of group 4/0x60869f8 (TEST_FAILGROUP) at power 1
Starting background process ARB0

## Validated that replacing disk is taking same name as old disk  验证替换磁盘的名称与旧磁盘的名称相同

SQL> select name,path,total_mb from v$asm_disk where group_number=4;

NAME                               PATH                  TOTAL_MB
-------------------------- ------------ -------------------------
TEST_FAILGROUP_0003           /dev/sdi1                      2541
TEST_FAILGROUP_0001           /dev/sdh2                      2565
TEST_FAILGROUP_0002           /dev/sdg1                      2165 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
TEST_FAILGROUP_0000           /dev/sde2                      2565

## Added disk was lager in size of original disk.  --添加的磁盘的原始磁盘容量更大
But at ASM level only same size allocated as old bad disk.  --但是在ASM级别上，仅分配了与旧的坏磁盘相同的大小

SQL> select name,path,total_mb,os_mb from v$asm_disk where group_number=4;

NAME                              PATH            TOTAL_MB                     OS_MB
------------------------- ------------ ------------------- -------------------------
TEST_FAILGROUP_0003          /dev/sdi1                2541                      2541
TEST_FAILGROUP_0001          /dev/sdh2                2565                      2565
TEST_FAILGROUP_0002          /dev/sdg1                2165                      2541 <<<<<<<<<<<<
TEST_FAILGROUP_0000          /dev/sde2                2565                      2565

## Simulate similar type of issue and tried to replace with less sized disk than bad disk.  模拟类似的问题，并尝试使用大小比坏磁盘小的磁盘进行替换
It did not allow replacement  不允许更换

SQL> alter diskgroup Test_failgroup replace disk TEST_FAILGROUP_0002 with '/dev/sdb4';
alter diskgroup Test_failgroup replace disk TEST_FAILGROUP_0002 with '/dev/sdb4'
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15408: Replacement disk for 'TEST_FAILGROUP_0002' must be at least 2541 M.    <<<<<<<<

3. Estimate Work  估算工作

Before 12C, the only way to know how long an expensive operation like disk add/drop at diskgroup level was to actually perform the operation, so there was no way to predict before-hand how much time this would take.
在12C之前，了解磁盘组级别的昂贵操作（如磁盘添加/删除）的唯一方法是实际执行该操作，因此无法预先预测所需的时间。
In 12c ASM, a more detailed and more accurate work plan is created at the beginning of each rebalance operation. In addition, DBAs can separately generate and view the work plan before performing a rebalance operation. This allows DBA to better plan and execute various changes such as adding storage, removing storage or moving between different storage systems.  在12c ASM中，在每个重新平衡操作开始时都会创建更详细，更准确的工作计划。此外，DBA可以在执行重新平衡操作之前分别生成和查看工作计划。这使DBA可以更好地计划和执行各种更改，例如添加存储，删除存储或在不同存储系统之间移动。
DBAs can generate the work plan using the ESTIMATE WORK command.  DBA可以使用ESTIMATE WORK命令生成工作计划。

Querying from V$ASM_ESTIMATE view give an idea of required time of that operation based on current workload on the system.  This feature allows DBAs to consider system load implications while planning an operation before actually taxing the system.
从V$ASM_ESTIMATE视图中查询可以根据系统上的当前工作量了解该操作所需的时间。通过此功能，DBA可以在计划操作之前实际对系统加税之前考虑系统负载的影响。
Note:  be sure to give the correct disk name, otherwise this estimation will fail  注意：请确保提供正确的磁盘名称，否则此估算将失败

## Tried to estimate non-existence disk in a diskgroup  试图估计磁盘组中不存在的磁盘

SQL> explain work set statement_id='drop_test_failgroup_0002' for alter diskgroup test_failgroup
2 drop disk test_failgroup_0005;
explain work set statement_id='drop_test_failgroup_0005' for alter diskgroup test_failgroup
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15054: disk "TEST_FAILGROUP_0005" does not exist in diskgroup "TEST_FAILGROUP"   <<<<<<<<<<

 

## Now generating estimation  现在生成估算

SQL> explain work set statement_id='drop_test_failgroup_0000' for alter diskgroup test_failgroup
2 drop disk test_failgroup_0000;

Explained.

SQL> select est_work from v$asm_estimate where statement_id='drop_test_failgroup_0000';

EST_WORK
----------
42

4. V$ASM_OPEARATION view

From version 11g onwards, we have a compact phase while rebalancing.  While this phase used to run at ASM level for a diskgroup, we cannot estimate compact phase timing approximately.

从版本11g开始，我们在重新平衡的同时处于紧凑阶段​​。虽然此阶段曾经在磁盘组的ASM级别上运行，但我们无法估计紧凑阶段的时序。

We used to see EST_MINUTES is 0.  At the same time we were also not able to track resync operations separately.

我们曾经看到EST_MINUTES为0。与此同时，我们也无法单独跟踪重新同步操作。

In 12C, we can view these phases separately from v$asm_operation, giving a better idea about on-going operation based on current utilization of the system.

在12C中，我们可以与v$asm_operation分开查看这些阶段，从而根据系统当前的使用情况更好地了解正在进行的操作。

SQL> SELECT PASS, STATE, EST_MINUTES FROM V$ASM_OPERATION;

PASS                  STAT          EST_MINUTES
----------------- -------- --------------------
RESYNC                RUN                     1
REBALANCE            WAIT                    20
COMPACT              WAIT                     2