I am currently investigating an occurrence of the same timeout exception with the same key wording:
This failure occured while attempting to connect to the Principle server.
The environment is SQL Server 2012 with mirroring, so I suspect that the problem was not directly related to a long-running query, but rather to a temporary network/sync issue, either between the application and the SQL servers or between the SQL servers themselves. Stack trace:
System.Data.SqlClient.SqlException (0x80131904): Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. This failure occured while attempting to connect to the Principle server. ---> System.ComponentModel.Win32Exception (0x80004005): The wait operation timed out
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
at System.Data.SqlClient.SqlDataReader.TryConsumeMetaData()
at System.Data.SqlClient.SqlDataReader.get_MetaData()
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource`1 completion, Int32 timeout, Task& task, Boolean asyncWrite)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
at System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior behavior)
at System.Data.Common.DbCommand.ExecuteReader()
at System.Data.Linq.SqlClient.SqlProvider.Execute(Expression query, QueryInfo queryInfo, IObjectReaderFactory factory, Object[] parentArgs, Object[] userArgs, ICompiledSubQuery[] subQueries, Object lastResult)
at System.Data.Linq.SqlClient.SqlProvider.ExecuteAll(Expression query, QueryInfo[] queryInfos, IObjectReaderFactory factory, Object[] userArguments, ICompiledSubQuery[] subQueries)
at System.Data.Linq.SqlClient.SqlProvider.System.Data.Linq.Provider.IProvider.Execute(Expression query)
at System.Data.Linq.ChangeDirector.StandardChangeDirector.DynamicUpdate(TrackedObject item)
at System.Data.Linq.ChangeDirector.StandardChangeDirector.Update(TrackedObject item)
at System.Data.Linq.ChangeProcessor.SubmitChanges(ConflictMode failureMode)
at System.Data.Linq.DataContext.SubmitChanges(ConflictMode failureMode)
...
Update: evidently, this wording is included in the exception message whenever a command times out against a mirrored/failover partner environment. It does indeed reflect a command that exceeded its timeout, and has nothing to do with a failure to attempting to connect. You can verify this by running a simple WAITFOR DELAY '00:00:31' command, which exceeds the default 30-second SqlCommand timeout, and triggers the same exception message.
I have opened a Connect bug to ask Microsoft to correct the misleading wording in the message.
If you use Query Analyzer(QA) go to Tools -> Option -> Connection.Reset all the values using 'Reset to Default' Button.By default there is no time out on QA.
Or, write your CREATE INDEX
or ALTER TABLE
statement in the query window and run it.
Setting the time out in SQL Server to -1 will prevent time outs. It's possible that you are changing the time out setting, but it won't take effect until a RECONFIGURE is performed.
Run:
sp_configure 'show advanced options', 1;
...and look at the time out settings there. Take note as to if the time out setting is active in the run_value column. If not, then you need to do a...
RECONFIGURE;
...to activate the changed setting.
Best Answer
I'm not sure exactly what the purpose is of your entire-table-update, but perhaps the timeout is because your query is causing:
If this table is replicated, the database is mirrored, or you've added CDC/Change Tracking then I think it is going to be much worse. If the table is participating in replication, you should read this topic.
What is the update supposed to do? It's too late now for this case but in the future an alternative way to do this for other tables might be:
Of course this still has to be done in a maintenance window. You don't want users contending for writes during 2.