Good day helpful forum users!

I am tasked with coming up with a solution to an Oracle migration from physical hardware to VMWare.

I have to come up with a number of different methods for the configuration on RedHat for HA.

My question to you is... Has anyone done this migration before? I am after your experience, any documentation you've read, any assistance at all.

I'm hoping to avoid the price overhead of having Oracle RAC for HA, so I was hoping to use RedHat clustering with a Quorum disk of sorts. I'm assuming we use GFS with this, but I'm wondering if anyone has done this before? And is there any performance hits you've noticed? Currently, the Oracle DBAs have four physical machines running 'packages' which are redundant across the four nodes... I'm hoping to add some HA over the top, but in VMWare, as we all know that DBA's are concerned with lots of things... If I can give them a 'feature' they don't currently have, that would be awesome.

Please, ask questions of me, send me your advice, or anything that might point me in the direction of white papers etc... I have googled this, and there's not a lot that I could find, it all leads back to using RAC etc.

Thank you!!

Xen.

xenner, I appreciate an adventurous spirit, but I don't think this is a good idea (in the sense that Oracle is all but certain to refuse to support it).

If your goal is HA (Oracle RAC does more than just HA, as you may know), you may wish to explore the "Data Guard" extension, for use with a standby server.

1 members found this post helpful.

Also if Oracles 12g DB is a must use
it would be wise to run it on Oracles clone of RHEL ( Oracle Enterprise Linux 6 )

it is explicitly optimized and configured to run the Oracle db

and runs that db the fastest

1 members found this post helpful.

Hi guys,

Thank you for your response. It's very much appreciated.

I will look into Oracle's clone of RHEL, and see what I can discover.

I'm certain I've worked at a company that had all native RHEL clustering with a quorum disk, and Oracle supported it... It was, however, all physical, no VM's involved. Perhaps that's the catch?

We are looking for an alternative to RAC, which is what spawned this question. I will also look into "Data Guard".

Thank you both for your assistance.... Any further information would be helpful also. I'll see if I can contact the old employer and they might be able to shed light on what they actually had in place... I will paste their response here.

Thank you.

We did use Oracle in a VM environment at a place where I worked a few years back...the difference between 'physical' and 'virtual' servers these days is trivial. However, if you are in a corporate environment, and are using both RHEL and Oracle, you need to pay for support from BOTH of them, and take this question to your sales/tech reps at both vendors. Trying to cobble together something for an HA database solution for a company seems like a recipe for disaster.

Check out the Oracle guides:
http://docs.oracle.com/cd/E11882_01/...e.htm#CHDGGBFI

You can use ASM without RAC, but you can also probably use DRDB from Linux as well, or use BCV snapshotting on your SAN (if it supports that feature). Personally, if I was the administrator, I'd not play around...use RAC and enjoy the benefits. As said, it's more than just HA.

1 members found this post helpful.

Hi,

I was referring to support with the "Physicals vs virtual" comment.

I have brought Red Hat to the table and asked the question. Once they give me a response, I'll send that to Oracle and see what they say. Then, I'll post the response on here.

But yes, I would prefer to use RAC, but it all depends on funding. If there's a cheaper method that is supported, the business would prefer to use that. But the catch word is "supported".

Thank you for your assistance! It's awesome and appreciated.

**Insert smiley faces of appreciation here**

Well, DRDB may work, but all that'll really buy you is the ability to use heartbeat to fail over to another DB server, in the event the primary dies. You'll still have a short period of downtime, and if that server starts to strain under the load, you'll have to build another, faster box. RAC avoids all those issues.

The 'business' would ALWAYS want to have a $5 solution which involves the admin sleeping under their desk to keep things going, rather than spending $50 on something that works reliably. Honestly, if funding is that much of an issue for them, they need to use CentOS and MySQL (which are FREE), and learn to live with any downtime. But if their business is important and they want to go 24/7, then they need to pony up the $$$ to do it. Trying to lowball things like this is never a good idea. My typical question would be "Ok, you'll save $XXX by doing this, but how much are you going to lose when your system is down for YYY time?".

1 members found this post helpful.

Oracle's stance used to be that if you were virtualizing Oracle DB you were fully supported if you were on their virtualization platform. In the event that you decided to move to VMware or something else. They would support you to the OS that Oracle was installed on and go no further.

1 members found this post helpful.