Installing Oracle ASMLib ASMLib is a support library for the Automatic Storage Management feature of Oracle Database 10g. This document is a set of tips for migrating ASM disks from raw device access to ASMLib. The complete installation guide is part of the Oracle Database 10g Documentation.

Migrating Raw Devices to ASMLib
	This document describes the steps required to migrate ASM disks from raw devices to the Linux specific ASM library (herein "ASMLib"). It assumes that the raw devices are already part of an ASM disk group. The migration steps must be performed by the system administrator.

Compatibilty of Raw Devices and ASMLib Disks.
	As a general rule, a disk device can be switched from raw device access to ASMLib access and back with no problems. ASM reads the header off of the disk and recognizes the diskgroup it belongs to. The disk group must be dismounted for this to take place, as the disk cannot be in active use by ASM. ASM won't let you dismount the disk if it is active. There are only two issues to deal with when moving from raw access to ASMLib access or vice versa. The most common issue is that of duplicated devices. ASM cannot see the same disk twice. If it does, it will cause an error. What would cause ASM to see a disk twice? Here, it would be because the disk is available via raw access and ASMLib access. The administrator responsible for configuring ASM must be sure that a disk accessed through ASMLib is not available via a raw device and vice versa. This can be accomplished in two ways. If the disk is to be accessed via ASMLib, make sure that there is no raw device mapping for the disk. Then ASM cannot possibly access the disk via a raw device. Whether the disk is accessed via ASMLib or a raw device, the ASM discovery string can be designed so as to include one access method and exclude another. Here's an example: Say ASM is using the disk /dev/sdb1. It has been attached to the raw device /dev/raw/raw2 and configured as an ASMLib disk with the name SDB1. Standard, inclusive discovery strings would be: "/dev/raw/raw*" "ORCL:*" With these strings, both the raw device (which matches "/dev/raw/raw*") and ASMLib ("SDB1" matches the ASMLib discovery string "ORCL:*") will see the disk. ASM will error. However, if the raw discovery string is changed to exclude this disk, then the problem goes away: "/dev/raw/raw1" "ORCL:*" The other issue is the method in which a device is apportioned to ASM. Any disk originally created for use with ASMLib can be moved to raw device access without any problems. Simply prevent the disk from matching the ASMLib discovery string, add it to the raw device mappings, and add its raw device to the raw discovery string. All while the disk is offline to ASM, of course. ASM will recognize the disk via the raw mapping, and away it goes. However, a disk originally created via a raw device mapping is not ready for ASMLib use. It needs to be labeled for ASMLib use. This document was written to describe this process.

The Missing Label
	There are a lot of things that ASM writes to a disk, but here we are only concerned with the two parts of a disk header that ASMLib cares about. The first is the disk marker or "tag". All ASM disks have the tag "ORCLDISK" stamped on them. If the tag exists, the disk is either in use by ASM or a candidate for use by ASM. This tag is added by ASMLib when a disk is configured for ASMLib use via the command /etc/init.d/oracleasm createdisk. If a disk is first used via a raw device, the tag is added by ASM itself. Once this tag is added, ASMLib and its associated tools will consider the disk "created". This will be important below. The second part of the disk header that ASMLib cares about is the label. This is a string of 20 characters or less allotted for ASMLib (any ASMLib, not just the Linux specific one) to use to identify a disk. When a system administrator allocates a disk to ASM using the /etc/init.d/oracleasm createdisk command, the associated label is written to the device. Consider a disk allocated thusly: [root@ca-test1 /]# /etc/init.d/oracleasm createdisk VOL1 /dev/sdb1 Creating Oracle ASM disk "VOL1" [ OK ] The tag "ORCLDISK" and the label "VOL1" are stamped to the disk. When ASMLib scans all disks on other nodes or upon a reboot, it will see the tag "ORCLDISK" and the label "VOL1" and create an ASMLib disk named "VOL1". Then ASM can discover this disk via ASMLib. Raw device access, which doesn't care about the label at all, will also work. This is why a disk can move from ASMLib access to raw device access with no problems. But what of a disk that was created via a raw device? The disk was used in ASM via raw access, so ASM stamped the "ORCLDISK" tag. ASM, not being an ASMLib, will not stamp any label at all. The label is the empty string "". When ASMLib tries to scan this device, it notes that the disk is an ASM disk -- it has the "ORCLDISK" tag -- but that it isn't a disk for ASMLib to access, as it has no label.

Adding the Label
	The naive approach is to try to create the disk for ASMLib: [root@ca-test1 /]# /etc/init.d/oracleasm createdisk VOL1 /dev/sdb1 Creating Oracle ASM disk "VOL1" [FAILED] Why did it fail? Because the disk is already an ASM disk. It has the "ORCLDISK" tag. ASMLib and its tools must honor that fact. If they blindly changed the disk while it appears to be valid, it could cause corruption of data. The entire operation is wrong, anyway. The disk has already been "created" for ASM. It just needs a label for ASMLib. The tools provided with ASMLib can do this. WARNING -- Read This Carefully -- WARNING Modification of the disk label must be done while ASM is not accessing the disk. That means that all ASM nodes in the cluster must have dismounted the diskgroup the disk is part of. If any ASM node is accessing this disk while the label is being modified, YOU CAN LOSE DATA Once the system administrator is sure that nothing is accessing the disk to be labeled, the administrator can proceed. The task is acomplished with the /etc/init.d/oracleasm renamedisk command. Note that renaming a disk from "VOL1" to "MYVOL1" is identical to renaming it from "" to "VOL1". Even though it has an empty original name, the tools still consider it renaming. The system administrator uses the command: [root@ca-test1 /]# /etc/init.d/oracleasm renamedisk /dev/sdb1 VOL1 Renaming disk "/dev/sdb1" to "VOL1" [ OK ] The disk now has the label "VOL1". ASMLib can now see the disk. If there are any other nodes in the cluster, running /etc/init.d/oracleasm scandisks on the other nodes will allow them to see the new label. Now that ASMLib can see the disk, the diskgroup can be mounted via ASMLib. As described earlier in this document, the disk can be accessed via a raw device mapping or via ASMLib, but not both at the same time.