it-swarm.com.de

SQL Server löscht den Plan-Cache und die Ausführungsstatistiken regelmäßig

Nach dem Upgrade von SQL Server 2014 auf 2016 setzt der Server die zwischengespeicherten Ausführungspläne und dm* Ansichten (wie dm_exec_query_stats) usw. alle paar Stunden

Als ob jemand DBCC FREEPROCCACHE und DBCC DROPCLEANBUFFERS manuell (außer niemand tut es automatisch).

Dieselbe Datenbank funktionierte auch unter SQL Server 2014 und Windows Server 2012 einwandfrei. Nach dem Wechsel zu SQL Server 2016 (und Windows Server 2016) ging es nach Süden.

Dinge, die ich überprüft habe: Die Datenbank hat nicht das Flag "Auto Close". Der SQL Server ist ad hoc optimized auf true gesetzt (ich dachte, es würde helfen, es tat nicht). Der "Abfragespeicher" ist "aus". Der Server verfügt über 16 GB Speicher.

Auch im "SQL Server-Protokoll" ist nichts hilfreich. Nur eine wöchentliche Backup-Nachricht ...

Ich habe auch diesen Artikel überprüft https://docs.Microsoft.com/en-us/sql/t-sql/statements/alter-database-transact-sql-set-options (scrollen Sie nach unten zu " Beispiele "Abschnitt und direkt darüber) gibt es eine Liste von Situationen, in denen der Plan automatisch gelöscht wird. Keine davon trifft zu.

AKTUALISIEREN:

Leider hat keiner der Vorschläge geholfen. Erteilen von LPIM-Berechtigungen, Erkennen und Korrigieren nicht parametrisierter Abfragen, die Tonnen von Plänen für dieselbe Abfrage generiert haben, Verringern des "maximalen Serverspeichers" ... Die Pläne werden nach dem Zufallsprinzip von allen paar Stunden auf alle 5-10 Minuten zurückgesetzt. Wenn der Server "unter Speicherdruck" stand, warum funktionierte die Version 2014 auf demselben Computer einwandfrei?

Hier ist die sp_Blitz-Ausgabe wie gewünscht

**Priority 10: Performance**:

- Query Store Disabled - The new SQL Server 2016 Query Store feature has not been enabled on this database.

    * xxx


**Priority 50: Server Info**:

- Instant File Initialization Not Enabled  - Consider enabling IFI for faster restores and data file growths.


**Priority 100: Performance**:

- Resource Governor Enabled  - Resource Governor is enabled.  Queries may be throttled.  Make sure you understand how the Classifier Function is configured.


**Priority 120: Query Plans**:

- Implicit Conversion Affecting Cardinality - One of the top resource-intensive queries has an implicit conversion that is affecting cardinality estimation.

    * 

- Missing Index - One of the top resource-intensive queries may be dramatically improved by adding an index.

    * 

- RID or Key Lookups - One of the top resource-intensive queries contains RID or Key Lookups. Try to avoid them by creating covering indexes.

    * 

**Priority 170: File Configuration**:

- System Database on C Drive
    * master - The master database has a file on the C drive.  Putting system databases on the C drive runs the risk of crashing the server when it runs out of space.

    * model - The model database has a file on the C drive.  Putting system databases on the C drive runs the risk of crashing the server when it runs out of space.

    * msdb - The msdb database has a file on the C drive.  Putting system databases on the C drive runs the risk of crashing the server when it runs out of space.


**Priority 200: Backup**:

- MSDB Backup History Not Purged msdb - Database backup history retained back to Jun 10 2017  9:47PM


**Priority 200: Informational**:

- Backup Compression Default Off  - Uncompressed full backups have happened recently, and backup compression is not turned on at the server level. Backup compression is included with SQL Server 2008R2 & newer, even in Standard Edition. We recommend turning backup compression on by default so that ad-hoc backups will get compressed.


**Priority 200: Non-Default Server Config**:

- Agent XPs  - This sp_configure option has been changed.  Its default value is 0 and it has been set to 1.

- max server memory (MB)  - This sp_configure option has been changed.  Its default value is 2147483647 and it has been set to 15000.

- optimize for ad hoc workloads  - This sp_configure option has been changed.  Its default value is 0 and it has been set to 1.

- show advanced options  - This sp_configure option has been changed.  Its default value is 0 and it has been set to 1.

- xp_cmdshell  - This sp_configure option has been changed.  Its default value is 0 and it has been set to 1.


**Priority 200: Performance**:

- Buffer Pool Extensions Enabled  - You have Buffer Pool Extensions enabled, and one lives here: Z:\sql_buffer_pool.BPE. It's currently 60.00000000000 GB. Did you know that BPEs only provide single threaded access 8KB (one page) at a time?

- cost threshold for parallelism  - Set to 5, its default value. Changing this sp_configure setting may reduce CXPACKET waits.

**Priority 240: Wait Stats**:

- No Significant Waits Detected  - This server might be just sitting around idle, or someone may have cleared wait stats recently.

**Priority 250: Informational**:

- SQL Server Agent is running under an NT Service account  - I'm running as NT Service\SQLSERVERAGENT. I wish I had an Active Directory service account instead.

- SQL Server is running under an NT Service account  - I'm running as NT Service\MSSQLSERVER. I wish I had an Active Directory service account instead.

**Priority 250: Server Info**:

- Default Trace Contents  - The default trace holds 125 hours of data between Aug 19 2017 11:55AM and Aug 24 2017  4:59PM. The default trace files are located in: C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Log

- Hardware  - Logical processors: 2. Physical memory: 15GB.

- Hardware - NUMA Config  - Node: 0 State: ONLINE Online schedulers: 2 Offline schedulers: 0 Processor Group: 0 Memory node: 0 Memory VAS Reserved GB: 29

- Locked Pages In Memory Enabled  - You currently have 12.02534484863 GB of pages locked in memory.

- Memory Model Unconventional  - Memory Model: LOCK_PAGES

- Server Last Restart  - Aug 20 2017 12:32PM

- Server Name  - xx

- Services
 - Service: SQL Full-text Filter Daemon Launcher (MSSQLSERVER) runs under service account NT Service\MSSQLFDLauncher. Last startup time: not shown.. Startup type: Manual, currently Running.

 - Service: SQL Server (MSSQLSERVER) runs under service account NT Service\MSSQLSERVER. Last startup time: Aug 20 2017 12:32PM. Startup type: Automatic, currently Running.

 - Service: SQL Server Agent (MSSQLSERVER) runs under service account NT Service\SQLSERVERAGENT. Last startup time: not shown.. Startup type: Automatic, currently Running.

- SQL Server Last Restart  - Aug 20 2017 12:33PM

- SQL Server Service  - Version: 13.0.4446.0. Patch Level: SP1. Edition: Enterprise Edition (64-bit). AlwaysOn Enabled: 0. AlwaysOn Mgr Status: 2

- Virtual Server  - Type: (HYPERVISOR)

- Windows Version  - You're running a pretty modern version of Windows: Server 2012R2 era, version 6.3


**Priority 254: Rundate**:

 - Captain's log: stardate something and something...
24
jitbit

OK, OP hier, ich habe dieses Problem endlich behoben, indem ich SQL Server 2016 auf die neueste Version aktualisiert habe. Ich hatte SP1 und gestern habe ich Cumulative Update 6.

Ich habe auch "max memory" entsprechend eingestellt, wie es die Antwort von Brent nahe legt. Tolle Antwort übrigens, ich fordere alle auf, sie zu verbessern.

Es sind 36 Stunden vergangen und es wird gezählt, Pläne werden nicht zurückgesetzt.

Brent Ozar hat auch eine sehr schöne Website hier: https://sqlserverupdates.com/ , um herauszufinden, welche Updates Sie benötigen.

Eine andere Sache, die geholfen hat, war das Erkennen und Lösen des Problems "nicht vertrauenswürdige Fremdschlüssel". Brent hat einen sehr schönen Artikel (hahah, ja, Brent schon wieder, ich weiß genau) darüber, wie man es löst. Nur Google, er ist das beste Ergebnis

5
jitbit

Ermitteln Sie zunächst die genauen Zeiten, zu denen der Plan-Cache geleert wird. Hier ist der einfachste Weg, dies zu tun - es sollte fast sofort ausgeführt werden und niemanden blockieren:

SELECT TOP 1 creation_time
FROM sys.dm_exec_query_stats WITH (NOLOCK)
ORDER BY creation_time;

Wenn Ihnen dieses Datum/diese Uhrzeit älter erscheint als erwartet , wird nur ein Teil des Plan-Cache gelöscht. Zum Beispiel führt jemand einen Job zum Wiederherstellen oder Aktualisieren von Statistiken durch, der den Plan-Cache für die spezifischen betroffenen Objekte leeren würde - aber andere Objekte bleiben weiterhin bestehen. Ich sehe dies oft, wenn Systemabfragen (wie DMV-Abfragen) bestehen bleiben, aber Benutzerdatenbankpläne gelöscht werden.

Wenn dieses Datum/diese Uhrzeit in bestimmten Intervallen aktualisiert wird , z. B. wenn es genau alle 2 Stunden aktualisiert zu werden scheint, um 6:00, 8:00, 10 zu sagen: 00 usw., dann führt wahrscheinlich jemand einen Job oder eine Abfrage aus, die dazu führt, dass der Plan-Cache gelöscht wird. Sobald Sie die genaue Frequenz kennen, können Sie:

  • Sehen Sie sich Ihre Jobpläne an, um zu sehen, was in diesem Intervall ausgeführt wird
  • Führen Sie während dieser Zeitspanne einen Profiler-Trace oder einen Extended Events-Trace aus, um das Rätsel zu lösen (ich bin normalerweise kein Fan von Tracing in der Produktion, aber wenn Sie genau wissen, wann der Killer zuschlagen wird, ist es einfach genug, ein Tief zu starten -Oberprobe von dem, was läuft)
  • Log sp_WhoIsActive zu einer Tabelle während dieser Zeit (die einfachste Methode, aber die am wenigsten wahrscheinliche, um sie auf die genaue Abfrage einzugrenzen, die sie verursacht)

Wenn sich dieses Datum/diese Uhrzeit jedes Mal ändert, wenn Sie die Abfrage ausführen , steht Ihr Server wahrscheinlich unter Speicherdruck. Führen Sie dies aus, um grundlegende Informationen zur Integritätsprüfung zu generieren. Anschließend können Sie diese kopieren/in Ihre Stapelfrage einfügen, damit wir sie diagnostizieren können:

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1, @CheckUserDatabaseObjects = 1

(Offenlegung: Ich bin einer der Autoren von sp_Blitz.)

Aktualisiert am 25.08.2017 mit Ihren sp_Blitz-Daten - danke, dass Sie sp_Blitz ausgeführt und Ihrer Frage hinzugefügt haben, und es hilft wirklich, ein paar Dinge zu zeigen. Sie führen SQL Server 2016 Enterprise Edition auf einem VM mit 2 Kernen und 16 GB RAM) aus. Zunächst ein kurzer Hinweis zur Lizenzierung: Wenn Sie vom Gast lizenziert werden, gilt die Mindestkaufanforderung ist 4 Kerne, nicht 2. (Weitere Informationen finden Sie im SQL Server-Lizenzierungshandbuch .) 4 Kerne der Enterprise Edition kosten etwa 28.000 USD, und es ist ziemlich ungewöhnlich, dass so viel Lizenzgeld nur ausgegeben wird 16 GB RAM. Wenn Sie SQL Server Enterprise Edition auf Hostebene lizenzieren, können Sie dies ignorieren und kleinere VMs ausführen.

Es sieht so aus, als ob Ihr SQL Server unter externen Speicherdruck gerät. Sie haben 16 GB RAM und den maximalen Serverspeicher auf 15 GB festgelegt. Leider ist 1 GB nicht genug für das Betriebssystem übrig (plus alles, was Sie dort ausführen werden, wie Sicherungssoftware und SSMS). In unserem SQL Server-Setup-Handbuch empfehlen wir, 4 GB oder 10% frei zu lassen, je nachdem, was Sie tun ist größer - in Ihrem Fall wären das 4 GB, daher sollte Ihre maximale Serverspeichereinstellung 12 GB statt 15 GB betragen.

Weitere Beweise werden in Ihren aktuellen Speicherzuordnungen angezeigt: Sie haben gesperrte Seiten im Speicher (LPIM) aktiviert, aber nur 12,02 GB Seiten im Speicher gesperrt. Dies bedeutet wahrscheinlich (aber nicht garantiert), dass eine andere Anwendung Speicher benötigt. Daher hat Windows eine Benachrichtigung über den Speicherdruck gesendet, und SQL Server hat die anderen 3 GB Speicher aufgegeben, damit die andere App ihre Aufgabe ausführen kann. Dies ist ein weiterer Beweis dafür, dass Sie mit maximal 15 GB nicht wirklich arbeiten können - Sie benötigen Speicher für andere Dinge.

Wenn Ihr SQL Server unter diesen externen Speicherdruck gerät und Speicher für andere Apps freigeben muss, leidet Ihr Plan-Cache.

Sie haben also einige Möglichkeiten:

  • Maximaler Speicher entsprechend einstellen - sagen wir 12 GB (oder sogar weniger, wenn Sie andere Apps auf dem Computer ausführen möchten Server.) Auf diese Weise muss SQL Server keinen Feuerverkauf im Speicher haben und keine Inhalte löschen, nur weil eine andere App 2-3 GB RAM - es ist bereits verfügbar) benötigt
  • Stoppen Sie die Ausführung anderer Apps auf dem Server - Dies kann schwierig sein, wenn es sich um andere Sysadmins handelt, die Remote-Desktopping durchführen und Dinge wie SSMS ausführen aber. Ich habe Perfmon-Zähleralarme für die Anzahl der geöffneten RDP-Sitzungen eingerichtet und benachrichtigt, wenn etwas anderes als 0 ist - das kann helfen, den Täter in Aktion zu fangen.
  • Füge der VM mehr Speicher hinzu - aber ich glaube nicht, dass du ihn wirklich brauchst. Der sp_Blitz-Bericht zeigt, dass "keine signifikanten Wartezeiten festgestellt wurden". Ich glaube nicht, dass Sie häufig unter Gedächtnisdruck stehen, zumal Sie berichten, dass dies nur ab und zu passiert. Dies ist die am wenigsten kostengünstige Option.
28
Brent Ozar

Ich hatte dieses Problem in meiner Home-Testbox und fand heraus, dass das Problem durch Hinzufügen der Berechtigung "Seiten im Speicher sperren" zum SQL Server-Dienstkonto behoben wurde. Ich bin mir jedoch nicht sicher, ob dies der beste Rat ist.

Siehe Aktivieren der Option "Seiten im Speicher sperren" (Windows)

1
MrKudz