Array aus DB mit Zahlen füllen

[Sir Rufo]

Da fallen mir doch ein paar wesentliche Dinge auf

1. Das ständige COMMIT bremst ... Starte die Transaktion, trage alle Daten ein, und ganz zum Schluss ein COMMIT
2. Du erstellst die SQL-Statements ständig neu, dadurch kommst du nicht in den Genuss der Prepared-Statements, die wesentlich schneller ablaufen. Erstelle die für jedes Statement ein Query-Objekt und benutze das (Parameter verwenden)
   
   Delphi-Quellcode:

   LCount_Query.SQL.Text := 'SELECT count(*) FROM ' + Fertigungslos + ' WHERE (Auftragsnummer = :JobId) ...';
   ...
   LCount_Query.ParamByName('JobId').Value := JobID;

Generell würde ich den Import aber anders auf die Beine stellen:

1. Anlage einer (oder mehrerer) Import-Tabelle(n)
2. Views von den Import-Tabellen anlegen, um die Daten in das neue Format zu überführen
3. Mit diesen Views den Import durchführen

Ab dem Schritt 2 läuft dann alles auf der Datenbank selber und sollte erheblich schneller funktionieren.
Sollte (wenn die Zieltabellen einen vernünftigen Index haben) sich dann nur um Stunden handeln

[jobo]

Zitat von Sir Rufo:

Ab dem Schritt 2 läuft dann alles auf der Datenbank selber und sollte erheblich schneller funktionieren.
Sollte (wenn die Zieltabellen einen vernünftigen Index haben) sich dann nur um Stunden handeln

Indizes,Import und Geschwindigkeit vertragen sich nicht gut.
Import ohne Index oder Indizes läuft schneller. Am Ende - Insert der aufbereiteten Daten- lässt sich natürlich ein Index in der Zieltabelle selten vermeiden. Ausnahme wäre bspw. ein einmaliger Import, bei dem zuvor die Indizierung deaktiviert / gelöscht und nach dem Import wieder restauriert
wird.

Ich verwende gerne "Raw" Importe, also 1:1 Import Altdaten in DB. Dort habe ich per SQL elegante Aufbereitungsmöglichkeiten. Der reine Import der Altdaten läuft dabei nur in Texttypen rein. Die Importtabelle wird dann gereinigt, plausibilisiert und typkonvertiert in die Zieltabelle eingetragen.
Das ist umgekehrt zu ETL, das Extrakt, Transform kommt erst nach dem Load. Ich hab aber nie so große Datenmengen importieren müssen, dass ich mir / dem System das nicht erlauben konnte.

[messie]

[QUOTE=jobo;1251785]

Zitat von Sir Rufo:

Ich hab aber nie so große Datenmengen importieren müssen, dass ich mir / dem System das nicht erlauben konnte.

Groß sind die Datenmengen eigentlich nicht: nur 20-30 MB - leider aber aufgeteilt in etwa 3000 Aufträge mit jeweils unterschiedlichen Messdaten mit TimeStamps aus den vergangenen zehn Jahren.

Ich bin gerade dran, das von den Commits zu befreien...

Grüße, Messie

[Sir Rufo]

@jobo

Das mag zutreffen, wenn man nicht - wie in diesem Fall - auf Dubletten überprüfen muss.
Hier werden Daten zusammengeführt.

Ein gangbarer Weg wäre aber die gültigen Importsätze wiederum in einer temporären Tabelle zu speichern, dann den Index bei der Zieltabelle abschalten, Importdaten einfügen und den Index aufbauen lassen.

[jobo]

Richtig, ich fand einfach nur die Aussage Import mit Index etwas zu pauschal, auch wenn es in diesem Thread etwas spezieller (Dubletten) gefasst war.

[jobo]

Zitat von messie:

Zitat von jobo:

Zitat von Sir Rufo:

Ich hab aber nie so große Datenmengen importieren müssen, dass ich mir / dem System das nicht erlauben konnte.

Groß sind die Datenmengen eigentlich nicht: nur 20-30 MB - leider aber aufgeteilt in etwa 3000 Aufträge mit jeweils unterschiedlichen Messdaten mit TimeStamps aus den vergangenen zehn Jahren.

Ich bin gerade dran, das von den Commits zu befreien...

Grüße, Messie

Der Kommentar ist bezieht sich wohl auf meine Äußerung nicht auf Sir Rufo.
Mit großen Datenmengen meine ich nicht 20-30 MB, sondern Volumen wo sich durch den Rohimport eine DB im 2-3 stelligen GB Bereich bspw. verdoppeln würde, ohne dass überhaupt Daten in Prod. Tabellen gelandet sind.
Wie gesagt, in kleineren Größenordnungen kann man sich durchaus den Luxus gönnen.
Damit meine ich nicht, einfach mit Speicherplatz rumzuasen, sondern diverse Vorteile dieses Verfahrens zu nutzen. Z.B. Performance und bequemer Dublettenabgleich gleichzeitig, begleitet von Reinigung, Validierung, Typkonvertierung der Daten. Eben nicht klassische ETL, sondern eher LET.

Bspw. allein der Murks, der häufig als Datum/Timestamp über Text reinkommt, kann einem das Leben schon sehr schwer machen. Wenn ich auf DB Seite per SQL eine Konvertfunktion mit definierter Formatmaske darauf ansetze, kann ich gleich noch eine Rückkonvertierung in Text mit Assert auf den Originalstring draufsetzen und bin damit sowohl gegen Original-Datenmüll als auch gegen Kovertierungsfehler 100% abgesichert. Geschieht das alles per SQL auf der DB, kostet mich das ungefähr 0% Aufwand.

[messie]

Moin,

ich habe mich schon auf Sir Rufo (#11) bezogen. Dass ich pro Import einer Datei tausend Mal ein commit sende was dann jedes Mal die DB beschickt, den Cache leert und was sonst noch so, ist verständlich.
Ich habe die Commits raus genommen und laufe vor die nächste Wand. Query.ExecSQL klappt nicht mehr. Offensichtlich hat das commit die verbundene Transaction so geerdet, dass ein Neuaufruf mit StartTransaction möglich ist.

Wie ist der genaue Ablauf? Ich habe eine Query, die einer Transaction zugeordnet ist. Die Transaction steht auf read_committed.
Ich habe bisher Transaction.StartTransaction -> Query.SQL.Clear -> Query.SQL.Add -> Query.ExecSQL. Wenn ich danach eine Query.open abfrage, bekomme ich eine Exception.

Ich vermute, dass ich das commit mit etwas Anderem ersetzen muss.

Grüße, Messie

Edit: wann kann ich auf das Transaction.StartTransaction verzichten? Denn das spuckt mir (Edit4: nach dem Entfernen des commit) in die Suppe. Ist das mit Performance verbunden? Also eher Transaction.Active = false und dann mit Starttransaction oder kann die die ganze Zeit offen bleiben?
Edit2: sehe ich das richtig, dass eine Query.open (nur Lesen) kein Transaction.active braucht und eine Query.ExecSQL (z.B. Schreiben) eine Transaction.active benötigt? Das sieht mir gerade so aus...
Edit3: ist dem Query.Open der Zustand der Transaction wegen des Nur-Lesens egal?

Danke!

[hoika]

Hallo,

Nicht Query.Clear, sondern Query.SQL.Clear.
Es gibt doch den SQL-Monitor zum Prüfen der Queries.
Die Geschwindigkeit lässt sich über prepared Queries erhöhen.
Drittens: Insert or Update benutzen, statt ständig per Select zu suchen, ob der Eintrag bereits existiert.


In einem Projekt hatte ich sogar sämtliche IDS in ein StringList geladen (Import lief exklusiv)


Heiko

[messie]

Moin,

ich habe die Transaction rausgenommen und die Daten kommen nicht in der DB an. Womit mache ich denn das kaputt?
Ich aktiviere die Transaction, frage dann per Query.Open an und füge bei Bedarf per Query.ExecSQL ein. Das mache ich rekursiv und zum Schluss ein commit. Irgendwo hakt es da aber. Ich habe die Vorstellung, dass meine ExecSQLs alle in einen Cache kommen und mit dem commit gespeichert werden. War das nicht so?

Grüße, Messie

[messie]

Moin,

ich habe mich mal durch die Einstellungen der IBCTransAction und der IBCQuery gearbeitet. Welche Kombination von Einstellungen sind denn sinnvoll für Transaction.IsolationLevel und Query.AutoCommit?

Grüße, Messie