[Gelöst] - [CC] unterschiedliche Buchung von Buchblattzeilen

Hallo,
wir haben zur Zeit in einer Datenbank ein interessantes Phänomen:
In einem Fibu-Buchblatt stehen ca 50.000 Zeilen für die Verbuchung bereit. Bisher lief diese Verbuchung immer in ca. 10 Minuten ab.
Beim letzten Mal lief die Verbuchung allerdings ca. 2 Std.
Nach einigen Analysen in der Datenbank habe ich dann eine 1:1 - Kopie der Datenbank (SQL bak-Sicherung) erstellt und auf dem gleichen Server und den gleichen Laufwerken wieder in eine neue Datenbank eingelesen.
Interessanterweise läuft hier die Verbuchung wieder wie gewohnt schnell.
Dabei hat sich eigentlich nichts geändert: Gleiche Datenbank, gleicher Server, gleiche Laufwerke, gleicher User....
Auch ein manuelles Aktualisieren der Statistiken sowie Neuerstellung der Indizes hat nichts gebracht.
Lt. Client Monitor entsteht der hohe Zeitbedarf in der Tabelle Gen. Journal Line; dort werden einige Prüfungen der ganzen Zeilen vorgenommen.

Da mir momentan eine Idee fehlt, woher dieses Phänomen kommt, bin ich für jede Anregung und Vermutung dankbar.
Ach ja: NAV 2009 SP1, Classic Client, SQL Server 2008 Standard

Danke!
Henning

Zuletzt geändert von Ronin666 am 28. Oktober 2012 22:59, insgesamt 1-mal geändert.

Macht ihr automatische Updates der Analyse-Ansichten?
Das kann Buchungen verlangsamen.

Nein, die Analyseansichten werden nicht mit Buchungen aktualisiert.

Könnte es mit dem Transaction-Log zusammenhängen? Ist das vielleicht voll?

VG Mike

Leider auch nein.
Die kopierte DB liegt ja auf den gleichen Laufwerken. Und im Log der Produktiv-Datenbank sind noch 80 von 100 GB frei. Zudem sind auf dem Laufwerk auch noch mal 100 GB frei, so dass sie sich bei Bdarf auch noch vergrößern kann...

Hatte sich die Org.-DB während des Buchens grad automagisch vergrößert? Waren grad andere Prozesse am Werk, die die Fesplatten ausgebremst haben?

Nein, leider auch nicht. Die langsame Verbuchung in der Prod-Datenbank ist auch reproduzierbar. Es lag also nicht an anderen Prozessen, die zu dem Zeitpunkt liefen, sondern ist mehr ein dauerhaftes Problem...

Nein, leider auch nicht. Die langsame Verbuchung in der Prod-Datenbank ist auch reproduzierbar. Es lag also nicht an anderen Prozessen, die zu dem Zeitpunkt liefen, sondern ist mehr ein dauerhaftes Problem...

Lass doch mal den Profiler mitlaufen, während die Buchung läuft.

Hallo,

erst einmal sorry für die späte Antwort. Die Woche war dicht :)

An den Profiler habe ich auch schon gedacht und ihn mitlaufen lassen. Die Ergebnisse habe ich jetzt mal beigefügt.
Im ersten Screenshot sieht man die Abfrage aus der produktiven, langsamen Datenbank.
C/AL - seitig handelt es sich um eine isempty - Abfrage auf die Gen. Journal Lines.
An den Spalten "Duration" und "Reads" (rot umrandet) erkennt man die hohen Kosten dieser Abfrage.

ProdDB.jpg

Der zweite Screenshot stammt von der Test-Datenbank. Diese ist aus einer bak-Sicherung der produktiven Datenbank entstanden.
Sie liegt auf dem gleichen Server und den gleichen Platten. Weder NAV - Objekte noch Daten wurden verändert.
Und dennoch ist diese DB deutlich schneller (wieder zu sehen an den Spalten "Duration" und "Reads").

PerfTest_DB.jpg

Eine Anmerkung noch, die ich aber noch nicht vollends durchgeprüft habe: Wenn man die Abfragen direkt im SSMS auf die Datenbanken loslässt, sind beide schnell und gleichschnell (Client - Problem?!)

Irgendwelche Ideen? Ich danke euch für alle Tipps im Voraus!

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Während der Buchungen: wie viele user sind da denn in der Datenbank und 'arbeiten' in der Buchblattzeile. Also buchen Einkauf/Verkauf/Fibu? Und welche Mengen?

Ich hatte auch schon das Problem, dass 30 Benutzer beim registrieren des WA sich gegenseitig ausbremsen. Das isempty auf die -wimre- whse activity line lief auf das timeout der DB.

Hallo,

wie sieht denn der Abfrageplan für die Screenshot-SQL Query aus?

Die hohe Anzahl von Reads in der Live-DB deuten eigentlich auf nicht aktuelle Statistiken für diese Tabelle hin.

gruß

Also das unterschiedliche Verhalten liegt vermutlich am "Procedure Cache" / "Parameter Sniffing" des SQL Servers ... aber die Details dazu sind nicht relevant. Im einen Fall kann der SQL Server mit einem geeigneten Index arbeiten, im anderen Fall nicht.

Mögliche Lösungs-Optionen:
- RECOMPILE HInt auf "Gen. Journal Line" setzen
- Oder Traceflag 4136 setzen (wenn entsprechende Build Nummern verwendet werden)
- Oder einen Optimierten Index für die Abfrage im SQL Server bauen (oder als "Key" in NAV):

Code:

CREATE INDEX ssi01_20121026 ON [dbo].[...$Gen_ Journal Line]
("Document No_", "Journal Template Name", "Journal Batch Name", "Document Type", "Account Type", "Account No_" )


Ich würde erst den Index im SQL Serevr bauen, und wenn der wirklich hilft, dann durch einen NAV "Key" ersetzen ...

Hey Jörg,

wie kann denn die Test-DB einen geeigneten Index haben und die "Ursprungs"-DB nicht?


gruß

Der Index ist in beiden DB vorhanden - nur der SQL Server entscheidet über die Verwendung offenbar anders (Procedure Caching & Parameter Sniffing).
Das bedeutet i.d.R. das der vorhandene Index zwar "OK" ist, aber nicht optimal. Ein voll-optimierter Index sollte dann immer greiffen ...

Man kann ja im Profiler die "Execution Plan XML" anzeigen lassen, dann würde man den Unterschied erkennen.

Also einmal als Index-Seek, während der weniger gute als Index-Scan aufgeführt wird?

Also einmal als Index-Seek, während der weniger gute als Index-Scan aufgeführt wird?

Das lässt sich so nicht sagen ... Am im Prinzip geht das schon in die Richtung ... Ich gehe davon aus, dass der SQL Server 2 unterschiedliche Indexe verwendet ...

Nabend zusammen,

Problem gelöst: Jörg hatte mit seinem Tipp recht: Nachdem ich mir den QEP angesehen hatte, konnte ich feststellen, dass der verwendete Index in der Produktiv - Datenbank offenbar nicht wirklich geeignet war.
Meine erste Maßnahme war, den Proc-Cache zu löschen, was auch schon den gewünschten Erfolg gebracht hat.
Ich werde das jetzt erst einmal beobachten, ob das Problem wieder auftritt.
Grundsätzlich erschließt es sich mir durchaus, dass in der Tabelle Gen. Journal Lines diese Probleme auftreten können:
Hier liegt ja keine "normale" Tabelle vor, die im Laufe der Zeit anwächst, wie die sonstigen üblichen Bewegungstabellen. Ebenso hat man wenig gleichbleibende Strukturen in der Tabelle, da diese gefüllt, durch Buchung gelöscht, gefüllt, wieder durch Buchung gelöscht etc wird.
Auch die Erstellung von sinnvollen Statistiken stelle ich mir problematisch vor, was aber wohl selten ein Problem ist, da die Anzahl der Datensätze in der Tabelle meistens eher gering ist.
Und genau da (in der Anzahl) kann ich mir auch das Problem mit den Indizes vorstellen: Wenn der ursprüngliche QEP erstellt worden ist, als eine normale Fibu-Buchung gebucht wurde, bildet sich das System daraus seinen QEP mit den geringsten Kosten. Nun hatte ich aber ein Buchblatt mit 50.000 Zeilen. Hier kann die optimale Verarbeitung natürlich schon ganz anders aussehen (Während der Verbuchung wird für jede Zeile geprüft, ob es im Buchblatt nochmal die gleiche (Belegart und Nr.) gibt.) Aber der SQL - Server hat wohl auf den QEP im Proc-Cache zurückgegriffen...
... wenn meine Vermutung/Theorie falsch ist, möge man mich korrigieren.

Lange Rede, kurzer Sinn: Vielen Dank für alle Tipps und die Mithilfe (vor allem an Jörg für den entscheidenden Hinweis).

Henning

Freut mich wenn's geklappt hat. Ja, solche Probleme sind leider typisch - der SQL Server trifft Entscheidungen die eban auch "Tabellen-Inhalts"-bezogen sind, plus "Parameter Sniffing" und Plan Caching etc. ...

Wenn ein DBCC FREEPROCCACHE das Problem beseitigen konnten, dann sine ddie Chance hoch, das ein RECOMPILE Hint in NAV (oder global Traceflag 4136) helfen kann; dann wird das QEP-Caching etwas "charmanter" gestaltet, und es kommt seltener zu solchen Problemen.

Bei Tabellen, die hohen Änderungsraten unterzogen sind, könnte auch ein häufigeres Statistik Update hilfreich sein; das könnte z.B. durch ...

Auto Update Stats = TRUE
UND
Auto Update Stats Async = TRUE
(regelmäßige Updates OHNE die Schreibzugriffe zu verlangsamen)

... geschehen.