[Gelöst] SIFT-Table neu aufbauen ?
23. Oktober 2007 11:51
Ich habe ein sehr merkwürdiges Problem.
Das Feld "Inventory" der Tabelle Item zeigt uns bei ca. 15 von 30.000 Artikeln einen falschen Bestand an.
Dabei ergibt die Aufsummierung der zugehörigen Artikelposten - bei diesen 15 Artikeln - immer einen Null-Bestand. Im Flowfield "Inventory" wird jedoch immer ein Minus-Bestand angezeigt.
Es ist definitiv kein Filter oder Flowfilter gesetzt.
Mit einer kleinen Codeunit habe ich alle Flowfield-Wert mal mit den aufsummierten Artikelposten verglichen und komme zum selben Ergebnis.
Diese 15 Artikel stimmen nicht - sonst sind alle Bestände in Ordnung.
Daraufhin habe ich eine Datensicherung erstellt und diese anschließend auf einem Test-System widerhergestellt. Siehe da - hier waren die Flowfield-Werte wieder in Ordnung.
Interessanterweise ist bei einigen der Artikel bereits seit Monaten keine Buchung mehr vorgenommen wurden und in einer der letzten Datensicherungen war trotzdem noch alles OK. Der Fehler scheint also auch nicht unmittelbar durch Buchungen begründet zu sein ?!.
Mein Verdacht ist nun, das in einer SIFT-Tabelle (SQL-Server) bei diesen Artikeln ein falscher Wert mitgeführt wird und dieser erst mit der Widerherstellung eine Datensicherung bereinigt wird, da diese Tabellen dann wohl neu aufgebaut werden ?!
Könnte mein Verdacht begründet sein?
Kennt jemand ein solches Problem?
Und gibt es da irgendeine Möglichkeit, die SIFT-Tabellen im Produktivsystem neu aufbauen zu lassen?
Schonmal danke für Eure Hilfe.
Gruß
Ralf Müller
Das Feld "Inventory" der Tabelle Item zeigt uns bei ca. 15 von 30.000 Artikeln einen falschen Bestand an.
Dabei ergibt die Aufsummierung der zugehörigen Artikelposten - bei diesen 15 Artikeln - immer einen Null-Bestand. Im Flowfield "Inventory" wird jedoch immer ein Minus-Bestand angezeigt.
Es ist definitiv kein Filter oder Flowfilter gesetzt.
Mit einer kleinen Codeunit habe ich alle Flowfield-Wert mal mit den aufsummierten Artikelposten verglichen und komme zum selben Ergebnis.
Diese 15 Artikel stimmen nicht - sonst sind alle Bestände in Ordnung.
Daraufhin habe ich eine Datensicherung erstellt und diese anschließend auf einem Test-System widerhergestellt. Siehe da - hier waren die Flowfield-Werte wieder in Ordnung.
Interessanterweise ist bei einigen der Artikel bereits seit Monaten keine Buchung mehr vorgenommen wurden und in einer der letzten Datensicherungen war trotzdem noch alles OK. Der Fehler scheint also auch nicht unmittelbar durch Buchungen begründet zu sein ?!.
Mein Verdacht ist nun, das in einer SIFT-Tabelle (SQL-Server) bei diesen Artikeln ein falscher Wert mitgeführt wird und dieser erst mit der Widerherstellung eine Datensicherung bereinigt wird, da diese Tabellen dann wohl neu aufgebaut werden ?!
Könnte mein Verdacht begründet sein?
Kennt jemand ein solches Problem?
Und gibt es da irgendeine Möglichkeit, die SIFT-Tabellen im Produktivsystem neu aufbauen zu lassen?
Schonmal danke für Eure Hilfe.
Gruß
Ralf Müller
Zuletzt geändert von neckit am 24. Oktober 2007 09:04, insgesamt 1-mal geändert.
23. Oktober 2007 14:56
Der Verdacht ist nicht nur begründet, sondern als Faktum bestätigt.
In NAV 4.00 ist ein Bug in den sog. "SIFT Triggern" (SQL Server seitig). Damit werden SIFT Datensätze falsch angelegt, nachdem man die SIFT Tabellen bereinigt hat (via "Table Optimizer" oder "Stored Procedures").
Der Bug ist erst mit 4.00 SP3 HF7 behoben (Build 25307). Allerdings wird hier eine neues Loch aufgerissen: IndexHinting ist nun "out-of-the-box" aktiviert und sollte unbedingt abgeschaltet werden:
Fur 5.00 gibt's noch keinen Fix; hier sollte man auf SIFT Wartung vorerst verzichten.
Um bestehende Inkonsistenzen zu bereinigen muss kein Backup/Restore erfolgen; es genügt, wenn man so vorgeht:
1) Backup FOB der betroffenen Tabelle (z.B. T32 Item Ledger Entry)
2) Im Object Designer alle SIFT Indexe der Tabelle deaktivieren (MaintainSIFTIndex = FALSE)
Beim Speichern werden alle SIFT Tabellen gelöscht.
3) Objekt aus 1) wieder importieren. Dabei werden die SIFT Tabellen neu aufgebaut.
In NAV 4.00 ist ein Bug in den sog. "SIFT Triggern" (SQL Server seitig). Damit werden SIFT Datensätze falsch angelegt, nachdem man die SIFT Tabellen bereinigt hat (via "Table Optimizer" oder "Stored Procedures").
Der Bug ist erst mit 4.00 SP3 HF7 behoben (Build 25307). Allerdings wird hier eine neues Loch aufgerissen: IndexHinting ist nun "out-of-the-box" aktiviert und sollte unbedingt abgeschaltet werden:
- Code:
use [NavisionDB] -- DB Namen hier ändern
go
create table [$ndo$dbconfig] (config varchar(1024))
grant select on [$ndo$dbconfig] to [public]
go
insert into [$ndo$dbconfig] values ('IndexHint=No')
Fur 5.00 gibt's noch keinen Fix; hier sollte man auf SIFT Wartung vorerst verzichten.
Um bestehende Inkonsistenzen zu bereinigen muss kein Backup/Restore erfolgen; es genügt, wenn man so vorgeht:
1) Backup FOB der betroffenen Tabelle (z.B. T32 Item Ledger Entry)
2) Im Object Designer alle SIFT Indexe der Tabelle deaktivieren (MaintainSIFTIndex = FALSE)
Beim Speichern werden alle SIFT Tabellen gelöscht.
3) Objekt aus 1) wieder importieren. Dabei werden die SIFT Tabellen neu aufgebaut.
23. Oktober 2007 15:50
Stryk - Du bist mein H-E-L-D 
Darf ich noch drei Fragen hinterher schieben
1. Könntest Du mir folgenden Korrekurablauf noch mal bestätigen?
> Hotfix einspielen (lasse ich vorsichtshalber über meinen MSP machen)
> IndexHinting ausschalten
> FOB der betroffenen Tabellen - wie oben beschrieben - aus- und wieder einlesen
2. Da ich weder die Tabellen optimiert, noch ein entsprechendes Stored Procedure ausgeführt habe, bin ich bezüglich der Ursache etwas verunsichert.
Allerdings habe ich vor kurzem einige Tabellen über die Datenbankinformationen geprüft (sinnvollerweise nicht optimiert). Kann es auch damit zusammen hängen oder gibt es noch andere denkbare Ursachen?
3. Unsicher bin ich mir auch noch über die evtl. betroffenen SIFT-Tabellen.
Gibt es noch eine Möglichkeit, vorsichtshalber alle SIFT-Tabellen in einem Rutsch neu aufbauen zu lassen, ohne den "Trick" mit den FOB-Dateien?
Gruß
Ralf Müller
Darf ich noch drei Fragen hinterher schieben
1. Könntest Du mir folgenden Korrekurablauf noch mal bestätigen?
> Hotfix einspielen (lasse ich vorsichtshalber über meinen MSP machen)
> IndexHinting ausschalten
> FOB der betroffenen Tabellen - wie oben beschrieben - aus- und wieder einlesen
2. Da ich weder die Tabellen optimiert, noch ein entsprechendes Stored Procedure ausgeführt habe, bin ich bezüglich der Ursache etwas verunsichert.
Allerdings habe ich vor kurzem einige Tabellen über die Datenbankinformationen geprüft (sinnvollerweise nicht optimiert). Kann es auch damit zusammen hängen oder gibt es noch andere denkbare Ursachen?
3. Unsicher bin ich mir auch noch über die evtl. betroffenen SIFT-Tabellen.
Gibt es noch eine Möglichkeit, vorsichtshalber alle SIFT-Tabellen in einem Rutsch neu aufbauen zu lassen, ohne den "Trick" mit den FOB-Dateien?
Gruß
Ralf Müller
23. Oktober 2007 16:32
neckit hat geschrieben:Gibt es noch eine Möglichkeit, vorsichtshalber alle SIFT-Tabellen in einem Rutsch neu aufbauen zu lassen, ohne den "Trick" mit den FOB-Dateien?
Den hast du ja bereits angewendet.
Datensicherung erstellen, mandant umbenennen (sicherheitshalber) und dann datensicherung wieder einlesen, dadurch werden alle Indizes und Sifts neu erstellt. Wenn alles glatt gegangen ist, kannst du den umbenannten Mandanten löschen
24. Oktober 2007 06:38
neckit hat geschrieben:1. Könntest Du mir folgenden Korrekurablauf noch mal bestätigen?
> Hotfix einspielen (lasse ich vorsichtshalber über meinen MSP machen)
> IndexHinting ausschalten
> FOB der betroffenen Tabellen - wie oben beschrieben - aus- und wieder einlesen
Hmmm .. ich würde dann eher so vorgehen:
1) Backup FOB
2) Abschalten SIFT (Löschen der Tabellen)
3) Hotfixes einspielen (alle bis Build 25307!). Dabei werden die bestehenden SIFT Trigger umgeschrieben und die SIFT Tabellen neu aufgebaut.
4) Index Hinting abschalten
5) FOB aus 1) importieren, damit werden die vormals fehlerhaften SIFT Tabellen mittels dem neuen Trigger Code neu aufgebaut.
Aber: eigentlich sollten im Rahmen der "Konvertierung" (Punkt 3) = Umschreiben SIFT Trigger) alle SIFT Tabellen neu & korrekt aufgebaut werden! D.h. die Punkte 1) und 5) sind wahrscheinlich gar nicht notwendig! Sollte aber mal getestet werden ...
neckit hat geschrieben:2. Da ich weder die Tabellen optimiert, noch ein entsprechendes Stored Procedure ausgeführt habe, bin ich bezüglich der Ursache etwas verunsichert.
Allerdings habe ich vor kurzem einige Tabellen über die Datenbankinformationen geprüft (sinnvollerweise nicht optimiert). Kann es auch damit zusammen hängen oder gibt es noch andere denkbare Ursachen?
Nun, NAV 4.00 hatte bis SP2 grundsätzlich Probleme mit dem SIFT Handling; im wesentlichen aufgrund von Benutzerrechten NAV vs. SQL Server ... welche Version habt ihr im Einsatz?
neckit hat geschrieben:3. Unsicher bin ich mir auch noch über die evtl. betroffenen SIFT-Tabellen.
Gibt es noch eine Möglichkeit, vorsichtshalber alle SIFT-Tabellen in einem Rutsch neu aufbauen zu lassen, ohne den "Trick" mit den FOB-Dateien?
Wie Michael schon gesagt hat.
Ist aber u.U. nicht notwendig (siehe oben).
1. November 2007 03:51
Noch ein kleiner Nachtrag meinerseits.
Ich weiss nicht ob unsere MSP was falsch gemacht hat. Aber nach dem "Reparieren" mussten wir alle Anwender in der SQL-Datenbank (mit Ausnahme des Anwenders, unter dem die Korrektur erfolgte) im SQL-Server - Löschen und neu anlegen.
Die Anwender kriegten die Fehlermeldung, das keine Berechtigung für die Tabelle "Artikelposten" existiert und bei dem Versuch der Synchronisation kam die Fehlermeldung, das der Anwender auf dem SQL-Server gar nicht existiert.
Nach Neuanlage der Anwender, waren aber alle Flowfields wieder in Ordnung.
Gruß
Ralf
Ich weiss nicht ob unsere MSP was falsch gemacht hat. Aber nach dem "Reparieren" mussten wir alle Anwender in der SQL-Datenbank (mit Ausnahme des Anwenders, unter dem die Korrektur erfolgte) im SQL-Server - Löschen und neu anlegen.
Die Anwender kriegten die Fehlermeldung, das keine Berechtigung für die Tabelle "Artikelposten" existiert und bei dem Versuch der Synchronisation kam die Fehlermeldung, das der Anwender auf dem SQL-Server gar nicht existiert.
Nach Neuanlage der Anwender, waren aber alle Flowfields wieder in Ordnung.
Gruß
Ralf
20. November 2007 18:28
stryk, folgende Aussage habe ich bei Microsoft gefunden:
Update 6 has introduced index hinting (enabled by default). Usual procedure when deploying this update is to disable index hinting and then enable it for tables/queries that benefit from this.
Ist das so korrekt? Nur um es zusammen zu fassen...
Update 6 has introduced index hinting (enabled by default). Usual procedure when deploying this update is to disable index hinting and then enable it for tables/queries that benefit from this.
Ist das so korrekt? Nur um es zusammen zu fassen...