Performance Report 112

Hallo,

ich schaue mir gerade Report 112 und frage mich gerade wo es da evtl. Optimierungspotential gibt. (Der Report läuft in einem System was nun gerade 16 Monate online ist für den aktuellen Monat 10-15 Minuten.)

Neben den Calcfields bei den Kunden (Bei den Schlüsseln sind die MaintainSIFT-Haken gesetzt) werden ja nur noch Value Entries über die Cost Calulation Management Codeunit abgegriffen.

Hier sieht es wie folgt aus:

Code:

CalcCustAdjmtCostLCY(VAR Customer : Record Customer) : Decimal
WITH ValueEntry DO BEGIN
  SETCURRENTKEY("Source Type","Source No.");
  SETRANGE("Source Type","Source Type"::Customer);
  SETRANGE("Source No.",Customer."No.");
  SETFILTER("Posting Date",Customer.GETFILTER("Date Filter"));
  SETFILTER("Global Dimension 1 Code",Customer.GETFILTER("Global Dimension 1 Filter"));
  SETFILTER("Global Dimension 2 Code",Customer.GETFILTER("Global Dimension 2 Filter"));
  SETRANGE(Adjustment,TRUE);

  CALCSUMS("Cost Amount (Actual)");
  EXIT("Cost Amount (Actual)");
END;


Nun sieht das SetCurrentKey recht dürftig aus für die Anzahl der Filter.
Ich habe mir die Keys auf der Value Entry mal angeschaut und irgendwie sind die einzigen Keys mit einem Teil der Filter Felder folgende:

Code:

1. Source Type,Source No.,Item No.,Posting Date,Entry Type,Adjustment;   Discount Amount,Cost Amount (Non-Invtbl.),Cost Amount (Actual),Cost Amount (Expected),Sales Amount (Actual),Sales Amount (Expected),Invoiced Quantity
2. Source Type,Source No.,Global Dimension 1 Code,Global Dimension 2 Code,Item No.,Posting Date,Entry Type,Adjustment;    Discount Amount,Cost Amount (Non-Invtbl.),Cost Amount (Actual),Cost Amount (Expected),Sales Amount (Actual),Sales Amount (Expected),Invoiced Quantity


Der zweite Schlüssel sieht für mich besser aus, aber ist nicht Enabled (Objekt ist W1 Standard ohne Anpassungen).

Hat sich jemand mit dem Report und der Performance mal auseinandergesetzt oder kann einen Tipp geben?

SQL oder Native?

bei ersterem ist es evtl. sinnvoll, den SETCURRENTKEY ganz weg zu lassen, bzw. den Schlüssel nicht pflegen zu lassen, damit der SQL-Server sich den besten Schlüssel selbst sucht.

Gruß, Fiddi

SQL oder Native?

bei ersterem ist es evtl. sinnvoll, den SETCURRENTKEY ganz weg zu lassen, bzw. den Schlüssel nicht pflegen zu lassen, damit der SQL-Server sich den besten Schlüssel selbst sucht.

Gruß, Fiddi

Es ist SQL

Aber würde das die Performance nicht reduzieren, wenn er den SIFTIndex erst erneuern muss bevor er ihn nutzen kann?
Da im C/AL ein CALCFIELD gemacht wird, muss ja vom SQL Server eh ein Schlüssel genommen der auch in einer entsprechende Indexed View hat?

Also wenn der Schlüssel mit SIFTs belegt ist, dann macht der gepflegte Schlüssel schon Sinn.

Der SQL- Server überlegt sich das in der Regel selbst ob und welchen Schlüssel er benutzt. Wenn du mal auf dem SQL-Server schaust, welchen Querry- Plan er benutzt, dann kannst du sehen ob er den Schlüssel benutzt, oder ob er die Tabelle sequenziell abarbeitet.

Gruß, Fiddi

Ich habs mir mal angeschaut und leider komme ich da nicht so wirklich weiter.
Insgesamt geht er pro Kunde einmal auf die Det. Cust. Ledger Entries, die Cust. Ledger Entries und Value Entries.
Bei fünfstelligen Kundenzahlen dauert das scheinbar ein wenig.
Der SQL Server-Cluster ist auch nicht wirklich ausgelastet mit 128GB RAM, 32 Kernen und einer NAV-Datenbankgröße von 3 GB (in Worten: drei).
Habe auch nochmal manuell die Statistiken der Indexed Views aktualisiert. Da scheint es nun einen Geschwindigkeitsvorteil von ca. 20% zu geben, aber bei 15 Minuten Laufzeit ist das immer noch nicht so viel.