Geschwindigkeitsproblem beim Buchung von Belegen über 10.000

Hallo,

könnt Ihr mir einen Tipp zur Geschwindigkeitsoptimierung im CC geben?

Situation:

- Versionen: 6.01 Classic (Client und Objekte), SQL 2008 (3 Server mit 10 operativen Datenbanken, zum Teil kaskadiert)

- Hardware: eigenes Rechenzentrum mit moderner Hardware (nach Vorgabe MS)

- Schlüssel sind weitestgehend optimiert, die Prüfungs- und Buchungsfunktionen sind größtenteils Standard (CJ 10 und 12)

- es wird ohne Steuer und Dimensionen gearbeitet (nicht alle Funktionen sind deaktiviert, Daten sind nicht eingerechnet)

- in größeren Mandanten werden im Durchschnitt täglich 250.000 Abrechnungen verarbeitet (ca. 1,5 h Buchungszeit), in Summe kommen täglich mehrere Millionen Buchungen zusammen

Problem:

- in den Abrechnungsdaten (50 bis 300.000 Datensätze) befinden sich neuerdings Einzelbelege mit bis zu 22.000 Datensätzen – dies führt zum Zusammenbruch der Performanz und einer immensen Vergrößerung des Transaktionsprotokolls

- Beispiel: Abrechnung mit 12.000 Datensätzen (ist im Normalfall in wenigen Minuten erledigt) – aber alle Datensätze gehören zum einem Beleg – nach 2,5 h Stunden wurden die Transaktion vom SQL Server abgebrochen – das Protokoll war mit 500 GB zu groß – bei einer Datenbankgröße von 30 GB

Das Problem ist die Performanz. Im Rahmen der täglichen Verarbeitung der Abrechnungen müssen auch Belege mit bis zu 22.000 Zeilen in einem Zeitfenster von max. 1 - 2 Stunden realisierbar sein.

Hallo,

könnt Ihr mir einen Tipp zur Geschwindigkeitsoptimierung im CC geben?

- in größeren Mandanten werden im Durchschnitt täglich 250.000 Abrechnungen verarbeitet (ca. 1,5 h Buchungszeit), in Summe kommen täglich mehrere Millionen Buchungen zusammen.

Wenn ich das so lese muß ich sagen das nach meiner Erfahrung euer Wert hier schon sehr gut ist!

Problem:
- in den Abrechnungsdaten (50 bis 300.000 Datensätze) befinden sich neuerdings Einzelbelege mit bis zu 22.000 Datensätzen – dies führt zum Zusammenbruch der Performanz und einer immensen Vergrößerung des Transaktionsprotokolls

Ein Einzelbeleg mit 22.000 Zeilen? Was kauft/verkauft/bestellt ihr alles?
Sind das 22.000 unterschiedliche Artikel oder meinst du hier nur die Zeilennummer?

Das Problem ist die Performanz. Im Rahmen der täglichen Verarbeitung der Abrechnungen müssen auch Belege mit bis zu 22.000 Zeilen in einem Zeitfenster von max. 1 - 2 Stunden realisierbar sein.

Man stelle sich nur die ganzen Posten in den Postentabellen vor (falls du hier Rechnungen auf Artikelbasis meinst), die das System erzeugen soll z.B. Artikelposten, Wertposten, Sachposten, MWSt-Posten usw...
Meiner Meinung nach ist das eine Performancegrenze im Navision, wo Ihr nicht mehr merklich viel rausholen werdet.

Andere können mich hier gern eines besseren belehren.

Eventuell solltest Ihr eher euere Belegdaten optimieren und die dort stehenden Datensätze in irgendeiner Form vor oder bei dem Datenimport zusammenfassen (z.B. Sammelartikel).

Vielleicht meldet sich ja noch ein Performanceguru, aber für mich klingt das nach einem großen Overhead in eueren Belegdaten ohne jetzt genauer zu wissen was ihr da eigentlich bucht.

mfg,
winfy

Hallo,

das Problem kommt mir bekannt vor. Es gab zwar nicht ganz soviele Zeilen zum Buchen (ca. 5000) aber nach Update auf NAV2009SP1 CC gabs das Problem das plötzlich diese Buchungen statt Minuten Stunden dauerten. Aufgetreten war es beim Fakturieren von Sammelrechnungen. Ursache hiefür war ein Standardfehler bezüglich der Vorauszahlungen. Da gibts auch ein temporäres Fix von Microsoft wenn man Vorauszahlungen nicht nutzt. Danach war die Dauer wieder normal im Minutenbereich. Betrifft Codeunits 80 und 90.

Code:

Codeunit 80 before:

PROCEDURE TestGetShipmentPPmtAmtToDeduct(SalesHeader : Record "Sales
Header";SalesLine : Record "Sales Line")
  TempSalesLine.SETRANGE("Document Type",SalesHeader."Document Type");
  TempSalesLine.SETRANGE("Document No.",SalesHeader."No.");
  IF NOT TempSalesLine.FIND('+') THEN
    EXIT; 
  TempSalesLine.SETFILTER(Quantity,'>0');
  TempSalesLine.SETFILTER("Qty. to Invoice",'>0');
  TempSalesLine.SETFILTER("Shipment No.",'<>%1','');


Codeunit 80 after:

PROCEDURE TestGetShipmentPPmtAmtToDeduct(SalesHeader : Record "Sales
Header";SalesLine : Record "Sales Line")
  TempSalesLine.SETRANGE("Document Type",SalesHeader."Document Type");
  TempSalesLine.SETRANGE("Document No.",SalesHeader."No.");
  TempSalesLine.SETFILTER(Quantity,'>0');
  TempSalesLine.SETFILTER("Qty. to Invoice",'>0');
  TempSalesLine.SETFILTER("Shipment No.",'<>%1','');
  TempSalesLine.SETFILTER("Prepmt. Line Amount",'<>0'); <- New filter
  IF TempSalesLine.isempty THEN <- moved line
    EXIT; <- moved line

Codeunit 90 before:

PROCEDURE TestGetRcptPPmtAmtToDeduct(PurchHeader : Record "Purchase
Header";PurchLine : Record "Purchase Line")
  TempPurchLine.SETRANGE("Document Type",PurchHeader."Document Type");
  TempPurchLine.SETRANGE("Document No.",PurchHeader."No.");
  IF NOT TempPurchLine.FIND('+') THEN
    EXIT;
  TempPurchLine.SETFILTER(Quantity,'>0');
  TempPurchLine.SETFILTER("Qty. to Invoice",'>0');
  TempPurchLine.SETFILTER("Receipt No.",'<>%1','');

Codeunit 90 after:

PROCEDURE TestGetRcptPPmtAmtToDeduct(PurchHeader : Record "Purchase
Header";PurchLine : Record "Purchase Line")
  TempPurchLine.SETRANGE("Document Type",PurchHeader."Document Type");
  TempPurchLine.SETRANGE("Document No.",PurchHeader."No.");
  TempPurchLine.SETFILTER(Quantity,'>0');
  TempPurchLine.SETFILTER("Qty. to Invoice",'>0');
  TempPurchLine.SETFILTER("Receipt No.",'<>%1','');
  TempPurchLine.SETFILTER("Prepmt. Line Amount",'<>0'); <- New filter
  IF TempPurchLine.ISEMPTY THEN <- moved line
    EXIT; <- moved line



Hallo Holger,

hast Du zufällig den KB Artikel dazu?

Hallo,

das Problem kommt mir bekannt vor. Es gab zwar nicht ganz soviele Zeilen zum Buchen (ca. 5000) aber nach Update auf NAV2009SP1 CC gabs das Problem das plötzlich diese Buchungen statt Minuten Stunden dauerten.

Hallo Holger auch 5.000 Zeilen pro Einzelbeleg? Kommt das bei den Kunden häufiger vor? Für mich klingt das irgendwie atypisch.

mfg,
winfy

Hallo Holger,

hast Du zufällig den KB Artikel dazu?

Hallo,
leider finde ich nicht den entsprechendne KB mehr dazu. Werde nochmal suchen.

Hallo Holger auch 5.000 Zeilen pro Einzelbeleg? Kommt das bei den Kunden häufiger vor? Für mich klingt das irgendwie atypisch.
mfg,
winfy

Hallo,

Ja, ca. 5000 Zeilen pro Sammelrechnung. Mag atypisch sein, kommt aber in manchen Branchen durchaus vor. Würde allerdings nicht sagen das dies bei vielen Kunden so ist. Dort wo es aber vorkommt ist es dann schon häufig. 22000 sind aber schon sehr viel. Problem hier ist das solche Fälle scheinbar von Microsoft selbst so gut wie nie ausgetestet werden, weswegen dann solche Bugs erst beim Kunden irgendwann aufschlagen.


Gruß

Ich meine mich an den korrigierten Code zu erinnern. Der sieht ansich gut aus und wäre auch mein Tipp gewesen. Bitte in einer Testdatenbank prüfen, sollte passen.

In den Buchungsroutinen wird auch viel mit den Temp-RecordVariablen gearbeitet. Und ab gewissen Anzahl der Datensätze in solchen Tabellen wird das ganze irgendwann ziemlich langsam, da der Speicher voll läuft. Das könnte ja auch die Ursache für die langen Buchungszeiten bei solchen Unmengen von Belegzeilen sein. Vielleicht, bringt es was den DBMS Cache zu erhöhen bzw. überhaupt verschiedene Einstellungen in Richtung DBMS Cache / Commit Cache auszuprobieren.
Apropos Unmengen: wenn täglich mehrere Millionen Buchungen erfolgen und damit mindestens genau so viele Posten in den Posten-Tabellen erzeugt werden, dann ist bei euch in der absehbaren Zeit in den Posten-Tabellen die Integer-Höchstgrenze erreicht, oder? Oder habt überall auch Integer durch BigInteger ersetzt?

Ab bestimmten Datengrößen/-mengen empfiehlt sich SQLPerform zu kontaktieren. Die sind auf solche Szenarien spezialisiert. U.a. mit hoch SQL optimierten Buchungsroutinen.

Ab bestimmten Datengrößen/-mengen empfiehlt sich SQLPerform zu kontaktieren. Die sind auf solche Szenarien spezialisiert. U.a. mit hoch SQL optimierten Buchungsroutinen.

Ist SQL-Perform die Firma von Jörg Stryk, wenn ich fragen darf? Denn bisher habe ich diesen Namen noch nicht gelesen...

Ist SQL-Perform die Firma von Jörg Stryk, wenn ich fragen darf? Denn bisher habe ich diesen Namen noch nicht gelesen...

Den Link um einen Firmenkontakt mit Jörg Stryk aufzunehmen findest du in seinem profil:
memberlist.php?mode=viewprofile&u=693

Jörg ist selbständig. SQLPerform ist eine Dienstleister-Firma.