Vb und Oracle

[aokieh]

Skandal,

ich brauche Hilfe.

Ich lese Daten aus einer .txt Datei zeilenweise aus. Soweit kein Problem.

Dann schneide ich mir die Zeile zurecht. Immer noch kein Problem.

Nun kommt es:

Es sind 500 MB Daten und die muss ich über das Netzwerk in eine Oracle Datenbank auf dem Server spielen. Die Daten bekomme ich zum Server. Nur leider dauert dies sehr lange.

Ich habe einen normalen ADO Zugriff mit Connection und Recordset und schreibe mit .addnew in die Datenbank, schliesse dann mit .update die Sache ab.

Weitere Möglichkeit die ich versuch habe:

Ohne Recordset dafür eine Command.

Nachdem ich dem Command einen RS.CommandText = sql übergeben habe führe

ich einen RS.Execute aus.

Dies dauert aber alles solange.

Wer kann mir helfen diese Angelegenheit zu verschnellern.

Vielen Dank!!

Gruß aokieh

[shad0w]

da gibt es keine moeglichkeit.

odbc ist und bleibt eine der langsamsten verbindungen ... du koenntest ueber native treiber auf die db zugreiffen, die funtzen aber nicht fuer vb. aber und php z.b. gehen die wunderbar.

MfG

[Olli_Master]

Grundsätzlich ist es besser bei solchen Datenmengen die Verarbeitung serverseitig laufen zu lassen.

Ich sehe folgende Alternativen:

1. VB + SQL-Plus

Du machst aus der 500MB-Datei ein SQL-Script mit den fertigen SQL-Anweisungen (auf dem Client) und das Script startest du über SQL-Plus (Oracle Client).

Den Script kannst du wahlweise

1a) vom Client aus ausführen

1b) auf Server kopieren (ggf. packen) und dort ausführen

2. VB + SQL-Loader

Du machst aus der 500MB-Datei ein Austauschdatei, die via SQL-Loader in die Datenbank geladen werden kann .

Den Script kannst du wieder wahlweise

2a) vom Client aus ausführen

2b) auf Server kopieren (ggf. packen) und dort ausführen

3. VB App auf dem Server ausführen.

4. ??? PHP, PLSQL, ... ???

Welche Variante die beste ist, hängt von deinem Problem ab:

I. Datensicherheit: Welcher schaden entsteht, wenn der Export aufgrund eines Netzausfalls (o.ä.) abbricht.

II. Kannst/darfst du serverseitig Oracle Werkzeuge benutzen.

III. Was genau dauert bei der übertragung so lang? Die Insert-Operation in der DB oder die reine Netzwerkübertragung (langsames Netz)?

1a und 2a dürften die schnellsten, client-basierten Lösungen sein.

Ich hoffe das hilft dir.

[aokieh]

Netzwerk ist in Ordnung.

Der Zugriff dauert zu lange.

Ich darf alle benötigten Programme und Mittel benötigen.

Hab mich noch mal informiert, es sind 1,7 GB Daten die ich an jedem 1.

in die Datenbank auf den Server laden muss.

Werde mal schau ob ich mit deinen Vorschlägen etwas anfangen kann.

Gruß aokieh

[aokieh]

Original geschrieben von -leliel-

da gibt es keine moeglichkeit.

odbc ist und bleibt eine der langsamsten verbindungen ... du koenntest ueber native treiber auf die db zugreiffen, die funtzen aber nicht fuer vb. aber und php z.b. gehen die wunderbar.

MfG

ich habe es mit der native Aktion versucht.

Da bekomme ich ca. 10000 Datensätze die Minute in die DB.

Nur leider habe ich ca. 22.000.000 Datensätze an jedem ersten in die DB zu spielen.

Ich frage mich ob es mit einer anderen Programmiersprache (momentan VB) besser geht.

Aber da ich in VB das ganze Prog mit allen Auswertungen geschrieben habe müßte ich einige Tage arbeit wegwerfen.

Java oder so müßte es schneller machen.

Naja, schau mer mal.

aokieh

[Olli_Master]

Da bekomme ich ca. 10000 Datensätze die Minute in die DB.

Das ist doch schon mal nicht schlecht. (Da bist du mit 3h 40 min dabei)

Wenn du schneller werden willst, dann musst du herausfinden, warum das ganze so "lange" dauert. Vielleicht liegt das Problem auf Datenbankseite?

Also:

Am Zugriff sollte es eigentlich nicht liegen, der native Zugrff (OCI, SQ-LPlus, SQL-Loader) ist erfahrungsgemäß der schnellstmögliche. (PHP wäre in der Textverarbeitung aber bedeutend schneller als VB.)

Ich denke es liegt an folgenden Punkten:

- Die Aktualisierung der Indices dauert bei jedem Update zu lang. Daher wäre es günstig die Indices vor dem einspielen zu löschen (Vorsicht!!) und anschließend neu zu generieren.

- Bei dem Einfügen der Datensätze werden eventuell verschiedene Constraints geprüft (Primärschlüssel, Fremdschlüssel, Eindeutige Schlüssel, usw.)

Für den Fall, das du weisst, das die Daten 100%tig in Ordnung sind, kann man diese Constraints vorübergehend deaktivieren.

Könnte das Problem an VB liegen (vielleicht schafft er das auslesen nicht schneller?)

- Wenn dem so ist, dann kannst du die Daten ja vorher ohne direkten Datenzugriff erstmal in eine "für die Datenbank einfach einlesbares" Format bringen --> SQL-Loader. Dieser ist eigentlich zum Zweck des Einlesens von Massendaten als Werkzeug vorgesehen.

Frage: Sind die 22 Mio DS der Komplettdatenbestand, oder werden diese zum bestehenden Datenbestand hinzugefügt?

Ich hoffe das hilft dir.

[aokieh]

Die Daten werden jetzt erstmalig in die DB geschrieben.

Dann monatlich ca. 1,5 GB dazu.

Habe versucht ein Script zu schreiben, dies ist mir aber nicht richtig gelungen.

Muss noch ein bisschen probieren.

Gruß :(

[JunkMarv]

hi,

vb ist grotten langsam. am besten nutzt man den sqlloader von oracle. ist sehr schnell, je nach nachlade art.

aufruf:

sqlldr userid=user/passwort@dienstname control=pfad\controlfile

control-file:

OPTIONS (DIRECT=TRUE,ERRORS=20000000)

LOAD DATA

INFILE 'h:\quell.txt' /quelldatei

Badfile 'h:\bad.txt' /meldung.log

DISCARDFILE 'h:\dis.dis' /abgelehnte datensätze

APPEND

INTO TABLE tabellen_namen

FIELDS TERMINATED BY '|' /trennungszeichen der datensätze

( spalte1, /spaltennamen in der db-tabelle

spalte2,

spalte3,

spalte4

)

bei DIRECT=TRUE haut der die ganzen daten ohne rücksicht auf schlüssel und indizes in die tabelle, also obacht, die tabelle kann korrupt werden. bei DIRECT=FALSE feuern alle trigger, indizes und schlüssel; dauert entsprechend länger das nachladen, aber man ist auf der sicheren seite. man kann noch mehr mit dem sqlloader machen, dazu empfehle ich die doku von oracle.

gruß

junkmarv

[aokieh]

Wahnsinn,

nach einer Woche harter Arbeit habe ich es geschaft.

22000000 Datensätze in 86 Minuten auf den Server zu schreiben.

Berechneter Zufriff mit Ado und ODBC 186 Stunden.

Danke, Danke, Danke.

Gruß aokieh

[fmarx2000]

Original geschrieben von aokieh

Wahnsinn,

nach einer Woche harter Arbeit habe ich es geschaft.

22000000 Datensätze in 86 Minuten auf den Server zu schreiben.

Berechneter Zufriff mit Ado und ODBC 186 Stunden.

Danke, Danke, Danke.

Gruß aokieh

Hallo,

würde mich mal interessieren wie du das gemacht hast, vielleicht kann man das ja

mal gebrauchen.

Frank

[aokieh]

Neuester Stand: 28,5 Mio Datensätze in der Stunde.

Eigentlich ist es oben schon gut erklärt.

Hinzuzufügen ist nur, dass der SQL Loader ein Oracletool ist.

Mit Start/Ausführen einfach

sqlldr userid=user/passwort@Datenbank control=pfad\Datei eingeben

die aufgerufene Datei muss eine *.cls Datei sein.

Die *.cls muss den Aufbau haben wie schon oben beschrieben.

z.B.

options (direct=true,errors=2000000)

Load Data

infile 'D:\1.txt' >--hier können beliebig viele Dateien eingefügt werden

infile 'D:\10.txt'

badfile 'D:\data.log' >-- Bericht über den Ablauf des Transfers

discardfile 'D:\data.dis' >--Abgelehnte Datensätze

Append

into table logfile >-- Tabellenname

fields terminated by ';' >-- trennzeichen zwischen den Datensätzen in der txt Datei

>--z.B. 234;567;134;

(spalte1,spalte2,spalte3) '>--hier müßen die Spaltennamen der Tabelle eingegeben werden

Ende der Datei.

Von VB hab ich dann mit Hilfe des Shellbefehls den SQL Loader gestartet

Shell "sqlldr userid=user/passwort@Datenbank control=pfad\Datei eingeben"

und schon geht es los. Das Dosfenster öffnet und wenn alle Daten in die Datenbank

geschaufelt wurde schliesst es.

Achja noch ein was.

Natürlich lass ich die *.cls Datei von meinem Programm aus erstellen, so kann ich dann auch

die Anzahl der INFILES dynamisch gestallten.

Ich habe in die Datei 107 Infiles reingeschrieben und los gings.

Ich hoffe das genügt.

1 Woche harte Arbeit habe ich hinter mir.

Hier sind auch noch Infos: http://www.rst-consult.com/database/oracle/

Gruß aokieh