[gelöst] Migrationstool für native Datenbank extrem langsam
7. Mai 2007 15:31
Hallo,
Nav 4.0 SP3 mit 100 GB Datenbank
Die CU 104015 "Field Check" läuft jetzt seit Samstag Mittag,
und läuft und läuft...
Je länger die CU läuft ums langsamer wird es.
Gibt es einen Trick diese CU zu beschleunigen?
Oder etwas anderes?
Gruß
Jörg
Nav 4.0 SP3 mit 100 GB Datenbank
Die CU 104015 "Field Check" läuft jetzt seit Samstag Mittag,
und läuft und läuft...
Je länger die CU läuft ums langsamer wird es.
Gibt es einen Trick diese CU zu beschleunigen?
Oder etwas anderes?
Gruß
Jörg
Zuletzt geändert von JoergK am 9. Mai 2007 09:58, insgesamt 1-mal geändert.
7. Mai 2007 21:22
Bei den Angaben ist es etwas schwer etwas genaues zu sagen. Die angegebene CU konnte ich im UpgTk nicht finden. Kannst du ggf. etwas genauer werden? NAV 2.60 ist leider auch nicht gerade mein Steckenpferd, will sagen 0 Plan :)
Field Check hört sich nicht wirklich nach Schreibvorgängen an. Aber allgemein solltest du dir die Codeunit (und auch alle anderen) mal genauer ansehen. Durch temp. ausschalten unbenutzter Keys konnten wir einen Migrationsschritt (3.70 -> 4.03) von 3 Tagen auf knappe 6 Stunden reduzieren. Sowas sollte bei euch auch möglich sein.
Es kommt natürlich immer auf die Umgebung im allgemeinen an.
Field Check hört sich nicht wirklich nach Schreibvorgängen an. Aber allgemein solltest du dir die Codeunit (und auch alle anderen) mal genauer ansehen. Durch temp. ausschalten unbenutzter Keys konnten wir einen Migrationsschritt (3.70 -> 4.03) von 3 Tagen auf knappe 6 Stunden reduzieren. Sowas sollte bei euch auch möglich sein.
Es kommt natürlich immer auf die Umgebung im allgemeinen an.
7. Mai 2007 22:43
Hallo,
die CU104015 wird zur Laufzeit der Migration aus der CU 104010 erzeugt und prüft die Felder (Feldinhalte) aller Tabellen, ob sie auf den SQL-Server migrierbar sind.
Auch wenn der Name "Field Check" nicht nach schreiben klingt, so kann dies doch eine wesentliche Aktion dieser Codeunit sein. Denn alle Feldinhalte, die nicht migriert werden können, werden in der Tabelle 104011 protokolliert.
Zwecks Optimierung würde ich vielleicht am Ende jeder Unter-Funktion ein COMMIT setzen bzw. bei den sehr großen Tabellen ggf. nach etwa 1000 INSERTS. Das Problem ist, dass zuviele COMMITS die Sache auch wieder verlangsamen.
Eine COMMIT-Anweisung würde ich in der CU 104015 im OnRun-Trigger vor die UNTIL-Anweisung platzieren, da diese Stelle nach jeder Unterfunktion "Tablexxx" ausgeführt wird.
Aber Erfahrung mit der Migration von Datenbanken dieser Größe habe ich leider nicht
die CU104015 wird zur Laufzeit der Migration aus der CU 104010 erzeugt und prüft die Felder (Feldinhalte) aller Tabellen, ob sie auf den SQL-Server migrierbar sind.
Auch wenn der Name "Field Check" nicht nach schreiben klingt, so kann dies doch eine wesentliche Aktion dieser Codeunit sein. Denn alle Feldinhalte, die nicht migriert werden können, werden in der Tabelle 104011 protokolliert.
Zwecks Optimierung würde ich vielleicht am Ende jeder Unter-Funktion ein COMMIT setzen bzw. bei den sehr großen Tabellen ggf. nach etwa 1000 INSERTS. Das Problem ist, dass zuviele COMMITS die Sache auch wieder verlangsamen.
Eine COMMIT-Anweisung würde ich in der CU 104015 im OnRun-Trigger vor die UNTIL-Anweisung platzieren, da diese Stelle nach jeder Unterfunktion "Tablexxx" ausgeführt wird.
Aber Erfahrung mit der Migration von Datenbanken dieser Größe habe ich leider nicht
Migrationstool
9. Mai 2007 09:57
war heute gegen 09.0 Uhr fertig 
und hat einen Fehler gefunden.
Gut, der Server war nicht der schnellste, aber die Zeit wird sich auf dem Echtsystem auch nur halbieren.
Hoffentlich werden diese Woche keine 'unkorrekten' Datums eingegeben.
und hat einen Fehler gefunden.
Gut, der Server war nicht der schnellste, aber die Zeit wird sich auf dem Echtsystem auch nur halbieren.
Hoffentlich werden diese Woche keine 'unkorrekten' Datums eingegeben.
9. Mai 2007 11:23
Na da hast du doch einen Anhaltspunkt. Evtl. modifizierst du die CU dass beim echtlauf nur Neue Records gescheckt werden. (kostet vielleicht 2 - 3 Stunden Programmierung, aber immer noch besser als Tagelang Balken gucken