Basically my current thinking is that you should use udev if you have Linux guys around to take care of it, ASMLIB if the DBAs are going to be tending the device permissions. Guess it kinda relates to that whole DBA2.0 thing that was recently making the rounds.

I heard that with regular block devices, after dropping or offline-ing a device it might still be help open by other rdbms processes besides the one that did the drop. I’m not sure if or how this might cause problems. (Do you need all the handles cleanly closed for OS operations like detaching the LUN or renaming the device?) I imagine that ASMLIB would not have this problem since each server process uses a single ASMLIB handle instead of direct device handles.

Have yet to verify the details. :)

Fritz and Jason – thanks for the comments. I agree that udev is a bit difficult; it’s not exactly obvious and the documentation is very poor. But once you figure it out, it’s quite powerful and flexible.

Tim Hall is widely known as “Tim…”. Though I think he may also be the original and only case of an illness called “Oracle Open World Syndrome (OOWS)” which seems to affect him each year he attends (at least two years running now).

Thanks for the blog. Hope to see more like this one coming soon!

Like Frits, I have also presented on ASM. Though I have a more benign attitude to ASM, but then I found udev to be quite impenetrable to use.

I have Oracle employees express the opinion the ASMLib enables global opening of devices, so 1 file handler per device which is shared amongst processes rather than each process having to do this.

I really have to test this so you’d treat this with a large pinch of salt until there is more concrete evidence.

Of course, whether reducing file handlers, and marginal improvement in context switches (thus reducing cpu) is really a benefit you will notice is a different question.

jason.

There are more things you have to be aware of when using asmlib:
-the asmlib library is placed in /opt/oracle/extapi/32/asm/orcl/1/libasm.so. No problem, but if you are not aware you have a critical library placed there, it’s possible that someone (a sysadmin) cleanes this up.
-asmlib adds a kernel dependency. No problem, but you have to be aware you have to upgrade the asmlib kernel package together with upgrading your kernel.
-what sense does a seperate asmlib name make for a disk? it means you have a device name (which can differ), a ASM diskname, and a asmlib name. seems redundant to me. also, when udev is setup to give the disks for oracle the correct permissions (and the asm discovery string is setup right), ASM reads the diskheaders and recognises them, no matter if disk /dev/sdd1 was /dev/sdb1 before the reboot.