Good thoughts Seth.
I hadn't thought about the middle tier or load balancers. We have a
kick-off meeting tomorrow and I'll bring these items up with the main
system architects (I'm only charged with the DB part).
I've implemented old-school physical standbys, but not the newer versions
of Data Guard. Thanks, I'll have to read more on FAN and TAF. The app side
uses jdbc.
Woody
On Tue, Jun 28, 2016 at 1:13 PM, Seth Miller <sethmiller.sm@xxxxxxxxx>
wrote:
Woody,
You briefly mentioned cost. If that is a factor then the hypervisor you
choose will potentially make a huge difference in cost.
Does "no app fail-over" mean you are planning on restarting the middle
tier? Perhaps you would be using a load balancer?
Keep in mind that going from the network to the data link layer in the OSI
model, the IP address is mapped to the physical or logical MAC address.
Each server keeps a cache of these mappings called the ARP cache. If you
failover to a different VM with a different MAC address (even if it has the
same IP), the middle tier will not know about the new MAC address right
away and will continue to try to communicate with the MAC address of the
failed VM until a network timeout is reached at which time the middle tier
server will send a broadcast message requesting the new MAC address
belonging to the IP address it is trying to reach. In other words, it may
not be as simple as "no app failover".
Data Guard on the other hand enables the middle tier to see all of the
database servers at all times. It can proactively switchover and failover
using messages from clusterware called fast application notification (FAN)
and transparent application failover (TAF) making maintenance and outages
much less painful for the users and the administrators.
VM failover can save on licensing costs and is an acceptable solution as
long as you can afford the potential data loss, the time required for
recovery and failover, and the middle tier is set up properly. Also, keep
in mind that if you are choosing not to license the failover site, you can
only have the database binaries mounted to it for ten days per year in
total.
Seth Miller
On Tue, Jun 28, 2016 at 10:47 AM, Woody McKay <woody.mckay@xxxxxxxxx>
wrote:
Hi,
In a few days, I need to start investigating maintenance and viability
for a DB redundancy solution for 2,700 Oracle 12.1.0.2 databases on Linux.
Currently, the 2,700 customers are in individual instances, but will be
looking to put them into PDB's later this year.
Leadership has told me that RAC is not an option to be considered. Only
Data Guard and VM with external storage. If the VM goes down, the thought
is to bring up another VM and mount the original storage (san). It's
obvious what to do with Data Guard.
I thought I'd check with the pros here to see what the rest of the best
are doing.
What are the best options for DB redundancy? Considering maintenance,
cost and overall viability. Want to be up 99% and downtime is limited to
45 minutes or less.
The VM option sounds interesting. Just bring up a new VM on the same IP
and mount the same storage - viola. No app fail-over or DNS change, etc.
Got just one DB cost. You would lose in-flight, but that appears to be
acceptable.
Thoughts, pros/cons ? Other better solutions?
--
Sincerely,
WoodyMcKay
