[gelöst] Upgrade einer sehr großen DB

[christiand]

Griezi!

Wir dürfen demnächst einen Kunden von FIN 2.5 auf 2009 R2 Upgraden, was mir dabei Sorgen macht ist die Datenbankgröße von ca. 60 GB . Ich befürchte fast dass hier die beiden Upgradetoolkits mehrere Tage laufen... Wie würdet Ihr hier vorgehen? Sollte man hier vorab viel Zeit drauf verwenden durch "Posten zusammenfassen" etc. die Datenbank zu verkleinern oder würdet Ihr das Upgrade mit einer Datenbank in dieser Größe durchführen? Ich wäre euch für eine Einschätzug sehr dankbar!

Viele Grüße

Christian

Zuletzt geändert von christiand am 19. Januar 2012 17:37, insgesamt 1-mal geändert.

Hallo,

Aus eigener leidvoller Erfahrung und auf Empfehlung vom MS würde ich darauf verzichten, Artikelposten zu übernehmen

Gruß, Fiddi

*heul* warum muss es immer so kompliziert sein...
bei dem Kunden handelt es sich um einen Lebensmittelgroßhandel, der wird natürlich gerne auf historische Daten verzichten

Der Report zur Artikelpostenkomprimierung wurde in Version 5 entfernt, nicht ohne Grund, weil das gerade bei Upgrades immer wieder Probleme machte. Die anderen Posten kann man schon komprimieren, wenn die keiner mehr detailliert braucht, vorher aber als Sicherung ablegen.
Wenn die 2.5 die Lagerbewertung von Impuls einsetzt (erkennbar an iLW in der Versionsliste) auf jeden Fall neu aufsetzen.

Wenn die 2.5 die Lagerbewertung von Impuls einsetzt (erkennbar an iLW in der Versionsliste) auf jeden Fall neu aufsetzen.

Hallo Kowa, das ist nicht nur bei der Impuls- Lagerregulierung so .

Gruß, Fiddi

Mit "Neu aufsetzen" meint ihr, ohne Upgradetoolkit Stammdaten übernehmen, Lagerbestände und Offene Posten neu einbuchen usw. ?

Mit "Neu aufsetzen" meint ihr, ohne Upgradetoolkit Stammdaten übernehmen, Lagerbestände und Offene Posten neu einbuchen usw. ?

Nicht unbedingt:

Aber Artikelposten löschen, und mit aktuellem Bestand neu einbuchen macht schon Sinn. Das spart dir außerdem den größten Teil der Update Laufzeit.

Die Alternative wäre sämtliche Artikelpostenausgleiche aufheben und neu ausgleichen, bzw. die Einstandsbeträge der Abgänge neu ermitteln, und damit die Wertposten aktualisieren. Das würde aber den Lagerwert auch in den Vorjahren massiv verändern. Je nach Ablauf kann das aber sehr aufwändig werden, wenn mit Logistik, Artikelverfolgung, Direktlieferung,... gearbeitet wurde. Da du allerdings vom Lebensmittelgroßhandel sprichst, wirst du das aber wohl wegen der Anforderungen in dem Breich durchführen müssen.
Das Problem ist die Berechnung des Lagerwerts in NAV. Der wird nämlich aus der "Summe aller Zugänge" - "Summe aller Abgänge"/Lagerbestand berechnet. Das kann aber zu Problemen führen, wenn der Einstandsbetrag eines Abgangs nicht exakt dem Lagerwert des ausgleichenden Zugangs entspricht.
Häufig merkt man das daran, das die Lagerwerte bei Artikeln mit abnehmenden Bestand immer höhere Lagerwerte entstehen, oder bei Bestand 0 ein Lagerwert vorhanden ist (immer bezogen auf einen Lagerort)

Gruß, Fiddi

Hi Fiddi!

das hört sich interessant an. Ich muss hier noch einmal recherchieren, doch ich glaube sogar dass es garnicht so schlimm wäre wenn man die Artikel neu zum EK-Preis neuester Einbuchen würde und dann eben danach bewertet würde, da sich die meisten Artikel in der Regel aufgrund der MHD's eh nicht all zu lange im Lager befinden, und somit der Einstandspreis meist sehr nahe am EK-Preis neuester liegt. Wir sprechen hier von 14839046 Artikelposten. 14 Milionen Datensätze in einer Tabelle machen das System in gewissen Bereichen langsam träge, und ich wäre sher froh, wenn wir diesen Ballast auf der Strecke lassen könnten. Da müsste man dann Artikelposten, Wertposten und Artikelausgleichsposten löschen oder? Bzw. würden wir die Posten erst exportieren um später die Bestände neu einbuchen zu können und dann bereits im Alstsystem löschen, dass sie garnicht durch das Upgradetoolkit verarbeitet werden.

Denk dran, das der Lebensmittelhandel evtl. Dokumentationspflichten hat, lange Abrechnungszeiträume, Artikelnachverfolgbarkeit,.... Evtl. wäre es besser, die Altdaten in separaten Tabellen unter zu bringen, damit man später noch darauf zugreifen kann.

Gruß, Fiddi

Wenn die 2.5 die Lagerbewertung von Impuls einsetzt (erkennbar an iLW in der Versionsliste) auf jeden Fall neu aufsetzen.

Hallo Kowa, das ist nicht nur bei der Impuls- Lagerregulierung so .

Die Warnung von MS bezieht sich auf das Addon Advanced Distribution. Systeme die mit Bewertungsmethode "Durchschnitt" arbeiten sind von ähnlichen Problemen betroffen. Die US-Version vom Upgrade Toolkit hatte dafür extra eine Korrekturroutine. Ein einfaches FIFO Sytem mit einem Lagerort, das bislang sauber lief und reguliert wurde, kann man prinzipiell schon upgraden. Bei 14 Mio. Posten würde ich aber so oder so davon abraten.

What's Navision Advanced Distribution

Falls saubere Komplettinventuren und nicht nur Stichproben gemacht wurden, kann man auch eine 2 Jahre alte Inventur als Ausgangsbasis nehmen und ab da die Bewegungen über Buchblätter nachbuchen. Dann hat man zumindest die wichtigsten Daten vom Vorjahr und Vorvorjahr. Das reicht ja häufig schon.

*heul* warum muss es immer so kompliziert sein...
bei dem Kunden handelt es sich um einen Lebensmittelgroßhandel, der wird natürlich gerne auf historische Daten verzichten

Wieso verzichten? SInd doch weiter in der alten Datenbank vorhanden die Daten . Brauch man nur ein schönes BI-Tool wo man da die notwendigen Daten wieder zusammenführt. Oder wenn sie im SQL-Server liegt dann diese alten Artikelposten zum Lesen wieder in die neue Datenbank reinholen.

Denk dran, das der Lebensmittelhandel evtl. Dokumentationspflichten hat, lange Abrechnungszeiträume, Artikelnachverfolgbarkeit,.... Evtl. wäre es besser, die Altdaten in separaten Tabellen unter zu bringen, damit man später noch darauf zugreifen kann.

Gruß, Fiddi

Ja, aber wenn man die Datenbank vor Update schön sich irgendwo wegsichert und als Archivsystem erhält sollte das ja wohl den Dokumentationpflichten und Nachverfolgbarkeit genüge tuen, oder?

Ja, aber wenn man die Datenbank vor Update schön sich irgendwo wegsichert und als Archivsystem erhält sollte das ja wohl den Dokumentationpflichten und Nachverfolgbarkeit genüge tuen, oder?

Aber nicht unbedingt, wenn du die Daten für irgendwelche übergreifende Auswertungen benötigst, oder du die Daten irgendwo hin melden musst

Gruß, Fiddi

Klar würden wir nicht gleich im einzigen Echtsystem ohne Netz und doppelten Boden "löschend" um uns schlagen Das Altsystem würde für eine gewisse Übergangszeit unverändert zur Verfügung bleiben. Aber ich denke, das wäre eine gute Zwischenlösung. Übernahme mit Upgradetoolkit, allerdings ohne Artikelposten. Diese Idee werde ich jetzt vorerst verfolgen. Danke euch für eure Anregungen. Falls es Probleme geben sollte, lass ich euch davon wissen.

Viele Grüße

Christian

Hallo Christian,
auch falls keine Probleme auftreten, würde mich die Laufzeit für das Upgrade interessieren.

Viele Grüße, gutes Gelingen und im Voraus schon mal danke für die Rückmeldung.
Jörg

Hi Jörg,

Was genau intreressiert dich dann? Die Durchlaufzeit des UpgradeToolkits oder die gesamte Projektlaufzeit?

Viele Grüße

Christian

Hallo Christian,

mich interessieren zunächst mal die Laufzeiten der Upgradetools - also das was in die Tabelle "time log" (aus dem Upgradetool) steht.
Es ist gut möglich, dass wir demnächst vor der selben Anforderung stehen - dann weiß ich schon mal ganz grob, wie lange die Datenmigration dauert.

Jörg

Kleiner Tipp zur Laufzeitoptimierung:
Bei allen Steps alle Schlüssel deaktivieren, die man nicht unbedingt benötigt (geht auch per Programm über die Tabelle Key), das bringt Stunden. Erst zum Schluss wieder einen Objektstand mit aktivierten Schlüsseln einspielen.

Gruß, Fiddi