oracle program files copy takes long time

[Aaron_4]

We are migrating our data from one EMC Sym to another. Typically, we will have the Oracle product files on u01 and the database files on u02-u05. We create temporary filesystems from the new Sym and copy up01-u05(old sym) to u01temp-u05temp(new Sym). /u01 is about 20gig and u02-u05 are over 150 gig. The problem is that u02-u05 takes less than an hour and u01 takes about 3 hours. Yes, u01 has more directories,files but less data than u02-u05. Maybe the system takes more time to create file structures than to to copy data. Any other ideas??

[Steven E. Protter]

If the data is mirrored,you could try breaking the mirror and assigning the virtual disk from source to target machine.

Is the disk set up for raid 10 or raid 5? On our array both settings are possible. There is a hugely noticeable performance penalty for using Raid 5.

If the transfer does succeed then largefiles is obviously set correctly.

P

[harry d brown jr]

What are you using to copy the files ???

live free or die
harry

[James R. Ferguson]

Hi:

Are the filesystems VxFS ones with different mount options? If so, that could make a noticable difference.

Regards!

...JRF...

[Aaron_4]

There all vxfs file systems. They were all created at the same time so same mount settings. I've tried on another system and same thing happens.

[GIRIJA SWAIN]

Hi
I have noticed same problem. The Oracle product files taakes longer time to copy as some root processes or Oracle processes keep the library files open. If you shutdown the database there is no open connection to u2-u5, so it is first. Try using fuser -cu and kill those processes holding file open in u1.

[Jeff Schussele]

Hi Aaron,

Assumptions are inherently risky. Just because they were created at the same time does not guarantee they're mounted the same way.
It's common practice to set different mount options (mincache=direct, convosync=direct, etc.) to improve performance on Oracle data & index extents. But these come at the cost of slower "normal" OS operations - like copies.

Check your mount options for these FSs in /etc/fstab.

Rgds,
Jeff

[Aaron_4]

The database was down. I did not use fuser -cu to look at processes. I will try to kill all the processes for that filesystem next time. I looked at the fstab and nothing more than largefiles option.

[Brian Crabtree]

You might want to see how many files are there. I have found that having a large number of small files (ie: daily logfiles) has caused copies to take a long time to complete. You can sometimes reduce this by tarring the directory and copying the tar file, sometimes not. Searching through and seeing if there are old files that are not required anymore would be a good option.

Brian

[Greg OBarr]

1) I would check the syslog file to be sure you're not logging disk errors.

2) Are you using cpio to copy the files?

3) You could also extend the filesystem to a mirror copy online and then when you're ready to duplicate the filesystem, just shutdown the database, break the mirror, and mount the mirror LVs as separate filesystems.

-greg