Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

We need to migrate the storage of our production database. What is the appropriate method of doing so and what specific/generic precautions do we need to take??

Database Configuration:
Volume Manager - ASM using Raw Disks. ASM External Redundancy as storage is published from storage subsystem
Database version - Oracle 10g R2
Database Size - 5TB approx.

Existing Storage (source): HP MSA 2312sa Dual Controller. Directly connected to our database server (no fc or ethernet switch).
The Oracle binaries are also on this storage

New Storage (Target): HP EVA6300 FC storage. This storage will be connected to the hosts via FC switches.

Can we use host based storage migration like VxVM Plex attach/dettach to copy data from source LUNs to the target LUNs?
Do we have to use Oracle RMAN backup and recovery method for storage migration?

share|improve this question

migrated from serverfault.com Aug 25 '11 at 18:53

This question came from our site for professional system and network administrators.

    
As this is a DB specific question I'll move it to DB.SE. –  Chopper3 Aug 25 '11 at 18:52

2 Answers 2

up vote 4 down vote accepted

There is no need to copy the files - there is an ASM "trick" that does exactly what you want to do with no interruption in service. When ASM rebalances a disk, it maintains a list of viable LUNS for each block independently of the LUN on which it presently lives. It also won't drop a disk on which there are active blocks without rebalancing elsewhere - but it will mark it as not a viable home for rebalancing!

Once you have used oracleasm to make the new LUNs visible to ASM, you just issue the single command (forgive syntax, off the top of my head)

alter diskgroup my_dg add disk 'new1', 'new2', 'new3' drop disk old1, old2, old3;

Then sit back and wait. ASM will hot-relocate each block from the old storage to the new, laying them out nicely on the way, and drop the old disks when the operation completes. I/O will be a bit higher, but your users probably won't notice a thing.

As for your ORACLE_HOME, I'm afraid switching that will require a (brief) outage.

share|improve this answer
    
Thank You for the answer, it's of great help. I'll try it on our test bed before taking it to the production. However i guess since this is destructive copy (like mv command) we need to have a consistent backup (cold backup) of the database. –  Jack Aug 25 '11 at 20:18
    
A regular RMAN backup will suffice - no need to shut down the DB for that either. You can to a surprising amount of stuff with Oracle "hot". ASM is very cautious by nature - it will make absolutely certain that it has a good copy of the block before removing the original. Remember that it rebalances all the time anyway... –  Gaius Aug 25 '11 at 20:29
    
Thanks. Your answer is appreciated. –  Jack Aug 26 '11 at 5:31

Do we have to use Oracle RMAN backup and recovery method for storage migration?

I may not have understood correctly, but perhaps you can add the new target to ASM (as a new diskgroup) and copy the database files across with RMAN or DBMS_FILE_TRANSFER?

Neither method involves "backup and recovery" - just two ways of copying the files

share|improve this answer
    
Thank you for the answer. To sum it up, let me put it this way- Bring down the database; Create a new ASM Disk Group using the New (target) luns; Use DBMS_FILE_TRANSFER (or RMAN) copy from source to target; Once the copy is complete Bring Up the database with the new disk group. –  Jack Aug 25 '11 at 20:03
    
"Bring Up the database with the new disk group" is not quite right - the disk group is added at the very beginning and is part of the instance from that point on. "Rename the file(s) and bring up the database" is how I'd put it. But what Gaius suggests sounds like a pretty neat alternative. –  Jack Douglas Aug 25 '11 at 20:38

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.