Hallo!
In einer Reihe von Beiträgen möchten wir unsere Erfahrungen bei der Entwicklung und dem Betrieb von Systemen der MS Dynamics AX-Familie (ehemals Axapta) teilen.
Über uns
Wir sind eine relativ junge Einzelhandelskette von Lebensmittel-Supermärkten "Da!" Zum Zeitpunkt dieses Schreibens haben wir etwas mehr als 100 Geschäfte. Die Hauptprozesse der operativen Aktivitäten des Unternehmens werden in einem Bündel von MS Dynamics Axe 2012 + MS Dynamics 365 FO-Systemen automatisiert. Die Systeme arbeiten rund um die Uhr. Im Durchschnitt durchlaufen pro Tag etwa eine Million Belegzeilen und etwa 70.000 Montageauftragslinien das System.
Planen Sie Anleitungen
Leistungsoptimierung Axapts können auf verschiedene Arten durchgeführt werden. Der effizienteste Weg ist natürlich die Optimierung des Anwendungsquellcodes. Es gibt jedoch Situationen, in denen dies problematisch ist. Anschließend können Sie das von MS SQL Server DBMS bereitgestellte Tool verwenden. Es heißt - Plan Guide. Erschien in der Version von SQL Server 2005. Nach unseren Ansichten in der Axapters-Community (insbesondere wenn das Unternehmen keinen professionellen DBA hat) ist er jedoch nicht immer bekannt und wird nicht verwendet. Obwohl in einigen Fällen seine Verwendung sehr effektiv sein kann.
Wozu?
Hier sind die Hauptgründe, warum Sie sich für dieses Tool
interessieren sollten: 1. Inkonsistente Daten in Abfrageparametern. Das Stichprobenergebnis (Anzahl der Datensätze) für dasselbe Stichprobenkriterium (Feldsatz) unterscheidet sich in Abhängigkeit von den Werten der Variablen in den Stichprobenkriterien. Oder auf einfachere Weise, wenn dieselbe Abfrage nach unterschiedlichen Eingabeparametern zu einer radikal unterschiedlichen Anzahl von Datensätzen führt (manchmal einer, manchmal zehntausend). Dies ist auf das sogenannte "Sniffing" von Anforderungsparametern zurückzuführen. Wenn ein Abfrageplan einmal unter der Abfragemaske erstellt und dann aus dem Cache entnommen wird. Die Werte dieser Parameter werden nicht berücksichtigt.
Dies ist häufig bei Abfragen der Fall, die InventSum- und InventDim-Tabellen betreffen. Zum Beispiel, wenn in der Analytik die Partei für einige Nomenklatura nur eine Partei hat, und für andere - mehrere Tausend. Die erste Anforderung an die Datenbank kann für einen Artikel erfolgen, für den die Stapelabrechnung deaktiviert ist. Das Optimierungsprogramm erstellt einen Abfrageplan dafür. Und legen Sie es in den Cache. Die nächste Anforderung an die Datenbank kann für einen Artikel ausgeführt werden, für den die Stapelabrechnung aktiviert ist. Und geben Sie mehrere tausend Datensätze in der Auswahl für InventSum und InventDim aus. Und für ein solches Beispiel ist der Plan aus dem Cache nicht optimal.
Eine Möglichkeit, dieses Problem zu lösen, besteht darin, den forceLiterals-Hinweis im Anforderungshauptteil zu verwenden. Dies signalisiert der SQL-Engine, jedes Mal einen neuen Abfrageplan zu generieren. Dies führt jedoch zu einer zusätzlichen spürbaren Belastung der CPU. Und mit den gleichen verbleibenden Anforderungen ist die Verwendung von InventDim keine akzeptable Option. Nun, Sie müssen verstehen, dass das SQL Server-Optimierungsprogramm nicht perfekt ist und manchmal sogar mit vollständigen Statistiken seltsame Pläne generiert.
In diesem Fall hilft Ihnen der Planleitfaden, mit dessen Hilfe Sie einen Abfrageplan auswählen können, der eine akzeptable Ausführungsgeschwindigkeit für alle Abfrageeingabeparameter bietet. Fügen Sie diesen Plan mithilfe des Planleitfadens der Abfragemaske hinzu.
2. Der Optimierer wählt einen Index aus, der zu langen Sperren führt. Mithilfe des Planleitfadens können Sie die Verwendung eines bestimmten Index „festnageln“, wodurch die Stichprobe eingegrenzt und die Anzahl der Sperren verringert wird.
3. Die Quelle (Stelle im Code) der Problemabfrage kann nicht schnell identifiziert werden, und das Problem eines Leistungsabfalls der Datenbank muss umgehend behoben werden.
4. Der Anwendungsquellcode kann aus irgendeinem Grund nicht geändert werden (Partnerlösung, Anforderungen vom Kernel usw.). Dies gilt insbesondere für D365, das das Überlagern verhindert.
Wie?
Ich werde eine Schritt-für-Schritt-Anleitung zum Erstellen eines Plan-Leitfadens nicht im Detail beschreiben. Auf der Website des Anbieters finden Sie eine gute Beschreibung (wir interessieren uns für die Art des Plans - SQL). Das Netzwerk verfügt über eine Vielzahl von Tutorials.
Es ist jedoch wichtig zu wissen, dass es ein anderes SQL Server-Tool gibt, das Ihnen bei der Erstellung eines neuen Planungshandbuchs sehr hilfreich ist. Es wird als Query Store bezeichnet. Erschien im Jahr 2016. Eine ausführliche Beschreibung hier .
Die Hauptidee des Tools besteht darin, dass zusätzlich zum aktuellen Abfrageplan im Cache der gesamte Verlauf der Pläne gespeichert wird, die der Optimierer in einem bestimmten Zeitraum erstellt hat. Wenn Sie wissen, dass die problematische Funktionalität zuvor "normal" funktioniert hat. Nicht langsamer. Sie müssen nur den gewünschten Plan im Repository finden und darauf basierend einen Planleitfaden erstellen. Aufgrund der Besonderheiten von Axapta ist es leider nicht möglich, einen Planleitfaden mit einem einzigen "Force Plan" -Button zu erstellen. Sie müssen den Abfrageplan aus dem Repository kopieren und den Planleitfaden manuell erstellen. Dies vereinfacht die Aufgabe jedoch erheblich.
Es sollte auch berücksichtigt werden, dass die Verwendung des Abfragespeichers einen geringen Overhead für die Rechenressourcen des verwendeten DBMS-Servers verursacht. In unserer Praxis sind sie jedoch unbedeutend, und dies kann vernachlässigt werden.
Beispiele von
Hier sind einige Plan Guide-Beispiele aus unserer realen Kampfbasis. Bitte beachten Sie, dass dies nur Beispiele sind, die für unsere spezifischen Geschäftsprozesse relevant sind. Sie sind möglicherweise nicht anwendbar oder schädlich für Ihre Installation.
1. InventSum
Dieser Planleitfaden löst das Problem suboptimaler Pläne bei Abfragen von Elementen mit einer kleinen Anzahl von Datensätzen in der InventDim-Tabelle. Mit diesem Handbuch können Sie immer den Plan verwenden, der für die Stichprobe mit einer großen Anzahl von InventDim-SKU-Kombinationen optimal ist. Abfragen für Elemente mit niedriger SKU-Anzahl sind etwas langsamer. Dies ist jedoch kein hoher Preis für eine stabile und vorhersehbare Geschwindigkeit für eine beliebige Kombination von Eingabeparametern.
Diese Abfragen werden hauptsächlich von der InventSum :: findSum () -Methode generiert. Und je nach Gruppierung können sich die Abfragemuster geringfügig unterscheiden. In Wirklichkeit haben wir also einen ähnlicheren Plan-Leitfaden, der für verschiedene Varianten von Gruppierungen angepasst ist.
2. InventSumDelta Mit
diesem Planhandbuch können Sie einen optimalen Abfrageplan für die InventSumDelta-Tabelle erstellen und unnötige Sperren für diese Tabelle vermeiden. Die Spezifität dieser Tabelle ist so, dass keine Daten darin gespeichert werden. Sie werden aber sehr intensiv hinzugefügt / entfernt. Es ist im Wesentlichen eine Semaphorentabelle. In dieser Hinsicht können für diese Tabelle keine normalen Statistiken erfasst werden. Daher hat der Optimierer manchmal suboptimale Pläne generiert, die zum Blockieren führten.
Ein bisschen offtopic - auch für diese Tabelle müssen Sie die Seitensperren für Indizes deaktivieren. Da die Auswahl aus dieser Tabelle immer durch eine eindeutige ID erfolgt, ist das Eskalieren von Sperren auf Seitenebene hier bedeutungslos und sogar schädlich.
Schlussfolgerungen
Aber im allgemeinen Fall möchte ich Sie noch einmal darauf aufmerksam machen, dass Sie dieses Tool nicht missbrauchen sollten. Wenn der Code optimal geschrieben ist, werden die Statistiken regelmäßig aktualisiert, die Indizes sind nicht sehr fragmentiert - der Optimierer wählt in den meisten Fällen den richtigen Plan selbst aus. Wenn der Planleitfaden jedoch konfiguriert ist, können die Eingabekriterien der Anforderung so herausfallen, dass der Planleitfaden nur Schaden anrichtet.