"Se agotó el tiempo de espera de la operación de espera" cuando se ejecuta SQL Server en Hyper-V

22

Estoy ejecutando SQL Server (2012) en una instancia de Hyper-V. Tiene muchos recursos y un 25% reservado de los recursos totales, el VHD se coloca en un disco SSD muy rápido para tiempos de respuesta rápidos.

De vez en cuando, cuando las aplicaciones que usan SQL Server no han sido accedidas por un tiempo, reciben el error "Se agotó el tiempo de espera de la operación de espera". Al recargar o volver a intentar acceder a la base de datos, parece que se ha "despertado" y es más rápido que nunca.

¿Hay alguna manera de garantizar que este modo de suspensión suave no se produzca en este tipo de entorno?

Adicional

Detalles de la excepción: System.ComponentModel.Win32Exception: se agotó el tiempo de espera de la operación de espera

sql-server hyper-v Eric Herlitz
fuente
1
Una posibilidad para verificar es en las opciones de la base de datos, asegúrese de que el cierre automático esté configurado en Falso Podrías ver los eventos de cierre y apertura en el registro de SQL si esto ocurriera.
Jason Cumberland
Cambiar AutoClose no funcionó, probablemente no son las bases de datos las que se ralentizan. El problema probablemente esté relacionado con la combinación de Hyper-V y SQL Server.
Eric Herlitz
Si otras respuestas no funcionan, intente stackoverflow.com/a/28626223/1290868 que le indica qué hacer en support.microsoft.com/en-us/kb/2605597 Esto puede ayudar.
myuce
Para SQL Server, el objetivo debe estar 100% reservado.
Joel Coel

Respuestas:

22

Intenta ejecutar este comando:

exe sp_updatestats

Increíblemente resolvió el problema.

El código anterior es el error antes de que se haya ejecutado el comando.

[Win32Exception (0x80004005): The wait operation timed out]

[SqlException (0x80131904): Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.]
   System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction) +1742110
   System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction) +5279619
   System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose) +242
   System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady) +1434
   System.Data.SqlClient.SqlDataReader.TryConsumeMetaData() +61
   System.Data.SqlClient.SqlDataReader.get_MetaData() +90
   System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString) +365
   System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite) +1355
   System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource`1 completion, Int32 timeout, Task& task, Boolean asyncWrite) +175
   System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method) +53
   System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method) +134
   System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior behavior) +41
   System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader(CommandBehavior behavior) +10
   System.Data.Common.DbDataAdapter.FillInternal(DataSet dataset, DataTable[] datatables, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior) +140
   System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior) +316
   System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, String srcTable) +86
   System.Web.UI.WebControls.SqlDataSourceView.ExecuteSelect(DataSourceSelectArguments arguments) +1482
   System.Web.UI.DataSourceView.Select(DataSourceSelectArguments arguments, DataSourceViewSelectCallback callback) +21
   System.Web.UI.WebControls.DataBoundControl.PerformSelect() +138
   System.Web.UI.WebControls.BaseDataBoundControl.DataBind() +30
   System.Web.UI.WebControls.BaseDataBoundControl.EnsureDataBound() +79
   System.Web.UI.WebControls.BaseDataBoundControl.OnPreRender(EventArgs e) +22
   System.Web.UI.Control.PreRenderRecursiveInternal() +83
   System.Web.UI.Control.PreRenderRecursiveInternal() +155
   System.Web.UI.Control.PreRenderRecursiveInternal() +155
   System.Web.UI.Control.PreRenderRecursiveInternal() +155
   System.Web.UI.Control.PreRenderRecursiveInternal() +155
   System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +974
Jeferson Tenorio
fuente
3
Simplemente no ejecute este comando sin comprender las consecuencias. sqlperformance.com/2013/07/sql-statistics/statistics-updates and stackoverflow.com/questions/23440770/…
Rosdi
2
Debe conocer las consecuencias probables antes de ejecutar este comando (de hecho, cada comando que ejecuta).
Sohail xIN3N
3
¿Estoy realmente interesado en su preocupación por las consecuencias de esto? La publicación vinculada dice "en realidad podría hacer más daño que bien, y es la opción menos recomendable". - pero parece que el único problema es que podría hacer cosas que sus planes de mantenimiento ya hacen, o ser ineficientes - si la alternativa es una instancia de servidor SQL que está completamente rota - No estoy seguro de por qué le importaría que pueda ser lento o redundante?
Ian Grainger
1
Me pregunto lo mismo que @IanGrainger ... ¿alguien quiere explicar por qué ejecutar exec sp_updatestatses una mala idea?
Flo
1

Tuve el mismo problema Correr exec sp_updatestatsfuncionó a veces, pero no siempre. Decidí usar la NOLOCKdeclaración en mis consultas para acelerar las consultas. Simplemente agregue NOLOCKdespués de su cláusula FROM, por ejemplo:

SELECT clicks.entryURL, clicks.entryTime, sessions.userID
FROM sessions, clicks WITH (NOLOCK)
WHERE sessions.sessionID = clicks.sessionID AND clicks.entryTime > DATEADD(day, -1, GETDATE())

Lee el artículo completo aquí .

Flo
fuente
1

Tuve exactamente el mismo problema y descubrí que fue causado por una asignación de memoria insuficiente en la máquina virtual Hyper-V. Tenía la memoria configurada como dinámica, pero no se estaba ampliando según lo requerido; cambiar a una cantidad fija de memoria, en mi caso 32 GB, resolvió el problema. ¿La interacción entre SqlBulkCopy y Sql Server no parece poder obtener más memoria cuando es necesario?

Tirano saurio Rex
fuente