Solved Problem When ASM Queries on v$asm_disk Hang / Block
Wenn trying to display ASM information, Oracle Cloud Control (Enterprise Manager) displays nothing.
Also when trying to perform some queries on ASM, they "hang" and no answer is returned.
(For example: SELECT * FROM v$asm_disk; hangs)
Commands with the ASM tool asmcmdh still work:
oracle@<Host>:~/ [+ASM] asmcmdh
ASMCMD> lsdsk -p
Group_Num Disk_Num Incarn Mount_Stat Header_Stat Mode_Stat State Path
1 0 2526484498 CACHED MEMBER ONLINE NORMAL /dev/ASM/grid
2 6 2526484516 CACHED MEMBER ONLINE NORMAL /dev/ASM/u01_07
2 7 2526484517 CACHED MEMBER ONLINE NORMAL /dev/ASM/u01_08
2 8 2526484518 CACHED MEMBER ONLINE NORMAL /dev/ASM/u01_09
2 9 2526484519 CACHED MEMBER ONLINE NORMAL /dev/ASM/u01_10
3 0 2526484503 CACHED MEMBER ONLINE NORMAL /dev/ASM/u02_01
3 1 2526484505 CACHED MEMBER ONLINE NORMAL /dev/ASM/u02_02
3 2 2526484504 CACHED MEMBER ONLINE NORMAL /dev/ASM/u02_03
3 3 2526484507 CACHED MEMBER ONLINE NORMAL /dev/ASM/u02_04
3 4 2526484506 CACHED MEMBER ONLINE NORMAL /dev/ASM/u02_05
The Metalink Doc ID 8786114.8 suggests to verify / correct the ASM discovery string in order to exclude "invalid devices"
like /dev/kmem or other devices that should not be scanned by the ASM disk discovery.
For example it suggests not to use /dev/* as an ASM disk discovery string.
Querying the DB for the ASM disk discovery string, returns:
SQL> show parameter asm_diskstring
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
asm_diskstring string /dev/ASM
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
asm_diskstring string /dev/ASM
Listing the mount points using the result from above, shows that still some mount points exits (highlighted)
that are not valid any more. (i.e. no storage is mounted on these mount points any more)
(These are not listed be the asmcmdh command from above.)
(This is not directly apparent from the result below. But I knew, that nothing was mounted at these mount points any more.)
oracle@<Host>:~/ [+ASM] ll /dev/ASM*
total 0
drwxr-xr-x 2 root root 360 Jan 24 10:29 .
drwxr-xr-x 12 root root 3660 Mar 26 15:47 ..
lrwxrwxrwx 1 root root 7 Apr 18 2013 grid -> ../xvdf
lrwxrwxrwx 1 root root 7 Apr 18 2013 u01_01 -> ../xvdb
lrwxrwxrwx 1 root root 7 Apr 18 2013 u01_02 -> ../xvdc
lrwxrwxrwx 1 root root 7 Apr 18 2013 u01_03 -> ../xvdd
lrwxrwxrwx 1 root root 7 Apr 18 2013 u01_04 -> ../xvde
lrwxrwxrwx 1 root root 7 Oct 4 2013 u01_05 -> ../xvdllrwxrwxrwx 1 root root 7 Oct 4 2013 u01_06 -> ../xvdm
lrwxrwxrwx 1 root root 7 Jan 24 10:29 u01_07 -> ../xvdn
lrwxrwxrwx 1 root root 7 Jan 24 10:29 u01_08 -> ../xvdo
lrwxrwxrwx 1 root root 7 Jan 24 10:29 u01_09 -> ../xvdp
lrwxrwxrwx 1 root root 7 Jan 24 10:29 u01_10 -> ../xvdq
lrwxrwxrwx 1 root root 7 Apr 18 2013 u02_01 -> ../xvdg
lrwxrwxrwx 1 root root 7 Apr 18 2013 u02_02 -> ../xvdh
lrwxrwxrwx 1 root root 7 Apr 18 2013 u02_03 -> ../xvdi
lrwxrwxrwx 1 root root 7 Apr 18 2013 u02_04 -> ../xvdj
lrwxrwxrwx 1 root root 7 Apr 18 2013 u02_05 -> ../xvdk
drwxr-xr-x 2 root root 360 Jan 24 10:29 .
drwxr-xr-x 12 root root 3660 Mar 26 15:47 ..
lrwxrwxrwx 1 root root 7 Apr 18 2013 grid -> ../xvdf
lrwxrwxrwx 1 root root 7 Apr 18 2013 u01_01 -> ../xvdb
lrwxrwxrwx 1 root root 7 Apr 18 2013 u01_02 -> ../xvdc
lrwxrwxrwx 1 root root 7 Apr 18 2013 u01_03 -> ../xvdd
lrwxrwxrwx 1 root root 7 Apr 18 2013 u01_04 -> ../xvde
lrwxrwxrwx 1 root root 7 Oct 4 2013 u01_05 -> ../xvdllrwxrwxrwx 1 root root 7 Oct 4 2013 u01_06 -> ../xvdm
lrwxrwxrwx 1 root root 7 Jan 24 10:29 u01_07 -> ../xvdn
lrwxrwxrwx 1 root root 7 Jan 24 10:29 u01_08 -> ../xvdo
lrwxrwxrwx 1 root root 7 Jan 24 10:29 u01_09 -> ../xvdp
lrwxrwxrwx 1 root root 7 Jan 24 10:29 u01_10 -> ../xvdq
lrwxrwxrwx 1 root root 7 Apr 18 2013 u02_01 -> ../xvdg
lrwxrwxrwx 1 root root 7 Apr 18 2013 u02_02 -> ../xvdh
lrwxrwxrwx 1 root root 7 Apr 18 2013 u02_03 -> ../xvdi
lrwxrwxrwx 1 root root 7 Apr 18 2013 u02_04 -> ../xvdj
lrwxrwxrwx 1 root root 7 Apr 18 2013 u02_05 -> ../xvdk
Problem Cause
As described in the Metalink-Article from above, the SQL statement and Cloud Control hang,
because the statement tried to query inexistent LUNs with a very long timeout.
Solution
In my case, the solution was to remove the old (invalid) mount points.
I did not need to change the ASM disk discovery string.
Tags: Oracle, ASM, Problems&Solutions, LUN, Hang, blockiert, Publish
May 06, 2014 at 09:21AM
No comments :
Post a Comment