lvol Vs rlvol for Oralce raw device setup

[Filipe_1]

Hi forumers,

When we create the logical volume, say "lvol" by lvcreate, it creates two special files, /dev/vg##/lvol and /dev/vg##/rlvol.

We are provisioning an Oracle environment using raw devices.

Question: what will happen, in practice if someone defines the "lvol" instead of the "rlovol" as the Oracle datafile? I know Oracle suggests "rlovol" but I think both would work.

Any ideas?

Thanks,

Filipe.

[Mark Grant]

If you use lvol then you will not be using a raw device but a cooked device. In other words, there will be buffering and block writes and reads and stuff. I imagine if Oracle is expecting to handle all the writing and reading itself through a raw character device then I would think that using lvol instead of rlvol will not work and not work rather badly!

I would be surprised if Oracle allows you to use the lvol device.

[Wim Rombauts]

For Oracle RAW devices, you should use the rlvols, because that are the real raw, character based device files.

The lvols are block based device files to create filesystems on it. It's a different type of device file and the O.S. allows different type of use of these device files.

Remember to change the rlvol ownership to the user running the oracle database background processes, or at least, be sure thet oracle has read/write access to these rlvols.

[Jakes Louw · Accepted solution]

If you do not use the Raw LVOL, then as was mentioned, the OS will queue and buffer the I/O requests as for a filesystem. This could cause data corruption after a crash, as the I/O would effectively be bypassing the VxFS intent log, but would still be sitting in disk I/O cache.

The Raw LVOL allows for the use of ASYNC drivers for the immediate writing of data, and therefore an ACK from a write operation means that the disk track/block has been updated. If you are going to use Raw LVOLs you therefore MUST activate the ASYNCDSK driver in the kernel. This includes creating a special file called /dev/async:
mknod /dev/async c 101 0x000000
(remember to give the DBMS user access to use this file)

Also set the MAX_ASYNC_PORTS to match the number of DBMS background server processes that will be performing write actions (default is 50).