Tägliche Pläne zur Neuerstellung von SQL Server

Wir haben dieses Problem in unserer Produktionsumgebung.

Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) - Enterprise Edition (64-Bit) unter Windows NT 6.1 (Build 7601: Service Pack 1).

SQL Server löscht alle (fast 100%) alten Ausführungspläne und erstellt sie täglich über Nacht (von 23:00 Uhr bis 08:00 Uhr) neu. Dies geschah sogar, als die "Auto-Update-Statistiken" deaktiviert waren. Wir haben die "Auto-Update-Statistiken" für die letzten 2-3 Wochen aktiviert. Aber es passiert immer noch.

Wir wissen nicht genau, was diese Neuerstellung von Plänen auslöst, aber wir sind sicher, dass wir dies nicht manuell tun.

Das einzige, was wirklich mit dem Zeitpunkt der Wiederherstellung der Pläne zusammenfällt, ist ein DB-Wartungsjob, den wir haben: die tägliche Indexreorganisation (bei einer Fragmentierung von 5-30%) und die tägliche Indexrekonstruktion (bei einer Fragmentierung von mehr als 30%). ) Job. Normalerweise führt diese tägliche Wartung nur eine Reorganisation durch (da die Indexfragmentierung täglich nie mehr als 30% beträgt).

Einschlag:

Diese neu erstellten Pläne bewirken, dass einige UDF-Aufrufe / Abfrageaufrufe (die von der Benutzeroberfläche / von Webseiten aus aufgerufen werden) viel länger dauern (Minuten statt weniger als 1 Sekunde), sodass die Sitzungen sich nur aufstapeln und die CPU fast 90% beanspruchen. .

Das Problem verschwindet in dem Moment, in dem diese blockierten Sitzungen zwangsweise gelöscht werden (auf der DB-Seite) und 1) wenn alle entsprechenden Ausführungspläne manuell gelöscht werden (für Abfragen) oder 2) wenn die UDFs geändert werden (für Funktionen). Alle neuen Pläne, die von diesem Moment an von SQL Server erstellt wurden, funktionieren den ganzen Tag über einwandfrei, bis am nächsten Morgen dasselbe Problem auftritt. Außerdem ist dieses Verhalten nicht zu 100% konsistent. Wir sehen es nicht jeden Morgen. Aber es hat Zeiträume gegeben, in denen wir es 4-5 Tage hintereinander durchgehend gesehen haben.

Das Problem tritt vormittags auf, wenn die Benutzeroberfläche oder die Webseiten offenbar intensiver aufgerufen werden.

Hat jemand eine Ahnung, was dies verursacht und wie man dieses Problem löst? Jede Hilfe wäre sehr dankbar.

Nun, ich habe einige Ideen, die dieses Verhalten verursachen könnten.

1. Überwachen Sie Ihren Speicherdruck? Möglicherweise erhöhen Ihre Abfragen ein bestimmtes Limit, wodurch der Plan-Cache geleert wird. Ich kenne Ihre Anwendung nicht, aber stimmt diese mit Ihren Protokollen von Ihren Front-End-Servern überein? Gibt es in dieser Zeit auch Druck?
2. Haben Sie einen dedizierten SQL Server oder teilt der Server seine Hardware mit anderen Prozessen / Diensten? Wenn nicht, versuchen Sie, Ihren SQL Server stattdessen an einen dedizierten Computer auszulagern. Dadurch werden die Nebenwirkungen anderer Dienste verringert.
3. Möglicherweise möchten Sie verwenden optimize for ad hoc workloads, wodurch nur ein Plan-Stub gespeichert und bei Bedarf kompiliert wird. Dies verringert die Belastung Ihres Plancaches, wodurch die Wahrscheinlichkeit einer Plancache-Leerung verringert wird. Sie können es mit aktivieren sp_configure 'optimize for ad hoc workloads',1; reconfigure. Dies ist möglich, wenn Sie die advanced optionsVerwendung aktiviert haben sp_configure 'show advanced options',1; reconfigure.
4. Eine andere Idee können Backups sein. Nur einfache Backups. Wenn sie aggressiv sind, kann es vorkommen, dass Ihre Maschine ebenfalls unter Druck gerät. Die Zeit, die Sie erwähnen, scheint nur ein guter Zeitraum für die Planung eines Backups zu sein.
5. Vielleicht ist es ganz einfach ein Fehler in Ihrem Wartungsskript. Haben Sie überprüft, ob es ein logisches Problem gibt, das dazu führt, dass Ihr Skript alle Indizes neu erstellt, anstatt nur diejenigen, die den Kriterien entsprechen. Dies kann möglicherweise auch dazu führen.

Gleich neben all dieser Möglichkeiten kann es sinnvoll sein , um die Protokolldateien für einige Änderungen an den Optionen zu prüfen affinity mask, affinity I/O maskund ihre x64 - Partner. Eine andere Sache kann eine Änderung der MAXDOPOption Ihrer Instanz sein. Bitte überprüfen Sie auch die Protokolle. Sie müssen auch den Plancache leeren.

Zu guter Letzt können Sie noch einen serverseitigen Trace ausführen (indem Sie ihn mit dem Profiler einrichten, starten, stoppen und mit dem Befehl sql erneut auf dem Server starten). Daneben perfmonist dein Freund. Es kann Ihre Leistungswerte eine Zeit lang beobachten und überwachen. Möglicherweise können Sie Parallelen im Druck bei bestimmten Aktionen auf Ihrem Server feststellen, die zu Flush führen können.

Hoffentlich hilft dir das, auch wenn die Antwort etwas später kommt.