Sperren auf der Tabelle Reservierungsposten

Hallo,
wir haben bei uns ein erhöhtes Sperrverhalten auf der Tabelle 337 Reservation Entry. Dieses resultiert wohl daraus, dass wir sehr viel chargenverfolgte Artikel führen und dadurch die Module Einkauf, Verkauf und Logistik diese Tabelle sehr stark frequentieren.

Welche Möglichkeiten gibt es die Sperren zu minimieren? HAt Jemand da schon Erfahrungen sammeln können?
Oder gibt es schon einen Eintrag, den ich nicht gesehen habe? Dann, sorry!

Danke!

Hallo Hendrik,

mit deinen Angaben kann man nur sehr generelle Antworten geben:
- Verringerung der Sperrdauer durch Optimierung auf SQL/Datenbank Seite
- Buchungen sammeln und als Batch außerhalb der Geschäftszeiten starten

In Nav 5.0 SP1 hat MS die SQL Indexe von der Reservation Entry entfernt, weil das Sortieren zu langsam war (Order by).
Kannst mal nach A222 im Changelog von NAV 5.0 suchen.

Vielleicht kommst Du den Problemen so auf die Schliche: http://dynamicsuser.net/blogs/stryk/archive/tags/Locking/default.aspx

Aber leider ist T337 schon immer ein Sorgenkind, das ganze "Reservation Management" ist eigentlich #@§%&!

Hallo Kollegen,

ja die Tabelle 337 - wer "liebt" sie nicht.

Hier noch ein Feature, dass zurzeit bei einem meiner Kunden wieder verstärkt auffällt: in einer neuen Auftragszeile wird das Warenausgangsdatum in die "Zukunft" gesetzt - und eine "echte" Reservierung auf einen vorhandenen Bestand gesetzt (= auch ein Eintrag in der T337). Läuft heute der Bestellvorschlag, löscht das System diese Reservierung "raus".

WIr haben zwar gelernt, dass offenbar der Planungs- / Bestellvorschlagslauf die Eigenart hat, Reservierungsposten offenbar zu löschen und wieder neu aufzubauen, dass er aber wieder mal vorhandene "echte" Reservierungen aber gleich komplett rausschmeisst, erfahren wir immer wieder. In diesem Fall half und hilft nur eine Anpassung.

Des Weiteren ist mir in der Vergangenheit mehrmals das Thema "halbe" Reservierungsposten aufgefallen - kommt zum Teil vor, wenn Anwender mit der Umlagerung arbeiten (Umlagerungsauftrag inkl. Warenaus- und Wareneingang) in Kombination mit Chargen oder Seriennr.
Es kam vor, dass z.B. die Artikelverfolgung - nachdem der "Warenausgang" gebucht wurde - für den Wareneingang auf einmal nicht mehr vorhanden ist. Grund: der Reservierungsposten fehlt.

Oder bei Lieferscheinstornos... auch da kam es zu fehlenden bzw. fehlerhaften Res.-Posten (sind ja immer "Zwillinge" - aber bei vielen fehlte dann der andere Part).

Beliebte Fehlermeldungen: "Die Reservierungsposten Lfd. Nr. xx existiert nicht (oder existiert bereits)", "Positiv muss "JA" bei Reservierungposten lfd. Nr. xxx sein" usw.

In vielen Fällen hilft nur das Löschen der "kaputten" Res.-Posten und Programmierungen durch Entwickler.

Diese Tabelle wird uns noch lange beschäftigen....
Viele Grüße
Sonja

Vielleicht kommst Du den Problemen so auf die Schliche: http://dynamicsuser.net/blogs/stryk/archive/tags/Locking/default.aspx

Aber leider ist T337 schon immer ein Sorgenkind, das ganze "Reservation Management" ist eigentlich #@§%&!

Hallo Jörg,

Gilt das Block Detection Script auch noch für NAV 2009R2?

Die Scripte & Co. sind unabhängig von der NAV Version und laufen auf SQL 2005, SQL 2008, SQL 2008 R2 und SQL 2012. Im empfehle stets die aktuellesten Scripts aus den "jüngsten" Artikeln zu verwenden (das wäre im MOment der von den Tech Days 2012).

Hallo,
wir haben die Locks analysiert. Zu ca. 70% ist ein FINDLAST (zur Ermittling der neue Entry No.) der Verursacher der Sperre.

Hat Jemad schonaml darüber nach gedacht, den Primärschlüssel (Gruppiert) zu verändern?

Viele Grüße
Henrik

Hat Jemad schonaml darüber nach gedacht, den Primärschlüssel (Gruppiert) zu verändern?

Ja ... Microsoft In NAV 2013 ist der PK nur noch "Entry No." (ohne "Positive") und wird per AutoIncrement gezogen ...
Das hilft uns aber in vorherigen NAV Versionen nix - ein PK Änderung würde ich mich so nicht trauen ...

Ja ... Microsoft In NAV 2013 ist der PK nur noch "Entry No." (ohne "Positive") und wird per AutoIncrement gezogen ...

Also in meiner NAV 2013 DE Demodatenbank nicht ... Alles beim Alten.

Hab' gerade mal nachgesehen (ich hatte das bisher nur aus einem MS Vortrag in Erinnerung) ...

Also der PK ist tatsächlich noch "Entry No.", "Positive" ... aber "Entry No." ist auf AutoIncrement gesetzt! (zumindest in meiner "Beta Refresh" Version, was neueres hab ich noch nicht)

D.h. technisch gesehen wird die Eindeutigkeit nur über "Entry No." gewährleistet, man hat aber offenbar das "Positive" aus Legacy Gründen noch beibehalten ...
Hmm ... vielleicht doch eine Chance, das in älteren Versionen nachzubauen?!

Hallo Herr Stryk,

Die Idee mit dem Downgrade ist schon charmant in Bezug aufs Sperrverhalten..
Aber.. Kann NAV2009R2 die SQL Statement umsetzten?
Der Planungslauf erstellt ja die Bedarfsverursacherpaare => Identity insert?

Könnte man auf jeden Fall mal ausprobieren....

Aber darüber nachzudenken bringt mich auch auf die Frage : "Wer hat eigentlich gesagt, dass Reservierungsposten in der Lfd. Nr. Integer sein sollen?"

Unser aktuelle "Lfd. Nr." ist mal wieder 1.505.392.736, da denke ich schon über BigInteger nach
Bei gleichbleibendem Wachstum rechne ich damit, dass wir nächstes Jahr zum 2. Mal die 2,147,483,647 erreichen

lg,

Chris

Hallo Herr Stryk,

Ne, ne, ne ... hier im Forum wird nich' "ge-Sie-tst'

Aber.. Kann NAV2009R2 die SQL Statement umsetzten?
Der Planungslauf erstellt ja die Bedarfsverursacherpaare => Identity insert?

Prinzipiell kann NAV das schon, die Applikation muss nur dahingehend programmiert sein ... und das ist wohl die Schwierigkeit dabei ...

Unser aktuelle "Lfd. Nr." ist mal wieder 1.505.392.736, da denke ich schon über BigInteger nach
Bei gleichbleibendem Wachstum rechne ich damit, dass wir nächstes Jahr zum 2. Mal die 2,147,483,647 erreichen

Auweia

Jo,

wir haben es getan!

Wir haben die Reservierungsposten und die Action Message Entries auf Autoincrement umgestellt.
Das Ergebins sieht bisher sehr gut aus.

Die Sperren habe sich insgesamt reduziert, allerdings auch ein bißchen auf die Artikelposten und die Lagerplatzposten verschoben.

Es hat sich somit auf jeden Fall gelohnt.

lg,

Christoph

Das hört sich ja super an! Wäre toll, wenn Du hier auch posten könntest, welche Code-Stellen ihr anpassen musstet und welche Hürden zu meistern waren.
Ich bin sicher, dass auch viele andere das Problem haben und gerne an eurer Lösung teilhaben möchten!

Wenn ich jetzt noch alles wüsste........

Die wichtigste Voraussetung war einfach unser Developer Toolkit.
Die Stellen rausgesucht, wo das Feld Lfd. Nr. genutzt wird und schon kanns losgehen....

Im wesendlichen (und hier erhebe ich keinen Anspruch auf Vollständigkeit)
Type No. Name
Table 337 Reservation Entry
Table 5773 Registered Whse. Activity Line
Table 6550 Whse. Item Tracking Line
Table 99000849 Action Message Entry
Table 99000853 Inventory Profile
Codeunit 5431 Calc. Item Plan - Plan Wksh.
Codeunit 6500 Item Tracking Management
Codeunit 6502 Late Binding Management
Codeunit 99000830 Create Reserv. Entry
Codeunit 99000831 Reservation Engine Mgt.
Codeunit 99000845 Reservation Management
Codeunit 99000854 Inventory Profile Offsetting

Ich habe nicht alle Ändeurngen aus NAV2013 übernommen,
Die Codeunit vom Aufbau zumeist an der NAV2009 Struktur

Dazu kamen noch einige unserer eigenen Codeunits, die ich hier mal außen vor lasse.
Nachdem alle Objekte verglichen und gemerged waren,
kam die lange Testphase.

Produktionsplanung, Logistik, Rechungsschreibung, Reklamationen, etc.
Das wichtige an der Stelle für uns war, da wir ja noch den CC einsetzen, dass unsere Benutzer die passenden SQL-Rechte bekommen mussten.
Sonst gab es die Meldung Sie haben keine Brechtigung Set Identity_insert ... zu nutzen.

Im Vergleich mal ein bischen Statistik: Sperren / KW
08.04.2013 921
15.04.2013 579
22.04.2013 323
29.04.2013 574
06.05.2013 446
13.05.2013 523
20.05.2013 342

LG,

Christoph

Danke für die Info! Ist gut zu wissen, dass es grunsätzlich möglich ist, aber schon einiges an Anpassungen erfordert!

Das wichtige an der Stelle für uns war, da wir ja noch den CC einsetzen, dass unsere Benutzer die passenden SQL-Rechte bekommen mussten.

Ich fürchte, Du bist hier auf einen "klassischen" Fehler gestossen:

AutoInceremet Felder müssen nach dem INIT (bzw. vor dem INSERT) stets manuell auf 0 gesetzt werden! Also z.B.

Code:

ResEntry.INIT;
ResEntry."Entry No." := 0;
...
ResEntry.INSERT;

Sonst versucht NAV das IDENTITY_INSERT Verhalten zur Laufzeit zu ändern - und das dürfen nur db_owner.
Die Lösung dieses Problems darf auf keinen Fall db_owner Rechte (oder gar höher) sein - das bedeutet ein enormes Sicherheitsrisiko!!!

Wie gesagt, die Lösung ist das manuelle setzen des AI Feldes auf 0

Rechte auf der DB dürfen nur von der NAV-Applikation verwaltet werden. Zusätzliche Rechte auf SQL-Ebene stellen ein ernstes, potentiell geschäftsgefährdendes Problem dar.

Sonst versucht NAV das IDENTITY_INSERT Verhalten zur Laufzeit zu ändern - und das dürfen nur db_owner.
Die Lösung dieses Problems darf auf keinen Fall db_owner Rechte (oder gar höher) sein - das bedeutet ein enormes Sicherheitsrisiko!!!

Wie gesagt, die Lösung ist das manuelle setzen des AI Feldes auf 0

Das Dumme ist nur, wenn an mit dem Planungslauf arbeitet und dann Bedarfsverursacherposten erstellt werden.
Hier muss man LEIDER eine definierte Lfd. Nr. eintragen

Gruß,

Christoph

Hmmm ... das ist schade ...

Da kann man nur hoffen, dass die User das nicht "spitz" kriegen ... die könnten sich z.B. via Excel an den SQL Server hängen uns unter Umgehung aller NAV Sicherheit alles in der DB tun, was sie möchten ...

Das Dumme ist nur, wenn an mit dem Planungslauf arbeitet und dann Bedarfsverursacherposten erstellt werden.
Hier muss man LEIDER eine definierte Lfd. Nr. eintragen

Kannst du hier etwas genauer werden?

Wie ich durch Recherche rausgekriegt habe, muss er nicht mehr db_owner sein,
sondern muss zumindest das ALTER Table Recht haben. (ab SQL 2008 R2)

Was ist also besser? Pest (db_owner) oder Cholera (ALTER TABLE)?

Naja im allgemeinen Cholera, da er ja nur eine Tabelle so im Zugriff hat

@McClane:

Wir setzen in unserem Haus die Produktionsplanung ein.
D.h., es werden die Bedarfe(Aufträge , Produktionsverbräuche, etc.) gegen die VerfügbarenMengen (Bestellungen, Artikelposten, etc) verrechnet.
In diesem Zyklus werden Reservierungsposten vom Typ Bedarfsaverursacher gebildet, die die gleiche Lfd.Nr. haben und sich im Kennzeichen Positiv unterscheiden (Primäschlüssel ist ja Lfd. Nr, Positiv)

Würden nur einzelne (neue) Posten gebildet, würde das Lfd. NR := 0 ohne weitere Erweiterung der SQL Rechte funktionieren.

Da aber beide Posten die gleiche Lfd. Nr. haben, wird vor dem Insert des 2. Postens ein "SET Indenty_insert" aufgerufen.

Gruß,

Christoph

OK, wenn ein ALTER TABLE Recht reicht, dann würde ich nur das explizit für die betroffenen Tabelle vergeben!
Ist auf jeden fall besser als uneingeschränkter Zugriff auf die gesamte DB!