SQL Anwendung läuft langsam

[Sunny61 773]

vor einer Stunde schrieb BWendle:

Dabei ist wieder ersichtlich, dass die CPU überhaupt nicht ausgelastet ist aber das System bei einigen Prozessen hohe Wartezeiten aufweist.

Wie viele TEMP-DBs sind denn im System vorhanden? Für jede CPU sollte eine DB existieren.

In der Übersicht aus dem SSMS finden sich 11 fehlende Indizies, sind die alle von der einen Anwendung/DB? Was sagt der Hersteller dazu?

 

EDIT: In diesem Artikel gibt es Script das dir Details zu den verwendeten TEMP-DBs liefert: https://learn.microsoft.com/en-us/sql/relational-databases/databases/tempdb-database?view=sql-server-ver16

bearbeitet 14. Dezember 2023 von Sunny61

[mwiederkehr 351]

Die zweite Abfrage bei den "Expensive Queries" ("SELECT target_data FROM") kommt vom Telemetrie-Dienst. Dieser führt sie alle 5 Minuten aus. Da sie im Durchschnitt 55 Sekunden CPU-Zeit benötigt, erklärt das die wechselnden Wartezeiten und den Effekt, dass es nach einem Neustart des SQL Servers für einige Minuten gut läuft. Aber es erklärt nicht, weshalb die Abfrage so lange läuft. Der Telemetrie-Dienst läuft auf jedem SQL Server und ich habe noch nie eine Auswirkung von dessen Abfragen bemerkt.

 

Als Sofortmassnahme kannst Du den Dienst deaktivieren und schauen, ob es dann besser wird. Zumindest müssten die Wartezeiten dann mehr oder weniger konstant sein. Eine Anleitung findest Du in den Kommentaren dieses Artikels: https://www.brentozar.com/archive/2019/02/what-queries-does-microsofts-telemetry-service-run-on-your-sql-server/

 

Du kannst die Abfrage auch im Management Studio ausführen und den Ausführungsplan anzeigen lassen. Dann siehst Du evtl., wo sie hängt. Ich denke aber, das ist nur ein Symptom eines tiefer liegenden Problems, denn wie erwähnt laufen diese Abfragen auf jedem SQL Server, ohne je in der Performance-Auswertung aufzutauchen.

[Nobbyaushb 1.359]

Es gibt von VMware einen Artikel, das man bestimmte Funktionen (TCP_Offloading etc.) bei einem SQL auf der VM abschalten soll

Ich suche mal, ob ich den wiederfinde

 

Das war mal ein anderer, das ist ein Forum-Beitrag:
https://communities.vmware.com/t5/ESXi-Discussions/ESX-4-1-Disable-TCP-Checksum-offload/td-p/1731240

bearbeitet 14. Dezember 2023 von Nobbyaushb

[zahni 521]

Mal ein paar Fragen/ Möglichkeiten:

 

- SQL Express 2017 würde ich nicht mehr nehmen. Dafür gibt es aktuell bald keine Updates mehr. Funktionale Updates sind schon länger ausgelaufen.

- Generell begrenzt SQL-Express die Performance und limitiert den RAM auf 1 GB. Die DB darf ohne Transaktions-Log max. 10 GB groß werden (damit die sie physikalische Größe der DB-Datei gemeint.

- Wenn es keinen Bedarf für Transaktionslogs gibt (z.B. bei einem täglichen Full-Backup) kann man das Logging auf Simple stellen. 

- Läuft ein Virenscanner? Dann den MSSQLServer-Prozess ausschließen. 

- Wirklich optimierte Indexe sind selten. Hier kann der Admin nachhelfen: https://learn.microsoft.com/en-us/sql/tools/dta/lesson-2-using-database-engine-tuning-advisor?view=sql-server-ver16

- In der Anwendung können lange Locks oder sogar Deadlocks auftreten, die ein vernünftiges Arbeiten verhindern. Der Admin hat die Aufgabe das zu erkennen, abstellen kann das nur die Entwicklung:

  https://www.sqlshack.com/what-are-sql-server-deadlocks-and-how-to-monitor-them/ . Ursache kann u.U. ein ungeeigneter Isolation Mode bei lesenden Abfragen sein. 

[BWendle 3]

Guten Morgen Zusammen,

 

ich würde Euch gerne heute ein Update geben, was ich bis heute erreicht habe und wie der Stand meines Problemes ist.

 

Am 10.01. haben wir mal auf dem Server den Arbeitsspeicher von 8GB auf 16GB erhöht. Diese Anpassung hat, wie erwartet, keine Auswirkung auf die Performance geben.

 

Aus diesem Grund haben wir, wie oben bereits geplant, einen neuen Server mit Microsoft Server 2019 aufgesetzt, bei dem mir heute abschließend der SQL Server 2019 Standard installiert wurde, sodass mir jetzt wieder eine opt. Plattform zur Verfügung steht, um die Etikettensoftware neu zu installieren. Sobald dies erfolgt ist und alle notwendigen Einstellungen und Testläufe erfolgreich durchgeführt werden konnten, wird der alte Server durch den neuen Server in der Produktion ersetzt.

 

Der Zeitdruck der Umstellung hat sich seit 12.01. wieder plötzlich schlagartig reduziert, nachdem ich die Rückmeldung aus der Produktion erhalten habe, das die Software wieder ohne Probleme läuft...

 

Nach Rücksprache unseres ITlers, gab es anscheinend in unserem Mutterkonzern in letzter Zeit immer mehr Prozesse, die Performance-Probleme aufgewiesen haben, wodurch vor kurzem (ich drücke mich jetzt wahrscheinlich sehr laienhaft aus) ein Neustart des "Hauptservers" durchgeführt wurde.

 

Ich vermute nun sehr stark, dass sich die Systeme irgendwie "aufgehängt" haben und durch diesen Neustart dieser Fehler behoben werden konnte. Für Details und als Grundlage für wiederkehrende Probleme, habe ich mal eine Anfrage an die IT gesendet.

 

Im diesem Zuge möchte ich mich nochmals bei allen Bedanken, die mir Tipps und Lösungsansätze, um das Problem zu beheben, aufgezeit haben.

 

Werde mich sehr gerne bei einem neuen Problem wieder an Euch wenden.

 

Mit freundlichen Grüßen

Bernd.

 

 

 

bearbeitet 19. Januar von BWendle