Re: 10g with HACMP (no RAC)?

From: DA Morgan <damorgan_at_psoug.org>
Date: Tue, 09 Sep 2008 22:08:39 -0700
Message-ID: <1221023319.170425@bubbleator.drizzle.com>


Palooka wrote:
> joel garry wrote:

>> On Sep 8, 3:51 pm, Palooka <nob..._at_nowhere.com> wrote:
>>> sybra..._at_hccnet.nl wrote:
>>>> On Mon, 08 Sep 2008 21:19:11 +0100, Palooka <nob..._at_nowhere.com>
>>>> wrote:
>>>>> Besides which, there are actually some reasons not
>>>>> to go with RAC. Firstly, the application vendor doesn't actually 
>>>>> support
>>>>> it.
>>>> That would be the perfect reason to replace the application.
>>>> RAC is transparent to the application.
>>>> If  a vendor states
>>>> 'We don't support RAC'
>>>> this likely means 'My application is unscalable and it mightily sucks'
>>>> Note most application vendors still promote the 'database independent'
>>>> fairy tale, and a whole lot of so-called DBAs rather manage a mess and
>>>> get fired in the end, than to set up things professionally.
>>>> You seem to be no exception to this rule.
>>>> Your case is lost, yet you continue to defend it.
>>>> You will notice your case is lost SOON. Let's only pray Herr Weber is
>>>> there to help you out.
>>> So the client decides on an application, and we are brought in as
>>> integrators for a fee of around 2m. We are supposed to turn this down,
>>> are we, because the client may not have made the best choice?
>>>
>>> As I said, some of us live in the real world.
>>>
>>> Palooka
>>
>> 2m to bring in someone who asks for a cookbook???  And RAC is too
>> expensive?  I tend to come down on the side of "real world," but that
>> just seems an alternate universe.
>>
>> I don't know if I should say I'm in the wrong business or be glad I'm
>> not in the right business.  Sybrand seems to be understating the
>> case.
>>

> No, I am a reasonably competent DBA, but without experience of HACMP. I
> have been tasked with implementing the chosen solution in an IBM shop,
> which is why I requested some guidance, and which some posters were kind
> enough to provide.
>
> In any case, Sybrand is way off base this time with his assumptions. The
> application is not database agnostic, and has been benchmarked using IBM
> facilities; it is limited in that the vendor does not support RAC,
> except in an active/passive configuration, and the vendor has openly
> stated that without major code changes, it will not scale at all with RAC.
>
> Thus the issue at hand is resilience, rather than scaleability. Agreed
> that RAC or DataGuard could offer transparent failover, but the
> application itself is another component of the stack, and requires a
> minute or two downtime in the event of failure.
>
> Palooka

Yet again ... why not Data Guard? For what technical reason?

-- 
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu (replace x with u to respond)
Received on Wed Sep 10 2008 - 00:08:39 CDT

Original text of this message