Oracle ASM and changing disk device files

[Duncan Edmonstone]

Hi all,

I've done plenty of SAN migrations in the past, which have involved a set of disk device file IDs changing - for LVM or VxVM thats a nice easy vgexport/vgimport or deport/import. However I'm not sure how Oracle ASM will handle these sort of changes - reading the docs on ASM it kind of implies that ASM just scans all available disks when the ASM instance starts and starts up all the disk groups it finds or all those mentioned in its instance parameter file. However I'm not in a position to test this, so I'm interested in other peoples experience... what happens to ASM when raw disk device files change? Does it handle it transparently (obviously I stop ASM for the migration) or are there some additional ASM tasks to perform?

Thanks

Duncan

[D Block 2]

Duncan,
one tought would be to add the New SAN devices to the ASM disks. Then you can force ASM to do the migration behind the scenes. Yes, I've heard that you can then remove the old devices, thus allowing the new devices to be left in the ASM disks. This sounds real simple, but it works.

[Duncan Edmonstone]

Tom, I see what you mean, but in this case its not possible to do that... I simplified things to try and get a simple answer, but maybe I should have actually explained - the oracle ASM instance will be on 1 EMC disk array, and then SRDF'd to another EMC disk array - obviously the replicated disk devices seen on the other disk array will have different device files, so I'm wondering what will happen when ASM is started - will it just scan all the disks, look at the headers and activate the disk groups anyway? or do I somehow need to tell ASM about the new disk device files?

Thanks,

Duncan

[Jean-Luc Oudart]

Hi Duncan,

Is this document any help for you?

http://www.oracle.com/technology/products/database/asm/pdf/asm-on-emc-5_3.pdf

Regards
Jean-Luc

[Duncan Edmonstone]

Yes it was, I read it earlier in the week and it does seem to indicate that I don't need to do anything special, but it doesn't state it *explicitly*.

Thx

Duncan

[D Block 2]

Duncan,

ASM at the host level, owns the disk devices (oracle user only, not root). This set of disks known as the ASM Disk Grp is managed by the DBAs. The DBAs can add to this Disk Grp or Shrink this Disk Grp via ASM. (BTW, I thought your first question was about migration to another Array, which ASM can do; DBA adds devices to the ASM Disk Grp, then can remove the older devices, which starts the migration, a great feature of ASM to utilize.)

I really think this ASM Disk Group is unlike anything to do with LVM terminology or thinking. So, it really up to the DBAs.

The DBA tells ASM about the new disk devices to be added or removed. Also, it's a fact that if you run SAM, it changes "owner" from oracle to "root" on these devices, which causes ASM not to work properly. So, best list these devices and force a chown oracle:oninstall to these devices, at times, if needed.

sorry I can't help which much details, but here's a starting link for you:
http://www.oracle.com/technology/oramag/webcolumns/2003/techarticles/murphy_asm.html

[Bob_Vance]

I use symbolic links.
That way, the device names, as far as ASM is concerned, do not change.

h1 ## ll -l /dev/oracle
... lrwxr-xr-x 1 root sys 16 Mar 21 10:59 ASM1 -> /dev/rdsk/c4t0d5
... lrwxr-xr-x 1 root sys 16 Mar 21 10:59 ASM2 -> /dev/rdsk/c4t0d6
... lrwxrwxrwx 1 root sys 16 Mar 21 13:50 rawCSSVotingDisk -> /dev/rdsk/c4t0d2
... lrwxrwxrwx 1 root sys 16 Mar 21 13:50 rawOCR_File -> /dev/rdsk/c4t0d4
h2 ## ll -l /dev/oracle
... lrwxr-xr-x 1 root sys 16 Mar 20 12:16 ASM1 -> /dev/rdsk/c6t0d5
... lrwxr-xr-x 1 root sys 16 Mar 20 12:16 ASM2 -> /dev/rdsk/c6t0d6
... lrwxrwxrwx 1 root sys 16 Mar 21 13:51 rawCSSVotingDisk -> /dev/rdsk/c6t0d2
... lrwxrwxrwx 1 root sys 16 Mar 21 13:51 rawOCR_File -> /dev/rdsk/c6t0d4

In ASM, I told it to use /dev/oracle/ASM*


hth
bv

[Duncan Edmonstone]

Thanks, I was considering using symbolic links, but I was concerned about what this would do with regards to asynchronous IO - if it doesn't appear to effect that in any way, then this would be the logical way to go...

Keep em coming...

Duncan