Do you put your BCV split VGs/LVs in your /etc/fstab ?

[Stuart Abramson_2]

I was thinking that I wouldn't, because they may not be there at boot time.

But, I'm thinking that what if the system goes down and reboots off-shift while the split BCV VGs/LVs are mounted? They can remount automatically if I put them in /etc/fstab. And nobody has to call me in the middle of the night.

And what is the harm of putting them in /etc/fstab if they aren't there? A few error messages. So what?

Isn't there some option for /etc/fstab that says "mount if they are there, ignore them if they aren't"?

Do you put boot-time startup scripts for your Oracle instances that are split from BCVs?

Same logic - why not start them automatically if they are there.

[John Poff · Accepted solution]

Hi,

I ran into the same issue a while back with some BCVs we keep on a test/dev system. I decided to keep them out of /etc/fstab to avoid any error messages and confusion, and I wrote a boot startup script that checked for the /dev/vg_bcv/group file and activated the VG, fsck'd the LVs, and mounted them up if it found them.

That worked great and did the right thing. Since the box that our BCVs live on is also the failover node in a MC/SG cluster, I decided to put them into a SG package which works great also.

JP

[Geoff Wild]

We only mount bcv's on our netbackup server - we don NOT put them in the /etc/fstab but rather place them in a scripts dir/application:

/usr/openv/netbackup/scripts/SIM

In here is a SIM_fstab file in a similiar fashion to MC/SG:

#
# This configuration file is used to mount
# SIM's volumes for NetBackup. It's read by
# SIM_activate and SIM_deactivate.
#
# Volume Group Definition Format :
# VOLUME GROUPS = ...
#
VOLUME GROUPS = /dev/vg20sim
#
# Volume Definition Format:
# VOLUME =
# Mount points must be in ascending order.
#
# SIM
# not needed as it is mounted locally VOLUME = /dev/vg20sim/lvol3 /oracle/SIM
VOLUME = /dev/vg20sim/lvol1 /oracle/SIM/origlogA
VOLUME = /dev/vg20sim/lvol2 /oracle/SIM/origlogB
#VOLUME = /dev/vg20sim/lvol4 /sapmnt/SIM
#VOLUME = /dev/vg20sim/lvol5 /usr/sap/SIM
VOLUME = /dev/vg20sim/lvol6 /oracle/SIM/sapdata1
VOLUME = /dev/vg20sim/lvol7 /oracle/SIM/sapdata2
VOLUME = /dev/vg20sim/lvol8 /oracle/SIM/sapdata3
VOLUME = /dev/vg20sim/lvol9 /oracle/SIM/sapdata4
VOLUME = /dev/vg20sim/lvol10 /oracle/SIM/sapdata5
VOLUME = /dev/vg20sim/lvol11 /oracle/SIM/sapdata6
VOLUME = /dev/vg20sim/lvol12 /oracle/SIM/sapdata7
VOLUME = /dev/vg20sim/lvol13 /oracle/SIM/sapdata8
VOLUME = /dev/vg20sim/lvol14 /oracle/SIM/sapdata9
VOLUME = /dev/vg20sim/lvol15 /oracle/SIM/sapdata10
VOLUME = /dev/vg20sim/lvol16 /oracle/SIM/saparch
VOLUME = /dev/vg20sim/lvol17 /oracle/SIM/mirrlogA
VOLUME = /dev/vg20sim/lvol18 /oracle/SIM/mirrlogB

Rgds...Geoff

[Tim Sanko]

We rearely keep our bcvs in
the /etc/fstab since we mount them only to backup, and export the oracle databse residing there.

After one backup completes we unmount then can resync with the original drives, or establish with another set of drives.

Tim

[Dave Wherry]

I never put them in fstab because I don't like the idea of getting operators or other admins used to ignoring error messages. If you just ignore them on a regular basis you will eventually miss something important.
When using BCV's or Business Copy LUNs I've always used pre-exec and post-exec scripts in the backup to handle mounting and unmounting. You ask "what if the system goes down and reboots off-shift while the split BCV VGs/LVs are mounted?" Well, what were they being used for? If it was backups your backup job failed with the crash. If the job automatically restarts or an operator restarts it, the pre-exec would handle the mounts.
If it is not supposed to be there every time at boot, I would not put it in fstab.

[Jordan Bean]

I'd keep my bcv file systems in a separate fstab file that mountall will use. Example:

mountall -l /etc/fstab.bcv

Unfortunately, umountall does not have the same feature, but various means are still available to work in reverse.