none
MSSQL Server langsam RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    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?

    Mittwoch, 22. August 2018 13:55
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    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

    Mittwoch, 22. August 2018 14:06
    |
    Moderator
  • Question
    Anmelden
    0
    Anmelden

    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)

    Donnerstag, 23. August 2018 06:16
    |
  • Question
    Anmelden
    0
    Anmelden

    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

    Donnerstag, 23. August 2018 06:29
    |
    Moderator
  • Question
    Anmelden
    0
    Anmelden

    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

    Donnerstag, 23. August 2018 06:52
    |
    Beantworter
  • Question
    Anmelden
    0
    Anmelden

    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)

    Samstag, 25. August 2018 13:29
    |
  • Question
    Anmelden
    0
    Anmelden
     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

    Montag, 27. August 2018 13:27
    |
  • Question
    Anmelden
    0
    Anmelden

    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)

    Montag, 27. August 2018 14:17
    |