Re: Windows refusing connections

  • From: Paul Drake <bdbafh@xxxxxxxxx>
  • To: jheinrichdba@xxxxxxxxx
  • Date: Tue, 12 Jan 2010 13:59:46 -0500

On Tue, Jan 12, 2010 at 1:25 PM, Jason Heinrich <jheinrichdba@xxxxxxxxx> wrote:
> This is a bit obscure and I can't reproduce it at will, but I was wondering
> if anyone here has seen something similar. First the stats:
> Oracle EE Patch 26 (Oct09 CPU)
> Windows Server 2003 SP2, x64, patched to the mega-update MS released about
> the same time as the Oct09 CPU.
> On this particular server, after applying both the patches mentioned above
> at the end of October, my monitoring started reporting sporadic "ORA-12541:
> TNS:no listener" errors.  I've also seen the same error occasionally when I
> do a lsnrctl status, but other clients don't seem to be affected.  Also, the
> same patches were applied to other servers, and they don't have the same
> problem.  Tracing revealed that something is blocking the connection.
> I've tried a few things to resolve this, but nothing has worked so far:
> - Added (QUEUESIZE=200) to the listener.ora
> - Added a second port to the listener for the monitoring.
> - Tried to balance incoming connections between the two ports.  I still see
> the error on both ports.
> Oracle Support says the following: "From the error we see in the lsnrctl
> trace, we see that something is blocking the connection to port 1521, on TCP
> layer, not SqlNet. So, it must be something on the machine at physical layer
> that rejects this connection to port 1521 or 1526." The fact that this
> started after the Windows security patches were applied makes me suspicious
> of that, but I'm uncertain which patch would be the culprit or how to prove
> it, especially since other servers seem to be fine.  Anybody else experience
> this?
> --
> Jason Heinrich


I have seen something similar.
It was with on ms w2k3 r2 x64, but prior to p26.
It had nothing to do with the Oracle stack.
It had to do with the ms DNS server.
Occasionally the DNS server lost the mappings and connections would no
longer find the correct primary host.
As connect time failover was configured, the Oracle client would then
attempt to connect to the server where the standby was located. This
was reported as an issue with the primary database instance, which in
fact was running along just fine as was the listener on that host.

So my question is - how do you know that the oracle client trace that
was uploaded to support, actually was connecting to the intended
server at an OSI layer 2, meaning MAC address?

If it ended up being directed to another server that did not have an
Oracle TNS Listener running on that port ... it could return that type
of error message.

I believe that the work-around that was used was to register the db
server with the ms DNS server daily via a scheduled task.

How much desire do you have for the real root cause?
How much distaste do you have for duct tape?



Other related posts: