Für SQLHANDLE wurde eine mögliche unendliche Neukompilierung festgestellt

Ich habe seltsame Fehlermeldungen im SQL-Fehlerprotokoll gefunden:

Bocss: Jede Stunde findet derselbe Deadlock statt - muss untersucht werden

Außerdem werden im Fehlerprotokoll viele Neukompilierungen für andere SPIDs gemäß den folgenden Beispielen aufgeführt:

2015.09.04 14: 30: 10, spid64, Unknown eine mögliche unendliche recompile erkannt wurde SQLHANDLE 0x0200000059631A288882589E0C54B76404CAE1B97E08D3680000000000000000000000000000000000000000 PlanHandle 0x0600040059631A2860A62B654100000001000000000000000000000000000000000000000000000000000000 1038 Start-Offset 2600. Der letzte recompile Grund war Offset Endung 2. 2015.09.04 14.30.10 30::, spid150, Unknown eine mögliche unendliche recompile wurde 2520. Der letzte recompile Grund Offset Offset 998 Ende war 2. 2015.09.04 14 SQLHANDLE 0x02000000EF886F018C4E0B163812B8B20150FE8FC7E6A06A0000000000000000000000000000000000000000 PlanHandle 0x06000400EF886F01901A816E0600000001000000000000000000000000000000000000000000000000000000 detektiert startet am 09, spid67, Unknown,30: 09, spid163, Unknown, wurde eine mögliche unendliche recompile für SQLHANDLE 0x02000000E7C7BF0E5D70DE55759C7842860272AD474D69AB0000000000000000000000000000000000000000 PlanHandle nachgewiesen Eine mögliche unendliche recompile wurde SQLHANDLE 0x0200000057C4C632D9052275CFF2B683B80F29501EE91D730000000000000000000000000000000000000000 PlanHandle 0x0600040057C4C63200EAC2BE3000000001000000000000000000000000000000000000000000000000000000 Offset 1064 beginnend 2652. Offset Beendigung der letzten recompile Grund 2. 2015.09.04 14 nachgewiesen 0x06000400E7C7BF0EF0EB68A52C0000000100000000000000000000000000000000000000000000000000000000 Startstart 1028 Endversatz 2580. Der letzte Grund für die Neukompilierung war 2.

was könnte das verursacht haben?

Sieht so aus, als hätte ich die Pläne nicht mehr im Cache.

Folgen Sie den Ratschlägen dieses Beitrags http://www.sqlservercentral.com/Forums/Topic1479420-146-1.aspx

Als Sicherheitsmaßnahme wurden dann die Volltextkataloge deaktiviert. Dies machte keinen Unterschied. Daher habe ich die Änderungen vollständig rückgängig gemacht (die neuen Objekte wurden gelöscht usw.). Dies machte auch keinen Unterschied. Am Ende schien das einzige, was es zu stoppen schien, ein Neustart der SQL-Instanzen zu sein. Dadurch wurde das Problem sofort behoben.

das hat mich auch geklärt, aber ich muss noch herausfinden, was dieses Chaos überhaupt verursacht hat?

— Marcello Miorelli
quelle

Ihre Fehlermeldung bedeutet nicht, dass sich der Plan nicht mehr im Cache befindet. Ich glaube, Sie haben das Planhandle falsch kopiert und es ist entweder ein Wert zu lang oder einer zu kurz. Ich kann ein SELECTOn dm_exec_sql_textmit dem Handle ausführen , das in Ihrer Fehlermeldung enthalten ist, ohne einen Fehler zu erhalten

— Mark Sinkinson

+ 1 gut entdeckt

— Marcello Miorelli

Gemäß der Meldung "Unendliche Neukompilierung" im Fehlerprotokoll im Blog des SQL-Programmierbarkeits- und API-Entwicklungsteams wird diese Meldung ausgelöst, wenn eine Anweisung in einem Stapel 100 Mal hintereinander neu kompiliert wird.

Diese Nachricht bedeutet nicht unbedingt, dass ein Problem vorliegt. Es hilft bei der Fehlerbehebung bei Anweisungen, die möglicherweise so häufig neu kompiliert werden (z. B. aufgrund schneller Änderungen in der Statistik), sowie bei echten Endlos-Kompilierungsschleifen (die im Extremfall selten sind).

Sie sollten zunächst die auslösende Anweisung anhand der bereitgestellten Informationen identifizieren und sie im Kontext des numerischen Codes auswerten, in dem der Grund für die Neukompilierungen angegeben ist. In Books Online finden Sie an mehreren Stellen eine Tabelle dieser Codes und ihrer Bedeutung, unter anderem unter SP: Recompile Event Class .

Weitere Informationen finden Sie unter Plan-Caching und Neukompilierung in SQL Server 2012 .

— Paul White 9
quelle