Re: ASM disk to physical disk mapping
From: Dan <daniel.ostertag_at_visaer.com>
Date: Wed, 1 Jul 2009 14:34:13 -0700 (PDT)
Message-ID: <9fa003ba-d9e3-4ad5-8421-d0c76cce5df8_at_z14g2000yqa.googlegroups.com>
On Jul 1, 3:03 pm, John Hurley <johnbhur..._at_sbcglobal.net> wrote:
> On Jul 1, 1:16 pm, Dan <daniel.oster..._at_visaer.com> wrote:
>
> snip
>
> > 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.
>
> 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.
Date: Wed, 1 Jul 2009 14:34:13 -0700 (PDT)
Message-ID: <9fa003ba-d9e3-4ad5-8421-d0c76cce5df8_at_z14g2000yqa.googlegroups.com>
On Jul 1, 3:03 pm, John Hurley <johnbhur..._at_sbcglobal.net> wrote:
> On Jul 1, 1:16 pm, Dan <daniel.oster..._at_visaer.com> wrote:
>
> snip
>
> > 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.
>
> 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.
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. Received on Wed Jul 01 2009 - 16:34:13 CDT