•should not span multiple PVs

•and should not share a PV with other LVs.

The idea is that ASM provides the mirroring, striping, slicing, and dicing functionality as needed and LVM supplies the multipathing functionality not provided by ASM. Figure 2 indicates this one-to-one mapping between LVM PVs and LVs used as ASM disk group members.

Further, the default retry behavior of LVM could result in an I/O operation on an LVM LV taking an indefinitely long period of time. This behavior could impede ASM retry and rebalance capabilities; hence a finite timeout must be configured for each LVM LV.

For example, the timeout could be configured to the value (total number of physical paths to the PV * PV timeout), providing enough time for LVM to try all available paths, if needed.

The PVs used in an ASM disk group can be organized into LVM volume groups as desired by the customer. In the example shown in Figure 2, for each ASM disk group, the PVs corresponding to its members are organized into a separate LVM volume group.

The LVM volume groups are marked as exclusive volume groups and exported across the Serviceguard cluster using standard Serviceguard procedures. As noted above, multiple physical paths to each physical volume should be configured using the LVM PV Links feature or a separate multipathing product such as HP StorageWorks Secure Path.

Figure 2 Oracle database storage hierarchy without and with ASM

Sample Command Sequence for Configuring LVM Volume Groups

Here is an example of a command sequence that can be used to prepare LVM Logical Volumes for use by ASM to meet the requirements specified above. The scenario for the example is that we are preparing a new volume group named vgora_asm with two PVs, each with two physical paths. The physical paths for the first PV are /dev/dsk/c9t0d1 and /dev/dsk/c10t0d1 and those for the second PV are /dev/dsk/c9t0d2 and /dev/dsk/c10t0d2.

Supporting Oracle ASM instance and Oracle database with ASM 29