VMware Cloud Community
robpetersen
Contributor
Contributor

P2V of Oracle databases

I have two seperate oracle databases that are overlapping one older version and one newer version

I would like to convert the databases into virtual machines but i need to do it with minimal down time

1) What would i need to concider when taking on this task (Best Practices)

2) How long would the P2V take per Gig of data

3) Is there a way to minimize the down time

4) Is there and alternative solution such as mirroring

Kind Regards

Roberto

Tags (1)
Reply
0 Kudos
3 Replies
Gkeerthy
Expert
Expert

Which version of VMware convertor you are going to use, and on which os the oracle is installed.

1) What would i need to concider when taking on this task (Best Practices)

refer the relese notes of the convertor for the OS compatibility

it is good to stop the DB instance because if the rate of change of DB is high then some corrouption may occur

if the OS if rhel 5.x or windows 2003, then you need to use the vmware covertor 5.1 so that you can align the partition, after the conversion it wont be a straight forward process and easy

2) How long would the P2V take per Gig of data

depending upon the size the network bandwidth the convertor machine speed etc... the storage performance etc.. lot of things there no single answer

3) Is there a way to minimize the down time

give more cpu and ram for the vmware converter machine.... and use a dedicated datastore in the destination and check the array performace.. that is do during the off peak hours.

4) Is there and alternative solution such as mirroring

it is easy and good to do a fresh installation...and restore the DB from a latest full backup... and then do a mirroring...by using oracle tools..

Please don't forget to award point for 'Correct' or 'Helpful', if you found the comment useful. (vExpert, VCP-Cloud. VCAP5-DCD, VCP4, VCP5, MCSE, MCITP)
Simon_H
Enthusiast
Enthusiast

I agree. Actually that last suggestion is quite appealling to me - do a clean Oracle installation in the a VM, use RMAN to do an image copy and then full restore onto the VM, then recover up to the last archive log - you can then suspend the application, do a final log switch and transfer, then apply it to the new database. At that point you should have two identical databases - you can do a sanity check of the new one and finally switch over the application to it (using tnsnames, JDBC config or whatever). That way you minimise your downtime, present no performance risk to production (no more than a full backup anyway) and have a very easy roll back if anything goes wrong. You could also do a few test runs (without the final log switch) so you know how long the process takes and to iron out any wrinkles.

The only downside to this seems to be if there's other stuff installed on the database server (code for batch jobs, directories with files for loading and so on). Depending on how much there might be of this, and how well it is documented, you might find it easier/safer to try to take everything over in one go using P2V.

robpetersen
Contributor
Contributor

Thanks for the help i will take all this into concideration when going forward with this

Reply
0 Kudos