June 4, 2009 at 12:57 pm
Hi All,
We are experiencing an issue that is running me in circles.
Our lab machine is AMD 64 bit, 8 processors, 4GB RAM with Windows Server 2003 (NT 5.2 – 3790)
SQL is 2005 EE (64 bit) 9.00.4035
Our application is connecting (trying to connect) using a domain account. This setup works fine with the 32 bit versions of Windows Server, SQL 2000, and SQL 2005 both SE and EE.
On the 64 bit version the application frequently does not connect successfully and the following is placed in the App Event Log on the application server.
Database: CdboPropertiesByNodeID::OpenDataSource
HRESULT: 0x80004005
Failed after 3 attempts.
An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections.
Communication link failure
Named Pipes Provider: No process is on the other end of the pipe.
This error is “expected” since we don’t have named pipes enabled in the SQL Server network configuration. We do have SharedMemory and TCP enabled. It appears that the client tries TCP which fails for some reason and then falls back to Named Pipes which are not enabled.
I don’t see any logged errors related to TCP on either the application or database server.
SQL Profiler does not record any failed connection requests.
Using the same domain user account, I can connect to the database server from other machines including the application server and execute queries.
Any ideas?
June 10, 2009 at 6:38 pm
We have been having similar problems. After extensive diagnostics, we've come to the conclusion that there is a subtle 'bug' when connecting from a 32-bit client to a 64-bit database.
My best guess is that some in-memory control structure for the database gets confused/corrupted. The only workable fix so far is to take the database offline, then immediately bring it back online. This fixes the issue until the next time it happens, which may be never, soon or later.
By the way, if you have replication on the affected database, you MUST stop replication and kill all connections to the database before taking it offline.
Hope this helps.
Peter
June 11, 2009 at 9:09 am
Hi Peter,
Thanks for the reply.
We are pretty sure we have this resolved now and it turns out to be a client issue with TCP/IP Sockets. This Microsoft Support Article http://support.microsoft.com/kb/328476 describes the symptoms of the problem pretty well.
In one particular condition, our client application is opening and closing connections very rapidly. Basically this ends up placing every Client side socket in a "TimeOut" state so after a few seconds the ~4K ports are all Not available and further connections requests are refused by TCP/IP on the client side. Apparently the OLEDB/ODBC drivers indicate this is a database error 🙂
Check out the article and see if it applies to you.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply