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

Nigel,

I agree about running tnsping. I plan on running my own tests today and the first step is to run tnsping starting with a 10 count, incrementing by 10-fold with each successive run, and parsing the output to get the min, max and average response times. I do know we have been faked out in the past due to a SQL*Net proxy server in the firewall returning our tnsping rather than the actual target listener, but I don't believe this will be the case on these two WANs.

Up till now I have only been brought in so that ideas could be bounced off of me. I have not been the one actually doing the testing. I have tried to emphasize the importance of consistency. By consistency I mean running the tests across each WAN with a minimal number of variables. For instance, originally it was my understanding that the materialized view refresh was 10g to 10g, but yesterday I found out that the source is 9i and the target is 10g, but some of the tests were done 9i to 9i and others 9i to 10g. My opinion was that those tests are invalid. The two DBAs who have been wrestling with this issue are currently rerunning those tests.

David

On Feb 1, 2008 4:21 AM, Nigel Thomas <nigel_cl_thomas_at_yahoo.com> wrote:

> David
>
>
>
> Just a quick thought: you say they've blocked ping, but (pardon my network
> naivety if necessary) is there a reason you can't tnsping? If you can run a
> few tnsping samples over both routes you would soon know if there are
> inherent differences in network latency.
>

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