Re: If you have a databaselink to a databae in the same server you should be using ipc

Hi Niall,
I might have been overreacting slightly, and maybe I need to rephrase to: [...] If you want to risk suffering from possible bad performance due to implementing a sub-optimal protocol for a database link [..]

I think there is nothing wrong having a natural drive to implement optimal techniques, if they score the same as suboptimal techniques. At configuration time one thinks about it all, when performance problems appear it will likely take far more time to find the root cause and solve it. I've seen programmers defining variables for 8.3 filenames as char[MAXSTRING], taking 65K each. That's the attitude I dislike. I was in an R&D department for a couple of years. There I learned to focus on 'optimal' solutions, and doing the right trade-off. Fear wasn't included in this process.

BAARF is another topic. Of course merely read-only system don't suffer from RAID-5. When you know that up front, and there is no reasonable chance that the system behaviour will change, and no other systems will be stored on the same array, the money saving is a good reason.

The IPC/TCP thing is different. When the TCP connection performs all-right, but another application saturates your network, It can take you quite some time to discover why the database app is slowing down. And yes, there is probably a bigger problem to solve.

And the bottom line is: fear on itself is a bad advisor. Don't know whether this is the right translation of Dutch idiom, but I think the phrasing in English is understandable.
Best regards,

Carel-Jan Engel

===
If you think education is expensive, try ignorance. (Derek Bok) ===

On Tue, 2004-10-12 at 09:59, Niall Litchfield wrote:

> On Mon, 11 Oct 2004 19:13:23 +0200, Carel-Jan Engel
> <cjpengel.dbalert_at_xs4all.nl> wrote:
> > The first time I read this comment I was simply too flabbergasted to
> > react. Thank you Jared.
> > If you want to suffer from bad performance due to totally unnecessary
> > routing of your local traffic through your network stack, be my guest.
>
> I'm not going to touch the issue of documentation of systems, just
> comment on the above. I'm not going to disagree that IPC is
> significantly faster than IP, just disagree that this *implies* poor
> performance. Its like my objection to BAARF - not that the technical
> argument is wrong - just a question as to whether it is relevant. Just
> as when considering RAID as a performance bottleneck you better make
> sure you have an IO limited system, in this case you'd need to make
> sure your network communications are what is eating up your time. If
> they aren't (doing loads of unnecessary sql, missing appropriate
> indexes/stats whatever) then increasing the rate at which data flows
> between client and server can *at best* have no discernible effect. If
> you manage to chuck more work at an overloaded server by doing this
> then things aren't going to be exactly wonderful.
>
> Even if you do find that network IO *is* the dominant bottleneck
> (large SQL*Net duration) I'd wager a pound to a penny that this will
> be down to the app doing row at a time logic, and whilst changing the
> comms channel will be worthwhile *in this case* it is still likely
> that fixing the code would be better.

--
http://www.freelists.org/webpage/oracle-l