Größenzuwachs der Datenbank bei Versionswechsel

Hallo,
wir wollen demnächst von NAV 2009 SP1 (classic Client) auf NAV 2013R2 wechseln.
Unsere aktuelle Datenbank hat eine Größe von 3.7 GB, traut sich einer abzuschätzen wie groß dieselbe Datenbank unter NAV 2013 R2 sein wird? Da sind doch sicher Tabellen dazugekommen.
Die aktuelle Datenbank läuft unter MS SQL 2005, wir ziehen um auf MS SQL 2012.

Danke für Eure Abschätzversuche und Erklärungen.

Gruß aus dem sonnigen Schwarzwald

5.5 GB, ganz grob geschätzt, wegen Unicode-Update.

Hallo zusammen,
ok, bei diesem Ausgangsvolumen ist das ja Hardware-technisch noch lösbar. Was kann man aber tun, wenn die Ausgangs-DB schon 600 GB groß ist?
Wir haben auch eine annähernde Verdoppelung feststellen müssen.

Kann man die DB irgendwie schrumpfen?

Hallo,

Was kann man aber tun, wenn die Ausgangs-DB schon 600 GB groß ist?

Das kommt darauf an.

Sollte die Größe durch Dimensionen (posten) verursacht worden sein, könnte es sein, dass die Datenbank sogar kleiner wird.

Auf alle Fälle muss man zunächst klären, wo die Platzfresser herkommen (Blobs?).

Gruß, Fiddi

Ja, das ist wohl der Ansatz, die alte DB zunächst zu bereinigen. Danke vielmals

600GB is schon ein Brocken - aber Speicherplatz ist heute nicht mehr ganz so teuer :)
mehr würde mich dann eher die Dauer des Upgrades interessieren!

mehr würde mich dann eher die Dauer des Upgrades interessieren!

Wenn wirklich die Dimensionen die Platzfresser sind sind, dürfte alleine deren Konvertierung auf das neue Verfahren schon Tage dauern, in denen hoffentlich nicht der Strom ausfällt, weil es dafür im Gegensatz zum Rest des Upgradeprozesses keine Transaktionssicherheit gibt, da das Skript aus Performancegründen direkt auf dem Server läuft.

Wenn wirklich die Dimensionen die Platzfresser sind sind, dürfte alleine deren Konvertierung auf das neue Verfahren schon Tage dauern

Wenn man den Standard Upgrade benutzt sicherlich

weil es dafür im Gegensatz zum Rest des Upgradeprozesses keine Transaktionssicherheit gibt, da das Skript aus Performancegründen direkt auf dem Server läuft

Warum sollte es da keine Transaktionssicherheit geben. Es werden genauso SQL- Befehle ausgeführt, wie der NAV- Client sie ausführt. Auch die laufen in einer Transaktion ab. Allerdings bekommt der Servicetier nicht von den geänderten Daten mit, und das kann schon zu einem Problem werden.

Gruß, Fiddi

Warum sollte es da keine Transaktionssicherheit geben. Es werden genauso SQL- Befehle ausgeführt, wie der NAV- Client sie ausführt.

Als Carsten Scholling das Skript bei der MsDynamics-Konferenz vorgestellt hat, kam gleich die Warnung: Don't do this at home. Es gibt für diese Phase keine Transaktionssicherheit. Da der normale Weg über C/AL viel zu lange dauern würde, wurde der Vorgang auf den Server ausgelagert.

IMG_4726.JPG

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Danke für die Info.

Hallo Kai,

Es gibt für diese Phase keine Transaktionssicherheit

Carsten hat damit wahrscheinlich gemeint, das die SQL-Kommandos und der C/AL- Code in getrennten Transaktionen ablaufen. D.h. geht was schief, wird die Aktion nicht komplett zurückgefahren, sondern nur gerade laufende Teil (SQL-Kommando bzw. C/AL- Code)

Auf dem SQL- Server läuft kein SQL-Befehl ohne Transaktion ab, egal von wo und wem abgesetzt. Ob der Ablauf korrekt durchläuft, bzw. bei einem Fehler komplett zurückgefahren werden kann, hängt davon ab, wann man ein COMMIT gemacht hat.

Gruß, Fiddi

Korrekt. In Transaktionen läuft das schon ab, aber unabhängig von Dynamics NAV. Ich bin nicht sicher, ob dort ein Wiederanlauf nach Rollback möglich ist.

So hatte ich das damals auch verstanden. Jedes System für sich ist natürlich schon transaktionssicher, aber die Kombination nicht, und damit ist der Gesamtupgradeprozess potenziell gefährdet.
Wer damit nicht leben kann, kann die Umsetzung auf das neue Dimensionenmodell ja komplett in C/AL umsetzen, falls die Zeit dafür reicht.

Man könnte den Upgradeprozess aber auch so gestalten, das man Die SQL-Kommandos in den normalen Ablauf der einzelnen Upgradefunktionen einbindet (nach jeder Funktion COMMIT) und so strukturiert, dass die SQL-Transaktion und die NAV- Transaktionen synchron laufen, dann ist das kein so großes Problem mehr.
Wenn man dann noch die Dimensionen analysiert und ein paar Annahmen macht, kann man ein Update von nach 20 Stunden abgebrochen schon auf 4 Stunden für das komplette Upgrade von 2009 auf 2013 bringen.

Gruß, Fiddi

Hier ist ein anderes Beispiel wie man die Upgradedauer durch Einsatz von SQL-Skripts um 78 Stunden verkürzen kann:
http://vjeko.com/blog/how-i-reduced-data-upgrade-time-by-78-hours