OK, i will start with this problem, otherwise the post will perhaps become too long. In the following i will try to explain some concepts as well as answer your question. Try to understand the concepts rahter than just copying the commands, because this is what will help you in the long run more than everything else.

The Logical Volume Manager
=====================

The LVM is a mechanism to deal with real (storage) hardware on an abstracted level, so that it is possible to logically treat a very diverse collection of things (single disks, RAID-sets, LUNs from a storage box, ...) in the same coherent way. The LVM has a layered architecture and we will explore one layer after the other.


First layer: disks and other devices that provide raw storage capacity

When we attach disks (or, rather, the devices i mentioned in the title - things that provide something to a system which can be measured in kilobytes) to a system we need to make these available to the LVM first before we can use them. Furthermore we want to be able to group these disks to reflect that some of them provide storage for the same purpose.

Supose we have a system with three different applications: there are, say, 7 disks connected to the system and 2 are used for appl1, one for appl2 and the rest for appl3. We will want to organise the disks so that it immediately becomes clear which disks provides capacity for which application.

For this we have "volume groups" or VGs for short. Every "disk" (we treat this term very losely here, including RAID-sets, LUNs, and what not) is attached to exactly one such VG. When we make a disk part of a VG it becomes a "physical volume", PV. Here are some commands to deal with physical volumes:

Code:

lsvg              # show a list of all VGs
lsvg <VG>         # show the attributes of volume group VG
lsvg -p <VG>      # show a list of PVs in VG
lspv              # show a list of all hdisks and to which VG they belong
lspv <hdisk>      # show the attributes of hdisk and a free-distribution

When you create a VG you have to make some decisions which can't be changed (at least not easily) afterwards. These are:

a) the type of the VG
The logical volume manager is a piece of software which is over 20 years old. This means that some of the concepts (especially where it deals with disk sizes) comes from a time where disk space was measured in MB rather than GB or TB. The "classical" VG had a maximum of 32 disks with a maximum of 1019 physical partitions (see below) each. This became a problem at some point in time and IBM developed a way to convert such "classical" VGs to "Big VGs" which alleviated some restrictions a bit. Later another type, the "Scalable VG" was introduced, which loosened even more restrictions. Today there is no reason to create anything else than a "scalable VG".

If you have a VG and don't know which type it is (there is no direct way to display it) do the following (handle the following low-level commands with EXTREME care!) to display it:

Code:

readvgda <one-PV-of-the-VG> | head -n 7

b) the size of the physical partitions (PPs)
When a disk becomes part of a VG (and thus a pv) it is partitioned into so-called physical partitions. These PPs are the smallest units of space that can be assigned. What makes the LVM so versatile is that you don't have to be concerned where (that is: from which disk) a PP comes from. As i said above the classical restriction of 1019 PPs per PV is not any more with scalable VGs but still it pays to select a reasonable size for the PPs. "2MB" for a database is just nonsense. Ask yourself which would be the smallest unit reasonably to add to a filesystem and use this as PP size. For most cases a PP size of 512MB-2GB is a reasonable choice.

c) create the VG concurrent-capable?
If there is any chance that the VG is (or will become) part of a cluster, you should create it as concurrent-capable. This means the VG can be opened at more than one system at the same time. If you have a strict single-system this won't matter in any way.

d) The major number
Every VG has its own major number. Within clusters where you have more than one system that can activate the VG it is good practive to make sure the major number is maintained throughout the cluster so that the VG has the same major number on every node. You do not need this to make the cluster work but it makes administration easier. If you have a (strict) single-system this doesn't matter so much.


-----------------
Ok, so much as a first part. I will write some more later today but for now this has to suffice. I hope you found that helpful.

One more point: it helps if you introduce naming conventions an stick to them. Don't name a VG "VG1", because once you have ten VGs, named VG1-VG10 you won't be able to tell which one is what. give them speaking names like "oraclevg" or "myorainstvg" or whatever - but something that tells you immediately what belongs to where.

My own convention (but that is as good as anthing else, just be consistent) is to name VGs with a "vg" at the end because the default "rootvg", which holds the system FSes is named that way. So i might have a "rootvg", an "orabinvg", an "oradatavg", etc. on one system.

I hope this helps.

bakunin