1832366 Members
2672 Online
110041 Solutions
New Discussion

BCV in HP-Unix

 
SOLVED
Go to solution
Ajin_1
Valued Contributor

BCV in HP-Unix

Hi Experts.

 

As of my understanding BCV can be useful for cloning a large production database for testing.

In HP-Unix OS pint of view ,how can we find weather BCV was configured in this Server ,and I want to know the basic concepts of BCV.

 

Thanks in Advance

Thanks & Regards
Ajin.S
Proverbs 3:5,6 Trust in the Lord with all your heart and lean not on your own understanding; in all your ways acknowledge him, and he will make all your paths straight.
1 REPLY 1
Matti_Kurkela
Honored Contributor
Solution

Re: BCV in HP-Unix

The BCV is mostly implemented at the storage system level. In the server, you will typically see only some pre- and post-backup scripts and some tool that can be used to tell the storage system to split and resync the BCV as needed.

 

A BCV is created and presented to the server in the storage system much like a regular LUN. You may also need to set up an username & password or another authentication mechanism in the storage system to allow the server to send BCV operation commands to the storage system.

 

At the beginning of a backup cycle, the BCV is synced with its origin LUN(s). The BCV clone LUNs may be hidden from the server OS at this point.

Then you use storage-system-specific tool to split the BCV: at that point, the storage system presents one or more new LUNs to the OS, which will seem to contain exactly the same data as the originals did at the time of the BCV split operation. When the originals are updated, the updates will not be reflected on the BCV clone until the BCV is synced again.

 

Before splitting a BCV, you should place any databases on the BCV in backup mode and run "sync" to make sure all the filesystem write operations to the BCV are in a consistent state. But you can put databases back to normal production mode as soon as the BCV split command completes, which should happen very quickly.

 

(NOTE: A BCV clone may or may not be a real mirror. The storage system may implement various shortcuts with BCVs: one of these is implementing the BCV internally as a list of blocks in the BCV origin that have been changed since the BCV split, and a copy of only those modified blocks as they existed at the BCV split time. The unmodified blocks can be read from the BCV origin. Because of this, just having the BCV split is not necessarily equivalent to a complete backup: BCV is just a tool for making such a backup with minimal interference to production.)

 

In HP-UX, this typically means you will see a new set of disk devices, which will contain another copy of an already-existing VG. In HP-UX 11.23 or earlier, this usually requires running ioscan and insf; in HP-UX 11.31, new disk devices will appear automatically if the SAN is configured correctly for HP-UX 11.31.

 

If you need to activate and mount the BCV clone on the same HP-UX system as the BCV origin, you must first perform a vgchgid operation on the BCV clone PVs and then import the clone VG by another name to make it accessible. (Raw database LUNs controlled by database-specific tools like Oracle ASM may need something similar done to them using the appropriate tools.) If a filesystem is mounted while its BCV is split, the BCV clone is similar to a RAID mirror half that has been suddenly yanked off the system while it is running, so it is recommended to run a filesystem check on the BCV clone filesystems to make sure they are in consistent state for backup.

 

After that, you can mount the clone filesystems in order to make a real backup of them, or run appropriate backup tools on raw database LUNs.

 

After the backup is complete, you unmount all clone filesystems and deactivate the clone VG, and then use another storage-system-specific command to resync the BCV. Once the BCV completes syncing, you are back from where you started and are ready to start another backup cycle.

MK