I'm using a client pc and i'm connecting via tcp/ip into a local database server. For some reason, after my connection will be idle for a while, then Sql keep alive is checking my tcp connection if it's still active. If the time when keep alive is checking my connection and tcp/ip traffic is high or other reasons, then it resets my connection inside pooling. So the result is that if my connection will be reset ,the first connection which client pc will try to run, it will get exception "TCP Provider, error: 0 - No connection could be made because the target machine actively refused it
" or " Server closed the connection" or something like this. This happens cause client pc will try to connect in a session which there is not exist inside sql pooling. I have set min pool size =10. But i still have the same problem.
after keep alive time
Here is my connection string
Data Source = xxx.xxx.xxx.xxx;Min Pool Size=20; Initial Catalog = WiOrder; user id = xxxx; password = 1234;Connection Timeout=5;
SQL Server does not terminate connections. What you are seeing is being done by the .Net driver on your client machine and is completely normal and expected behavior.
Please see:
https://learn.microsoft.com/en-us/dotnet/framework/data/adonet/sql-server-connection-pooling#removing-connections
Related
I host an azure appservice and sometimes it gets random timeouts on queries that usually take 1ms to complete. The SQL server is hosted in azure too and they talk to each other in a private network. What could be going wrong. It even happens when there is no load and I do one call. 99% of the calls work but it's the 1% that happens way to frequently. It's causing 40 second timeouts for no reason.
There are almost zero open connections. The database is 1200 DTU. The appservice is p3v2 and has always on. Performance to the database seem to be really good except if a query randomly takes really long. It almost seems like there is a connection issue in the azure backbone. It seems to happen almost once every 40 database requests. The transient error rate is higher than I have ever seen on any application. We never hit above 20% DTU but the errors still happen around 1% DTU. It randomly started happening two weeks ago after maintenance from Microsoft. We did not deploy new code during that time.
The exception I see is:
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 0 - A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.) A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 0 - A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.)
From Microsoft Doc,
Cause:
The SQL Server client is unable to reach the server. The server's firewall may have rejected the connection or the server may not be set up to accept remote connections, which might both lead to this error.
Workaround:
Ensure that the firewall on the machine is set up to let this instance of SQL Server to receive connections and to enable remote connections for SQL Server, use the SQL Server Configuration Manager tool.
From here:
When SQL Server clients request SQL Server resources, the client network library sends a UDP message to the server using port 1434. SQL Server Browser responds with the TCP/IP port or named pipe of the requested instance.
Apparently when UDL or SSMS used for connecting remotely to SQL Server instance name, the query for resolving the instance name's port number store's somewhere in client machine.
I tested this by two client machines. When the 1434 UDP port was open first machine could connect to SQL Server instance name. Then I closed the port and tried again with that machine. The first client still could connect without the port being open. Then I tried with second machine but it couldn't connect.
I just wondering how and where this caching takes place?
Client APIs like SqlClient use connection pooling by default to avoid the overhead of name resolution, physical network connection, and authentication every time a connection is opened. When the initial connection is closed, the connection is added to a connection pool where it can be reused the next time another connection with the same attributes is opened. The client API in that case simply retrieves and unused connection from the pool avoiding the significant overhead of establishing the physical connection.
With a named instance, connection pooling also avoids the need to query the SQL Server Browser service every time a connection is opened so this explains your observations. I suspect if you exit and re-launch the application after blocking UDP port 1434, the SQL connection for the named instance will fail due to the failed SQL Server Browser data gram query during the initial connection open.
I have got step by step information on how to enable/set/modify the keep alive option on MSSQL Server side. But, how to do the same while using ODBC client to connect with MSSQL Server? This is mainly used to close the socket on client side and start reconnecting.
I came across an option called "Connect Timeout
-or-
Connection Timeout", in connection string, which disconnects if there is no connection after that timeout. But i hope TCP keep alive does more than this.
Couple of options would do for me,
1) Is there a keepalive option that could be added in connection string (similar to postgres)?
2) How to get the client socket fd, which connects with the MSSQL Server, (without using OS commands) so that, i could use setsockopt API and enable keep alive
I am trying to identify SQL connection leaks in my application. After some operations, when my application is idle (user not doing any activity), I see 7 connections with my database in the result set returned by sp_who2. The status for all connections is Sleeping and Command value for all of them is AWAITING COMMAND.
I am using connection pooling but Connection Lifetime is not specified in the connection string. This means that it's default value 0 will be used if I am right. Connection Lifetime having value zero means SQL server should not close connection ever, right?
I keep my application idle for some time (15-20 minutes) and then I see that sp_who2 does NOT show any connection with my database. I am wondering why I get this result when Connection Lifetime is zero. Does SQL Server terminates unused connection after some time regardless of the Connection Lifetime value?
How can I identify which connection is open due to leakage and which is hanging around there due to connection pooling?
My application supports SQL Server 2008, 2014 and 2016. It's ASP.NEt application.
Connection Lifetime having value zero means SQL server should not close connection ever, right?
No. The rules used to purge the pool are not well documented AFAIK, but they can be closed by the pooler. Refer https://msdn.microsoft.com/en-us/library/8xx3tyca%28v=vs.110%29.aspx?f=255&MSPPError=-2147217396.
I don't think there is a reliable/documented method to identify pooled connections from within the database engine.
I develop an SMS Server that receive SMS, Analysis them and reply to messages. This application developed with entity framework 4.0 and SQLServer 2008.
When I receive SMS I run new thread for that message and analysis and response to message. Each thread has its own new instance of object context and all threads call same stored procedure in SQL Server.
But when large number of SMS arrived to server and number of thread increase, I get one of these 2 error each time:
The underlying provider failed on
Open. A connection was successfully
established with the server, but then
an error occurred during the pre-login
handshake. (Provider: TCP Provider,
error: 0 - The specified network name
is no longer available.)
OR
The underlying provider failed on
Open. A connection was successfully
established with the server, but then
an error occurred during the login
process. (Provider: TCP Provider,
error: 0 - The specified network name
is no longer available.)
I increase Max Pool Size and Connect Timeout to 400 and 150.
Can anyone help me??
Thanx
You might try increasing the timeout setting in SQL Server. The default is 10 minutes.
http://msdn.microsoft.com/en-us/library/ms189040(v=sql.105).aspx
Might be because some connections still get available. Try to do this :
sp_configure 'user connections', 0
go
reconfigure with override
Also check your server properties, in Connections section, that your parameter : Maximum number of concurrent connections is set to 0 (unlimited).
In my opinion, 98% sure, because I recently had the same experience, it is a network issue from the server provider.
for instance: if you are rent the server from Ionos, by default all remote connections are blocked, even though you disable the firewall in the server. you still won't be able to connect remotely. You can, however, do your work on the server without any problem.
To connect remotely, you have to contact the Server provider. They will explain how to enable firewall ports from your control panel.
I contacted my server provider as I almost get frustrated.
here was their response.
click to see the snapshot of their response
And, whola!! every permitted client can connect remotely to the server.
I wish you success.