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>
> 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
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