Langsamer Zugriff - trotz gleicher SQL-DB

Hallo,

ich habe zwei unabhängig von einander - auf NAV 2013 Rollup 16 - konvertierte Datenbanken, die beide fast den gleichen Datenstand haben und auch auf dem gleichen Server und der gleichen Serverinstanz laufen (SQL Server 2012) - auch die Einstellungen in der NAV-Administrationsumgebung sind identisch (natürlich abgesehen von den Port-Nummern).

Bei beiden Datenbanken habe ich nun eine Codeunit mit einer einfachen Repeat-Schleife auf beispielsweise die Tabelle ITEM geschrieben, die einfach nur einen Feldwert ändert + anschließende Modify-Anweisung.

Nun habe ich folgendes Phänomen:
Die Ausführung in der einen Datenbank dauert 20-mal länger als in der anderen DB.
Wenn ich - ohne Modify - einfach nur lesend die Tabelle durchgehe, ist das Zeitverhalten jedoch ähnlich.

Da beide Datenbanken in der völlig gleichen physischen Umgebung laufen, kann es eigentlich nicht an Hardware, Arbeitsspeicher oder ähnlichem liegen.
Da die Lesezugriffe identisch sind - spricht doch eigentlich auch nichts für Indexprobleme. Und auch ein Vergleich der Tabellengrößen über den NAV-Entwicklungsumgebung (unter >Datenbank >Informationen >Tabellen) zeigt mir nichts auffälliges.

Hat irgend jemand eine Idee, woran das liegen könnte?

Gruß
Ralf

Hat die eine SQL-Datenbank in Tabelle Item vielleicht weniger Indizes, bzw. wurde die Indexstatistik (nennt man das so?) noch nicht aufgebaut?

Danke für den Tipp - Natalie - aber Nein - an den Indexes der Tabelle ITEM liegt es nicht.

Aber ich habe festgestellt, das die Änderungsprotokollierung das ganze so enorm ausbremst.
In NAV 4.0 habe ich In der Tabelle Item lediglich 3 Felder unter "Beobachten" gestellt und dort wird die Verarbeitungszeit auch kaum oder so gar nicht beeinflusst.
Nach der Konvertierung auf NAV 2013 dauert der gleich Job (Codeunit) 20-mal länger.

Ich meine ich hätte schon irgendwo gelesen, das in NAV 2013 - im Gegensatz zu NAV 4.0 - auch Änderungen per Code protokolliert werden.
Aber die "beobachteten Felder" werden im Code gar nicht angesprochen - sondern ganz andere Felder der Tabelle. Ist das beabsichtigt?
Oder wie könnte man das ausschalten bzw. positiv beeinflussen ohne gleich die ganze Änderungsprotokollierung deaktivieren zu müssen.

Hat jemand ein Idee?

Gruß
Ralf

Ich meine ich hätte schon irgendwo gelesen, das in NAV 2013 - im Gegensatz zu NAV 4.0 - auch Änderungen per Code protokolliert werden.

Sogar ab 2009 R2, siehe hier: viewtopic.php?p=71823#p71823.

Wenn du möchtest, dass nach wie vor das Änderungsprotokoll nur bei händischen Datenänderungen greift, stelle in Codeunit 1 die Funktionen OnGlobal... wieder her (siehe hier) und verschiebe den Änderungsprotokoll-Aufruf in die OnGlobal-Trigger.

Hallo,

da gibt es viele Möglichkeiten, warum das eine funktioniert, und das andere nicht.

Der SQL- Server pflegt gewöhnlich selbst zu entscheiden in welcher Form er auf die Tabellen zugreift.
Sind die Schlüssel zu sehr fragmentiert?
Sind die SQL- Statistiken gepflegt?
Ist die Datenbankdatei fragmentiert?
ist die Datenbankdatei fast voll und wird laufend in kleinen Schritten vergrößert?

Und, und,....
EDIT:
Desweiteren kann auch ungeschickte Programmierung für die mangelnde Performance verantwortlich sein. Programme die mit der CRONUS vernünftig laufen, haben mit größeren Datenvolumina u.U. große Probleme weil z.B.:

• Flowfields auf Flowfields verwendet werden.
• Schlüssel (für den SQL- Server) ungeschickt gewählt wurden.
• Filter ungeschickt gewählt wurden. (Bestes Beispiel aus dem Standard: die Funktion CalcOverDueBalance aus der Debitorentabelle. Hier wird der fällige Saldo ermittelt. Bis CU?? wurde das über alle Debitorenposten gemacht. Dann hat man eine Query erfunden, und filtert diese sinnigerweise auf den Status Offen=Ja. Den Unterschied merkt jeder, der in einer größeren NAV 2013-DB die Debitorenübersicht öffnet. Dabei ist nicht die Query der Performancebringer, sondern das Filtern auf Offen=ja. Kann man auch ausprobieren, indem man den alten Code lässt und nur den Filter auf Open=True hinzufügt).

In NAV 2013 kommt noch hinzu , das alle Felder einer Page immer geladen werden, auch wenn sie ausgeblendet sind. Um den Übeltäter zu finden kann man nur Flowfield für Flowfield aus der Artikelübersicht entfernen, und schauen wann es besser wird. Das so ermittelte Feld muss man sich dann genauer anschauen, warum der Zugriff langsam sein könnte.
Zu guter letzt gab es auch technische Probleme in NAV2013, die zu Performance- Problemen geführt haben, und mit einem technischen Update verbessert wurden.

Gruß, Fiddi

Ich werde Natalie's Vorschlag aufgreifen, so dass nur manuelle Änderungen protokolliert werden.
Mal schauen, ob die CU dann wieder so schnell wie gewohnt durchläuft, wenn das umgesetzt ist.

Gruß
Ralf