【Oracle ASM】被drop掉的ASM Disk/Diskgroup可能仍有进程未释放

Comments

2 responses to “【Oracle ASM】被drop掉的ASM Disk/Diskgroup可能仍有进程未释放”

1. 

   Ask_Maclean_liu_Oracle

   September 9, 2013

   有一个SR里提了一个偏门的方法 是对 drop的DISK建一个临时diskgroup 然后drop 这个diskgroup ，不过不太推荐。The bug # 7225720 should be included in your 11.2 version.Also, there is a workaround of creating a dummy diskgroup. And when it is dropped, the file descriptors should be gone.Or, bouncing the ASM instance.Is the database 11.2 as well as the ASM? Since the patch #7225720 must be on both the database and ASM homes.Can you please upload the ASM alert.logs and the database alert.log.As we discussed, this will most likely require testing and a bug.In the interim, the following information exists in Note #429296.1 (Internal note), explaining this condition. And suggests that you may want to also utilize ASMLIB for your disks;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 DISKGROUPSolution————-When use of a datafile by Oracle is “completed” by any of the above mentionedmethods … There is no mechanism within Oracle to force all sessions holdinga handle on the “completed” file to release that handleAfter long detailed discussion with development it was determined that there are only twomethods that can provide a consistant release / close of file handle / descriptors: * via the implementation of ASMLIB (if using ASM) * via the impementation of ODMLIBODMLIB’s are written by third party software vendors like VeritasASMLIB’s are written by operating system vendors and as suchcannot be provided by Oracle except in the case of Linux as we provide Linuxsupport and have access to the source code.The only ‘manual’ method that will force the release of all file handles would be to close all processes that havethat handle heldThis means all Oracle sessions in all instances and ifclustered on all boxes … that are holding that handleThe problem arises in determining which sessions hold the handle. The ‘lsof’ command can beused to determine which processes have open file handles and then it may be possible to track thisback to database processes which if it is not a vital process (background processes are for the most part)it could be killed. Perhaps, the following note can help:Article-ID: Note 787780.1Circulation: PUBLISHED (EXTERNAL)Title: Open Files/Open File DescriptorsIf this does not release the handle then shutting down all suspect instances is theonly solution === ODM Research ===Article-ID: Note 883028.1Circulation: PUBLISHED (EXTERNAL)Title: New Background Processes introduced by ACFSArticle-ID: Note 402526.1Circulation: PUBLISHED (EXTERNAL)Title: Asm Devices Are Still Held Open After Dismount or DropArticle-ID: Note 787780.1Circulation: PUBLISHED (EXTERNAL)Title: Open Files/Open File DescriptorsArticle-ID: Note 429296.1Circulation: MODERATED (EXTERNAL)Title: Why aren’t file handles closed in all processes when Oracle stops using a file? ASMCMD> lsdsk -kp /dev/raw/raw21(nothing)[oracle@devrac1b ~]$ /usr/sbin/lsof | grep raw21oracle 15114 oracle 12u CHR 162,21 25309 /dev/raw/raw21oracle 15150 oracle 12u CHR 162,21 25309 /dev/raw/raw21oracle 18752 oracle 77u CHR 162,21 25309 /dev/raw/raw21oracle 18754 oracle 51u CHR 162,21 25309 /dev/raw/raw21oracle 18760 oracle 53u CHR 162,21 25309 /dev/raw/raw21oracle 18762 oracle 78u CHR 162,21 25309 /dev/raw/raw21[oracle@devrac1b ~]$ ps -ef | grep 15114oracle 2586 15351 0 15:29 pts/2 00:00:00 grep 15114oracle 15114 1 0 May11 ? 00:00:00 oracleivrdvl2 (LOCAL=NO)[oracle@devrac1b ~]$ ps -ef | grep 15150oracle 3493 15351 0 15:29 pts/2 00:00:00 grep 15150oracle 15150 1 0 May11 ? 00:00:00 oracleivrtst2 (LOCAL=NO)[oracle@devrac1b ~]$ ps -ef | grep 18752oracle 3536 15351 0 15:29 pts/2 00:00:00 grep 18752oracle 18752 1 0 May11 ? 00:00:00 asm_dbw0_+ASM2[oracle@devrac1b ~]$ ps -ef | grep 18754oracle 3681 15351 0 15:30 pts/2 00:00:00 grep 18754oracle 18754 1 0 May11 ? 00:00:00 asm_lgwr_+ASM2[oracle@devrac1b ~]$ ps -ef | grep 18760oracle 4538 15351 0 15:30 pts/2 00:00:00 grep 18760oracle 18760 1 0 May11 ? 00:08:53 asm_rbal_+ASM2[oracle@devrac1b ~]$ ps -ef | grep 18762oracle 4726 15351 0 15:30 pts/2 00:00:00 grep 18762oracle 18762 1 0 May11 ? 00:00:00 asm_gmon_+ASM2### STEPS TO REPRODUCE ###SQL>alter diskgroup drop disk$lsof Hdr: 7225720 10.2.0.4 RDBMS 10.2.0.4 ASM PRODID-5 PORTID-197 4693355Abstract: ASM DOES NOT CLOSE OPEN DESCRIPTORS EVEN AFTER APPLYING THE PATCH 4693355Fixed-Releases: A2041 A205 B1071 B201 PATCH:A204.RECRAC.2 PATCH:B107.RECRAC.1Article-ID: Note 7225720.8Circulation: PUBLISHED (EXTERNAL)Title: Bug 7225720 – ASM does not close open descriptors

   Reply
2. 

   Ask_Maclean_liu_Oracle

   September 16, 2013

   oradebug call close 可以用来强制释放文件句柄，但是注意 直接使用该系统调用是绕过 OPI 的，可能造成后续的未知问题，不是理想的解决方案

   Reply