Re: 10g with HACMP (no RAC)?

From: DA Morgan <>
Date: Tue, 09 Sep 2008 22:08:39 -0700
Message-ID: <>

Palooka wrote:
> joel garry wrote:

>> On Sep 8, 3:51 pm, Palooka <> wrote:
>>> wrote:
>>>> On Mon, 08 Sep 2008 21:19:11 +0100, Palooka <>
>>>> 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 (replace x with u to respond)
Received on Wed Sep 10 2008 - 00:08:39 CDT

Original text of this message