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

From: "David Taft" <oradbt054@xxxxxxxxx>
To: "Nigel Thomas" <nigel_cl_thomas@xxxxxxxxx>
Date: Fri, 1 Feb 2008 09:16:13 -0500

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@xxxxxxxxx> 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.
>

Follow-Ups:
- Re: The problem is that SQL*Net is too chatty, because FTP runs fine.
  - From: Carel-Jan Engel

References:
- Re: The problem is that SQL*Net is too chatty, because FTP runs fine.
  - From: Nigel Thomas

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

Other related posts: