Import FBK auf SQL nur 3 MB pro Sekunde

Hallo Liste,

oft habe ich gute Hinweise finden können - bei diesem Fall bitte ich direkt um Eure Erfahrungen, da ich so
nicht weiterkomme:

Wir migrieren von 4.0 SP2 (NativeDB) auf 5.0 SP1 (SQLDB).

- die NativeDB läuft auf exakt identischer Hardware wie die testhalber installierte SqlDB
- der Komplett-Import einer FBK-Sicherung (etwa 50 GB) dauert auf der NativeDB "nur" 8 Stunden inkl. Schlüsselerstellung
- auf dem SQLer etwa 12 Stunden inkl. Schlüsselerstellung

Hier sehe ich den Grund für die Unterschiede bei der Einlesegeschwindigkeit
- etwa 15 MB pro Sekunde reines Einlesen beim Native
- etwa 3 MB pro Sekunde reines Einlesen beim SQL

Wo liegen da die Unterschiede, da der SQL-Server (mit Platten, Prozessor und RAM) sich wirklich ziemlich
langweilt. Ist es möglich, dass der 32bit-Client von Navision nicht richtig performant auf dem SQL-Server (64bit)
arbeiten kann?

Spezifikationen des SQL 2005 Standard X64
- Prozessor 3.0 Dual-Quadcore
- 32 GB RAM
- SAN (Netapp 2050 mit 9x 300 GB Raid 4)

- C-Partition (System)
- D-Partition (Pagefile)
- E-Partition (Navision-DB 240 GB aufgeteilt in 8 Teildatenbanken)
- F-Partition (Systemdatenbanken)
- G-Partition (Temp-DB)
- H-Partition (TA-Protokoll mit 200 GB)

Über eine kurze Info würde ich mich freuen. Ich habe noch weitere Threads, die interessant
sein könnten, werde diese lieber separat schreiben.

Besten Dank

Marc

Hallo!

Wenn sich der Prozessor beim Einlesen der Datenbank langweilt, wartet er wahrscheinlich auf jemanden, dass ist i.d. Regel der Massenspeicher.
Mir fällt auf, dass eine Datenbank auf einem RAID4 läuft. Laut Wikipedia hat das RAID4 einige Einschränkungen. MS empfiehlt. im allgemeinen ein RAID1 bzw. RAID10- Verbund, da dieser beim Lesen erhebliche Vorteile bietet (siehe Wikipedia).
Der SQL-Server schreibt für jeden Datensatz in der Datenbank midestens 2 Dateien, die Datenbank und das Log. Solltest du Datenbank und Log nicht von Anfang an mit einer Größe definiert haben, die in etwa der erwarteten Datenbankgröße entspricht (also ca. 50 GB für die DB und 20 GB fürs LOG), versucht der SQL-Server immer wieder deine Datenbank zu vergrößern. Er ist dann mehr damit beschäftigt, die Datenbank zu vergrößern, als deine NAV-fbk einzulesen.
Fürs Einlesen der FBK solltest du die Datenbank in den Einfachen oder Massen-protokollierten Modus versetzen (mal testen), damit dein LOG nicht so groß wird.

Wie schnell ist deine SAN-Anbindung, kann die auch der Flaschenhals sein?
Die SQL-Datenbank sollte auf physikalisch getrennte Platten verteilt werden (DB und LOG auf auch physikalisch getrennte Platten), damit DB und LOG-Zugriffe möglichst parallel ausgeführt werden können. Außerdem macht es wenig Sinn mehrere Datenbankteile auf eine Platte zu legen, da der Plattencontroller (der auf dem SAN) hier nicht optimal arbeiten kann.

Schränke evtl. den Arbeitsspeicher des SQL-Servers etwas ein, damit das OS etwas mehr Luft zum Arbeiten hat.
Evtl. kannst du aber das Einlesen auch beschleunigen, wenn du z.B. das erstellen der Statistiken während des Einlesens abschaltest, und diese erst danach aufbaust.
Du solltest dich für die Optimierung mit 'Perfmon' beschäftigen. Das Programm kann dir sicherlich Informationen beschaffen, wo es hängt.

Als letzten Tip, prüfe bitte, wie schnell der NAV-Client auf den Server zugreifen kann. Er sollte evtl.mit einer GB-Netzwerkverbindung auf den Server zugreifen, damit er die Daten möglichst schnell mit dem Server austauschen kann. Es ist wahrscheinlich nicht so optimal, den 32bit-Client auf dem 64bit Server laufen zu lassen.

Gruß, Fiddi