"Zeitüberschreitung beim Warten" beim Ausführen von SQL Server in Hyper-V

22

Ich führe SQL Server (2012) auf einer Hyper-V-Instanz aus. Es hat viele Ressourcen und 25% der gesamten Ressourcen reserviert. Die VHD befindet sich auf einem sehr schnellen SSD-Laufwerk für schnelle Reaktionszeiten.

Hin und wieder, wenn auf die Anwendungen, die den SQL Server verwenden, eine Weile lang kein Zugriff erfolgt ist, wird der Fehler "Timeout der Warteoperation" angezeigt. Beim Neuladen oder erneuten Versuch, auf die Datenbank zuzugreifen, scheint sie "aufgeweckt" worden zu sein und ist so schnell wie nie zuvor.

Gibt es eine Möglichkeit, um sicherzustellen, dass dieser Soft-Sleep-Modus in einer solchen Umgebung nicht auftritt?

Hinzugefügt

Ausnahmedetails: System.ComponentModel.Win32Exception: Die Wartezeit ist abgelaufen

sql-server hyper-v

— Eric Herlitz
quelle

1

Eine Möglichkeit, dies zu überprüfen, besteht darin, in den Datenbankoptionen sicherzustellen, dass "Automatisch schließen" auf "Falsch" gesetzt ist. In diesem Fall können Sie die schließenden und öffnenden Ereignisse im SQL-Protokoll sehen.

— Jason Cumberland

Das Ändern von AutoClose hat nicht funktioniert, wahrscheinlich sind es nicht die Datenbanken, die langsamer werden. Das Problem hängt höchstwahrscheinlich mit der Hyper-V- und SQL Server-Kombination zusammen.

— Eric Herlitz

Wenn andere Antworten nicht funktionieren, versuchen Sie es mit stackoverflow.com/a/28626223/1290868. Dort erfahren Sie, was auf support.microsoft.com/en-us/kb/2605597 steht. Dies kann helfen.

— 12.

Für SQL Server sollte das Ziel 100% reserviert sein.

— Joel Coel

22

Versuchen Sie diesen Befehl auszuführen:

exec sp_updatestats

Es hat das Problem unglaublich gelöst.

Der Code über dem Fehler, bevor der Befehl ausgeführt wurde.

[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
quelle

3

Führen Sie diesen Befehl nicht einfach aus, ohne die Konsequenzen zu verstehen. sqlperformance.com/2013/07/sql-statistics/statistics-updates und stackoverflow.com/questions/23440770/…

— Rosdi

2

Sie sollten die wahrscheinlichen Konsequenzen kennen, bevor Sie diesen Befehl ausführen (in der Tat jeden Befehl, den Sie ausführen).

— Sohail xIN3N

3

Ich bin aufrichtig an Ihrer Besorgnis über die Konsequenzen interessiert? Der verlinkte Post sagt "könnte tatsächlich mehr Schaden anrichten und ist die am wenigsten empfehlenswerte Option." - aber das einzige Problem scheint zu sein, dass es möglicherweise Dinge tut, die Ihre Wartungspläne bereits tun, oder ineffizient ist - wenn die Alternative eine vollständig kaputte SQL Server-Instanz ist - Ich bin mir nicht sicher, warum es Ihnen etwas ausmacht, dass sie langsam sein kann oder überflüssig?

— Ian Grainger

1

Ich frage mich dasselbe wie @IanGrainger ... jemand möchte gerne erläutern, warum das Ausführen exec sp_updatestatseine schlechte Idee ist.

— Flo

1

Ich hatte das gleiche Problem. Laufen exec sp_updatestatshat manchmal funktioniert, aber nicht immer. Ich habe beschlossen, die NOLOCKAnweisung in meinen Abfragen zu verwenden, um die Abfragen zu beschleunigen. Fügen NOLOCKSie einfach nach Ihrer FROM-Klausel Folgendes hinzu:

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

Lesen Sie den vollständigen Artikel hier .

— Flo
quelle

1

Ich hatte genau das gleiche Problem und stellte fest, dass es durch nicht genügend Arbeitsspeicher auf der Hyper-V-VM verursacht wurde. Ich hatte den Speicher auf dynamisch eingestellt, aber er wurde nicht nach Bedarf vergrößert - ein Wechsel zu einer festen Speichergröße, in meinem Fall 32 GB, löste das Problem. Die Interaktion zwischen SqlBulkCopy und Sql Server scheint nicht in der Lage zu sein, bei Bedarf mehr Speicher zu erhalten?

— T-Rex
quelle