Sky13 wrote:To troubleshoot that, you need to enable debug tracing in the listener in order to see just what happens with the listener handoff to a dedicated server process.
I agree with the problem isolation as trouble shooting always comes down to that. I think I have done some of that at a high level by looking at the logs. It seems to be pointing at hand off from the Listener to the Database but just for the first one.
I was reading Doc ID 561429.1 and it seems to match and applies to my version of 184.108.40.206. We are planning to upgrade to 220.127.116.11 anyway so I will keep you all posted to what happens after the upgrade.As I read it, this is not a 18.104.22.168 bug - the same problem will still exist after a 22.214.171.124 upgrade. The note states that the problem is with the getaddrinfo() kernel (socket) call. That remains unchanged as the kernel and socket call interface do not change with an Oracle RDBMS upgrade.
So this specific issue described in that note is a network related issue (the note refers to DNS misconfiguration). This means host and IP resolution is a problem. Nothing to do with RDBMS bugs in my view (having written network server code in the past).
The getaddrinfo(3) function combines the functionality provided by the getipnodebyname(3), getipnodebyaddr(3), getservbyname(3), and getservbyport(3) functions into a single interface. The thread-safe getaddrinfo(3) function creates one or more socket address structures that can be used by the bind(2) and connect(2) system calls to create a client or a server socket.