Veritas Volume Manager Cheat Sheet:

The Setup: an Oracle database supporting an application called ABC, and given th
e following:
Assuming that we need to create filesystems intended for Oracle and:
we are using a SID of 'ABC'
we have nine disks, c0t0d1 through c0t0d9
we will be creating six volumes: /u01/oradata/ABC ( 4gb ), /u02/oradata/ABC (4gb
), /u03/oradata/ABC (8gb ), /u04/oradata/ABC ( 4gb ), /u01/app/oracle/product/8
.0.5_ABC ( 4gb ), and /u01/admin/ABC ( 4gb ).
We added these disks to Volume Manager Control during installation with vxinstal
l, or later with vxdiskadd(1m). Both vxinstall and vxdiskadd can add either init
ialize a previously unused disk, or 'encapsulate' a disk already containing data
, but not under Volume Manager control.
we could take the following steps to set up our filesystems.
Adding an EMC disk to Veritas
Use the inq utility to see if you have SCSI visibility to the disk
Use vxdisk -o alldgs list to see if Veritas has seen the disk
if not, try the following, and then repeat the previous step:
devfsadm
vxdctl initdmp
vxdctl enable
Creating a Disk Group in Volume Manager:
Create a vxvm disk group for the Oracle SID using vxdg(1m). It's important that
all of the disks/filesystems necessary for the ABC database to run are included
in the disk group, otherwise the database could not be moved to another system.
The easiest way to do this is to use vxdiskadd
vxdiskadd c0t0d0 c0t0d1 c0t0d2 . . .
Doing it the hard way:
vxdg init ABCdg ABCdg01=c0t0d1
This would create a disk group called ABCdg containing one physical disk, c0t0d1
, which will be referred to by it's name within vxvm, ABCdg01. You cannot initia
te a disk group without specifying at least one disk as a member of the group. Y
ou should not include any disks destined to be part of an Oracle Database in the
default vxvm group, rootdg. This allows you to use the vxdg 'deport' and 'impor
t' commands to migrate an entire vxvm disk group to another host.
Now that we've create the disk group for our database, we can add the rest of ou
r disks to it:
vxdg -g ABCdg adddisk ABCdg02=c0t0d2

vxdg -g ABCdg adddisk ABCdg09=c0t0d9

Creating Volumes With vxassist
vxassist(1m) is a vxvm command that acts as a front-end to other vxvm commands,
much as newfs(1m) acts as a simpler-to-use front-end to mkfs(1m). Using vxassist
with it's -v flag will display the actual vxvm commands used during volume cons
truction. vxassist also front-ends vxfs commands and normal UNIX utilities durin
g volume construction. An example of this is using a single vxassist command to
set up a volume. Using vxassist simplifies many vxvm tasks, but you should pay c
areful attention to the defaults you will inherit when setting up volumes using
this tool. Understanding the contents of the /etc/default/vxassist file is impor
tant, especially when striping disks.
To make our 8gb /u03/oradata/ABC volume, we could use the following command line
:
vxassist -g ABCdg make ABC01 8g
Breaking it down into it's component parts:
vxassist
-g ABCdg # this volume will belong to the ABCdg disk group
make # tells vxassist that we are creating a new volume
ABC01 # name the volume
8g # specify the size of the volume
Here we create the other five volumes:
vxassist -g ABCdg make ABC02 8g
vxassist -g ABCdg make ABC03 8g
vxassist -g ABCdg make ABC04 8g
vxassist -g ABCdg make ABC05 8g
vxassist -g ABCdg make ABC06 8g
Creating a File System:
We now lay filesystems down on our newly created volumes. We assume here that yo
u've agreed with the Oracle DBA's to use a block size of 8192 for our filesystem
s. Not specifying a block size allow Veritas to dynamically assign one for you b
ased upon the size of the volume. Our volumes would default to 1024 for a block
size on our 4 GB volumes, and 2048 for our 8GB volume. We will specify the large
files option, because the mkfs_vxfs(1m) command uses nolargefiles as a default,
unlike mkfs_ufs(1m) on Solaris 2.6 or greater, which uses largefiles as a defaul
t. If we forgot to do so, we could use fsadm ( fsadm_vxfs(1m) ) to set the large
files bit on. fsadm can also query a mounted filesystem for the current setting
of this flag. Be certain that whatever flags you set during file system creation
or modification are reflect in vfstab, or the resulting file system may be un-m
ount-able.
mkfs -F vxfs -o bsize=8192,largefiles /dev/vx/rdsk/ABCdg/ABC01

Mounting a File System:

Creating and mounting filesystems go hand in hand. You must be certain that any
special flags set at creation time are reflected in /etc/vfstab, or on the comma
nd line if there is no entry in vfstab for your filesystem.
mount -F vxfs -o largefiles /dev/vx/dsk/ABCdg/ABC01 /u03/oradata/ABC
Resizing a mounted volume and file system:
/etc/vx/bin/vxresize -g rootdg -F vxfs archive 16g
Recovering disks under VM control:
(if you want to live dangerously, try looking at dfwset01:/root/progs/hose_vx_dg
.pl)
Pre-reqs
Do a vxprint -g mydg first to see what disks your volumes lie on!
Do a vxdisk list and save it
Do an inq -et and save it!
You may wish to review moving a volume off of a particluar disk
Procedure
1) comment the volume(s) you're destroying out of vfstab
2) umount the volume
3) stop it:
vxvol stop volume01
4) remove it:
vxedit -rf rm volume01
5) remove the disk(s) the volume was on from the disk group ( up to the last dis
k )
vxdg -g mydg rmdisk dmdiskname01
6) Remove the the disk(s) from VXVM control
vxdisk rm c1t1d51s2
7) If you wish do get rid of the disk group ( in order to recover the last disk
), you must destroy the disk group:
vxdg destroy mydg
8) remove the last disk
vxdisk rm c2t7d9s2
9) If you're removing the disks from the EMC port, be sure to clean up:
drvconfig
disks
vxdctl enable
vxdctl initdmp
10) Freak out and realize you whacked the wrong thing, use /root/eotw to recover
.
Renaming a VM Disk:
Since names like "ABCdg10" are not as descriptive as they could be, you can rena
me it to something more useful.

vxedit rename ABCdg10 ABCdg_hot_spare

Using long disk names can be more descriptive, but will make using vxva trickier
, as it will truncate your disk name somewhat if it is too long.
Moving a Disk Group to Another System:
1) umount the disks:
umount /u01/app/oracle/product/8.0.5_ABC
umount /u01/admin/ABC
umount /u01/oradata/ABC
umount /u02/oradata/ABC
umount /u03/oradata/ABC
umount /u04/oradata/ABC
2) Stop the volumes:
vxvol -g ABCdg stopall
3) deport the disk group from one system:
vxdg deport ABCdg
4) import them on another system:
vxdg import ABCdg
5) Start all of the volumes on the new system and resync mirrors in the backgrou
nd:
vxrecover -g ABCdg -sb
6) mount the filesystems
mount /u01/app/oracle/product/8.0.5_ABC
mount /u01/admin/ABC
mount /u01/oradata/ABC
mount /u02/oradata/ABC
mount /u03/oradata/ABC
mount /u04/oradata/ABC
This procedure assumes that the second system can see the disks, and also that y
ou have commented the file systems out of vfstab on the old system.
Rename a Disk Group
/root

dfwns19 # df -k | grep reports

/dev/vx/dsk/reportsdg/ncr01 /u01/app/oracle/admin/REPORTS
/dev/vx/dsk/reportsdg/ncr02 /u01/app/oracle/product/8.0.5REPORTS
/dev/vx/dsk/reportsdg/ncr03 /u01/oradata/REPORTS
/dev/vx/dsk/reportsdg/ncr04 /u02/oradata/REPORTS
/dev/vx/dsk/reportsdg/ncr05 /u03/oradata/REPORTS
/dev/vx/dsk/reportsdg/ncr06 /u04/oradata/REPORTS
/dev/vx/dsk/reportsdg/ncr07 /u11/oraarch/REPORTS
dfwns19
dfwns19
dfwns19
dfwns19
dfwns19
dfwns19
dfwns19

#
#
#
#
#
#
#

umount
umount
umount
umount
umount
umount
umount

/u01/app/oracle/admin/REPORTS
/u01/app/oracle/product/8.0.5REPORTS
/u01/oradata/REPORTS
/u02/oradata/REPORTS
/u03/oradata/REPORTS
/u04/oradata/REPORTS
/u11/oraarch/REPORTS

dfwns19 # vxvol -g reportsdg stopall

dfwns19 # vxdg deport reportsdg
dfwns19 # vxdg -n nclproddg import reportsdg
dfwns19 # vxdg list
Mirroring and then breaking mirrors
# make an sd from your dm ( use the -g, or it won't work. The book is wrong )
#
sdname
dmname,start_offset,sd_length
vxmake -g dwproddg sd dwprodd15-01 dwprodd15,0,8389440
# create a plex from your sd
vxmake -g dwproddg plex dw01-02 sd=dwprodd15-01
# attach the plex to your volume
vxplex -g dwproddg att dw01 dw01-02
# watch it
/tmp
dfwora03 #
Task:
Type:
Operation:
Started:
Throttle:
Progress:
Work time:
# more
vxmake
vxmake
vxmake
vxplex

silver ( check out the pause and slow options. badass )

vxtask -l list
162 RUNNING
ATCOPY
PLXATT Vol dw01 0.0
Tue Dec 05 03:47:29 2000
0
18.33% 1537352 of 8388608 Blocks
1 minute, 26 seconds (06:23 remaining)

than one sd
-g dwproddg
-g dwproddg
-g dwproddg
-g dwproddg

per plex for plexen > one dm

sd dwprodd17-01 dwprodd17,0,8833920
sd dwprodd18-01 dwprodd18,0,7944000
plex dw03-02 sd=dwprodd17-01,dwprodd18-01
att dw03 dw03-02

# now for the scary part. dis-associating the plexes and sd's
vxplex -o rm dis dw01-01
# zap the dm from the dg
vxdg -g dwproddg rmdisk dwprodd01
# nuke the da
vxdisk rm c2t2d13s2

NAME
nclproddg

STATE
ID
enabled 949356971.2501.dfwns19

Renaming a disk group and volume

bansecdbdg -> secproddg used as an example
# Unmount all volumes in the bansecdbdg disk group.
# Stop all volumes
vxvol -g bansecdbdg stopall
# Deport bansecdbdg
vxdg deport bansecdbdg
# Import bansecdbdg using the -n option
vxdg -n secproddg import bansecdbdg
# Recover the disk group by the new dg name
vxrecover -g secproddg -sb
# Rename each volume
vxedit -g secproddg rename bansecdb01 sec01
vxedit -g secproddg rename bansecdb02 sec02
.
.
.
vxedit -g secproddg rename bansecdb08 sec08
# Update vfstab, your mount points and remount the volumes
Resizing a disk, while specifying the disk
# Resize volume u11, and only use disk dev20dg23
# x requires the volume to grow (i.e. does not let you specify a
# smaller than existing volume size), and b backgrounds the
# task (according to the tech)
./vxresize -F vxfs -bx -g dev20dg u11 16g dev20dg23
Moving a volume off of a particluar disk
# Move u11 off of dm dev20dg20
vxassist -g dev20dg move u11 !dev20dg20