# Performance gut?



## Verjigorm (19. Nov 2008)

Hallo,

ich komme jetzt in die Endphase meines Projekts.
Beim heutigen Test wurden knapp 1Mio Datensätze testweise von Superbase per ODBC-Treiber in Access importiert.
Das Ganze dauerte etwa 6Stunden.
Jeder Datensatz wurde mindestens 2mal angefasst, 1mal lesend und 1mal schreibend.
Mit diversen Plausibilitätsprüfungen waren es etwa 2,5Mio SQL-Anweisungen in 6h.
Lustigerweise sind das gradmal 154MB reine Daten.
So im Schnitt sind das also 2500000/(360*60) ~ 100 Anweisungen pro Sekunde.

Was ich für den ODBC-Treiber unglaublich schnell finde.
Naja wie das so ist, Chef hat gesagt es ist zu langsam .....

Bin allerdings nicht der Meinung, dass sich da irgendwas "performanter" programmieren lässt, was wirklich was bringt.
Die 2 Treiber sind imho einfach nicht schneller.
Wobei das 2-3mal schneller ist, als ich vorher vermutet habe.

Denkt ihr, der Treiber schafft mehr und es lohnt sich wirklich nach mehr Performance im Code zu suchen?

mfg Verjigorm


----------



## Gast (19. Nov 2008)

>>Denkt ihr, der Treiber schafft mehr und es lohnt sich wirklich nach mehr Performance im Code zu suchen? 

Denkst du, dass irgendjemand eine vernünftige Anwort geben kann ohne deine App zu profilen?

schnell, langsam

Alles so subjektiv..


----------



## AlArenal (19. Nov 2008)

Lass mich raten, beide DBs liefen auf derselben Karre, einem Pentium 3 mit 500 MHz und 128 MB RAM und du hast brav jeden Datensatz einzelen ausgelesen, einzeln abgespeichert und commitet...

Gast hat völlig Recht: Auf ungenaue Fragen kannst du keine präzise Antworten erwarten.


----------



## Verjigorm (20. Nov 2008)

SuperbaseDatenbank mit Superbase 32-bit Driver (*.sbf)
Access 2002 mit dem Standardtreiber WinXP-Treiber Microsoft Access Driver (*.mdb)
1 Rechner mit WinXP mit 2GHz und 2GB Ram (sonst lief nicht wirklich ein anderes Programm)
Java 6 Update 10



			
				AlArenal hat gesagt.:
			
		

> .. und du hast brav jeden Datensatz einzelen ausgelesen, einzeln abgespeichert und commitet...



Ja, genauso isses 
Von Superbase in Access.


----------



## foobar (20. Nov 2008)

Benutzt du denn Batchupdates zum Schreiben der Datensätze?


----------



## Verjigorm (20. Nov 2008)

Nö.

Das Ganze läuft nach einer Nummernliste ab, die abgearbeitet wird.
Jeder Datensatz wird einzeln gelesen, auseinandergenommen, überprüft, neu zusammengesetzt und geschrieben.
Nach jedem datensatz kommt ein Commit, falls irgendwo unerwartete Fehler auftreten wird genau da abgebrochen.


----------



## foobar (20. Nov 2008)

Dann brauchste dich auch net zu wundern, daß die Anwendung lahm ist.


----------



## Verjigorm (20. Nov 2008)

Wie gesagt, ich finds eigentlich nicht lahm *schulterzuck*


----------



## GilbertGrape (20. Nov 2008)

Verjigorm hat gesagt.:
			
		

> Wie gesagt, ich finds eigentlich nicht lahm *schulterzuck*


Warum fragst du dann hier überhaupt?
Du wolltest nur hören, dass dein Chef ne Meise hat und du alles genau richtig gemacht hast?  :wink:


----------



## foobar (20. Nov 2008)

Machst du für jeden Datensatz einen Select und einen Insert oder wie läuft das?


----------



## -MacNuke- (20. Nov 2008)

Verjigorm hat gesagt.:
			
		

> Lustigerweise sind das gradmal 154MB reine Daten.



Äh, warum holst du dir nicht auf einen Schlag alle Daten in den RAM, bearbeitest sie und haust sie in ein paar Batch-Arbeiten in die andere Datenbank?

6 Stunden, um 154MB Daten zu bewegen ist etwas... naja.... lahm.


----------



## Verjigorm (20. Nov 2008)

foobar hat gesagt.:
			
		

> Machst du für jeden Datensatz einen Select und einen Insert oder wie läuft das?



Ja natürlich, ohne Select krieg ich das Ding net aus der DB und ohne Insert nicht wieder in die andere rein   :?: 




			
				-MacNuke- hat gesagt.:
			
		

> Äh, warum holst du dir nicht auf einen Schlag alle Daten in den RAM, bearbeitest sie und haust sie in ein paar Batch-Arbeiten in die andere Datenbank?
> 
> 6 Stunden, um 154MB Daten zu bewegen ist etwas... naja.... lahm.



Es ist ja keine 1:1 Kopie, sondern eine Migration von A nach B.
Sämtliche Werte, sämtlicher Spalten, sämtlicher Tabellen werden anhand von Listen/Bedingungen verglichen, geändert etc.


----------



## Gast (20. Nov 2008)

Deswegen musst du es trotzdem nicht  für jeden Datensatz einzeln machen...


----------



## AlArenal (20. Nov 2008)

Verjigorm hat gesagt.:
			
		

> Jeder Datensatz wird einzeln gelesen, auseinandergenommen, überprüft, neu zusammengesetzt und geschrieben.



Und das ist ein Fehler, weil du damit sowohl lesend als auch schreibend einen riesigen Overhead erzeugst. Pass die Programmierung an, dass du blockweise immer x Zeilen ausliest, verdengelst und in einer (!) Transaktion wegschreibst. Setz für x mal 1, 50, 200, 500, 1000... und schau dir die Permance an..
Ein Briefträger holt auch nicht jeden Brief einzeln bei der Post ab, stellt ihn zu, holt den nächsten Brief, liefert ihn aus, holt den nächsten, ...

Wenn du nicht jeden zweiten Datensatz nen Fehler hast (es sollte ja nur während der Entwicklung mal einer vorkommen), ist der evtl. Overhead für ein Rollback vernachlässigbar. Von daher ist mir nciht wirklich begreiflich,w arum du dein Prog so eine Stückelarbeit machen lässt.

Zu meine Anfangszeiten habsch noch auch proprietären Datenbanken, die kein Mensch lesen konnte, gedruckt, den Druck in eine Datei umgeleitet (damals noch indirekt via Abfangen der Druckdaten an der seriellen Schnittstelle), habe die Druckdaten mit Sed und Perl durchgeahst und ein schmuckes CSV zum direkten Access Import erzeugt.
Ach ja, die guten alten Zeiten...


----------



## Verjigorm (21. Nov 2008)

Ich wüsste nicht, wie ich da x Zeilen auf einmal auslesen sollte ...


----------



## homer65 (21. Nov 2008)

Nach jedem Insert ein Commit zu machen ist tödlich für die Performance. Nebenbei bemerkt sind 6 Stunden für den insert von einer Millionen Sätze mehr als lahm. Ich würde bei einem brauchbaren Datenbanksystem Zeiten von ca 1 Minute für normal halten.


----------



## tfa (21. Nov 2008)

Wer tatsächlich Access als Datenbank einzusetzen versucht bekommt ganz genau das, was er verdient.


----------



## Verjigorm (21. Nov 2008)

Naja das Problem ist eher Superbase ...
Der letzte Treiber ist von 1999.
Alleine die 75.000 Nummern auszulesen dauert etwa 90sek und das ist eine einfache Select-Anweisung ohne irgendwas

```
"SELECT EquipmentNr FROM DBESTAND ORDER BY EquipmentNr"
```

Selbst ohne Order BY dauerts 75sek


edit: Ihr habt ja keine Vorstellung davon, wie schlecht Superbase ist und wieviel schlechter der ODBC-Treiber ist


----------



## AlArenal (21. Nov 2008)

Ein Grund mehr alles in einem Rutsch auszulesen, loakl zu verarbeiten und dann in einem Schwung in die Ziel-DB zu schreiben.

Zur Not:
Musst du zwingend über den Treiber direkt auf die Quelle zugreifen? Reichen nicht auch exportierte Files? Das sagt einem doch der gesunde Menschenverstand, dass es schneller wäre den Scheiß lieber lokal in eine temporäre DB zu klatschen und damit zu arbeiten. Ob das nun ne HSQL ist, oder CSV Dateien mit passendem Treiber, oder oder.. ist ja ein anderes Thema.


----------



## Verjigorm (21. Nov 2008)

Ich würde liebend gerne exportierte Dateien nehmen.
Aber das müsste der User dann von Hand machen.
Jedes "Modul" sind 80 Tabellen, sprich 80 Dateien.
Es gibt 4 Module, also ca. 300Tabellen pro Migrationsimport.
Der User müsste also erst 300mal die Tabellen Exportieren und irgendwo horten.

Von diesen Migrationsimporten gibt es ca. 200
Sind also geschätzte 50.000 Tabellen, die es gilt mit dem Tool gilt von Superbase in Access zu migrieren.

Viel Spaß beim vorherigen Exportieren


----------



## AlArenal (21. Nov 2008)

Verstehe ich nicht wirklich, aber ich kenne ja auch eure Umgebung nicht.

Wenn ich mirgirere, dann doch nur einmal. Und es wird dem DBA doch wohl möglich sein alles auf einmal zu exportieren...


----------



## tfa (21. Nov 2008)

Sehe ich genauso. Es ist doch egal, wielange die Migration dauert. Meinetwegen ein ganzes Wochenende. Oder soll diese Aktion regelmäßig stattfinden?


----------



## Verjigorm (21. Nov 2008)

AlArenal hat gesagt.:
			
		

> Verstehe ich nicht wirklich, aber ich kenne ja auch eure Umgebung nicht.
> 
> Wenn ich mirgirere, dann doch nur einmal. Und es wird dem DBA doch wohl möglich sein alles auf einmal zu exportieren...



Nö, Superbase kann immer nur eine Tabelle nacheinander exportieren, sonst würden wir es ja anders machen ...
Das scheiss Tool ist halt von 1987 oder so 

Die Migration ist (hoffentlich) ne einmalige Angelegenheit, aber man weiss ja nie ....


----------

