1 person found this helpful
You have this alternative:
1.-You can create the new OCFS2
2.- Use RMAN to create image copies of your datafiles
3.-Then Switch to Image Copies for Fast Recovery.
4.-Move the OCr and Voting Files
5.- Move ControlFIle
OCFS2 is a poor choice as RAC storage.
And it is not just me that says so - also the sentiments of Oracle's own RAC quality/assurance experts in my discussions with them.
If you have a new storage layer, why on earth slap OCFS2 (again!) on it? Why not use the LUNs as raw devices, and make use of ASM?
What does OCFS2 provide (real tangible benefits) that ASM would not?
Thank you for answer
is a project with a customer and already I suggested but don't want to ASM.
It can be duplicated from operating system tools.
Using the dd command or something of the style
Thank you very much.
Then you failed as you are not advising your customer and assisting them in making the correct technical decision.
dd? You must be joking. It is not robust. It lacks error correction.
If you and your client want to continue with the idiocy of using OCFS2 instead of ASM, use RMAN (as already stated) to copy the database to the new mount point.
Alternative, shutdown the database. Do a recursive command line copy of current OCFS2 mount to new OCFS2 mount. Unmount both file systems. Mount the new OCFS2 LUN using the old OCFS2 mount point. Open the database.
And with ASM this could have been done online, with database(s) up and running, and not a single second downtime...