sql-server - usuario - no se puede conectar a local sql server 2014
Múltiples tiempos de espera de conexión SQL simultáneos en el servicio de Windows multiproceso (5)
Tengo un servicio de Windows multiproceso que he desarrollado con VS 2010 (.NET 4.0) que puede tener desde unas pocas hasta una docena de subprocesos, cada uno de los cuales recupera datos de un servidor lento a través de Internet y luego usa una base de datos local para registrar esto. Datos (por lo que el proceso está vinculado a Internet, no a LAN ni a CPU).
Con cierta regularidad, recibo una inundación / ráfaga / ráfaga del siguiente error de varios subprocesos simultáneamente:
System.Data.SqlClient.SqlException (0x80131904): Timeout expiró. El período de tiempo de espera transcurrido antes de la finalización de la operación o el servidor no responde.
La pila de llamadas para este error suele ser:
en System.Data.ProviderBase.DbConnectionPool.GetConnection (DbConnection owningObject)
en System.Data.ProviderBase.DbConnectionFactory.GetConnection (DbConnection owningConnection)
en System.Data.ProviderBase.DbConnectionClosed.OpenConnection (DbConnection outerConnection, DbConnectionFactory connectionFactory)
en System.Data.SqlClient.SqlConnection.Open ()
No estoy especificando un Tiempo de espera de conexión en la cadena de conexión, y hay otras aplicaciones y procesos trabajando en esta base de datos. ¿Alguien se ha encontrado con este tipo de comportamiento y, de ser así, qué se hizo para prevenirlo?
El método más comúnmente llamado en mi capa de acceso a datos se ve así, y todos mis otros métodos DAL siguen el mismo enfoque:
using (SqlConnection con = new SqlConnection(GetConnectionString()))
using (SqlCommand cmd = new SqlCommand("AddGdsMonitorLogEntry", con))
{
cmd.CommandType = CommandType.StoredProcedure;
/* setting cmd.Parameters [snipped] */
// We have been getting some timeouts writing to the log; wait a little longer than the default.
cmd.CommandTimeout *= 4;
con.Open();
cmd.ExecuteNonQuery();
}
¡Muchas gracias!
EDITAR
Dados los comentarios acerca de que esto ocurra en entornos duplicados, debo mencionar que la base de datos en cuestión está reflejada. Está marcado en SSMS como "Principal, Sincronizado", en modo "Alta seguridad sin conmutación por error automática (síncrono)".
EDITAR 26/05/11
No veo nada en los registros de SQL Server para indicar ningún problema. (No tengo acceso al Visor de eventos de Windows en ese servidor, pero le pedí a alguien que me busque).
De acuerdo con la publicación del blog de MSDN que se creó hoy (¡hurra por Google!):
Microsoft ha confirmado que este es un problema en la versión actual de ADO.NET. Este problema se solucionará en la versión ADO.NET que se envía con Visual Studio 2011.
Mientras tanto, solicitamos utilizar las siguientes soluciones:
Aumenta el tiempo de espera de la cadena de conexión a 150 seg. Esto le dará al primer intento el tiempo suficiente para conectarse (150 * .08 = 12 segundos)
Agregue MinPool Size = 20 en la cadena de conexión. Esto siempre mantendrá un mínimo de 20 conexiones en el grupo y habrá menos posibilidades de crear una nueva conexión, reduciendo así la posibilidad de este error.
Mejorar el rendimiento de la red. Actualice sus controladores NIC a la última versión de firmware. Hemos visto la latencia de la red cuando su tarjeta NIC no es compatible con ciertas configuraciones del Paquete de red escalable. Si está en Windows Vista SP1 o superior, también puede considerar desactivar el ajuste automático de la ventana de recepción. Si tiene el equipo de NIC habilitado, deshabilitarlo sería una buena opción.
La publicación en sí es una lectura interesante, que habla de un algoritmo de reintento de conexión TCP / IP. ¡Y felicitaciones a todas las personas que dijeron "hey, parece que está relacionado con la creación de reflejo ..."! Y tenga en cuenta que el comentario sobre esto es "debido a una respuesta lenta de SQL Server o debido a retrasos en la red".
UGH !!!
Gracias a todos los que publicaron. Ahora todos debemos solicitar un parche para .NET Framework (o algún otro mecanismo de parcheo de ADO.NET), para que no tengamos que esperar (y comprar) Visual Studio 11 ...
El tiempo de espera de conexión es una cosa diferente al tiempo de espera del comando. El tiempo de espera del comando se aplica a la situación cuando se ha establecido la conexión, pero debido a razones internas, el servidor no puede devolver ningún resultado dentro del tiempo requerido. El tiempo de espera predeterminado del comando es de 30 segundos. http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlcommand.commandtimeout.aspx
Intente especificar el tiempo de espera de conexión en la cadena de conexión. El valor predeterminado es de 15 segundos, lo que puede ser la causa del problema que ve. También puede especificar el tiempo de espera de la conexión en el código: http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectiontimeout.aspx
He podido reproducir este problema de forma fiable. Tengo un servicio que, cuando se solicita un trabajo de procesamiento, se inicia el procesamiento en un nuevo dominio de aplicación / subproceso. Este hilo ejecutará 10 a 16 consultas de base de datos simultáneamente. Cuando ejecuto 30 de estos trabajos uno tras otro, uno o dos de los trabajos se bloquearán con el error de tiempo de espera.
Cambié la cadena de conexión para desactivar la Agrupación de conexiones con Agrupación = falso y luego el error cambió a lo siguiente. Esto se lanza 3 o 4 veces dentro de una excepción agregada, ya que las conexiones ocurren dentro de un Parallel.For
System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning()
at System.Data.SqlClient.TdsParserStateObject.ReadSniError(TdsParserStateObject stateObj, UInt32 error)
at System.Data.SqlClient.TdsParserStateObject.ReadSni(DbAsyncResult asyncResult, TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParserStateObject.ReadNetworkPacket()
at System.Data.SqlClient.TdsParser.ConsumePreLoginHandshake(Boolean encrypt, Boolean trustServerCert, Boolean& marsCapable)
at System.Data.SqlClient.TdsParser.Connect(ServerInfo serverInfo, SqlInternalConnectionTds connHandler, Boolean ignoreSniOpenTimeout, Int64 timerExpire, Boolean encrypt, Boolean trustServerCert, Boolean integratedSecurity)
at System.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin(ServerInfo serverInfo, String newPassword, Boolean ignoreSniOpenTimeout, TimeoutTimer timeout, SqlConnection owningObject)
at System.Data.SqlClient.SqlInternalConnectionTds.LoginWithFailover(Boolean useFailoverHost, ServerInfo primaryServerInfo, String failoverHost, String newPassword, Boolean redirectedUserInstance, SqlConnection owningObject, SqlConnectionString connectionOptions, TimeoutTimer timeout)
at System.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist(SqlConnection owningObject, TimeoutTimer timeout, SqlConnectionString connectionOptions, String newPassword, Boolean redirectedUserInstance)
at System.Data.SqlClient.SqlInternalConnectionTds..ctor(DbConnectionPoolIdentity identity, SqlConnectionString connectionOptions, Object providerInfo, String newPassword, SqlConnection owningObject, Boolean redirectedUserInstance)
at System.Data.SqlClient.SqlConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection)
at System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(DbConnection owningConnection, DbConnectionPoolGroup poolGroup)
at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
at System.Data.SqlClient.SqlConnection.Open()
at Tps.PowerTools.CoreEngine.V5.DataAccess.DataContext.ExecuteQuery(PtQuery query, ValueStore`1 store, String readerDescription) in C:/SourceCode/Tps.PowerToolsV1/Trunk/Libraries/CoreEngine/CoreEngine.V5/DataAccess/DataContext.cs:line 326
at Tps.PowerTools.CoreEngine.V5.DataAccess.DataContext.<StockHistoricalData>b__15(PtQuery query) in C:/SourceCode/Tps.PowerToolsV1/Trunk/Libraries/CoreEngine/CoreEngine.V5/DataAccess/DataContext.cs:line 302
at System.Threading.Tasks.Parallel.<>c__DisplayClass32`2.<PartitionerForEachWorker>b__30()
at System.Threading.Tasks.Task.InnerInvokeWithArg(Task childTask)
at System.Threading.Tasks.Task.<>c__DisplayClass7.<ExecuteSelfReplicating>b__6(Object )
La optimización de las consultas que está ejecutando en el servidor remoto siempre ayudará. Calcula cada consulta y busca las de larga duración. Si solo está haciendo lecturas, use la (NOLOCK) en las sentencias SELECT. Esto fue un salvavidas para mí. Solo lea sobre esto para asegurarse de que sea apropiado en su aplicación. Si tiene acceso a la base de datos remota, asegúrese de que los índices no estén fragmentados . Esto causará una desaceleración importante en la ejecución de la consulta. Asegúrese de que los índices se reconstruyan / reorganicen como parte del plan de mantenimiento de SQL. Añadir nuevos índices cuando sea apropiado.
Extender el tiempo de espera puede empeorar las cosas . Si deja que las consultas se ejecuten durante más tiempo, potencialmente, más consultas caducarán. El tiempo de espera está ahí para proteger el servidor y otros clientes que acceden a él. Subirlo un poco no es un gran problema, pero no querrás que las consultas se ejecuten durante mucho tiempo y que maten al servidor.
Recibo esto de vez en cuando en este antiguo servidor de base de datos que tenemos (con 10 años de antigüedad ahora). Cuando sucede, es porque algo está martillando esa cosa con conexiones / consultas constantemente. Mi conjetura es que, cuando suceda, el servidor de la base de datos está bajo carga (o una gran cantidad de conexiones o algo parecido). De todos modos, en mi experiencia, si puede optimizar el código, optimizar la base de datos, obtener una mayor seguridad. Servidor de base de datos, etc. Todo ayuda. Otra cosa que puede hacer, que sugiere Piotr, es simplemente aumentar el tiempo de espera para la conexión. Aun así, seguiría y optimizaría algunas cosas (debería ayudar a largo plazo).