【MOS】零宕机迁移ASM磁盘组到另一个SAN/磁盘阵列/DAS的准确步骤 (文档 ID 1946664.1)

适用于:

Oracle Database - Enterprise Edition - 版本 10.2.0.1 到 11.2.0.4 [发行版 10.2 到 11.2]
Oracle Database Cloud Schema Service - 版本 N/A 和更高版本
Oracle Database Exadata Express Cloud Service - 版本 N/A 和更高版本
Oracle Database Exadata Cloud Machine - 版本 N/A 和更高版本
Oracle Cloud Infrastructure - Database Service - 版本 N/A 和更高版本
本文档所含信息适用于所有平台

目标

 

本文详述了在零宕机时间的前提下将 ASM 磁盘组从一个存储设备（SAN/磁盘阵列/DAS等）迁移到另一个存储设备（SAN/磁盘阵列/DAS等）的准确步骤。此过程也适用于存放 OCR、表决磁盘和 ASM spfile 的磁盘组。

 

提问，获得帮助，并分享您对于这篇文档的经验。

您是否希望与其他 Oracle 客户、Oracle 员工和业内专家进一步探讨此主题？

请点击这里进入 Oracle 社区（中文）。
请点击这里进入 My Oracle Support 社区的数据库安装/升级（英文）主页发现更多的话题和讨论。

 

解决方案

如果你您计划将你您的磁盘组从当前的磁盘迁移到新的存储上，此操作过程能没有没有任何停机时间地实现它。请按照如下步骤：

1) 备份所有数据库并检验备份有效性（为保护数据所必须）。

2) 增加新的路径（新存储的新磁盘）到 asm_diskstring 以供 ASM 识别：

例如：

SQL> alter system set asm_diskstring = '/dev/emcpowerc*' , '/dev/emcpowerh*'; 

这里: '/dev/emcpowerc*' 是当前的磁盘。 
这里: '/dev/emcpowerh*' 是新的磁盘。

3) 确认新磁盘被 ASM 识别：

SQL> select path from v$asm_disk;

 

4) 使用下面文档中的方法验证所有新磁盘：
 

How To Add a New Disk(s) to An Existing Diskgroup on RAC Cluster or Standalone ASM Configuration (Best Practices). (Doc ID 557348.1)

  
5) 增加新磁盘到目标磁盘组：

SQL> alter diskgroup add disk 
‘’, 
‘’, 
‘’, 
‘’, 
. 
. 
. 
‘’ rebalance power <#>; 

6) 接下来等待重平衡操作完成：

SQL> select * from v$asm_operation; 
SQL> select * from gv$asm_operation;

7) 最后，移除旧磁盘：

SQL> alter diskgroup drop disk 
, 
, 
, 
, 
. 
. 
. 
  rebalance power <#>;

8) 接下来等待重平衡操作完成：

SQL> select * from v$asm_operation; 
SQL> select * from gv$asm_operation;

9) 至此，你您的 ASM 磁盘组和数据库已经迁移到了新的存储上面。

注: 或者，我们也可以按照如下命令，将加盘，删盘放在一个操作里执行，这种方式只会发生一次重平衡操作：

SQL> alter diskgroup  
add disk '', .., '' 
drop disk , , .., 
rebalance power <#>;

这样会比使用分开的命令（加盘和删盘语句）高效许多。

 

注1：因为在 10g 版本（如果驱逐磁盘时发生了某些错误，比如 hang）ASM 不会去自动重启重平衡操作（这个已经在 11g 和 12c 版本得到增强），所以需要做一个手工的重平衡操作。手工启动重平衡的命令如下：

SQL> alter diskgroup rebalance power 11;

  

 

注2：一旦 drop 磁盘发起的重平衡操作完成，来自旧的 SAN/磁盘阵列/DAS 中的磁盘最终要从磁盘组中驱逐出去，此时在 v$asm_disk 视图中这些磁盘的记录为 HEADER_STATUS = FORMER。

 

---

参考

NOTE:1918350.1 - Exact Steps to Migrate ASM Diskgroups to Another SAN/Disk-Array/DAS/Etc without Downtime (When ASMLIB Devices Are Involved)
NOTE:557348.1 - How To Add a New Disk(s) to An Existing Diskgroup on RAC Cluster or Standalone ASM Configuration (Best Practices).

----------------------------------------------

Oracle Database - Enterprise Edition - Version 10.2.0.1 to 12.1.0.2 [Release 10.2 to 12.1]
Oracle Database Cloud Schema Service - Version N/A and later
Oracle Database Exadata Cloud Machine - Version N/A and later
Oracle Cloud Infrastructure - Database Service - Version N/A and later
Oracle Database Exadata Express Cloud Service - Version N/A and later
Information in this document applies to any platform.

GOAL

 

The present document explains in detail the exact steps to migrate ASM diskgroups (using ASMLIB devices) from one SAN/Disk-Array/DAS/etc. to another SAN/Disk-Array/DAS/etc. without a downtime. This procedure will also work for diskgroups hosting OCR, Vote files and ASM spfiles.

 

Note: These steps are applicable to External, Normal & High redundancy diskgroups.

 

SOLUTION

 

If you need to migrate and to replace the current ASMLIB disks associated to your diskgroups to a new storage, then you can perform this operation without any downtime, therefore you can follow the next steps:

1) Backup all your databases and valid the backup (it is always required to protect your data).

 

2) Create new ASMLIB devices on the new storage physical disks as described in the following document/demo:

White Paper: ASMLIB Installation & Configuration On MultiPath Mapper Devices (Step by Step Demo) On RAC Or Standalone Configurations. (Doc ID 1594584.1)

Example:

2.1) Create the new ASMLIB disks using the “/etc/init.d/oracleasm createdisk” command as root OS user:
  

# /etc/init.d/oracleasm    createdisk       ASMDISK_NEW_SAN_1    /dev/mapper/mpathbp1
# /etc/init.d/oracleasm    createdisk       ASMDISK_NEW_SAN_2    /dev/mapper/mpathcp1
# /etc/init.d/oracleasm    createdisk       ASMDISK_NEW_SAN_3    /dev/mapper/mpathdp1
# /etc/init.d/oracleasm    createdisk       ASMDISK_NEW_SAN_4    /dev/mapper/mpathep1
# /etc/init.d/oracleasm    createdisk       ASMDISK_NEW_SAN_5    /dev/mapper/mpathfp1
# /etc/init.d/oracleasm    createdisk       ASMDISK_NEW_SAN_6    /dev/mapper/mpathgp1
# /etc/init.d/oracleasm    createdisk       ASMDISK_NEW_SAN_7    /dev/mapper/mpathhp1
# /etc/init.d/oracleasm    createdisk       ASMDISK_NEW_SAN_8    /dev/mapper/mpathip1
# /etc/init.d/oracleasm    createdisk       ASMDISK_NEW_SAN_9    /dev/mapper/mpathjp1
# /etc/init.d/oracleasm    createdisk       ASMDISK_NEW_SAN_10   /dev/mapper/mpathkp1

 
2.2) Scan the new ASMIB disks on all the other RAC nodes (on Standalone configurations the disks are implicitly scanned during the ASMLIB disk creation) as follows (as root OS user):

 

# /etc/init.d/oracleasm    scandisks

  
2.3) Make sure the new ASMLIB disks and old ASMLIB disks are present on all the RAC Cluster nodes or Standalone configurations as follows:
  

# /etc/init.d/oracleasm  listdisks

ASMDISK_NEW_SAN_1
ASMDISK_NEW_SAN_2
ASMDISK_NEW_SAN_3
ASMDISK_NEW_SAN_4
ASMDISK_NEW_SAN_5
ASMDISK_NEW_SAN_6
ASMDISK_NEW_SAN_7
ASMDISK_NEW_SAN_8
ASMDISK_NEW_SAN_9
ASMDISK_NEW_SAN_10

ASMDISK_OLD_SAN_1
ASMDISK_OLD_SAN_2
ASMDISK_OLD_SAN_3
ASMDISK_OLD_SAN_4
ASMDISK_OLD_SAN_5
ASMDISK_OLD_SAN_6
ASMDISK_OLD_SAN_7
ASMDISK_OLD_SAN_8
ASMDISK_OLD_SAN_9
ASMDISK_OLD_SAN_10

   

# /usr/sbin/oracleasm-discover 'ORCL:*'
Using ASMLib from /opt/oracle/extapi/64/asm/orcl/1/libasm.so
[ASM Library - Generic Linux, version 2.0.4 (KABI_V2)]

Discovered disk: ORCL:ASMDISK_NEW_SAN_1 [40017852 blocks (20489140224 bytes), maxio 512]
Discovered disk: ORCL:ASMDISK_NEW_SAN_2 [40017852 blocks (20489140224 bytes), maxio 512]
Discovered disk: ORCL:ASMDISK_NEW_SAN_3 [40017852 blocks (20489140224 bytes), maxio 512]
Discovered disk: ORCL:ASMDISK_NEW_SAN_4 [40017852 blocks (20489140224 bytes), maxio 512]
Discovered disk: ORCL:ASMDISK_NEW_SAN_5 [40017852 blocks (20489140224 bytes), maxio 512]
Discovered disk: ORCL:ASMDISK_NEW_SAN_6 [40017852 blocks (20489140224 bytes), maxio 512]
Discovered disk: ORCL:ASMDISK_NEW_SAN_7 [40017852 blocks (20489140224 bytes), maxio 512]
Discovered disk: ORCL:ASMDISK_NEW_SAN_8 [40017852 blocks (20489140224 bytes), maxio 512]
Discovered disk: ORCL:ASMDISK_NEW_SAN_9 [40017852 blocks (20489140224 bytes), maxio 512]
Discovered disk: ORCL:ASMDISK_NEW_SAN_10 [40017852 blocks (20489140224 bytes), maxio 512]


Discovered disk: ORCL:ASMDISK_OLD_SAN_1 [40017852 blocks (20489140224 bytes), maxio 512]
Discovered disk: ORCL:ASMDISK_OLD_SAN_2 [40017852 blocks (20489140224 bytes), maxio 512]
Discovered disk: ORCL:ASMDISK_OLD_SAN_3 [40017852 blocks (20489140224 bytes), maxio 512]
Discovered disk: ORCL:ASMDISK_OLD_SAN_4 [40017852 blocks (20489140224 bytes), maxio 512]
Discovered disk: ORCL:ASMDISK_OLD_SAN_5 [40017852 blocks (20489140224 bytes), maxio 512]
Discovered disk: ORCL:ASMDISK_OLD_SAN_6 [40017852 blocks (20489140224 bytes), maxio 512]
Discovered disk: ORCL:ASMDISK_OLD_SAN_7 [40017852 blocks (20489140224 bytes), maxio 512]
Discovered disk: ORCL:ASMDISK_OLD_SAN_8 [40017852 blocks (20489140224 bytes), maxio 512]
Discovered disk: ORCL:ASMDISK_OLD_SAN_9 [40017852 blocks (20489140224 bytes), maxio 512]
Discovered disk: ORCL:ASMDISK_OLD_SAN_10 [40017852 blocks (20489140224 bytes), maxio 512]

  

3) Verify the ASM discovery string (“ASM_DISKSTRING”) is correctly pointing to the ASMLIB devices (in all the ASM instances) as follows:

3.1) RAC Cluster configurations:

+ASM1 instance:
  

[grid@dbaasm ~]$ . oraenv
ORACLE_SID = [+ASM1] ? +ASM1
The Oracle base remains unchanged with value /u01/app/grid
[grid@dbaasm ~]$ sqlplus "/as sysasm"

SQL*Plus: Release 11.2.0.3.0 Production on Mon Aug 18 18:39:28 2014

Copyright (c) 1982, 2011, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Automatic Storage Management option

SQL> show parameter  ASM_DISKSTRING

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
asm_diskstring                       string      ORCL:*

  
+ASM2 instance:
  

[grid@dbaasm ~]$ . oraenv
ORACLE_SID = [+ASM2] ? +ASM2
The Oracle base remains unchanged with value /u01/app/grid
[grid@dbaasm ~]$ sqlplus "/as sysasm"

SQL*Plus: Release 11.2.0.3.0 Production on Mon Aug 18 18:39:28 2014

Copyright (c) 1982, 2011, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Automatic Storage Management option

SQL> show parameter  ASM_DISKSTRING

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
asm_diskstring                       string      ORCL:*

  
3.2) Standalone configurations:

+ASM1 instance:

 

[grid@dbaasm ~]$ . oraenv
ORACLE_SID = [+ASM] ? +ASM
The Oracle base remains unchanged with value /u01/app/grid
[grid@dbaasm ~]$ sqlplus "/as sysasm"

SQL*Plus: Release 11.2.0.3.0 Production on Mon Aug 18 18:39:28 2014

Copyright (c) 1982, 2011, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Automatic Storage Management option

SQL> show parameter  ASM_DISKSTRING

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
asm_diskstring                       string      ORCL:*

  

4) Then confirm that the new ASMLIB disks and old ASMLIB disks are being detected by ASM as follows:
  

ORACLE_SID = [+ASM] ? +ASM
The Oracle base remains unchanged with value /u01/app/grid
[grid@dbaasm ~]$ sqlplus "/as sysasm"

SQL*Plus: Release 11.2.0.3.0 Production on Mon Aug 18 18:39:28 2014

Copyright (c) 1982, 2011, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Automatic Storage Management option


SQL> select path from v$asm_disk;

PATH
--------------------------------------------------------------------------------
ORCL:ASMDISK_NEW_SAN_1
ORCL:ASMDISK_NEW_SAN_2
ORCL:ASMDISK_NEW_SAN_3
ORCL:ASMDISK_NEW_SAN_4
ORCL:ASMDISK_NEW_SAN_5
ORCL:ASMDISK_NEW_SAN_6
ORCL:ASMDISK_NEW_SAN_7
ORCL:ASMDISK_NEW_SAN_8
ORCL:ASMDISK_NEW_SAN_9
ORCL:ASMDISK_NEW_SAN_10

PATH
--------------------------------------------------------------------------------
ORCL:ASMDISK_OLD_SAN_1
ORCL:ASMDISK_OLD_SAN_2
ORCL:ASMDISK_OLD_SAN_3
ORCL:ASMDISK_OLD_SAN_4
ORCL:ASMDISK_OLD_SAN_5
ORCL:ASMDISK_OLD_SAN_6
ORCL:ASMDISK_OLD_SAN_7
ORCL:ASMDISK_OLD_SAN_8
ORCL:ASMDISK_OLD_SAN_9
ORCL:ASMDISK_OLD_SAN_10

10 rows selected.

  

5) Validate all the new disks as described in the following document:
 

How To Add a New Disk(s) to An Existing Diskgroup on RAC Cluster or Standalone ASM Configuration (Best Practices). (Doc ID 557348.1)

  

6) Add the new disks to your desired diskgroup as follows:

 

SQL> alter diskgroup  add disk
‘’,
‘’,
‘’,
‘’,
.
.
.
‘’ rebalance power <#>;

Example:

SQL> alter diskgroup DATA add disk
'ORCL:ASMDISK_NEW_SAN_1',
'ORCL:ASMDISK_NEW_SAN_2',
'ORCL:ASMDISK_NEW_SAN_3',
'ORCL:ASMDISK_NEW_SAN_4',
'ORCL:ASMDISK_NEW_SAN_5',
'ORCL:ASMDISK_NEW_SAN_6',
'ORCL:ASMDISK_NEW_SAN_7',
'ORCL:ASMDISK_NEW_SAN_8',
'ORCL:ASMDISK_NEW_SAN_9',
'ORCL:ASMDISK_NEW_SAN_10'  rebalance power 11;

6) Then wait until the rebalance operation completes:

 

SQL> select * from v$asm_operation;

no rows selected

SQL> select * from gv$asm_operation;

no rows selected

 

7) Finally, remove the old disks:

SQL> alter diskgroup  drop disk
,
,
,
,
.
.
.
  rebalance power <#>;

Example:

SQL> alter diskgroup DATA drop disk
ASMDISK_OLD_SAN_1,
ASMDISK_OLD_SAN_2,
ASMDISK_OLD_SAN_3,
ASMDISK_OLD_SAN_4,
ASMDISK_OLD_SAN_5,
ASMDISK_OLD_SAN_6,
ASMDISK_OLD_SAN_7,
ASMDISK_OLD_SAN_8,
ASMDISK_OLD_SAN_9,
ASMDISK_OLD_SAN_10  rebalance power 11;

8) Then wait until the rebalance operation completes:

SQL> select * from v$asm_operation;

no rows selected

SQL> select * from gv$asm_operation;

no rows selected

9) After the old disks are completely expelled from the diskgroup(s), then your ASM diskgroup(s) and database(s) have been migrated to the new storage.
 

Note 1: Alternatively, we can execute add disk & drop disk statements in one operation, in that way only one rebalance operation will be started as follow:

SQL> alter diskgroup 
add disk '', .., ''
drop disk , , ..,  rebalance power <#>;

  
Example:

alter diskgroup DATA add disk
'ORCL:ASMDISK_NEW_SAN_1',
'ORCL:ASMDISK_NEW_SAN_2',
'ORCL:ASMDISK_NEW_SAN_3',
'ORCL:ASMDISK_NEW_SAN_4',
'ORCL:ASMDISK_NEW_SAN_5',
'ORCL:ASMDISK_NEW_SAN_6',
'ORCL:ASMDISK_NEW_SAN_7',
'ORCL:ASMDISK_NEW_SAN_8',
'ORCL:ASMDISK_NEW_SAN_9',
'ORCL:ASMDISK_NEW_SAN_10'  
drop disk
ASMDISK_OLD_SAN_1,
ASMDISK_OLD_SAN_2,
ASMDISK_OLD_SAN_3,
ASMDISK_OLD_SAN_4,
ASMDISK_OLD_SAN_5,
ASMDISK_OLD_SAN_6,
ASMDISK_OLD_SAN_7,
ASMDISK_OLD_SAN_8,
ASMDISK_OLD_SAN_9,
ASMDISK_OLD_SAN_10  rebalance power 11;

  

This is more efficient than separated commands (add disk & drop disk statements).

Then wait until the rebalance operation completes:
  

SQL> select * from v$asm_operation;

no rows selected

SQL> select * from gv$asm_operation;

no rows selected

  

 

Note 2:  As a best practice, never execute the “/etc/init.d/oracleasm deletedisk” command on active ASMLIB disks (those which are currently being used by ASM diskgroups as disks members).

 

Note 3:  As a best practice, never execute the “/etc/init.d/oracleasm createdisk” command on active ASMLIB disks (those which are currently being used by ASM diskgroups as disks members).

 

Note 4:  Never remove/format/modify/overlap/resize (at OS level or hardware) the physical associated disk until the corresponding logical ASMLIB/ASM disk is completely dropped and expelled from the ASM diskgroup (in other words, until the rebalance operation completes).

 

Note 5: On 10g, a manual rebalance operation is required to restart the diskgroup rebalance and expel the disk(s) because on 10g (if something wrong happens on disk expelling, e.g. hanging) ASM will not restart the ASM rebalance automatically (this was already enhanced on 11g and 12c), therefore you will need to restart a manual rebalance operation as follows:

SQL> alter diskgroup rebalance power 11;