One correction, automatic failover only occurs if you have the observer
configured. And there are a decent number of configurable parameters for
that. THe database will stop if it loses connection to the standby in
maximum protection mode and observer is not configured, it will not
failover automatically.
On Thu, Mar 3, 2016 at 1:15 PM, Chris King <ckaj111@xxxxxxxx> wrote:
Thanks everyone. This is an excellent discussion.
In this particular case, I believe DataGuard is what this customer needs.
But they are afraid of possible data loss .I am aware of the maximum
protection mode, but if the network experiences the least bit of a glitch,
failover will automatically occur. That seems more risky than setting
parameters to write redo every 15 minutes, and then accept the possible 15
minutes of data loss, should the primary fail moments before it is about to
write the next archived redo log.
RAC doesn't protect against data loss as much as against the loss of one
node. But compared side-by-side, if one server goes down, and it's a RAC
node, no data is lost. If the node that goes down is the primary server in
a DG configuration, there could be data loss.
------------------------------
*From:* "Ruel, Chris" <Chris.Ruel@xxxxxxx>
*To:* "tim@xxxxxxxxx" <tim@xxxxxxxxx>; "andrew.kerber@xxxxxxxxx" <
andrew.kerber@xxxxxxxxx>; Jeremiah Wilton <jcwilton93@xxxxxxxxxxx>
*Cc:* "ckaj111@xxxxxxxx" <ckaj111@xxxxxxxx>; Oracle-l Digest Users <
oracle-l@xxxxxxxxxxxxx>
*Sent:* Thursday, March 3, 2016 1:41 PM
*Subject:* RE: cost-effective, low-performance options for RAC?
Maybe it’s just a matter of personal differences with definitions of HA,
but, I have always professed to customers that HA is one of the hallmark
features of RAC (along with scale out) as it allows *properly designed*
applications to take advantage of failover for both planned and unplanned
outages through TAF or a mechanisms like Active Gridlink for Oracle through
Weblogic. Things like rolling patches or hardware failures at the node
level can be sustained without outage via a proper RAC implementation.
On the other hand, to me, Data Guard is not as much an HA solution as it
is a DR solution. Data Guard, no matter how hard you try, will not provide
seamless failover. I will admit, that what I am saying is very academic as
it is rare that I have encountered applications that have been properly
designed for take advantage of RAC’s TAF for failed transactions. Seems
like most apps these days use JDBC thin clients that automatically preclude
you from using TAF unless you have them connected through a Weblogic
connection pool that is protected by Active Gridlink for Oracle.
So, even a customer, as described below, could take advantage of/need RAC
if that have a need for Five 9’s and their application is appropriately
designed. Which brings up another argument, half the time, people that
think they need five 9’s don’t, or, only one component of their application
infrastructure has it (i.e. the database, but, not the storage or app-tier).
My 2 cents anyway.
Chris..
_____________________________________________________________________
Chris Ruel * Oracle Database Administrator * Lincoln Financial Group
cruel@xxxxxxx * Desk:317.759.2172 * Cell 317.523.8482
*From:* oracle-l-bounce@xxxxxxxxxxxxx [mailto:
oracle-l-bounce@xxxxxxxxxxxxx] *On Behalf Of *Tim Gorman
*Sent:* Thursday, March 03, 2016 1:17 PM
*To:* andrew.kerber@xxxxxxxxx; Jeremiah Wilton
*Cc:* ckaj111@xxxxxxxx; Oracle-l Digest Users
*Subject:* Re: cost-effective, low-performance options for RAC?
HA is not a practical use-case (by itself) for RAC. If HA is their
requirement, they should use Data Guard.
Performance scalability is the practical use-case for RAC. Your customer
has self-selected themselves out of that use-case, but apparently they'd
rather spend more money, time, and effort to get to the same place. C'est
la vie...
On 3/3/16 10:46, Andrew Kerber wrote:
You can run RAC over iscsi and dnfs according to the oracle
documentation. But I agree with you, sounds like they probably dont need
it that badly, unless its solely for HA.
On Thu, Mar 3, 2016 at 11:37 AM, Jeremiah Cetlin Wilton <
jcwilton93@xxxxxxxxxxx> wrote:
You could build something like this on smaller EC2 instances.
http://aws.amazon.com/articles/7455908317389540
Jeremiah
------------------------------
*From: *"Chris King" <ckaj111@xxxxxxxx>
*To: *"Oracle-l Digest Users" <oracle-l@xxxxxxxxxxxxx>
*Sent: *Thursday, March 3, 2016 8:54:11 AM
*Subject: *cost-effective, low-performance options for RAC?
I was asked an odd question today. A customer is determined to use an
Oracle RAC solution, and we are trying to convince them that in their case,
this is too big a solution for what they need. In the meantime, however,
I've been asked a few interesting questions, which I would love to have
your feedback on.
The customer's requirement is for a small database, with only 200 users
maximum, and not concurrent users. We're not looking for high-performance
because the database will not be heavily used.
I've always used fibre connects with Oracle RAC. Is it possible to run RAC
with something other than fibre? I've been asked if we could run RAC with a
single SAS attached disk array.. I'm assuming not, but maybe there are
other lower-cost RAC compatible storage and network connectivity options.
May I have your feedback on this?
Thanks!
-ChrisK
--
Andrew W. Kerber
'If at first you dont succeed, dont take up skydiving.'
Notice of Confidentiality: **This E-mail and any of its attachments may
contain
Lincoln National Corporation proprietary information, which is privileged,
confidential,
or subject to copyright belonging to the Lincoln National Corporation
family of
companies. This E-mail is intended solely for the use of the individual or
entity to
which it is addressed. If you are not the intended recipient of this
E-mail, you are
hereby notified that any dissemination, distribution, copying, or action
taken in
relation to the contents of and attachments to this E-mail is strictly
prohibited
and may be unlawful. If you have received this E-mail in error, please
notify the
sender immediately and permanently delete the original and any copy of
this E-mail
and any printout. Thank You.**
