Is there a method to copy LVM and raw devices?

[tommy_28]

There 's a project, we have a AutoRAID SCSI disk subsystem, and we made some PV/VG, lv and raw devices here, and install oracle databases and some applications in these devices.
But after these works we have to shift all contents in AutoRAID to a VA7410. I heard some suggestions to directly copy lvs using dd. I'm not sure it'll work, somebody can give some suggestion?

Thanks.

Tommy

[Jean-Luc Oudart]

Check this thread

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xb4b150dde50cd71190050090279cd0f9,00.html

I suggested HP MirrorUx

Rgds
Jean-Luc

[Stefan Farrelly]

Yes, dd is the best way to copy raw LV's. We use it all the time - never had a problem. Only conditin is the original LV and the new LV must be the same size (in Mb+extents).

Then unmount the filesystems so nobody is using them then dd;

dd if=/dev/vgXX/rlvolYY of=/dev/vgZZ/rlvolVV bs=1024k

Its also the fastest way to copy.

[Leif Halvarsson_2]

Hi,

With Data Protector (and som other backup programs) it is possible to backup/restore raw devices (Disk Images).

[Tim D Fulford]

Hi

As jean Luc has suggested Mirror Disk is a good route, could be done on-line. HOWEVER, not always possible as
o MAY be using kB stripped,
o reached the limit of number of disks per VG
o reached max PEs per PV so that new LUNS on VA will be too small!

I've done the above from FC60 --> VA7400

0 - shutdoen appllications, this must be done OFF LINE (as far as applications accessing the disks are concerned)
1 - Create new VG say vgnew, create ALL the logical volumes (same LV names)
2 - dd if=/dev/vgold/r bs=4096k of=/dev/vgnew/r
3 - Rename vgnew to vgold
# vgexport vgold
# vgexport -m /tmp/vgnew vgnew
# mkdir /dev/vgold
# mknod /dev/vgold/group c 64 0xNN0000
# vgimport -m /tmp/vgnew vgold /dev/dsk/.....

Bingo data back in same format & names as the old VG. BTW take the oppertunity of reviewing the defults of MAX PE/VG, MAX PE/PV, MAX PV/VG etc.

Regards

Tim

[doug mielke]

You might want to take this opportunity to convert away from raw devices. The Oracle 'old school' benefits are all but lost today, and the eva will be much faster than the Autoraids anyway.
and, management on the EVA is a dream.

[Tim D Fulford]

Doug

to raw device or not raw device is a hotly debated issue. Some people swear by raw devices others swear by cooked. They both have advantages & disadvantages.

Tim

[doug mielke]

Tim,
I might be missing some of the advantages to raw devices. I
I have certainly been assuming that touted raw advantages are related to i/o performance, in which case, I know on which side of the fence I sit.

But, Am I missing other advantages to raw not related to i/o speed?

Sign me,
Waiting to be sold,
Doug

[Tim Sanko]

Doug,Tim,Tommy,

We have a EMC Sym 8530 on which we have bechmarked the io difference at < .5 %
raw to cooked using HFS. The difference for vxfs was about .8%. That was with our scenario.

The database is ~= 1.5 T and that was with test benchmarks like the nightly run of daily job. Since we have had such performance from HFS, we have "eschewed" raw file systems. (not a bit sorry about the pun).

Under informix There was be a higher difference
but, we also had an older/slower 3430 symm.


Tim

[Tim D Fulford]

Raw IO Vs Cooked IO

o Resource utilisation, raw uses no HP-UX buffers/memory, cooked uses buffer cache. Effectively your system will hold buffered pages in the database instance & on the OS, you have the same info twice in the same physical memory!!
o raw IO is more efficient, it does not rely on the cooked services to perform IO, cooked IO will need to go to via buffer cache first, then to disk. A well tuned instance will keep its pages in the instance memory.
o Organisation. cooked devices can be "de-fraged" on-line raw will need to be manually manipulated at a database level. After time raw devices performance can suffer from fragmentation (in a bad sense) of data.

It does not surprise me that tests show cooked devices are of similar or better performance than raw or vica versa. BUT as far as system resource usage are concerned they are chalk & cheese. I don't believe there is a right or wrong choice, just that there is a choice, and that it is dependant on your attitude & how big your pocket book is $$$$. If you go for raw, you should be able to save money (probably not much) on memory etc. If you go for cooked, you should be able to keep IO performance levels up over time & not suffer from data fragmentation. The whole area is further complicated by the fact that SANs also have a cacheing area to improve performance.

Regards

Tim