Fragensteller
MSSQL Server langsam

Frage
-
Hallo zusammen,
wir haben immer mal wieder das Problem, dass unsere Datenbank beruhend auf MS AX 2009 langsam wird - man sieht aber nirgendwo etwas besonderes - weder bei der CPU Auslastung noch beim Festplattenzugriff. Es kann auch nicht an den abfragen liegen, da die gleichen Abfragen normalerweise schnell durchlaufen.
Was hilft ist, dass ich das ich den "Maximalen ServerArbeitsspeicher" ein paar GB geringer mache und dann wieder zurück stelle auf den Ausgangswert, dann ist alles wieder schnell.
Worauf deutet sowas hin?
Alle Antworten
-
Hi,
das kann an allem Möglichen liegen. Indizes stark fragmentiert, Plattenfehler, Speicherfehler, nicht optimierte SQL Abfragen, irgendein Hotfix/Update/CU/SP des Datenbankservers, der das Analyse- und Optimierungsverhalten der SQL Engine verändert hat, usw. usw. usw.
Welche SQL Server Version setzt ihr ein? (bitte exakte Versionsnummer, bspw. über SELECT @@VERSION ausgelesen, posten)
Welche Art von Abfragen läuft so langsam? Wie sehen die Ausführungspläne dieser Abfragen aus? (Bitte zweimal, einmal, wenn es langsam ist und einmal, wenn es schnell ist).
Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET (2001-2018)
https://www.asp-solutions.de/ - IT Beratung, Softwareentwicklung, Remotesupport -
Indizes lassen wir eigentlich jede Nacht neu "defragmantieren". Plattenfehler und Speicherfehler auch definitiv nicht - sind 3 SSD in Raid 5 drin. Wie gesagt an nicht optimierten abfragen kann es auch nicht liegen, da es die gleichen abfragen sind, die dann nach dem "Maximalen ServerArbeitsspeicher" verändern wieder schnell funktionieren und es auch generell überall im Dynamics AX 2009 dann "langsam geht".
Noch Ideen?
@@Version zeigt folgendes:
Microsoft SQL Server 2012 - 11.0.2218.0 (X64)
Jun 12 2012 13:05:25
Copyright (c) Microsoft Corporation
Business Intelligence Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)
-
Hallo Andre,
ähm. Bevor wir weiterreden, bitte erstmal die Instanz auf einen halbwegs aktuellen Stand bringen. 11.0.2218.0 ist RTM mit einem Sicherheitshotfix. Aktuell wäre 11.07469.6, da liegen Welten dazwischen.
Ansonsten bringt es gar nichts, wenn wir uns damit beschäftigen, da das auch ein Bug sein kann.
Gruß, Stefan
Microsoft MVP - Visual Developer ASP/ASP.NET (2001-2018)
https://www.asp-solutions.de/ - IT Beratung, Softwareentwicklung, Remotesupport -
Was bewirkt denn die Änderung des Arbeitsspeichers? Die Pläne aus dem Speicher könnten evtl. verschwinden oder ungültig werden und beim nächsten Aufruf wieder optimal neu erstellt werden.
Versuch doch mal, ob diese Option ähnliches bewirkt:
Use <MeineProblematischeDatenbank> go Declare @db_ID int = DB_ID(); DBCC FLUSHPROCINDB(@db_ID);
Das ist undokumentiert und entfernt alle Pläne, die zu der Datenbank gehören aus dem Cache. Wenn es dann wieder besser wird, liegt es an suboptimalen Plänen.
Eine Ursache dafür hat Stefan bereits genannt. Also erst mal patchen!
Einen schönen Tag noch, Christoph - http://www.insidesql.org/blogs/cmu
-
Hallo Andre,
"Was hilft ist, dass ich das ich den "Maximalen ServerArbeitsspeicher" ein paar GB geringer mache und dann wieder zurück stelle auf den Ausgangswert, dann ist alles wieder schnell."
Ich würde hier ganz stark auf Probleme mit Parameter Sniffing und/oder veraltete Statistiken tippen. Wenn Du den Arbeitsspeicher veränderst, können Executionpläne aus dem Cache geworfen werden, da Du den Speicher verringerst. In diesem Fall müssen natürlich die Abfragen neu kompiliert werden.
Wenn Du das gleiche Verhalten beobachten kannst, wenn Du - wie Christoph ja schon geschrieben hat - die Ausführungspläne mit DBCC FREEPROCCACHE oder DBCC FLUSHPROCINDB löschst, ist es das wahrscheinlichste Problem.
Ansonsten würde ich auch mal versuchen, mit Hilfe eines "Blocked Process Reports" zu untersuchen, ob Statements häufig durch andere Prozesse blockiert werden.
Uwe Ricken (Blog | Twitter)
Microsoft Certiied Master - SQL Server 2008
Microsoft Certified Solution Master - CHARTER Data Platform
Microsoft Certified Solution Expert - Data Platform
db Berater GmbH
Microsoft SQL Server Blog (german only) -
Wenn Du den Arbeitsspeicher veränderst, können Executionpläne aus dem Cache geworfen werden, da Du den Speicher verringerst. In diesem Fall müssen natürlich die Abfragen neu kompiliert werden.
Hi Uwe,
können oder werden? Ich würde jetzt IMO sagen das Zweite.
Hab auf meiner Spielwiese auf die Schnelle (gibt ja noch genug anderes zu tun) den Speicher etwas reduziert.
Im SQL Server Error Log bekommt man sofort folgende Meldungen präsentiert:
SQL Server has encountered 1 occurrence(s) of cachestore flush for the 'Object Plans' cachestore (part of plan cache) due to some database maintenance or reconfigure operations.
SQL Server has encountered 1 occurrence(s) of cachestore flush for the 'SQL Plans' cachestore (part of plan cache) due to some database maintenance or reconfigure operations.
SQL Server has encountered 1 occurrence(s) of cachestore flush for the 'Bound Trees' cachestore (part of plan cache) due to some database maintenance or reconfigure operations.@Threadersteller:
Entsprechende Tipps sind ja schon eingegangen: Ggf wird bei einer der ersten Abfragen ein "unglücklicher" Parameter gewählt, weswegen der Abfrageplan für nachgelagerte Queries suboptimal daherkommt. Außerdem auf einen aktuellen Build patchen.
Darüber hinaus schreibst Du, dass die Indizes regelmäßig "defragmentiert" werden.
Was passiert denn tatsächlich an der Stelle? Gibt es nur einen Reorganize oder Index Rebuilds? Bei einem Reorg kann es nämlich sein, das eine Aktualisierung der Statistiken möglicherweise gar nicht angestoßen wird.
Wie schaut denn generell die Konfig des SQL Servers aus? Wie viel RAM steht der Instanz zur Verfügung und wie groß ist die Datenbank?
Gruß
Dirk
May you never suffer the sentiment of spending a day without any purpose
-
Hallo Dirk,
"können oder werden? Ich würde jetzt IMO sagen das Zweite."
Kann man so nicht zu 100% sagen. Wenn der Speicher so extrem reduziert wird, dass es sehr eng wird, werden die Pläne auf jeden Fall rausgeschmissen. Ich habe hier mal einen Test mit einer Instanz mit 8 GB gemacht. Der RAM war nicht vollständig ausgenutzt und bei einer Neukonfiguration auf 4 GB hat sich nichts im Cache geändert.
Habe aber nicht getestet, wie es ist, wenn der vollständige Speicher verwendet wird.
Uwe Ricken (Blog | Twitter)
Microsoft Certiied Master - SQL Server 2008
Microsoft Certified Solution Master - CHARTER Data Platform
Microsoft Certified Solution Expert - Data Platform
db Berater GmbH
Microsoft SQL Server Blog (german only)