•Extend each LV to the maximum size possible on that PV (the number of extents available in a PV can be determined via vgdisplay
•Configure LV timeouts, based on the PV timeout and number of physical paths, as described in the previous section. If a PV timeout has been explicitly set, its value can be displayed via pvdisplay
•Null out the initial part of each LV to ensure ASM accepts the LV as an ASM disk group member. Note that we are zeroing out the LV data area, not its metadata. It is the ASM metadata that is being cleared.
#lvcreate
#lvcreate
#lvchange
#lvchange
#Assume vgdisplay shows each PV has 2900 extents in our example
#lvextend
#lvextend
#Assume a PV timeout of 30 seconds.
#There are 2 paths to each PV, so the LV timeout value is 60 seconds
#lvchange
#lvchange
#dd if=/dev/zero of=/dev/vgora_asm/rlvol1 bs=8192 count=12800
#dd if=/dev/zero of=/dev/vgora_asm/rlvol1 bs=8192 count=12800
3.Export the volume group across the SGeRAC cluster and mark it as shared, as specified by SGeRAC documentation. Assign the right set of ownerships and access rights to the raw logical volumes on each node as required by Oracle (oracle:dba and 0660, respectively).
We can now use the raw logical volume device names as disk group members when configuring ASM disk groups using the Oracle database management utilities. There are a number of ways of doing this described in Oracle ASM documentation, including the dbca database creation wizard as well as sqlplus.
The same command sequence, with some modifications, can be used for adding new disks to an already existing volume group that is being used by ASM to store one or more RAC databases. If the database(s) should be up and running during the operation, we use the Single Node Online volume Reconfiguration (SNOR) feature of SLVM.
Step 1 of the above sequence is modified as follows:
•First, deactivate the volume group vgora_asm on all nodes but one, say node A. This requires prior shutdown of the database(s) using
•Next, on node A, switch the volume group to exclusive mode, using SNOR.
•Initialize the disks to be added with pvcreate, and then extend the volume group with vgextend.
Step 2 remains the same. Logical volumes are prepared for the new disks in the same way.
In step 3, switch the volume group back to shared mode, using SNOR, and export the VG across the cluster, ensuring that the right ownership and access rights are assigned to the raw logical volumes. Activate the volume group, and restart ASM and the database(s) using
ASM over Raw disk
As mentioned above, a new I/O infrastructure that enables the native
