AIX

Well, if you can afford it - you may standup a standby (Oracle-Standby) database and decide a date and shutdown the real DB and convert the new database as the production. If you plan it well, you might be done with an Hour downtime. In the worst case, backout is to shutdown the new database and startup the old. ( 5 mins ? ). I am sure change management is going to like this one. Very similar to the hot backup solution someone posted.

If all you want is to move to new disks, the storage vendor might have some utilities as well. BCV for local copies and SRDF for copy across arrays in the EMC world. (I assumed you have SAN storage)

okay, cplv has failed

1) I had a filesystem with 200G allocation with actual Data of 100.6 GB
so I created another filesystem with 245 GB and tried to copy with cplv command and i got a message to use chlv with -t parameter ; so i didn't understand why i should change the type when they are both same type of filesystem JFS2 ?

so, i skipped and went to another option , cplv to user-create logical volume ( that is the system will create the logical volume by itself )

2) cplv to user-create logical volume is taking more than 1.1 hour and still the copy was not finished and I had to cancel/abort the operation because users needed the filesystem to copy 100.6 GB (total filesystem size 200GB) Logical Volume to another logical volume is taking more than 1.1 hours
any suggestions ?

some suggested copying files and directories but Oracle team is avoiding this approach.

mirrorlv for the above example : filesystem of 200G allocation with actual Data of 100.6 GB takes around 3.5 hours.

Note: the filesystem / logical / volume group is from SAN Storage connected by one 4 GB fiber.

so we are here copying a filesystem/logical volume from SAN Storage to SAN Storage.

So, if 200G logical volume takes 3.5 hours with mirrorlv imagine 2.6TB ?
around 40 hours or so ?

next I will try to cp as zxmaus or as bakunin said, will backup and restore.

Folks, there is a small problem. After using cplv and log was created and initialized and a new filesystem ( new name for filesystem) was mounted on that Logical Volume. But after mounting it, I didn't see any data !

but lsvg volume_group shows PPs are in use.

any clue as to what might be the issue ?

do you have a new mountpoint or the same - maybe it is just overmounted with something else

BTW - if you only want to move to new SAN - but not necessarily to a new volumegroup - why dont you just add the new disks to the existing VG and do a migratepv olddisk newdisk(s) and drop the old empty disks afterwards from the VG. This is for sure not the fastest but the easiest way as it doesnt need ANY downtime whatsoever.

Regards
zxmaus

It is a new mount point..

Okay here is what happened:

1. Created a new VG ==> oraclevg6
2. cplv logical volume from oldvg to newvg ( and the system created lv called fslv06 )
3. after the cplv was over lsvg -l oraclevg6 ==> showed that there is a log logical volume called loglv01
4. create a filesystem with a new name and not the existing one for the copied logical_volume call it /u06
5. mount /u06 on fslv06
6. doesn't work...umount /u06
7. logform /dev/loglv01
8. mount /u06

still no data present.


==========
No, it cannot be done for various administrative reasons.
1. the array is different and new san is different
2. Database team want to have the new disks totally seperate.
3. the above experiment was with 200GB and it took 3.5 - 4 hours....what about 2.6TB...... ? and if something goes wrong then the company application might need a total restore.
too risky !

I think the problem may be the new filesystem on the copied lv.
Here's what I did on a test filesystem and it worked fine:

1. Created new lv

Code:

# mklv -y lvcorenew -t jfs2 data2vg 32

2. changed new lv to be type 'copy'

Code:

# chlv -t copy lvcorenew

3. Ran cplv

Code:

# cplv -e lvcorenew -f lvcore

4. Created new jfs2log for the new lv

Code:

# mklv -y corelog -t jfs2log data2vg 1

5. Formated the new jfs2log

Code:

# logform /dev/corelog

6. Modified the existing filesystem to use the newly copied lv

Code:

# chfs -a dev=/dev/lvcorenew -a log=/dev/corelog /usr/local/corefiles

7. Mounted fs

Code:

# mount /usr/local/corefiles

8. Check filesystem

Code:

# ls /usr/local/corefiles