[Gelöst] - Langsamer Dataport

[rotsch]

Hallo zusammen

Ich habe einen Dataport erstellt um Adressrecords einzulesen. Es sind rund 100'000 Datensätze. Der Aufbau der Records ist fix, dass heisst, der Dataport muss die Werte für die einzelnen Felder an bestimmten Stellen auslesen. Der Dataport schafft ungefähr 1 Datensatz pro Sekunde. Da der Gesammtimport schlussendlich rund 1 Mio. Adressen enthalten wird, bin ich längst in Rente, bis alles eingelesen ist

Ist das normal, das Dataports mit fixer Recordlänge so viel langsamer sind als mit variablem Satzaufbau? Oder habe ich etwas übersehen, dass das Teil schneller machen könnte?

Zuletzt geändert von rotsch am 20. Dezember 2006 10:03, insgesamt 1-mal geändert.

Naja, dafür müsste man schon den Quelltext sehen...

Vom blauen Himmel aus geraten würde ich sagen:
Wenn du die Daten zusammensuchst - verwendest du dort den optimalen Schlüssel?

Ich importiere ein Textfile. Da kann der Schlüssel doch keinen Einfluss haben, oder?

Quelltext gibt es einen keinen, ausser etwas Code auf OnAfterImportRecord:

Code:

Adressimport.ID := NewID;
NewID := NewID + 1;

Nun ja, einen Unterschied in der Laufzeit zwischen Fix und Variable hab' ich noch nicht beobachtet ...

Aber: Je größer das Import-File, desto langsamer werden die Dinger. Insbesondere, wenn Business-Logik in den verschiedenen Triggern abgearbeitet wird.

Hier 'n paar Anregungen, den Import zu beschleunigen:

- Wenn SQL Server gestützt, dann DTS/SSIS anstatt Dataport verwenden
- Daten in temporäre Tabelle importieren - Achtung: Client braucht genügend RAM! - und danach die Daten in die echte Tabelle "dumpen"
- Es sollte u.U. ein Schlüssel verwendet werden, der der Sortierung der Daten im File entspricht
- Ggf. keine AutoInsert / AutoReplace durchführen, sondern "zu Fuß"

Viel Glück ...

Hi,
wir haben in so einem Fall auch schon mal das Source File in mehrere kleinere Files aufgeteilt, um so das Importieren zu beschleunigen.

Beim Imprtieren / Exportieren von Objekten selber ist mir auch schon aufgefallen, dass die Performance rapide sinkt, wenn man mehr Objekte gleichzeitig laden will. Inzwischen laden wir hier auch nur noch alle Tabellen, Reports, Forms usw. auf einmal und nicht alles zusammen.

Gruesse
feri

- Wenn SQL Server gestützt, dann DTS/SSIS anstatt Dataport verwenden
- Daten in temporäre Tabelle importieren - Achtung: Client braucht genügend RAM! - und danach die Daten in die echte Tabelle "dumpen"
- Es sollte u.U. ein Schlüssel verwendet werden, der der Sortierung der Daten im File entspricht
- Ggf. keine AutoInsert / AutoReplace durchführen, sondern "zu Fuß"

DTS/SSIS kenne ich leider nicht. Ich nehme an, das führt man direkt auf dem SQL-Server aus?
Datenübernahmen mache ich grundsätzlich immer in Zwischentabellen und verteile die Daten dann in die produktiven Tabellen
RAM muss ich noch prüfen, da ich das via Citrix ausgeführt habe
Wie muss ich das verstehen mit dem "zu Fuss"? Die Zeilen selber lesen mit READ und dann mit INIT/INSERT in die Tabelle spitzen?

Hi,
wir haben in so einem Fall auch schon mal das Source File in mehrere kleinere Files aufgeteilt, um so das Importieren zu beschleunigen.

Das habe ich schon versucht, und hatte auch Erfolg damit. Nur ist es schwierig zu sagen, wie gross denn ein File maximal sein soll. 100'000 Zeilen sind eindeutig schon zuviel. Wahrscheinlich wären so 20'000 bis 30'000 noch gut zu verarbeiten.

Da dir sicher ein SQL Server zur Verfügung steht, würde ich auf jeden Fall die Idee von stryk nochmal aufgreifen. Die Zeit die du mit testen und Haare raufen verbringst kannst du auch mit einer kurzen Lektüre zu SSIS bzw. SQL 2000 DTS verbringen.

Und da du wie du schreibst eh über Puffertabellen arbeitest, könntest du die Daten auch gleich in die Ziel-Puffertabelle schreiben. Das wird in minutenschnelle drin sein.

Als Vergleich: Unsere Debitorentabelle braucht per Dataport mehr als 18 Stunden zum Einlesen OHNE weitere Verarbeitung auf einem durchaus schnellen Server. Das ganze per SSIS dauerte überschlagen, da damals insgesamt 20 Tabellen importiert wurden, ca. 5 Minuten. Und da lief wahrscheinlich noch ein Backup nebenbei

Ich habe jetzt einen Test gemacht mit einem Importfile, in welchem die Felder mit dem |-Zeichen getrennt sind. Das File enthält rund 60'000 Datensätze.

Erstens ist das Importfile anstatt 80MB nur noch 18MB gross, und zweitens läuft der Importvorgang etwa um Faktor 500! schneller.

Fazit:
Verwende nie Importfiles mit fixen Satzlängen, da macht Navision die Grätsche bei grossen Files.

DTS (SQL Server 2000) = Data Transformation Services
SSIS (SQL Server 2005) = SQL Server Integration Services

Hier können Objekte auf SQL Server Seite erzeugt werden, die Daten importieren, exportieren, konvertieren, transformieren, etc.. Vereinfacht gesagt, die SQL Server Version von Dataports. Diese Features sind zwar weitaus mächtiger, können aber auch zum simplen FileImport benutzt werden - und das eben um ein vielfaches schneller.

Das Problem mit Dataports ist, daß NAV offensichtlich versucht die gesamte Datei zu laden um die Daten dann zu importieren. D.h. je größer die Datei, desto mehr Speicher wird allokiert, desto langsamer gehts. Läuft das Ganze auf SQL Server, so wird der gesamte Import in einer einzigen Transaktion durchgeführt, was nochmals die Performance drückt.

"Zu Fuss" heißt deshalb im Detail:
- GlobaleVariable der Importtabelle als TEMPORÄR erstellen
- Importdaten auf Felder der tempörären Tabelle ziehen, damit wird die gesamte Verarbeitung soz. im lokalen RAM ausgeführt, keine echten Server Transaktionen - geht wesentlich schneller, aber der Client braucht reichlich RAM
- Importfile schließen, und danach die temporären Records in die "echte" Tabelle kopieren. Hierbei ggf. COMMIT nach jeweils 100 - 1000 Datensätzen.

Unterm Strich sollte das schneller gehen. Aber wie gesagt: Wenn möglich, dann DTS/SSIS - mit den entsprechenden Assistenten auch für Newbies kein echtes Problem!

@stryk
Danke für die ausführlichen Erläuterungen. Ich werde mir diese Tools des SQL-Servers auf jeden Fall ansehen.