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?
#yiv4832981647 #yiv4832981647 -- _filtered #yiv4832981647
{font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv4832981647
{panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv4832981647
{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv4832981647
#yiv4832981647 p.yiv4832981647MsoNormal, #yiv4832981647
li.yiv4832981647MsoNormal, #yiv4832981647 div.yiv4832981647MsoNormal
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;color:black;}#yiv4832981647
a:link, #yiv4832981647 span.yiv4832981647MsoHyperlink
{color:blue;text-decoration:underline;}#yiv4832981647 a:visited, #yiv4832981647
span.yiv4832981647MsoHyperlinkFollowed
{color:purple;text-decoration:underline;}#yiv4832981647
span.yiv4832981647EmailStyle17 {color:#1F497D;}#yiv4832981647
.yiv4832981647MsoChpDefault {font-size:10.0pt;} _filtered #yiv4832981647
{margin:1.0in 1.0in 1.0in 1.0in;}#yiv4832981647 div.yiv4832981647WordSection1
{}#yiv4832981647 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.**
