Re: The problem is that SQL*Net is too chatty, because FTP runs fine.

I got hung up on "set up as a tunnel". In my limited experience that sounds like you're going out on the public internet rather than a dedicated T1 or what have you. Again, in my limited experience, that means all bets are off as far as performance goes. Is the SW connection the same?

Finn

On 1/31/08, David Taft <oradbt054_at_gmail.com> wrote:
>
> Mark,
>
> It is a materialized view complete refresh. The source is always the same
> (US-EC). The ultimate target is in a new data center (US-SE). This refresh
> was duplicated to US-SW as a sanity check comparison. Your last statement
> about the queue situation is interesting. When we graphed our throughput
> testing on the refresh, it does start out faster and then steps down over
> time. We are in the process of rerunning all tests. One piece of info I
> was given before needs to be corrected. When asked in a meeting (I didn't
> attend), the network group did say they could give us traceroute statistics,
> but they said it wouldn't show anything because our connection is set up as
> a tunnel. I am guessing that means that even if there are router hops along
> the way, we can't see them from inside the tunnel? Also, I agree with
> everything you said in the second paragraph. I got pulled into this
> situation after it had already progressed to the point it is at now. I am
> hoping we can find a resolution rather than digressing to trying to prove
> somebody else's stuff is the problem.
>
> David
>
>
> On Jan 31, 2008 4:16 PM, Mark W. Farnham <mwf_at_rsiz.com> wrote:
>
> > Is there some reason that you think the amount of data across the
> > network
> > will be the same for the US-SW to US-EC refresh as for the US-SE to
> > US-EC
> > refresh? I guess I am getting at precisely what do you mean when you
> > write
> > "That same refresh...?" Are duplicate threads of changes being made at
> > US-SW
> > and US-SE so when the refresh is made data is identical? Are they both
> > complete refreshes?
> >
> > And of course it is entirely possible in a queue situation to have a
> > large
> > chunk transmitter like FTP work okay while a small chunk, chatty
> > tranmitter
> > like a materialized view refresh gets differentially slower and slower.
> > Think of an up escalator feeding a slide. One person per step, no matter
> > how
> > big (or small). Even though the occupation of the slide is low and the
> > large
> > persons move many pounds down the slide relatively quickly and the itsy
> > bitsy children get just as many turns on the up escalator, the little
> > kids
> > move pounds down the slide very slowly.
> >
> >
>

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