Oracle background processes still use and lock the dropped ASM disks and these disks can not be removed and assigned to another server without restart

http://uralural.blogspot.com/2010/02/oracle-background-processes-still-use.html

Asm Devices Are Still Held Open After Dismount or Drop [ID 402526.1]

Applies to:

Oracle Server - Enterprise Edition - Version: 10.1.0.2 to 11.1.0.7 - Release: 10.1 to 11.1
Information in this document applies to any platform.

Goal

Why are the ASM devices still opened by Oracle foreground and background processes even after they have been dropped or dismounted?

Solution

This behavior, despite what it might look, is not an Oracle software problem.
Actually, when a disk is dropped or dismounted, this action is signalled to all the processes in a similar manner to the situation when a tablespace is dropped. If those processes are active, they release the file handle immediately. If the processes are idle, they have to become active to release the file handle.
The thing that comes closer to such a situation is killing an idle session. The shadow process would stay forever in the system if not killed at OS level or if the client application does not attempt a new operation.
As such, when an ASM disk is dropped, there would be probably more than one process still holding handles on it. The background processes, which are quite active, would quickly release the handle. The foreground processes that are active would do the same. Unfortunately, the idle processes that have an open handle, don't do anything, so they don't get to run the handle release instructions. These processes should either be killed at OS level or forced to perform something in the database (note that they can be ASM or main instance processes).
This issue is addressed in several known issues:
Bug 7225720 ASM DOES NOT CLOSE OPEN DESCRIPTORS EVEN AFTER APPLYING THE PATCH 4693355
The 7225720 fix is implemented in releases 10.2.0.5,11.1.0.7,11.2 (Note 4693355.8)
For bug fixes on currently supported releases, please file backport requests for the specific Oracle release and OS version.
BUG 11785938 ASM 11.2.0.2 IS NOT RELEASING FILE DESCRIPTORS AFTER DROP DISKGROUP
This is fixed in 11.2.0.3, patches can be requested for the supported releases.

References

BUG:4642808 - ASM DOES NOT CLOSE FILE HANDLE ON DROPPED DISKGROUP
BUG:5665537 - ASM KEEPS THE DEVICE OPEN EVEN WHEN THE DISKGROUP HAS BEEN DISMOUNTED
BUG:5687341 - COMMAND TO RELEASE DROPPED OR DISMOUNTED ASM DISK LOCKS.
BUG:7225720 - ASM DOES NOT CLOSE OPEN DESCRIPTORS EVEN AFTER APPLYING THE PATCH 4693355
NOTE:4693355.8 - Bug 4693355 - ASM does not close open descriptors even after DROP DISKGROUP




Why aren't file handles closed in all processes when Oracle stops using a file? [ID 429296.1]

Applies to:

Oracle Server - Enterprise Edition - Version: 10.2.0.1.0 to 11.1
Information in this document applies to any platform.

Goal

Why aren't file handles closed in all processes when Oracle stops using a file?

Stopping use can be due to several reasons:

    * Dropping a tablespace
    * In ASM ... an ALTER DISKGROUP ... DROP DISK
    * In ASM ... a DROP DISKGROUP

Solution

When use of a datafile by Oracle is "completed" by any of the above mentioned methods ... There is no
mechanism within Oracle to force all sessions holding a handle on the "completed" file to release that handle

After long detailed discussion with development it was determined that there are only two methods that can provide a consistant release / close of file handle / descriptors:

   * via the implementation of ASMLIB (if using ASM)
   * via the impementation of ODMLIB
ODMLIB's are written by third party software vendors like Veritas

ASMLIB's are written by operating system vendors and as such cannot be provided by Oracle except in the case of Linux as we provide Linux support and have access to the source code
The only 'manual' method that will force the release of all file handles would be to closes all processes that have that handle held

This means all Oracle sessions in all instances and if clustered on all boxes ... that are holding that handle

The problem arises in determining which sessions hold the handle. The 'lsof' command can be used to determine which processes have open file handles and then it may be possible to track this back to database processes which if it is not a vital process (background processes are for the most part) it could be killed.  If this does not release the handle then shutting down all suspect instances is the only solution
NOTE: This now fixed in 10.2.0.5 and 11.2 and a request for a fix for 11.1.0.8 has been filed
   Bug 4693355 ASM DOES NOT CLOSE OPEN DESCRIPTORS EVEN AFTER DROP DISKGROUP (Internal only bug)