Dynamics 365 BC SQL Server-Leistung
Dynamics 365 BC SQL Server-Leistung – worauf sollten Sie bei einem Überwachungstool achten? Was ist erforderlich?
Ein Überwachungstool / Analyse-Tool wie z.B. V8 Search XE muss Ihnen ein Verständnis der häufig komplexen Leistungsmuster vermitteln, die SQL Datenbanken unter Last aufweisen. Damit Sie vorhersagen können, wie Sie mit der Erweiterung bzw. Vergrößerung der Datenbank umgehen werden. Es muss uns auch helfen, die Symptome von Stress zu erkennen und zu handeln, bevor sie zu Problemen werden. Das Tool sollte aufzeigen, was in Ihrer Datenbank passiert ist, als ein zeitweise auftretendes Problem auftrat und die Dynamics 365 BC SQL Server-Leistung spürbar beeinflusste.
- Chronische Leistungsprobleme: Wenn eine Datenbank langsam und konsistent reagiert, wird oft davon ausgegangen, dass Ihr System mehr Ressourcen oder eine andere Technologie benötigen. Der Kauf von „mehr Metall“ oder die Erhöhung Ihrer Cloud-Ressourcen ist teuer, wenn die vollen Kosten berücksichtigt werden. Ebenso steigen die Kosten einer neuen Technologie schnell an, sobald Lizenzen und die Schulung der Mitarbeiter berücksichtigt werden. Solche Investitionen mögen als logische Lösung erscheinen, aber ohne die Ursache für das langsame Verhalten von Dynamics 365 BC/ NAV untersuchen zu können, sind sie sinnlos. Sie müssen wissen, warum Ihre Dynamics Lösung langsam läuft und was das Problem verursacht, bevor Sie davon ausgehen können, dass ein Upgrade die Antwort ist. Das Beheben einiger unerwünschter Abfragen kann zu einer überraschend schnellen Verjüngung einer müden Datenbank führen und diese unnötigen Kosten und Verzögerungen vermeiden.
- Zeitweise auftretende Leistungsprobleme: Wenn eine Dynamics 365 Business Central SQL Server Datenbank ein zeitweiliges Problem aufweist, ist es einfacher zu lösen, wenn Ihnen Daten zur Verfügung stehen, wann und unter welchen Umständen dies geschieht. Wenn Sie eine historische Aufzeichnung der zuverlässigsten Leistungsindikatoren oder Metriken haben, können Sie die Aktivitäten über verschiedene Zeiträume hinweg vergleichen, und es ist dann viel einfacher, das Problem schneller zu finden und zu beheben.
- Akute Leistungsprobleme: Wenn Sie die Leistung Ihrer Dynamics SQL Datenbank nicht überwachen, verlassen Sie sich tatsächlich darauf, dass sich Ihre Benutzer beschweren, wenn die Datenbank zu langsam ist, um ihre Arbeit zu erledigen. Dies ist keine gute Idee, da nur wenige Unternehmen etwas tolerieren, das Ihr Geschäft behindert.
Mit der Verantwortung Dynamics 365 BC/NAV Server ist es möglich, SQL Server-eigenen Tools zu verwenden, um die Diagnosedaten zu erfassen, die Sie benötigen, um besorgniserregende Änderungen oder Trends zu erkennen. Sofern die Person, die für die erste Beantwortung von Leistungsproblemen verantwortlich ist, nicht weiß, wo sie nachforschen muss, ist die in SQL Server verfügbare Informationsmenge kaum mehr als eine Ablenkung. Die Schwierigkeit besteht häufig darin, die für Ihre Systemlandschaft notwendigen Informationen aus den zahlreichen Server-Metriken zu finden, die auf Ressourcenkonflikte, Fehlerbedingungen und Engpässe auf dem SQL Server hinweisen können.
Infolgedessen sollten Sie ein Überwachungstool einsetzen, dass Sie darauf hinweist, dass mit der SQL Server-Datenbanken etwas nicht richtig ist und gerade genug Informationen mit der Warnung bereitstellt. Sobald die Art des Problems hinreichend verstanden ist, können Sie bei Bedarf verschiedene zusätzliche Leistungsmetriken verwenden, die im SQL Server und den Dynamics NAV Servern verfügbar sind.
Anzeichen für mögliche Leistungsprobleme
- Die aktuelle Leistung ist ungewöhnlich langsam.
- Der Server steht unter hohem Prozessordruck.
- Es gibt mehr Vorfälle als üblich mit Blockierungen, Deadlocks und lang laufenden Abfragen
- Es gibt eine zunehmende Anzahl von Wartezeiten bestimmter Arten
- Die Leistung verschlechtert sich erheblich, als man mit zunehmender Datenbankgröße erwarten würde
- Der Speicherbedarf und der für die Protokollierung erforderliche Speicherplatz nehmen rapide zu
Diagnosedaten sammeln
Sowohl Windows Server, Dynamics NAV Server als auch SQL Server verfügen über integrierte Leistungstools, und wir haben mit V8 Search XE ein Tool, um Probleme mit der Leistung zu beheben. Einige dieser Tools bieten allgemeine Metriken, während andere sehr spezifische Bedingungen überprüfen sollen, die eine Theorie darüber bestätigen können, was ein Problem verursacht. Ist die Ursache für eine lang laufende Abfrage (Long Duration) beispielsweise ein fehlender Index, eine schlechte Abfragelogik wie ein „Non-SARGable-Abfrage-Filter“? Sie können erweiterte Ereignisse (XEvents), Perfmon, DMVs (Dynamic Management Views) und Traces verwenden, um diese Daten bereitzustellen.
Wenn Leistungsprobleme bestehen bleiben, nachdem die Datenbankadministratoren auf das Problem aufmerksam gemacht wurden, können Sie mit V8 Search XE wahrscheinlich die Hauptursache finden. Wenn das Problem jedoch vorübergehend und zeitweise auftritt, kann es sehr schwierig werden, da die von Ihnen benötigten Details verschwunden sind. Bis das Problem gemeldet wird, ist es zu spät und sie müssen warten, bis es erneut Auftritt.
Datenbankadministratoren benötigen ein Tool wie V8 Search XE, das die erforderlichen Diagnosedaten kontinuierlich in regelmäßigen Abständen sammelt, damit sie Probleme schnell beheben können, unabhängig davon, wann sie auftreten. Ein effektives Überwachungssystem muss auf jedem SQL Server funktionieren, um alle Punkte in der gesamten Serverlandschaft zu verbinden.
Anforderungen an die Leistungsüberwachung
Es gibt eine Reihe von Möglichkeiten, wie Sie mit Ihrem Überwachungstool Leistungsprobleme anhand der gesammelten Diagnosedaten identifizieren und diagnostizieren können. Hier können Sie nur einige der offensichtlicheren Möglichkeiten behandeln.
Verbinden Sie Server-Stressbedingungen schnell mit ihrer Ursache
Angenommen, Dynamics Benutzer melden eine langsame Datenbankleistung, und Ihr Überwachungstool zeigt an, dass die CPU-Auslastung „hoch“ ist. Bedeutet dies, dass „Prozessordruck“ das Leistungsproblem verursacht? Es hängt davon ab, ob! Wenn der Server ausgelastet ist, sollten Ihre Prozessoren hart arbeiten, um alle Anfragen der Benutzer zu verarbeiten! Ein gutes Überwachungstool hilft Ihnen dabei, diese eine Metrik schnell mit anderen zu korrelieren, die den CPU-Druck bestätigen (oder ausschließen) und mit den spezifischen Abfragen, die zum Zeitpunkt des Problems ausgeführt werden.
Ist die CPU nur deshalb ausgelastet, weil der Server ausgelastet ist? Ist die Anzahl der Verbindungen oder die Anzahl der Benutzeranforderungen pro Sekunde höher als normal? Sie können nur sicher wissen, ob Ihr Überwachungstool für jede dieser Metriken eine Basislinie hat. Mit anderen Worten, wenn Sie damit schnell aktuelle Werte mit Werten für dieselben Metriken gestern zur gleichen Zeit oder zur gleichen Zeit in den letzten Tagen oder Wochen vergleichen können.
Geht die CPU-Erhöhung mit einer signifikanten Verlängerung der Zeit einher, die Benutzerprozesse nur damit verbringen, auf die CPU zu warten? Diese häufigen Signalwartezeiten können zusammen mit einer hohen CPU-Auslastung auf einen CPU-Druck hinweisen. Auch hier benötigen Sie eine Basislinie für Signalwartezeiten, um dies festzustellen, und Ihr Überwachungstool sollte es sehr einfach machen, bei Bedarf eine Metrik zum Sammeln dieser Daten hinzuzufügen.
Ihre Leistungsmetrik-Baselines zeigen möglicherweise, dass der CPU-Druck in der letzten Woche eines jeden Monats normal ist. An diesem Punkt der Leistungsuntersuchung möchten Sie den Server-Stresszustand, ob hohe CPU-, Speicher- oder I/O-Auslastung (oder alle drei), direkt mit lang laufenden Abfragen in diesem Zeitraum verbinden. Eine übermäßige CPU-Auslastung wird häufig durch lang andauernde, komplexe Abfragen verursacht, die einfach viel Rechenleistung erfordern. Schlecht abgestimmte T-SQL-Anweisungen und schlecht gestaltete Indizes können zu einer hohen Belastung aller Ressourcen führen.
Gibt es Möglichkeiten, den Druck durch die Optimierung dieser Abfragen oder der Datenbankindizes zu verringern? Wenn nicht, können Sie Schritte unternehmen, um die CPU-Zuordnung für diesen Zeitraum zu optimieren. Wenn es sich beispielsweise um Cloud-basierte Server handelt, können Sie diese elastisch erweitern, um mehr Prozessoren zu verwenden, und so die Leistung Ihrer wichtigen Berichtsabfragen optimieren?
Ohne die Tools, mit denen festgestellt werden kann, ob die Engpässe durch schlecht geschriebene Abfragen oder fehlende Indizes verursacht werden, besteht die Versuchung, die Anzahl der Kerne zu erhöhen. Mithilfe eines Überwachungstools kann häufig eine kleine Anzahl von Abfragen gefunden werden, die die meisten Engpässe verursachen. Sobald diese Abfragen identifiziert sind, müssen nur noch die Abfragen und Indizes optimiert werden.
Server-Wartezeiten analysieren
Warten Sie im Statistikbereich mit dem leistungsstarken Tool, um den größten Engpass auf Ihren SQL-Servern festzustellen. Jedes Mal, wenn eine Anforderung zum Warten gezwungen wird, zeichnet SQL Server die Länge der Wartezeit und die Ursache der Wartezeit (den Wartetyp) auf, die im Allgemeinen die Ressource angibt, auf die die Anforderung gewartet hat, die sie jedoch nicht abrufen konnte. Wartezeiten können beispielsweise mit Parallelität, I/O Langsamkeit oder Sperrung zusammenhängen. Dies wird als Gesamtaggregatwerte angegeben, die seit dem letzten Neustart des Servers erfasst wurden. DBAs überprüfen normalerweise Wartezeiten, um die Belastungen auf dem Server zu verstehen.
Auch hier bedeutet das Wissen, dass eine bestimmte Wartezeitmetrik „hoch“ ist, kein Problem für sich. Ihr Überwachungstool muss Ihnen dabei helfen, diese mit anderen Metriken zu korrelieren und diese Wartezeiten zu analysieren, um die tatsächlichen Abfragen zu finden, die von ihnen betroffen sind:
Ein gutes Überwachungstool meldet auch die häufigsten Wartezeiten über einen bestimmten Zeitraum, sodass der DBA Trends oder Ausreißer leicht erkennen kann.
Nehmen wir an, Sie beobachten hohe CXPACKET Wartezeiten. Ist das ein Problem? Diese Art des Wartens tritt immer dann auf, wenn Abfragen auf mehreren Prozessoren parallel ausgeführt werden. Eine häufige Fehldiagnose bei sehr hohen CXPACKET Wartezeiten besteht darin, dass die parallele Arbeitslast das Festplatten-I/O-Subsystem überlastet. Überprüfen Sie jedoch zunächst die von diesen Wartezeiten betroffenen Abfragen. Wenn es sich um ein OLTP-System wie Dynamics 365 BC oder NAV handelt, bei dem Transaktionen kurz und schnell sein sollten, sollten Sie die Abfragen untersuchen, für die parallele Pläne vorliegen, und nach Optimierungsmöglichkeiten suchen. In ähnlicher Weise können übermäßige I/O-Wartezeiten beispielsweise einfach ein Zeichen dafür sein, dass eine große Tabelle wiederholt gescannt wird und dass ein Index die Abfrage unterstützen kann.
Schnelle Fehlerbehebung in Echtzeit
So proaktiv ein DBA sein möchte, um Probleme zu lösen, bevor sie zu echten Problemen werden, spielt das Überwachungstool immer eine wichtige Rolle bei der Lösung von Echtzeit-Leistungsproblemen.
Wenn auf einem wichtigen Business-Server derzeit schwerwiegende Leistungsprobleme auftreten, sollten Sie sehr schnell wissen, welche Verbindungen und Sitzungen betroffen sind und welche Aktivitäten auf dem Server stattfinden. Eine Möglichkeit, wie ein professionelles Überwachungstool wirklich helfen kann, besteht darin, nicht nur übermäßiges „Blockieren“ zu erkennen oder beispielsweise zu melden, dass ein Deadlock aufgetreten ist, sondern innerhalb der Warnung auch eine Liste der aktiven Prozesse und einige einfache Visualisierungen des Blockierens bereitzustellen oder Deadlocking-Kette. Das folgende Bild zeigt eine Blockierungskette:
Das Blockieren in SQL Server ist wie eine Kreuzung im Stau. Die Abfrage im Herzen des Problems wirkt sich auf andere Abfragen aus und lässt sie warten, bis die Problemabfrage ausgeführt oder beendet wurde. Häufige Ursachen sind übermäßige I/O aufgrund von Scans für große Tabellen oder Transaktionen, die nach Fehlern offen bleiben. Um das Problem kurzfristig zu lösen, muss die fehlerhafte Abfrage gefunden und möglicherweise die Verbindung unterbrochen werden. Ein gutes Überwachungstool, wie V8 Search XE identifiziert die Ursache der Blockierung, damit geeignete Maßnahmen ergriffen werden können.
Ein Deadlock ist eine kreisförmige Verriegelungskette, da jede Verarbeitung der Blockierungskette auf einen oder mehrere andere Prozesse in derselben Blockierungskette wartet, sodass keiner abgeschlossen werden kann. Dies ist eine schwerwiegende Fehlerbedingung, die SQL Server durch Beenden und Zurücksetzen eines der Prozesse behebt. Der DBA muss sofort nachforschen, um herauszufinden, was den Deadlock verursacht hat, und Maßnahmen ergreifen, um ein erneutes Auftreten zu verhindern.
Vorher und Nachher: Baselines
Eine weitere wichtige Verwendung der von uns gesammelten Überwachungsdaten ist die Erstellung visueller Basislinien. Dies hilft dem DBA zu verstehen, ob sich die Leistung in bestimmten Zeiträumen vorhersehbar verschlechtert oder ob die aktuelle Leistung des Servers typisch oder ungewöhnlich ist. Sie können auch auf Änderungen achten, wenn die Daten wachsen oder das System mit der Zeit geschäftiger wird.
Wie oft hören wir: „Dynamics NAV war gestern langsam“ oder „Es war schneller, bevor wir das Upgrade veröffentlicht haben“ oder „NAV ist gerade langsam“? Um diese Behauptungen zu validieren und die Ursache herauszufinden, benötigen wir Ressourcenverbrauchsdaten von gestern, um sie mit heute vergleichen zu können.
Vielleicht können Sie jedoch feststellen, dass die CPU-Auslastung dieser Prozessors jetzt höher ist als letzte Woche. Ist das ein beunruhigender Trend? Zur Unterstützung möglicher Optimierungsbemühungen müssen Sie feststellen, ob Sie das sehen, was als normales Verhalten beschrieben werden kann. Oder Sie sehen tatsächlich einen Trend, der zu Druck auf diese Ressource führt. Sofern Sie keine Maßnahmen ergreifen, wie Suche nach Möglichkeiten, die Last in diesen geschäftigen Zeiten besser auf die verfügbaren Prozessoren zu verteilen.
Fazit
SQL Datenbanken sind äußerst komplex, noch bevor Sie versuchen, ihr Verhalten unter Last im Produktionsbetrieb zu verstehen. Sie brauchen dieses Verständnis der Leistung, um vorhersagen zu können, wie Sie mit Expansion oder Skaleneffekt umgehen werden. Sie müssen verhindern, dass Stresssymptome zu Problemen werden, die sich auf den Service auswirken. Sie brauchen die Informationen, die es Ihnen ermöglichen, intelligente Entscheidungen über das Hosting zu treffen. Sie müssen auch verstehen, was in der Dynamics 365 BC/NAV SQL Datenbank passiert ist, als ein zeitweise auftretendes Problem auftrat.
Alle RDBMS verfügen über Diagnosetools. Sie werden jedoch am besten verwendet, nachdem die allgemeine Natur und der Kontext eines Leistungsproblems verstanden wurden. Insbesondere, wenn die Zeit knapp ist und Probleme behoben werden müssen, bevor sich die Benutzer beschweren. Mit zunehmender Arbeitsbelastung des Betriebspersonals lohnt es sich, über ein System zu verfügen, das die Dynamics 365 Business Central / NAV System im Auge behält und Warnungen ausgibt, wenn eine Kombination von Metriken einen beunruhigenden Trend zeigt.
Gerne beantworten wir Ihnen persönlich weitergehende Fragen zu diesem Thema.
Ihr dynamicsproject.com Team
German 
English