Does anyone know how to map an ASM disk that I can see in OEM to its
physical drive? I have a disk that is throwing errors via my hardware
diagnostic (but no errors yet in Oracle). I would like to identify it
in ASM, remove it and rebalance off of it. I know and can see the
exact physical disk that is bad, yet I cannot definitively identify
what ASM disk maps to that physical disk.

Is there a tool to do this?

For example, my bad disk is disk 1:11 - on Channel 1, Target ID 11,
Lun 0. I have 3 disk arrays of 14 disks each, channel 0 and 1 on one
controller, channel 0 on another controller. But in my Windows
environment when I use Disk Management, I see two disks with Target ID
11, Lun 0. I'm not sure which is the culprit.



Thanks.

Dan

On Jul 1, 11:55*am, Dan <daniel.oster... (AT) visaer (DOT) com> wrote:
Do you have your create diskgroup statements around? You can look at
those ... or do some querying against the ASM views.

On Jul 1, 12:08*pm, John Hurley <johnbhur... (AT) sbcglobal (DOT) net> wrote:
I checked the views and they give only what I can see in OEM.
Unfortunately I don't have the create diskgroup statements because I
stamped and added them to the diskgroup via asmtoolg, a gui-like tool
that does all the work for you (another reason to do things
yourself). I'm still researching this, I'll let you know what I
find. I've seen others that lament this difficulty too, so I guess
it's a known problem.

On Jul 1, 1:16*pm, Dan <daniel.oster... (AT) visaer (DOT) com> wrote:

snip

Don't forget that asm has an alert log file and ( well depending on
how long ago they occurred ) many important things that occur to an
asm instance ( like creating / mounting / etc diskgroups ) will show
up in that alert log.

....

SQL> alter diskgroup prod_dg1 mount
WARNING: Deprecated privilege SYSDBA for command 'ALTER DISKGROUP
MOUNT'
NOTE: cache registered group PROD_DG1 number=1 incarn=0xd954fd6e
NOTE: cache began mount (first) of group PROD_DG1 number=1
incarn=0xd954fd6e
WARNING::ASMLIB library not found. See trace file for details.
NOTE: Assigning number (1,1) to disk (/storage/prod_dg1/disk2)
NOTE: Assigning number (1,2) to disk (/storage/prod_dg1/disk3)
NOTE: Assigning number (1,3) to disk (/storage/prod_dg1/disk4)
NOTE: Assigning number (1,0) to disk (/storage/prod_dg1/disk1)
NOTE: start heartbeating (grp 1)
kfdp_query(): 3
kfdp_queryBg(): 3
NOTE: cache opening disk 0 of grp 1: PROD_DG1_0000 path:/storage/
prod_dg1/disk1
NOTE: F1X0 found on disk 0 fcn 0.0
NOTE: cache opening disk 1 of grp 1: PROD_DG1_0001 path:/storage/
prod_dg1/disk2
NOTE: cache opening disk 2 of grp 1: PROD_DG1_0002 path:/storage/
prod_dg1/disk3
NOTE: cache opening disk 3 of grp 1: PROD_DG1_0003 path:/storage/
prod_dg1/disk4
NOTE: cache mounting (first) group 1/0xD954FD6E (PROD_DG1)
NOTE: cache recovered group 1 to fcn 0.129503
NOTE: LGWR attempting to mount thread 1 for diskgroup 1
NOTE: LGWR mounted thread 1 for disk group 1
NOTE: opening chunk 1 at fcn 0.129503 ABA
NOTE: seq=51 blk=6183
NOTE: cache mounting group 1/0xD954FD6E (PROD_DG1) succeeded
NOTE: cache ending mount (success) of group PROD_DG1 number=1
incarn=0xd954fd6e
kfdp_query(): 4
kfdp_queryBg(): 4
NOTE: Instance updated compatible.asm to 10.1.0.0.0 for grp 1
SUCCESS: diskgroup PROD_DG1 was mounted
SUCCESS: alter diskgroup prod_dg1 mount

....

My output may look a little funny as we are running EMC powerpath on
linux and it generates some strange names for devices ( /dev/
emcpower* ) ... I use symbolic links from a directory structure /
storage/asm_diskgroup_name to point to the emc power path devices to
make it more clear what is being used where.

On Jul 1, 3:03*pm, John Hurley <johnbhur... (AT) sbcglobal (DOT) net> wrote:
That was a good suggestion which I hadn't thought of. I just checked
though and it has the same configuration labels that I get in the
other utilities. Somehow I need to associate the disk with the LUN
number and Target ID. This is so low level that it doesn't seem to
have a link.

I guess what I could do is go up to the array and pull the bad disk
out. I had wanted to logically remove the disk from ASM, but if I
simulate a single disk failure by just yanking it out, it should be
okay, right? The ASM will remove the disk automatically.

On Jul 2, 1:34*am, Dan <daniel.oster... (AT) visaer (DOT) com> wrote:
Depends on ASM version and patchset level: some early releases didn't
handle such failures all too well, so I'd do this as a last resort.
What does

SELECT
disk_number
,mount_status
,header_status
,mode_status,
,state
,label -- disk label (don't confuse with ASM disk name)
,path -- OS path to the disk - what you are looking for
,udid -- Universal Device ID of the disk - might help, too
FROM V$ASM_DISK, D, V$ASM_DISKGROUP G
WHERE G.GROUP_NUMBER=D.GROUP_NUMBER
AND G.NAME='YOUR_DISK_GROUP_NAME'
-- optionally restrict the query to show only
-- currently mounted members of the DG
-- AND (D.MOUNT_STATUS='CACHED' OR D.MOUNT_STATUS='OPENED')
-- AND D.HEADER_STATUS='MEMBER'

show when executed in the ASM instance? Never dealt with ASM on
Windows, so not sure if this will give you the information you need,
but worth a try anyway. Note that you need to run this in ASM
instance, not in the Oracle instance connected to this ASM instance.

Hth,
Vladimir M. Zakharychev
N-Networks, makers of Dynamic PSP(tm)
http://www.dynamicpsp.com