Home » Other » General » Failover Strategy (Oracle - 11.2.0.4)
Failover Strategy [message #648623] Sat, 27 February 2016 09:30 Go to next message
manishdba007
Messages: 27
Registered: September 2014
Location: India
Junior Member
Hello,

I am planning to create a DR for my project.
FYI this will be a OS level mirroring not through data guard (client decided)

Now there is a prod site where two DB's are running and another one is Dev site where already two DB's are running
Now my manager wants to know that in case of failover is the Dev server strong enough that it can handle 4 running DB's ( 2 dev + 2 prod ) .. ?

Please let me know what are the areas we have to look for before going further .
I am attaching some basic configuration details of Dev server.
Please let me know about rest of the information required.

Regards
Manish
Re: Failover Strategy [message #648626 is a reply to message #648623] Sat, 27 February 2016 09:52 Go to previous messageGo to next message
Michel Cadot
Messages: 68728
Registered: March 2007
Location: Saint-Maur, France, https...
Senior Member
Account Moderator

Bad idea to have on the same server Dev and Prod.
If Prod fails over, shut down Dev.
Now the question becomes simply "is the Dev site has at least the same performances and capacity than Prod?"

Re: Failover Strategy [message #648627 is a reply to message #648626] Sat, 27 February 2016 09:57 Go to previous messageGo to next message
manishdba007
Messages: 27
Registered: September 2014
Location: India
Junior Member
Yes i understand your point but here data is not too important. Yes! they have almost same configuration.
Re: Failover Strategy [message #648630 is a reply to message #648627] Sat, 27 February 2016 10:19 Go to previous messageGo to next message
Michel Cadot
Messages: 68728
Registered: March 2007
Location: Saint-Maur, France, https...
Senior Member
Account Moderator

Even more if data are important you MUST shut down the Dev when your Prod fails over.

Re: Failover Strategy [message #648631 is a reply to message #648630] Sat, 27 February 2016 10:23 Go to previous messageGo to next message
manishdba007
Messages: 27
Registered: September 2014
Location: India
Junior Member
Laughing can i please get something to give my manager ?
Re: Failover Strategy [message #648633 is a reply to message #648631] Sat, 27 February 2016 10:45 Go to previous messageGo to next message
Michel Cadot
Messages: 68728
Registered: March 2007
Location: Saint-Maur, France, https...
Senior Member
Account Moderator

Just ask him if he wants to get developers accessing the prod.

Re: Failover Strategy [message #648635 is a reply to message #648623] Sat, 27 February 2016 11:11 Go to previous messageGo to next message
John Watson
Messages: 8962
Registered: January 2010
Location: Global Village
Senior Member
Typically, performance will degrade when a resource becomes saturated (ie, fully used). So do some arithmetic.
What is the CPU usage on both machines? Is the total less than 100%?
What is the total memory usage of your four instances? Is it less than whatever you have on the one machine?
How about the network traffic? Is the total of both machines enough to saturate the NIC on one?

It isn't this simple, but that would give you a starting point.
Re: Failover Strategy [message #648666 is a reply to message #648635] Mon, 29 February 2016 03:08 Go to previous message
ThomasG
Messages: 3212
Registered: April 2005
Location: Heilbronn, Germany
Senior Member
In my experience performance is usually not eaten up by "running DBs" but by "users doing something" on those DBs.

So, for example, when you have 2000-3000 users active and 5-6 developers active the impact of the developers on the DB server is usually negligible. (unless they are currently developing something in the direction of resource heavy batch runs or something like that). So does the dev server have the same specifications as the prod server?

The important thing would be how you prevent the developers from accessing the Prod DB by accident. If they don't need or have shell access, and only connect via TNSNames from their development machines, and don't even have login credentials to the Prod DBs then that would probably be safe enough.
Previous Topic: New oracle rdbms version
Next Topic: Oracle Processor Licenses
Goto Forum:
  


Current Time: Fri Dec 27 05:18:32 CST 2024