Re: 10g with HACMP (no RAC)?
From: Palooka <nobody_at_nowhere.com>
Date: Wed, 10 Sep 2008 01:45:35 +0100
Message-ID: <kMExk.16763$Yc5.12314@newsfe27.ams2>
>> 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
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.
Date: Wed, 10 Sep 2008 01:45:35 +0100
Message-ID: <kMExk.16763$Yc5.12314@newsfe27.ams2>
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 Received on Tue Sep 09 2008 - 19:45:35 CDT