How To Add Back An ASM Disk When The DISK_REPAIR_TIME Attribute Expired

How To Add Back An ASM Disk or Failgroup (Normal or High Redundancy) After A Transient Failure Occurred Or When The DISK_REPAIR_TIME Attribute Expired (10.1 to 12.1)? (文档 ID 946213.1)

转到底部

---

In this Document Goal   Ask Questions, Get Help, And Share Your Experiences With This Article Solution   Community Discussions References APPLIES TO: Oracle Database - Enterprise Edition - Version 10.2.0.1 to 12.1.0.2 [Release 10.2 to 12.1] Information in this document applies to any platform. GOAL The present document describes how to add back an ASM disk or entire failgroup (on Normal or High Redundancy diskgroups) after a Transient Failure occurred on release10.1 & 10.2 or  when the DISK_REPAIR_TIME attribute has expired (11.1, 11.2 or 12c). Ask Questions, Get Help, And Share Your Experiences With This Article Would you like to explore this topic further with other Oracle Customers, Oracle Employees, and Industry Experts? Click here to join the discussion where you can ask questions, get help from others, and share your experiences with this specific article. Discover discussions about other articles and helpful subjects by clicking here to access the main My Oracle Support Community page for Database Install/Upgrade.   SOLUTION In Oracle Database 10g, restoring the redundancy of all extents in the diskgroup following a disk failure is a relatively costly operation. This can be especially expensive in the case of transient errors, which can include cable disconnections, host bus adapter or controller failures, or even disk power interruptions, which cause the entire failure group to be dropped. Additionally, a transient failure of the storage interconnect between sites would appear as a failure of an entire failure group. When an ASM disk fails, the ASM disk is taken offline and dropped.  If the ASM diskgroup is created with two failure groups, the loss of one entire failure group is tolerated with no downtime.  The diskgroup continues to operate normally, allocating space in the one surviving failure group. The failed disks show up in V$ASM_DISK twice (as of 10.1.0.4): once as missing and candidate statuses for HEADER_STATUS and STATE, respectively, and another as offline hung. The reason that you have missing, candidate, and offline hung disks is that you have had a failure group crash, and an insufficient number of surviving failure groups exists to complete a rebalance successfully to restore the contents from the failed disks. The offline hung entries in V$ASM_DISK essentially track the fact that there are extents whose redundancy has not yet been restored.  To restore the disks to a normal status, you need to add back the missing disks. To add the disks back, you must specify the FORCE flag, as in the following example, because they still have their old disk headers: SQL> ALTER DISKGROUP DATA ADD FAILGROUP SAN2 DISK  '/dev/rdsk/c3t19d3s4' FORCE,'/dev/rdsk/c3t19d4s4' FORCE,  '/dev/rdsk/c3t19d5s4' FORCE, '/dev/rdsk/c3t19d6s4' FORCE REBALANCE POWER <power number 1-11>;   When adding back the disks, be sure to specify the previously used failure group name. Adding these disks initiates a rebalance. Once the rebalance completes from adding back the disks from the failed failure group, the offline hung entries should go away.  In cases where it is appropriate, you can also use a disk add pattern such as ’/dev/rdsk/c*’; just make sure that you have the right pattern for the disks you are adding and the appropriate failure group name.  The following are some points to consider when adding back disks into the failgroup:  =)> Make sure to add the disk back using the same failure group as before the storage failure.  =)> If upon disk failure the disk to be added back to the failgroup has been physically replaced, then the ASM disk header no longer exists. In this case, the disk cannot be added back to the failgroup using the FORCE option; it must be added using the standard add disk command: SQL> ALTER DISKGROUP DATA ADD FAILGROUP SAN2 DISK '/dev/rdsk/c3t13d3s4' REBALANCE POWER <power number 1-11>; =)> If you are providing a disk name when adding back to the failgroup, ensure that the disk name is different from the previous disk name. Currently, ASM does not support adding a disk back using the same disk name in the diskgroup. It is a best practice to let ASM generate a new disk name for you. If you are using ASMLIB, the default name is provided by the ASMLIB disk name stamped by oracleasm. In such cases, the user must explicitly specify a new disk name as part of the add disk.  When disks are added back to reform a second failure group, the rebalance restores redundancy and the hung disks are dropped. Note that adding back an insufficient number of disks can result in the diskgroup running out of space during rebalance. The added storage must be of sufficient capacity to hold a copy of all the data allocated in the surviving failure group. It is also possible to get in a similar state if all but a few disks in a failure group fail. For example, if there are 10 disks in each failure group and 9 of them fail in one failure group, the surviving disk is unlikely to have the capacity to hold a copy of every extent, so the rebalance runs out of space. The easy way to avoid this circumstance is to drop force the one surviving disk.   Note: 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 <diskgroup name> rebalance power 11;          Community Discussions Still have questions? Use the communities window below to search for similar discussions or start a new discussion on this subject. (Window is the live community not a screenshot) Click here to open in main browser window

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/21980353/viewspace-1878137/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/21980353/viewspace-1878137/