Copying data from Prod XP array to Dev XP array using Mirroring?

[paul vail_1]

Hi Guys,

I need to copy 3TB of Oracle Databases from my Production XP array to a separate Dev XP array to refresh the Development environment.

The way it's been done in the past has been by presenting the Storage from the Dev array to a production server. Then using 'dd' to copy the data from the Prod BCV's to the presented Dev storage, as you can imagine this takes around 5 days to do all of the databases in our allowed timeslots. Our tape backup infrastructure cannot take the load of this refresh so unfortunately its not a possible option.

I have migrated data from one san to another before using mirroring but that involved presenting the new disks, mirroring and then removing the old disks which are then re-used. I have also used fbackup which works well but its not suitable in this instance as the storage is used as raw devices (not mounted).

In this case i need to make a mirror copy of the BCV's, split the mirror and then use re-import the disks on the Dev server with the refeshed data, Is this possible?

[Duncan Edmonstone]

5 days for 3TB? That's pitiful even for dd! If I can use a calculator effectively thats about 7MB/s (or about 60Mb/s). Thats slower than ethernet speed!

I'd look again at what options were used on the dd and make sure you're using a suitably large block size and running as many in parallel as you are able. That then remains simpler than mucking around with mirroring...

HTH

Duncan

[Eric SAUBIGNAC]

Bonjour Paul,

Maybe you could also use a product like "HP StorageWorks XP Continuous Access Software" ( see www.hp.com/products1/storage/products/disk_arrays/xpstoragesw/continuousaccess )

The main idea is : create pairs between the 2 storage arrays, once data is syncrhonised, stop the production, break the pairs, restart the production ...

Anyway, transfering data in background with LVM will work. But you will have some cleaning to do on LVM configuration both on production and development host. Continuous access would be more friendly.

Eric

[Mark McDonald_2]

OFF TOPIC - Paul are you still in Hinkley? Hows that big ugly Ford?

[Mark McDonald_2]

Paul - cant you use DDS tape? external drive?

[paul vail_1]

The reason why it takes 5 days is that we have a small window to do the 'dd's over 5 days as the BCV's are used for daily backups. I was thinking that mirroing may be a fair bit faster.

We use CA but extra CA licenses are not an option unfortunately, they only do this refresh once or twice a year.

Its looking like dd is the only realistic option at the moment.

[James R. Ferguson]

Hi Paul:

> Its looking like dd is the only realistic option at the moment.

Then make sure to use a large blocksize and _raw_ devices so that you don't needlessly involve the buffer cache:

# dd if=/dev/rdsk/cXtYdZ of=/dev/rdsk/C1t2d3 bs=1024k

Regards!

...JRF...

[Mark McDonald_2]

Paul

As discussed else where - you can run some test dd's with different block sizes to find the optimal size.

Mark

[psreedhar]

From my past experience i suggest to use 4096K block size is the fastest.

[Mark McDonald_2]

Paul did you manage to complete this? What block size was best? Can we have some points?