I have two mirrored SQL Servers (A and B for example).
I wrote a simple C# program (connect via SqlConnection), which insert rows into DB. When I make failover on server A, the program throws exception, then I try reconnect, and get exception by timeout (**A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: SSL Provider, error: 0**).
When I restart the app, the connection is successfully established (to server B). Next, I make failover on B server, and program throws exception, then I try to reconnect, and its work - connection to A witout restarting program.
My connection string:
Data Source=SERVER_A;Failover Partner=SERVER_B;Initial Catalog=TEST_DB;persist security info=True;user id=USER_LOGIN;password=USER_PASS;Connection Timeout=60;
I also try to set big timeout (60 seconds), and try to clear All sqlconnection pools, clear single pool by connection, but it is not working.
Interesting fact: if I use domain login and password, all works fine!
(user SID are same)
Hard to tell what your exact problem is. Perhaps it's that failovers aren't instant, and can't transfer query state - see https://dba.stackexchange.com/questions/27528/can-availability-groups-provide-seamless-failover-with-no-query-failures. If your application immediately retries the query the failover node may therefore still be in the process of taking over and therefore not ready to accept connections.
Related
We are using SQLLocalDB to connect to a local database. No network access is required - C# Client application is on the same machine as SQLLocalDB. Sometimes I get the following error (only seems to happen on some PCs):
Microsoft.SqlServer.Management.Common.ConnectionFailureException: Failed to connect to server (localdb)\myserverinstancename. ---> System.Data.SqlClient.SqlException: Connection Timeout Expired. The timeout period elapsed while attempting to consume the pre-login handshake acknowledgement. This could be because the pre-login handshake failed or the server was unable to respond back in time. The duration spent while attempting to connect to this server was - [Pre-Login] initialization=27888; handshake=0; ---> System.ComponentModel.Win32Exception: The wait operation timed out
Oddly, it seems to happen if the PC is offline, and if connected to any sort of internet connection and retried, the issue goes away. However, in most cases the connection works fine even when there is no connection.
The closest I've found to my problem is this: Connection to SQL Server Works Sometimes
But that is discussing full SQL Server, rather than SQLLocalDB, and the solution uses "Sql Server Configuration Manager", which doens't work with SQLLocalDB.
My questions:
Does SQLLocalDb use IPv6/TCP for some reason, even when on the same PC?
Is there a way to change these settings for SQLLocalDB?
Or is there a different cause for this issue?
Edit: With help from some of the comments below I realised that the line that fails is when it calls a database creation script. The initial attempt at connection seems to work, but when I run my creation script it throws a "Failed to connect to server".
/// This line works
var server = new Server("(localdb)\myserverinstancename");
/// this line works 99% of the time, but sometimes "failed to connect to server"
server.ConnectionContext.ExecuteNonQuery(databaseCreationScript);
How can I check the database connection using Entity Framework 6?
Here's my code:
using (var context = new DatabaseDataModel(connectionString))
{
if (context.Database.Connection.State != System.Data.ConnectionState.Open)
return;
if (!context.Database.Exists())
return;
context.Items.Add(item);
}
How can I check if the connection is established before adding my items to the database? I can't open the connection because it will take plenty of time in case of corrupt connection string. That means my state check above is meaningless. The same concerns for the context.Database.Exist(), it will also take long time in case of corrupt connection string.
I aim to detect the corrupt connection string before doing any critical operation.
You want to predict if it is possible to connect to your database. Well, this is not possible. There is no way to know if you will connect until you try to. Connection to the db may fail for various reasons:
DB Server is not responding, because SqlServer is down.
The server computer is down (power failure, for example).
The server you connect to does not exist.
The server exists, but you connect on wrong port.
The database refuses connection because you are not authorized.
The db server is busy and responds very slowly.
The network is bad / busy and data is transmitted very slowly.
The server is there, but configured in such a way that it refuses your connection. For example, it wants TCP, but you try named pipes.
And many more. It is absolutely impossible to validate against all these.
I have a database in azure which have standart s2 edition.In logs of my application I always see many exceptions such formats:
1.
System.Data.SqlClient.SqlException: The client was unable to establish a connection because of an error during connection initialization process before login. Possible causes include the following: the client tried to connect to an unsupported version of SQL Server; the server was too busy to accept new connections; or there was a resource limitation (insufficient memory or maximum allowed connections) on the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.) ---> System.ComponentModel.Win32Exception: An existing connection was forcibly closed by the remote host
2.
System.Data.Entity.Core.EntityException: The underlying provider failed on Open. ---> System.InvalidOperationException: Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached
3
System.Data.SqlClient.SqlException (0x80131904): The client was unable to establish a connection because of an error during connection initialization process before login. Possible causes include the following: the client tried to connect to an unsupported version of SQL Server; the server was too busy to accept new connections; or there was a resource limitation (insufficient memory or maximum allowed connections) on the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.) ---> System.ComponentModel.Win32Exception (0x80004005): An existing connection was forcibly closed by the remote host.
I use SqlAzureExecutionStrategy so this exceptions are thrown after some number of retries.
I see different performance metrics on azure portla,but it seem they are ok.
How can I identify the problem?
I think that your database is under too heavy load, or you have some queries which are still running or not letting go of the connection.
I use this query to see what is running:
SELECT (SELECT TOP 1 SUBSTRING(s2.text,statement_start_offset / 2+1 ,
( (CASE WHEN statement_end_offset = -1
THEN (LEN(CONVERT(nvarchar(max),s2.text)) * 2)
ELSE statement_end_offset END) - statement_start_offset) / 2+1)) AS sql_statement,
s1.* FROM sys.dm_exec_requests s1
CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS s2
ORDER BY 1
See if you have queries still running here or keep an eye on the CPU usage in the Azure portal.
The S2 databases aren't particularly good and it will throttle your requests so if you are doing lots of them (even small ones), it might be rejecting them.
Your retry strategy could also be making the problem worse, but throwing more requests at it when it has already been filled. You could try using an exponential back-off if this is the case.
All three could be explained by your connection pooling design. Are you re-using your connections, or is every call to the database opening it's own connection? Are you closing connections at the end of each DBContext? Are you implementing any kind of caching layer to reduce the number of round trips to your database to a minimum?
Here's a way to see if it is an issue with your pooling. From the portal go to the database in question, look at the Resource utilization graph, then hit edit.
Then add Sessions percentage and workers percentage from the select list, and hit OK.
If your pooling is an issue, you'll find that your sessions and workers percentages are high, and may be pegged at 100% for periods. If you hit 100%, you can be denied new connections for up to 5 minutes until the current sessions and workers either finish, or get killed off.
When I try to do the following code, the program hangs indefinitely. I don't know why and there seems to be other unanswered topics on the matter. Although, if the IP\website cannot be reached, then it works as intended.
private void DoStuff()
{
string connectionString = "Data Source=www.google.com;Connection Timeout=5";
using (SqlConnection connection = new SqlConnection(connectionString))
{
connection.Open(); //Hangs here indefinitely
Console.WriteLine("Test");
}
}
For example, if I set the connection string to
connectionString = "Data Source=www.nonexistentsite.com;Connection Timeout=5";
then it will throw an exception. How do I get it to throw an exception for an active site? ... Also google is just for testing purposes, obviously.
EDIT :
If I try to connect to an unreachable server name or IP address I WILL get this exception...
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: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)
UPDATE :
After letting the program run for quite a while, it usually times out finally after 3-5 minutes and gives me the error I posted above. How can I get it to timeout quicker?
If you have set an FQDN (Fully Qualified Domain Name) for your Data Source such as example.com and the DNS server is unable to resolve this FQDN for a long time it is pretty obvious that your request will hang out. Make sure that the machine from which you are running your application can reach the SQL server and resolve it without any issues. Also you probably want to make sure that there is no firewall that might be blocking the request.
Another possible cause for those symptoms is if you have exhausted the connection pool of ADO.NET. This could happen if you have many slow SQL queries running in parallel, each of them taking a physical connection to the database. There is a limit in the number of available connections on this pool and when this limit is reached the next call to connection.Open() might wait for an available connection to be returned to the pool.
Remark: you might also need to specify in your connection string how you want to authenticate against the SQL server. Checkout connectionstrings.com for more examples.
All this is to say that there is absolutely nothing wrong in the C# code you have posted in your question. It looks more like a network related problem that you could bring to the attention of your network administrators.
To get the connection to exit after a specified amount of time without success, you can use the Connection Timeout parameter in the connection string. The number you specify is in seconds, so for example, Connection Timeout=240 is equal to 240 seconds\60 seconds = 4 minutes.
Sample connection string:
<add name="MyConnectionString"
connectionString="
Data Source=MyServer\MSSQL2017;
Initial Catalog=MyDatabase;
Integrated Security=True;
Connection Timeout=10;"/>
In the above connection string, the Open() command will timeout after 10 seconds.
I am getting this error:
Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
I know there are already guides out there to help solve this but they are not working for me. What am I missing or where should I add the code to these SQL statements in my C# program:
String sql = project1.Properties.Resources.myQueryData;
SqlDataAdapter sqlClearQuestDefects = new SqlDataAdapter(sql,
"Data Source=ab;Initial Catalog=ac;User ID=ad; Password =aa");
DataSet lPlanViewData = new DataSet();
sqlClearQuestDefects.Fill(lPlanViewData, "PlanViewData");
I am getting the timeout error at this line:
SqlDataAdapter sqlClearQuestDefects = new SqlDataAdapter(sql,
"Data Source=ab;Initial Catalog=ac;User ID=ad; Password =aa");
SqlDataAdapter adp = new SqlDataAdapter();
adp.SelectCommand.CommandTimeout = 0; // Set the Time out on the Command Object
You're trying to connect to a SQL Server, and it is taking longer than ADO.NET is willing to wait.
Try connecting to the same server, using the same username and password, using SQL Server Management Studio. If you get the same error, there is either something wrong with your connection string, the server you specify is not running, or you can't get to the server across the network from where you are (maybe you're on a public IP address trying to get in to an internal server name). I can't think of a scenario in which you'd enter the exact same server and credentials into SSMS and connect, then do the same in ADO.NET and fail.
If you're on a slow network, you can try increasing the timeout value. However, if a connection is going to happen at all, it should happen pretty quickly.
Take a look at both your SQL Native Client settings, and the SQL Server settings on the server. There is a section for allowed protocols; SQL can connect using a variety of protocols. Usually, you want TCP/IP for a server on the network, and Named Pipes for a server running on your own computer.
EDIT FROM YOUR COMMENT: Oh, that's normal; happens all the time. From time to time on a TCP network, packets "collide", or are "lost" in transmission. It's a known weakness of packet-switching technologies, which is managed by the TCP protocol itself in most cases. One case in which it isn't easily detected is when the initial request for a connection is lost in the shuffle. In that case, the server doesn't know there was a request, and the client didn't know their request wasn't received. So, all the client can do is give up.
To make your program more robust, all you have to do is expect a failure or two, and simply re-try your request. Here's a basic algorithm to do that:
SqlDataAdapter sqlClearQuestDefects;
short retries = 0;
while(true)
{
try
{
sqlClearQuestDefects = new SqlDataAdapter(sql, "Data Source=ab;Initial Catalog=ac;User ID=ad; Password =aa");
break;
}
catch(Exception)
{
retries++;
//will try a total of three times before giving up
if(retries >2) throw;
}
}
Since the exact command to increase connection time out wasn't mentioned in the other answers (of yet)- if you do determine a need to increase your connection time out, you would do so in your connection string as follows:
Data Source=ab;Initial Catalog=ac;User ID=ad; Password =aa; Connection Timeout=120
Where 120 = 120 seconds. Default is 20 or 30 as I recall.
This is probably a connection issue with your database, for example if you had the following connection string:
"Data Source=MyDatabaseServer...
Then you need to make sure that:
The machine MyDatabaseServer is connected to the network and is accessible from the machine you are running your application from (under the name "MyDatabaseServer")
The database server is running on MyDatabaseServer
The database server on MyDatabaseServer is configured to accept connections from remote machines
The firewall settings both on the local machine and MyDatabaseServer are correctly set up to allow SQL Server connections through
Your username / password etc... are correct
You can also try connecting to the given database instance using SQL Server Management Studio from the client machine as a diagnosis step.
There are plenty of articles that address SQL Server connectivity issues - do a Google search for the specific error message that comes up or failing that as a specific question on Server Fault
Faced this problem recently and found the resolution that worked for me.
By the way, setting Timeout = 0 helped to avoid the exception, but the execution time was unreasonable, while manual execution of the store procedure took a few seconds.
Bottom line:
I added SET IMPLICIT_TRANSACTIONS OFF to the stored procedure that is used to fill the data set.
From MSDN:
The SQL Server Native Client OLE DB Provider for SQL Server and the
SQL Server Native Client ODBC driver automatically set
IMPLICIT_TRANSACTIONS to OFF when connecting. SET
IMPLICIT_TRANSACTIONS defaults to OFF for connections with the
SQLClient managed provider, and for SOAP requests received through
HTTP endpoints.
[...]
When SET ANSI_DEFAULTS is ON, SET IMPLICIT_TRANSACTIONS is ON.
So I believe that in my case defaults weren't as required. (I couldn't check that. Don't have enough privileges on SQL server). But adding this line to my SP solved the problem.
IMPORTANT: In my case I didn't need the transaction, so I had no problem to cancel the implicit transaction setting. If in your case transaction is a must you, probably, shouldn't use this solution.