Copy raw logical volumes of oracle to new disk

[prajeesh_va]

HI all,


I want to copy raw datas ( raw logical volumes) those are used by database. Means i am going to move raw data from an old disk to new disk . which command i can use for this . I feel that dd command is a good option.

is it will word

dd if=/dev/oldvgname/lvname of=/dev/newvgname/lvname bs=1024 conv=sync

i had heard that we can tune the performance copy with dd options . could you please help me ?


Thanks in advance

prajeesh

[Hein van den Heuvel · Accepted solution]

Yes, typcally you would use dd.

The single (biggest) tuning knob for dd is the block size.
And don't specify any conv option.

bs=1024 as specified is NOT enough.
8192 would be the bare minimum imho
You may want to try with bs=1024k (bs=1048576)

Or 64k or 256k

Just try a few times making sure to move the same amount of data, a subset of the real stuff:

time dd count=200 bs=1048576 ...
time dd count=204800 bs=1024...
time dd count=25600 bs=8192...

hth,
Hein.

[Aussan]

the safest way would be to do a backup of it, and a restore on the new disk.

dd would work also, but the backup and restore is a safe bet

[Pete Randall]

Yes, that would work, but very slowly. You can improve the performance of dd by first, using the raw volume and second, by using a larger block size. Try "bs=1024k".


Pete

[prajeesh_va]

Thank you very much .....

I am waiting for some more suggestions.

[Hein van den Heuvel]

Ah, good call Pete! I failed to see the raw device was not used. Prajeesh, be sure to specify that
And why not turn this into a learning experience and also time it both ways to see the difference. Watch how the raw device copy, with large blocks, takes virtually no cpu time!

Aussan wrote>>> dd would work also, but the backup and restore is a safe bet

backup and restore might work, but is most likely to just fail
What value to you feel a backup/restore would add over copying the block when all you want to achieve is copying the blocks?

Now if you _know_ the storage is on a logical drive on a controller served by many physical spindles, then you can speed up by dividing and conquering.

Prajeesh,

If I needed to do this often, and there was Terabytes of data to copy, then I would (try first) take as many as up to half the number for spindles as dd stream and give them each a seperate range. I'd max that out to 20 or so.
So with an LV on an 80 member diskgroup in an EVA I might use 20GB or 100GB chunks each and do something like:
#dd bs=1024k count 20000 iseek=00000 oseek=00000 if=... &
#dd bs=1024k count 20000 iseek=20000 oseek=20000 if=...&
#dd bs=1024k count 20000 iseek=40000 oseek=40000 if=...&
#dd bs=1024k count 20000 iseek=60000 oseek=60000 if=...&
#wait... and submit next dd from list when one finishes. Loop until done:

Divide up in even cunks, or (perl) script is such that there are always many streams active.
If you have multiple devices to copy, then the streams should of course operate primarely on distinct device.

script outline...

streams=0
max=20
while (chunks to copy) {
chunk++;
if (streams++ > max) { wait; streams--}
fork
if (child) { dd cmd{$chunk} }
}
while wait(); # make children, no zombies


But watch out... it's all too easy to spend more time scripting a perfect solution than just brute forcing the copy and wait.

The multystream does pay of very nicely though if you can do a pre-run early in the week and then set up for the fastest possible copy with minimum down time for the real switch over. teh prep run will also give you a rather exact time estimate to share with management at your discretion. :-).

hth,
Hein.

[prajeesh_va]

Thanks for replay

I have to move about 30 rlvs ...
each will be in 1 gb size ..
I feel that i can create a shell script for automation

[Hein van den Heuvel]

>>> Thanks for replay

Say thanks with points! (0 points for this one)
http://forums1.itrc.hp.com/service/forums/helptips.do?#28

>>> I have to move about 30 rlvs ...
>>> each will be in 1 gb size ..
>>> I feel that i can create a shell script for automation

That's nothing? Why worry!

In fact, turn that around... are you sure to want to keep dealing with lots of tiny little volumes?
Maybe it is time to grow up.
Use this transition to do to for example 20GB or 50 GB volumes and let Oracle play with that.

Of course in order to do so, you'll probable want to export from the old and and re-import into a fresh db.

You will have to edit tablespace names and such, but that's really worth it.

Bite the bullet now, be happier next year!

Hein.

[Emil Velez]

If you are talking about disks in the same volume group do a pvmove


pvmove -n

[Tim Nelson]

Another safe way.

If you have the HP Mirror/UX you can just mirror the lvols to another disk, then remove the old path. Can be done on the fly with no worry of data corruption or having to silence the application, if any.