Schlechte Leistung von SQL Server 2016 Enterprise

Es tut mir leid, dass ich lange bin, aber ich möchte Ihnen so viele Informationen wie möglich geben, damit diese für die Analyse hilfreich sein können.

Ich weiß, dass es mehrere Posts mit ähnlichen Problemen gibt. Ich habe diese verschiedenen Posts und andere im Web verfügbare Informationen bereits verfolgt, aber das Problem bleibt bestehen.

Ich habe ein ernstes Leistungsproblem in SQL Server, das Benutzer verrückt macht. Dieses Problem dauert mehrere Jahre an und wurde bis Ende 2016 von einem anderen Unternehmen verwaltet und ab 2017 von mir verwaltet.

Mitte 2017 konnte ich das Problem beheben, indem ich den in Microsoft SQL Server 2012 Performance Dashboard Reports angegebenen Indizierungshinweisen folgte. Der Effekt war sofort, es klang wie Magie. Der Prozessor, der in den letzten Tagen fast immer zu 100% war, wurde super ruhig und das Feedback der Benutzer war durchschlagend. Sogar unser ERP-Techniker war begeistert, da es normalerweise 20 Minuten dauerte, um bestimmte Angebote zu erhalten, und er es schließlich in Sekundenschnelle tun konnte.

Im Laufe der Zeit begann es sich jedoch langsam zu verschlechtern. Ich habe es vermieden, mehr Indizes zu erstellen, aus Angst, dass zu viele Indizes die Leistung beeinträchtigen würden. Aber irgendwann musste ich diejenigen löschen, die keinen Nutzen hatten, und die neuen erstellen, die mir das Performance Dashboard vorschlägt. Aber keine Auswirkungen.

Die Langsamkeit ist im Wesentlichen beim Speichern und Beraten im ERP zu spüren.

Ich habe einen Windows Server 2012 R2 für SQL Server 2016 Enterprise (64-Bit) mit der folgenden Konfiguration:

• CPU: Intel Xeon CPU E5-2650 v3 bei 2,30 GHz
• Speicher: 84 GB
• In Bezug auf den Speicher verfügt der Server über ein Volume, das dem Betriebssystem gewidmet ist, ein anderes für die Daten und ein anderes für die Protokolle.
• 17 Datenbanken
• Benutzer:
  • In der größten Datenbank sind mehr oder weniger 113 Benutzer gleichzeitig verbunden
  • In einem anderen gibt es ungefähr 9 Benutzer
  • In zwei von ihnen sind 3 + 3
  • Der Rest hat jeweils nur 1 Benutzer
  • Wir haben ein Web, das auch für die größere Datenbank schreibt, bei dem die Verwendung jedoch viel weniger regelmäßig ist und das ungefähr 20 Benutzer haben sollte.
• Größe der DBs:
  • Die größte der Datenbanken hat 290 GB
  • Der zweitgrößte hat 100 GB
  • Der drittgrößte hat 20 GB
  • Die vierten 14 GB
  • Der Rest beträgt jeweils etwas mehr als 3 GB

Dies ist die Produktionsinstanz, aber wir haben auch eine Entwicklungsinstanz, von der ich glaube, dass sie für diesen Zweck ignoriert werden kann, da ich die meiste Zeit die einzige Verbindung dort bin, aber dieses Problem tritt ständig auf, selbst wenn ich nicht verbunden bin .

Der Prozessor ist fast immer so:

Wir haben Routinen, die nachts laufen (nicht problematisch) und einige, die tagsüber laufen.

Benutzer stellen über Remotedesktop eine Verbindung zu anderen Computern her, die von ODBC 32 für den Zugriff auf SQL Server konfiguriert wurden.

Das Rechenzentrum, in dem sich die Server befinden, hat 100/100 Mbit / s, und wo ich bin. Die meisten Websites sind durch MPLS und andere durch IPSec (von FO bis 4G) verlinkt. Der Anbieter hat viele Analysen durchgeführt und die Schaltung ist in Ordnung.

Die Cache-Trefferquote beträgt 99% (sowohl Benutzeranforderungen als auch Benutzersitzungen).

Die Wartezeiten sehen so aus:

Ich habe bereits Daten mit Perfmon gesammelt und habe die Ergebnisse, wenn dies bei Ihrer Analyse hilfreich ist. Ich persönlich habe aus der Analyse keine Schlussfolgerungen gezogen.

Ich zähle auf Ihre Unterstützung bei der Lösung dieses Problems und stehe zur Verfügung, um die Informationen bereitzustellen, die Sie für die Lösung für notwendig halten.

Vielen Dank.

Hier ist der sp_blitz-Abschlag (ich habe Firmennamen durch Pseudonyme ersetzt):

Priorität 1: Zuverlässigkeit :

• Letzte gute DBCC CHECKDB über 2 Wochen alt

  • Meister

  • Modell - Letzter erfolgreicher CHECKDB: 2018-02-07 15: 04: 26.560

  • msdb - Letzte erfolgreiche CHECKDB: 2018-02-07 15: 04: 27.740

Priorität 10: Leistung :

• CPU mit ungerader Anzahl von Kernen

  • Knoten 0 sind 5 Kerne zugeordnet. Dies ist eine wirklich schlechte NUMA-Konfiguration.

  • Knoten 1 sind 5 Kerne zugeordnet. Dies ist eine wirklich schlechte NUMA-Konfiguration.

Priorität 20: Dateikonfiguration :

• TempDB auf C-Laufwerk tempdb - Die tempdb-Datenbank enthält Dateien auf dem C-Laufwerk. TempDB wächst häufig unvorhersehbar und birgt das Risiko, dass auf Ihrem Server nicht mehr genügend Speicherplatz auf dem Laufwerk C vorhanden ist und ein schwerer Absturz auftritt. C ist auch oft viel langsamer als andere Laufwerke, sodass die Leistung beeinträchtigt werden kann.

Priorität 50: Zuverlässigkeit :

• Kürzlich in der Standardablaufverfolgung protokollierte Fehler
  • master - 2018-03-07 08: 43: 11.72 Anmeldefehler: 17892, Schweregrad: 20, Status: 1. 2018-03-07 08: 43: 11.72 Anmeldung Die Anmeldung für die Anmeldung 'example_user' ist aufgrund der Triggerausführung fehlgeschlagen. [KUNDE: IPADDR]

(Hinweis: Viele Fehler wie dieser aufgrund eines aktivierten Auslösers, der Benutzersitzungen einschränkt - zur Kontrolle der Nutzung der ERP-Lizenzierung)

• Seitenüberprüfung nicht optimal

  • DATABASE_A - Die Datenbank [DATABASE_A] hat KEINE für die Seitenüberprüfung. SQL Server hat möglicherweise Schwierigkeiten, Speicherbeschädigungen zu erkennen und wiederherzustellen. Verwenden Sie stattdessen CHECKSUM.

  • DATABASE_B - Die Datenbank [DATABASE_B] hat KEINE für die Seitenüberprüfung. SQL Server hat möglicherweise Schwierigkeiten, Speicherbeschädigungen zu erkennen und wiederherzustellen. Verwenden Sie stattdessen CHECKSUM.

  • DATABASE_C - Die Datenbank [DATABASE_C] hat KEINE zur Seitenüberprüfung. SQL Server hat möglicherweise Schwierigkeiten, Speicherbeschädigungen zu erkennen und wiederherzustellen. Verwenden Sie stattdessen CHECKSUM.

  • DATABASE_D - Die Datenbank [DATABASE_D] hat KEINE zur Seitenüberprüfung. SQL Server hat möglicherweise Schwierigkeiten, Speicherbeschädigungen zu erkennen und wiederherzustellen. Verwenden Sie stattdessen CHECKSUM.

  • DATABASE_E - Die Datenbank [DATABASE_E] hat KEINE für die Seitenüberprüfung. SQL Server hat möglicherweise Schwierigkeiten, Speicherbeschädigungen zu erkennen und wiederherzustellen. Verwenden Sie stattdessen CHECKSUM.

  • DATABASE_F - Die Datenbank [DATABASE_F] hat KEINE für die Seitenüberprüfung. SQL Server hat möglicherweise Schwierigkeiten, Speicherbeschädigungen zu erkennen und wiederherzustellen. Verwenden Sie stattdessen CHECKSUM.

  • DATABASE_G - Die Datenbank [DATABASE_G] hat KEINE zur Seitenüberprüfung. SQL Server hat möglicherweise Schwierigkeiten, Speicherbeschädigungen zu erkennen und wiederherzustellen. Verwenden Sie stattdessen CHECKSUM.

  • DATABASE_H - Die Datenbank [DATABASE_H] hat KEINE für die Seitenüberprüfung. SQL Server hat möglicherweise Schwierigkeiten, Speicherbeschädigungen zu erkennen und wiederherzustellen. Verwenden Sie stattdessen CHECKSUM.

  • DATABASE_I - Die Datenbank [DATABASE_I] hat KEINE zur Seitenüberprüfung. SQL Server hat möglicherweise Schwierigkeiten, Speicherbeschädigungen zu erkennen und wiederherzustellen. Verwenden Sie stattdessen CHECKSUM.

  • DATABASE_Z - Die Datenbank [DATABASE_Z] hat KEINE zur Seitenüberprüfung. SQL Server hat möglicherweise Schwierigkeiten, Speicherbeschädigungen zu erkennen und wiederherzustellen. Verwenden Sie stattdessen CHECKSUM.

  • DATABASE_K - Die Datenbank [DATABASE_K] hat KEINE zur Seitenüberprüfung. SQL Server hat möglicherweise Schwierigkeiten, Speicherbeschädigungen zu erkennen und wiederherzustellen. Verwenden Sie stattdessen CHECKSUM.

  • DATABASE_J - Die Datenbank [DATABASE_J] hat KEINE für die Seitenüberprüfung. SQL Server hat möglicherweise Schwierigkeiten, Speicherbeschädigungen zu erkennen und wiederherzustellen. Verwenden Sie stattdessen CHECKSUM.

  • DATABASE_L - Die Datenbank [DATABASE_L] hat KEINE für die Seitenüberprüfung. SQL Server hat möglicherweise Schwierigkeiten, Speicherbeschädigungen zu erkennen und wiederherzustellen. Verwenden Sie stattdessen CHECKSUM.

  • DATABASE_M - Die Datenbank [DATABASE_M] hat KEINE für die Seitenüberprüfung. SQL Server hat möglicherweise Schwierigkeiten, Speicherbeschädigungen zu erkennen und wiederherzustellen. Verwenden Sie stattdessen CHECKSUM.

  • DATABASE_O - Die Datenbank [DATABASE_O] hat KEINE zur Seitenüberprüfung. SQL Server hat möglicherweise Schwierigkeiten, Speicherbeschädigungen zu erkennen und wiederherzustellen. Verwenden Sie stattdessen CHECKSUM.

  • DATABASE_P - Die Datenbank [DATABASE_P] hat KEINE zur Seitenüberprüfung. SQL Server hat möglicherweise Schwierigkeiten, Speicherbeschädigungen zu erkennen und wiederherzustellen. Verwenden Sie stattdessen CHECKSUM.

  • DATABASE_Q - Die Datenbank [DATABASE_Q] hat KEINE zur Seitenüberprüfung. SQL Server hat möglicherweise Schwierigkeiten, Speicherbeschädigungen zu erkennen und wiederherzustellen. Verwenden Sie stattdessen CHECKSUM.

  • DATABASE_R - Die Datenbank [DATABASE_R] hat KEINE zur Seitenüberprüfung. SQL Server hat möglicherweise Schwierigkeiten, Speicherbeschädigungen zu erkennen und wiederherzustellen. Verwenden Sie stattdessen CHECKSUM.

  • DATABASE_S - Die Datenbank [DATABASE_S] hat KEINE zur Seitenüberprüfung. SQL Server hat möglicherweise Schwierigkeiten, Speicherbeschädigungen zu erkennen und wiederherzustellen. Verwenden Sie stattdessen CHECKSUM.

  • DATABASE_T - Die Datenbank [DATABASE_T] hat KEINE zur Seitenüberprüfung. SQL Server hat möglicherweise Schwierigkeiten, Speicherbeschädigungen zu erkennen und wiederherzustellen. Verwenden Sie stattdessen CHECKSUM.

  • DATABASE_U - Die Datenbank [DATABASE_U] hat KEINE zur Seitenüberprüfung. SQL Server hat möglicherweise Schwierigkeiten, Speicherbeschädigungen zu erkennen und wiederherzustellen. Verwenden Sie stattdessen CHECKSUM.

  • DATABASE_V - Die Datenbank [DATABASE_V] hat KEINE für die Seitenüberprüfung. SQL Server hat möglicherweise Schwierigkeiten, Speicherbeschädigungen zu erkennen und wiederherzustellen. Verwenden Sie stattdessen CHECKSUM.

  • DATABASE_X - Die Datenbank [DATABASE_X] hat KEINE zur Seitenüberprüfung. SQL Server hat möglicherweise Schwierigkeiten, Speicherbeschädigungen zu erkennen und wiederherzustellen. Verwenden Sie stattdessen CHECKSUM.

• Remote-DAC deaktiviert - Der Remotezugriff auf die Dedicated Admin-Verbindung (DAC) ist nicht aktiviert. Der DAC kann die Remote-Fehlerbehebung erheblich vereinfachen, wenn SQL Server nicht reagiert.

Priorität 50: Serverinfo :

• Sofortige Dateiinitialisierung nicht aktiviert - Aktivieren Sie IFI für schnellere Wiederherstellungen und das Wachstum von Datendateien.

Priorität 100: Leistung :

• Füllfaktor geändert

  • DATABASE_A - Die Datenbank [DATABASE_A] enthält 417 Objekte mit einem Füllfaktor von 70%. Dies kann Probleme mit der Speicher- und Speicherleistung verursachen, aber auch Seitenaufteilungen verhindern.

  • DATABASE_B - Die Datenbank [DATABASE_B] enthält 318 Objekte mit einem Füllfaktor von 70%. Dies kann Probleme mit der Speicher- und Speicherleistung verursachen, aber auch Seitenaufteilungen verhindern.

  • DATABASE_C - Die Datenbank [DATABASE_C] enthält 346 Objekte mit einem Füllfaktor von 70%. Dies kann Probleme mit der Speicher- und Speicherleistung verursachen, aber auch Seitenaufteilungen verhindern.

  • DATABASE_D - Die Datenbank [DATABASE_D] enthält 663 Objekte mit einem Füllfaktor von 70%. Dies kann Probleme mit der Speicher- und Speicherleistung verursachen, aber auch Seitenaufteilungen verhindern.

  • DATABASE_E - Die Datenbank [DATABASE_E] enthält 335 Objekte mit einem Füllfaktor von 70%. Dies kann Probleme mit der Speicher- und Speicherleistung verursachen, aber auch Seitenaufteilungen verhindern.

  • DATABASE_F - Die Datenbank [DATABASE_F] enthält 1705 Objekte mit einem Füllfaktor von 70%. Dies kann Probleme mit der Speicher- und Speicherleistung verursachen, aber auch Seitenaufteilungen verhindern.

  • DATABASE_G - Die Datenbank [DATABASE_G] enthält 671 Objekte mit einem Füllfaktor von 70%. Dies kann Probleme mit der Speicher- und Speicherleistung verursachen, aber auch Seitenaufteilungen verhindern.

  • DATABASE_H - Die Datenbank [DATABASE_H] enthält 2364 Objekte mit einem Füllfaktor von 70%. Dies kann Probleme mit der Speicher- und Speicherleistung verursachen, aber auch Seitenaufteilungen verhindern.

  • DATABASE_I - Die Datenbank [DATABASE_I] enthält 1658 Objekte mit einem Füllfaktor von 70%. Dies kann Probleme mit der Speicher- und Speicherleistung verursachen, aber auch Seitenaufteilungen verhindern.

  • DATABASE_Z - Die Datenbank [DATABASE_Z] enthält 673 Objekte mit einem Füllfaktor von 70%. Dies kann Probleme mit der Speicher- und Speicherleistung verursachen, aber auch Seitenaufteilungen verhindern.

  • DATABASE_K - Die Datenbank [DATABASE_K] enthält 312 Objekte mit einem Füllfaktor von 70%. Dies kann Probleme mit der Speicher- und Speicherleistung verursachen, aber auch Seitenaufteilungen verhindern.

  • DATABASE_J - Die Datenbank [DATABASE_J] enthält 864 Objekte mit einem Füllfaktor von 70%. Dies kann Probleme mit der Speicher- und Speicherleistung verursachen, aber auch Seitenaufteilungen verhindern.

  • DATABASE_L - Die Datenbank [DATABASE_L] enthält 1170 Objekte mit einem Füllfaktor von 70%. Dies kann Probleme mit der Speicher- und Speicherleistung verursachen, aber auch Seitenaufteilungen verhindern.

  • DATABASE_M - Die Datenbank [DATABASE_M] enthält 382 Objekte mit einem Füllfaktor von 70%. Dies kann Probleme mit der Speicher- und Speicherleistung verursachen, aber auch Seitenaufteilungen verhindern.

  • DATABASE_O - Die Datenbank [DATABASE_O] enthält 356 Objekte mit einem Füllfaktor von 70%. Dies kann Probleme mit der Speicher- und Speicherleistung verursachen, aber auch Seitenaufteilungen verhindern.

  • msdb - Die [msdb] -Datenbank enthält 8 Objekte mit einem Füllfaktor von 70%. Dies kann Probleme mit der Speicher- und Speicherleistung verursachen, aber auch Seitenaufteilungen verhindern.

  • DATABASE_P - Die Datenbank [DATABASE_P] enthält 291 Objekte mit einem Füllfaktor von 70%. Dies kann Probleme mit der Speicher- und Speicherleistung verursachen, aber auch Seitenaufteilungen verhindern.

  • DATABASE_Q - Die Datenbank [DATABASE_Q] enthält 343 Objekte mit einem Füllfaktor von 70%. Dies kann Probleme mit der Speicher- und Speicherleistung verursachen, aber auch Seitenaufteilungen verhindern.

  • DATABASE_R - Die Datenbank [DATABASE_R] enthält 2048 Objekte mit einem Füllfaktor von 70%. Dies kann Probleme mit der Speicher- und Speicherleistung verursachen, aber auch Seitenaufteilungen verhindern.

  • DATABASE_S - Die Datenbank [DATABASE_S] enthält 325 Objekte mit einem Füllfaktor von 70%. Dies kann Probleme mit der Speicher- und Speicherleistung verursachen, aber auch Seitenaufteilungen verhindern.

  • DATABASE_T - Die Datenbank [DATABASE_T] enthält 322 Objekte mit einem Füllfaktor von 70%. Dies kann Probleme mit der Speicher- und Speicherleistung verursachen, aber auch Seitenaufteilungen verhindern.

  • DATABASE_U - Die Datenbank [DATABASE_U] enthält 351 Objekte mit einem Füllfaktor von 70%. Dies kann Probleme mit der Speicher- und Speicherleistung verursachen, aber auch Seitenaufteilungen verhindern.

  • DATABASE_V - Die Datenbank [DATABASE_V] enthält 312 Objekte mit einem Füllfaktor von 70%. Dies kann Probleme mit der Speicher- und Speicherleistung verursachen, aber auch Seitenaufteilungen verhindern.

  • DATABASE_X - Die Datenbank [DATABASE_X] enthält 352 Objekte mit einem Füllfaktor von 70%. Dies kann Probleme mit der Speicher- und Speicherleistung verursachen, aber auch Seitenaufteilungen verhindern.

  • tempdb - Die Datenbank [tempdb] enthält 2 Objekte mit einem Füllfaktor von 70%. Dies kann Probleme mit der Speicher- und Speicherleistung verursachen, aber auch Seitenaufteilungen verhindern.

• Viele Pläne für eine Abfrage - 20763 Pläne sind für eine einzelne Abfrage im Plan-Cache vorhanden - was bedeutet, dass wir wahrscheinlich Probleme mit der Parametrisierung haben.

• Server-Trigger aktiviert - Der Server-Trigger [connection_limit_trigger] ist aktiviert. Stellen Sie sicher, dass Sie verstehen, was dieser Auslöser tut - je weniger Arbeit er leistet, desto besser.

• Gespeicherte Prozedur MIT RECOMPILE

  • master - [master]. [dbo]. [sp_AllNightLog] enthält WITH RECOMPILE im Code der gespeicherten Prozedur, was aufgrund ständiger Neukompilierungen des Codes zu einer erhöhten CPU-Auslastung führen kann.

  • master - [master]. [dbo]. [sp_AllNightLog_Setup] enthält WITH RECOMPILE im Code der gespeicherten Prozedur, was aufgrund ständiger Neukompilierungen des Codes zu einer erhöhten CPU-Auslastung führen kann.

Priorität 110: Leistung :

• Aktive Tabellen ohne Clustered-Indizes

  • DATABASE_A - Die Datenbank [DATABASE_A] enthält Heaps - Tabellen ohne Clustered-Index -, die aktiv abgefragt werden.

  • DATABASE_B - Die Datenbank [DATABASE_B] enthält Heaps - Tabellen ohne Clustered-Index -, die aktiv abgefragt werden.

  • DATABASE_C - Die Datenbank [DATABASE_C] enthält Heaps - Tabellen ohne Clustered-Index -, die aktiv abgefragt werden.

  • DATABASE_E - Die Datenbank [DATABASE_E] enthält Heaps - Tabellen ohne Clustered-Index -, die aktiv abgefragt werden.

  • DATABASE_F - Die Datenbank [DATABASE_F] enthält Heaps - Tabellen ohne Clustered-Index -, die aktiv abgefragt werden.

  • DATABASE_H - Die Datenbank [DATABASE_H] enthält Heaps - Tabellen ohne Clustered-Index -, die aktiv abgefragt werden.

  • DATABASE_I - Die Datenbank [DATABASE_I] enthält Heaps - Tabellen ohne Clustered-Index -, die aktiv abgefragt werden.

  • DATABASE_K - Die Datenbank [DATABASE_K] enthält Heaps - Tabellen ohne Clustered-Index -, die aktiv abgefragt werden.

  • DATABASE_O - Die Datenbank [DATABASE_O] enthält Heaps - Tabellen ohne Clustered-Index -, die aktiv abgefragt werden.

  • DATABASE_Q - Die Datenbank [DATABASE_Q] enthält Heaps - Tabellen ohne Clustered-Index -, die aktiv abgefragt werden.

  • DATABASE_S - Die Datenbank [DATABASE_S] enthält Heaps - Tabellen ohne Clustered-Index -, die aktiv abgefragt werden.

  • DATABASE_T - Die Datenbank [DATABASE_T] enthält Heaps - Tabellen ohne Clustered-Index -, die aktiv abgefragt werden.

  • DATABASE_U - Die Datenbank [DATABASE_U] enthält Heaps - Tabellen ohne Clustered-Index -, die aktiv abgefragt werden.

  • DATABASE_V - Die Datenbank [DATABASE_V] enthält Heaps - Tabellen ohne Clustered-Index -, die aktiv abgefragt werden.

  • DATABASE_X - Die Datenbank [DATABASE_X] enthält Heaps - Tabellen ohne Clustered-Index -, die aktiv abgefragt werden.

Priorität 150: Leistung :

(Hinweis: Viele Ratschläge hier, aber ich konnte sie aufgrund der Beschränkung der Zeichen nicht einschließen. Wenn es eine andere Möglichkeit zum Teilen gibt, geben Sie dies bitte an.)

Sie haben uns eine lange (und sehr detaillierte) Frage gestellt. Jetzt müssen Sie sich mit einer langen Antwort auseinandersetzen. ;)

Es gibt mehrere Dinge, die ich auf Ihrem Server ändern möchte. Beginnen wir jedoch mit dem dringendsten Problem.

Einmalige Notfallmaßnahmen:

Die Tatsache, dass die Leistung nach der Bereitstellung der Indizes auf Ihrem System zufriedenstellend war und die Leistung langsam abnimmt, ist ein sehr starker Hinweis darauf, dass Sie mit der Pflege Ihrer Statistiken beginnen und sich (in geringerem Maße) um die Indexframentierung kümmern müssen.

Als Notfallmaßnahme würde ich eine einmalige Aktualisierung der manuellen Statistiken für alle Ihre Datenbanken vorschlagen. Sie können die notwendige TSQL erhalten, indem Sie dieses Skript ausführen:

DECLARE @SQL VARCHAR(1000)  
DECLARE @DB sysname  

DECLARE curDB CURSOR FORWARD_ONLY STATIC FOR  
   SELECT [name]  
   FROM master..sysdatabases 
   WHERE [name] NOT IN ('model', 'tempdb') 
   ORDER BY [name] 

OPEN curDB  
FETCH NEXT FROM curDB INTO @DB  
WHILE @@FETCH_STATUS = 0  
   BEGIN  
       SELECT @SQL = 'USE [' + @DB +']' + CHAR(13) + 'EXEC sp_updatestats' + CHAR(13)  
       PRINT @SQL  
       FETCH NEXT FROM curDB INTO @DB  
   END  

CLOSE curDB  
DEALLOCATE curDB

Es wird von Tim Ford in seinem Blogpost auf mssqltips.com bereitgestellt und er erklärt auch, warum die Aktualisierung von Statistiken wichtig ist.

Bitte beachten Sie, dass dies eine CPU- und E / A-intensive Aufgabe ist, die nicht während der Geschäftszeiten ausgeführt werden sollte.

Wenn dies Ihr Problem löst, hören Sie bitte nicht dort auf!

Routinewartung:

Schauen Sie sich die Ola Hallengren Maintenance Solution an und richten Sie dann mindestens diese beiden Jobs ein:

• Ein Statistikaktualisierungsjob (wenn möglich jede Nacht). Sie können diesen CMD-Code in Ihrem Agentenjob verwenden. Dieser Job muss von Grund auf neu erstellt werden.

sqlcmd -E -S $(ESCAPE_SQUOTE(SRVR)) -d MSSYS -Q "EXECUTE dbo.IndexOptimize @Databases = 'USER_DATABASES', @FragmentationLow = NULL, @FragmentationMedium = NULL, @FragmentationHigh = NULL, @UpdateStatistics = 'ALL', @OnlyModifiedStatistics = 'Y', @MaxDOP = 0, @LogToTable = 'Y'" -b

• Ein Indexwartungsjob. Ich würde vorschlagen, einmal im Monat mit einer geplanten Ausführung zu beginnen. Sie können mit den Standardeinstellungen beginnen, die Ola für den IndexOptimize-Job bereitstellt.

Es gibt mehrere Gründe, warum ich den ersten Job vorschlage, um Statistiken separat zu aktualisieren:

• Bei einer Indexwiederherstellung werden nur die Statistiken der von diesem Index abgedeckten Spalten aktualisiert, während bei einer Indexreorganisation die Statistiken überhaupt nicht aktualisiert werden. Ola unterteilt die Fragmentierung in drei Kategorien. Standardmäßig werden nur kategorienhohe Indizes neu erstellt.
• Statistiken für Spalten, die nicht von einem Index abgedeckt werden, werden nur vom IndexOptimize-Job aktualisiert.
• Um das aufsteigende Schlüsselproblem zu mildern .

SQL Server aktualisiert die Statistiken automatisch, wenn die Standardeinstellung aktiviert bleibt. Das Problem dabei sind die Schwellenwerte (weniger ein Problem mit Ihrem SQL Server 2016). Statistiken werden aktualisiert, wenn sich eine bestimmte Anzahl von Zeilen ändert (20% in älteren Versionen von SQL Server). Wenn Sie große Tabellen haben, können sich viele Änderungen ergeben, bevor die Statistiken aktualisiert werden. Weitere Informationen zu Schwellenwerten finden Sie hier .

Da Sie, soweit ich das beurteilen kann, CHECKDBs ausführen, können Sie diese wie zuvor ausführen oder die Wartungslösung auch dafür verwenden.

Weitere Informationen zur Indexfragmentierung und -pflege finden Sie unter:

Übersicht über die Fragmentierung des SQL Server-Index

Sorgen Sie sich nicht mehr um die SQL Server-Fragmentierung

In Anbetracht Ihres Speichersubsystems würde ich vorschlagen, nicht zu viel auf "externe Fragmentierung" zu fixieren, da die Daten ohnehin nicht in der richtigen Reihenfolge in Ihrem SAN gespeichert sind.

Optimieren Sie Ihre Einstellungen

Das sp_Blitz-Skript bietet Ihnen eine hervorragende Startliste.

Priorität 20: Dateikonfiguration - TempDB auf Laufwerk C: Sprechen Sie mit Ihrem Speicheradministrator. Fragen Sie sie, ob Ihr C-Laufwerk die schnellste für Ihren SQL Server verfügbare Festplatte ist. Wenn nicht, legen Sie Ihre Tempdb dort ab ... Punkt. Überprüfen Sie dann, wie viele Temdb-Dateien Sie haben. Wenn die Antwort eine ist, beheben Sie das . Wenn sie nicht die gleiche Größe haben, beheben Sie diese beiden.

Priorität 50: Serverinfo - Sofortige Dateiinitialisierung nicht aktiviert: Folgen Sie dem Link, den Sie vom Skript sp_Blitz erhalten, und aktivieren Sie IFI.

Priorität 50: Zuverlässigkeit - Seitenüberprüfung nicht optimal: Sie sollten dies auf die Standardeinstellung (CHECKSUM) zurücksetzen. Folgen Sie dem Link, den das Skript sp_Blitz Ihnen gibt, und folgen Sie den Anweisungen.

Priorität 100: Leistung - Füllfaktor geändert: Fragen Sie sich, warum es so viele Objekte mit einem Füllfaktor von 70 gibt. Wenn Sie keine Antwort haben und kein Anwendungsanbieter dies strikt verlangt. Stellen Sie es wieder auf 100% ein.

Dies bedeutet im Grunde, dass SQL Server 30% leeren Speicherplatz auf diesen Seiten lässt. Um die gleiche Datenmenge zu erhalten (im Vergleich zu 100% vollständigen Seiten), muss Ihr Server 30% mehr Seiten lesen, und sie benötigen 30% mehr Speicherplatz. Der Grund dafür ist häufig, eine Indexfragmentierung zu verhindern.

Aber auch hier speichert Ihr Speicher diese Seiten ohnehin in verschiedenen Blöcken. Also würde ich es auf 100% zurücksetzen und es von dort nehmen.

Was tun, wenn alle glücklich sind:

• Sehen Sie sich den Rest der Ausgabe von sp_Blitz an und entscheiden Sie, ob Sie sie wie vorgeschlagen ändern.
• Führen Sie sp_BlitzIndex aus und sehen Sie sich die von Ihnen erstellten Indizes an, ob sie verwendet werden oder wo die Möglichkeit besteht, einen hinzuzufügen / zu ändern.
• Sehen Sie sich Ihre Query Store-Daten an (wie von Peter vorgeschlagen). Eine Einführung finden Sie hier .
• Genießen Sie den Rockstar live, den ein DBA verdient. ;)

Ohne all Ihre Antworten zu ignorieren, die sehr nützlich waren und die ich angewendet habe oder anwenden werde, war das größte Problem nicht leicht zu finden.

Das Problem wurde in den Tagen nach unseren letzten Nachrichten noch schlimmer.

Da wir auf Cloud basieren, haben weder ich noch das Unternehmen, das die Infrastruktur verwaltet und uns unterstützt, Zugriff auf die physischen Hosts.

Etwas ließ mich wundern, als ich bemerkte, dass der Prozessor an manchen Tagen durchschnittlich 20% betrug und an anderen Tagen viel höher war, über 60%, wenn die Arbeitslast, obwohl nie genau gleich, ähnlich ist. Es gibt die gleiche Anzahl von Personen, die mehr oder weniger die gleiche Art von Operationen ausführen.

Anfang dieser Woche blieben die Benutzer einige Minuten lang hängen und nur der Prozessor wurde erwürgt. Ich habe mehrere Benutzer gebeten, sich abzumelden (diejenigen, die mehr Ressourcen ausgegeben haben, aber immer noch nichts Außergewöhnliches). Ich habe verschiedene mit der Datenbank verknüpfte Dienste deaktiviert, und am Ende hat sich nichts geändert. Ich habe den Systemadministrator gefragt, der uns unterstützt und mit den Mitarbeitern unserer Cloud kommunizieren kann, um zu sehen, was ich sehe, und um mir zu helfen, etwas zu finden, da ich das Problem nicht besser finden könnte.

Der Techniker hat auch nichts gefunden. Endlich gab er mir einen Grund, warum etwas anderes dieses Problem verursachen musste, als er die Cloud kontaktierte. In der Cloud haben sie nichts realisiert, nur dass die VM, die unseren SQL Server unterstützt, an diesem Tag einige Male zwischen physischen Hosts verschoben wurde, da ein Lastenausgleich zwischen physischen Hosts konfiguriert ist. Glücklicherweise teilte ich unserem Techniker genau mit, zu welcher Zeit die Probleme an diesem Tag auftraten, was mit der Zeit zusammenfiel, als die VM das letzte Mal auf einen der physischen Hosts verschoben wurde, von denen sie den Rest des Tages nicht verlassen hatte.

Wenn der Techniker dieses Problem nicht genau verfolgt hätte, wäre dies eher eine der Zeiten gewesen, in denen er sogar mit den Cloud-Leuten sprechen konnte, aber wenn sie Leistungsbeispiele sahen, würden sie nichts bekommen, weil die Cloud wieder nur sah Proben mit CPU in der Größenordnung von 40/50%, obwohl sie im Durchschnitt über 80% lag und oft bei 100% steckte.

Jetzt steht der Computer auf einem physischen Host (bewegt sich nicht zwischen Hosts) und obwohl wir noch nicht die perfekte Leistung erzielt haben, arbeiten alle und geben viel mehr positives Feedback, da die durchschnittliche CPU bei allen unseren Benutzern und ungefähr 20% beträgt Dienstleistungen.

In der Zwischenzeit haben wir tempdb auch auf einer anderen Festplatte abgelegt (es befand sich auf der Betriebssystemfestplatte) und die Dateien vergrößert, um der Anzahl der Kerne der CPUs besser zu entsprechen.

Die Anzahl der Kerne wurde ebenfalls basierend auf den Empfehlungen von sp_Blitz angepasst.

Es gab auch eine automatische Routine, die den ganzen Tag lief, basierend auf einem alten Datum ... und da sie nicht am Morgen endete, als wir ankamen, und wir keine Möglichkeit haben zu überprüfen, ob sie läuft oder nicht, fing ich immer noch an manuell ausführen. Aber wahrscheinlich lief der andere noch und lief während dieser Zeit zweimal. Wir haben das Datum geändert, um die Zeit zu verkürzen, und jetzt ist es spät in der Nacht. Dies war jedoch nicht die Lösung, da es vor vielen Problemen gelöst wurde, die wir wie das hier beschriebene hatten.

Wir haben es auch geschafft, den ERP-Assistenten dazu zu bringen, ein Treffen mit dem Hersteller zu vereinbaren. Deshalb werden wir unser System zeigen und nach Vorschlägen suchen sowie einige Zweifel klären, da die Schulungsvideos Empfehlungen enthalten, die den meisten widersprechen Empfehlungen, einschließlich Microsoft selbst, wie Priority Boost on und Fill Factor 70%.

Da die Anwendung auch über einen Wartungsbildschirm verfügt, werde ich nach der erforderlichen Periodizität dieser Wartung und den verbleibenden Aufgaben außerhalb der Anwendung suchen. Meine Idee ist es, Ola Hallengrens Pläne zu verwenden.

Ich glaube, dass die Antwort von Thomas Kronawitter absolut richtig ist, und ich wende sie an. Ich denke jedoch, dass diese Beschreibung für andere Menschen wichtig sein kann, die nach Befolgung aller bewährten Methoden das Problem immer noch nicht beheben können, da sie sich auf den physischen Hosts befinden kann . Danke Thomas.