Datenbankaktionen responsive halten

[Zwirbel]

Hi,

was ist die beste Strategie, wenn es darum geht, während eines Migrationsprozesses Daten von einer alten Datenbank in eine Firebird-Datenbank zu übertragen? Speziell geht es um die Frage, wie sorge ich dafür, dass Windows (und alle anderen laufenden Prozesse) in der Zeit nicht lahm gelegt werden oder nur noch zögerlich reagieren?

Bisher sieht mein Code so aus, dass ich Tabelle für Tabelle durch die Quelldaten marschiere und dann Datensatz für Datensatz per

Delphi-Quellcode:

            InsertSQL := Format('INSERT INTO %s (%s) VALUES (%s)', [TableName, InsertFieldNames, InsertFieldValues]);
            qry_FB.SQL.Clear;
            qry_FB.SQL.Add(InsertSQL);
            qry_FB.ExecSQL(InsertSQL);

... die Daten in die Firebird-Tabellen schreibe. Alle hundert Datensätze gebe ich mal etwas Zeit ab:

Delphi-Quellcode:

              { Genügend Zeit abgeben, damit die Applikation nicht hängt. }
              if j mod 100 = 0 then begin
                Application.ProcessMessages;

Aber obwohl pro Sekunde mehr als 10 Mal das "Application.ProcessMessages;" aufgerufen wird, fühlt sich Windows und auch die eine oder andere Applikation sehr träge an. Es kann auch vorkommen, dass eine Applikation mehrere Minuten gar nicht mehr reagiert. Die gesamte Prozessauslastung von Windows liegt dabei aber lediglich um 20%, von insgesamt 16 GB Hauptspeicher ist noch 30% frei. Da sehe ich also keine Engpässe.

Im Moment ist das noch nicht so tragisch, dieser Migrationsprozess wird einmal ausgeführt und gut ist. Aber später in der eigentlichen Applikation werden häufig Berechnungen durchgeführt, bei denen zehntausende von Datensätzen aus unterschiedlichen Tabellen gelesen werden und ebenso viele Datensätze in anderen Tabellen gespeichert werden.

Wie hält man da seine eigene Applikation und auch das restlichen Windows "responsive"?

Danke, Gruß, Markus

[mensch72]

die beste Strategie ist, sich um das Abgeben von Rechenzeit garnicht selbst zu kümmern.

Das Betriebssystem nutzt und verteilt MultCore-CPUs selbst optimal, wenn DU deine Aufgaben einfach per (Multi)Threads & Async-Tasks realisierst:)

[Mavarik]

Zitat:

Zitat von Zwirbel (Beitrag 1345454)

Wie hält man da seine eigene Applikation und auch das restlichen Windows "responsive"?

Ganz einfach: Alles was nicht UI ist in eine Thread packen...

[hstreicher]

20% CPU Last sagt nicht viel ,
da es sich um einen Datenbank Anwendung handelt wäre die Auslastung der Disks viel interessanter
(Windows 10 den Resourcenmonitor über den Taskmanager Seite 2 Leistung unten Aufrufen und dann Datenträger)

und Firebird ist ein eigener Prozess , den kümmert dein Application.Processmessages nicht
wenn dann würde nur durch ein Sleep weniger Daten an die DB versandt werden

mfg Hannes

[Zwirbel]

Zitat:

Zitat von hstreicher (Beitrag 1345461)

20% CPU Last sagt nicht viel ,
da es sich um einen Datenbank Anwendung handelt wäre die Auslastung der Disks viel interessanter
(Windows 10 den Resourcenmonitor über den Taskmanager Seite 2 Leistung unten Aufrufen und dann Datenträger)

Die involvierte Disk ist eine "Samsung SSD 850 Pro 512", der Task-Manager zeigt 100% Auslastung. Ca. 6 MB/s Schreibgeschwindigkeit und <= 1,5 MB/s Lesegeschwindigkeit. Diese Konstellation ist sicherlich nicht das Optimum, ich stecke noch in den Anfangsschuhen mit der Entwicklung mit Firebird. Das mittelfristig ein eigener Firebird-Datenbank-Server her muss ist schon beschlossen. Aber ich will das heraus zögern bis Windows Server 2016 herausgekommen ist, dieses unsagbare Kachelgedöns unter Server 2012 geht mir auf die Nerven. Auf der anderen Seite gibt es Kunden die werden die Firebird-Datenbank nicht auf einem extra Fileserver betreiben sondern als embedded Datenbank auf dem Arbeitsplatzrechner (Notebook) der einzelnen Anwender und da fürchte ich wird man kaum mit einer SSD rechnen können.

Zitat:

Zitat von hstreicher (Beitrag 1345461)

und Firebird ist ein eigener Prozess , den kümmert dein Application.Processmessages nicht

Stimmt, meine Anwendung und Firebird teilen sich die 20% Gesamtauslastung ungefähr hälftig auf.

Zitat:

Zitat von hstreicher (Beitrag 1345461)

wenn dann würde nur durch ein Sleep weniger Daten an die DB versandt werden

Das Komische ist, das sich Thunderbird als Applikation heraus stellt, die während dieses Prozesses am ehesten unresponsive wird. Die Migrationsapp selbst läuft eigentlich flüssig und ihr GUI reagiert gut.

Bliebe später evtl. wirklich als letzter Ausweg, bei langen Berechnungen, Sleeps einzuführen. Naja, bis dahin ist es noch ein weiter weg.

Die Sache in Threads aufzuteilen ist natürlich auch eine Sache die ich mir anschauen werde.

Danke an alle für die Hilfestellungen. Gruß, Markus

[mkinzler]

Zitat:

Bliebe später evtl. wirklich als letzter Ausweg, bei langen Berechnungen, Sleeps einzuführen. Naja, bis dahin ist es noch ein weiter weg.

Besser gleich in Threads auslagern.

[hstreicher]

das folgende ist nur für den Kopiervorgang sinnvoll

in der Datenbank vor dem Kopieren alle Indices deaktivieren

und erst nachdem alle Daten eingefügt sind wieder aktivieren
-

Bitte mal wie vorgeschlagen im Resourcenmonitor(Gibts auch in Windows 7) die Seite mit dem Datenträger öffnen ,
über den Diagrammen steht da ein Wert Warteschlange
das sind die Schreib und Lesevorgänge die noch auf Bearbeitung warten
wenn der Wert dauerhaft deutlich über 1 liegt
dann ist das Plattensystem der Flaschenhals

mfg Hannes

[Zwirbel]

Zitat:

Zitat von hstreicher (Beitrag 1345502)

das folgende ist nur für den Kopiervorgang sinnvoll

in der Datenbank vor dem Kopieren alle Indices deaktivieren

und erst nachdem alle Daten eingefügt sind wieder aktivieren

Davon hatte ich auch schon gelesen, allerdings suche ich noch nach einer Möglichkeit alle Indizes möglichst mit einem Befehl ein- und auszuschalten. Oder ich müsste mein Skript, das die Tabellen aufbaut um die Indizes kürzen und die Indizes erst nach dem Befüllen der Tabellen anlegen.

Zitat:

Zitat von hstreicher (Beitrag 1345502)

Bitte mal wie vorgeschlagen im Resourcenmonitor(Gibts auch in Windows 7) die Seite mit dem Datenträger öffnen, über den Diagrammen steht da ein Wert Warteschlange das sind die Schreib und Lesevorgänge die noch auf Bearbeitung warten wenn der Wert dauerhaft deutlich über 1 liegt dann ist das Plattensystem der Flaschenhals

Da steht "0.05".

[himitsu]

Zitat:

Delphi-Quellcode:

            InsertSQL := Format('INSERT INTO %s (%s) VALUES (%s)', [TableName, InsertFieldNames, InsertFieldValues]);
            qry_FB.SQL.Clear;
            qry_FB.SQL.Add(InsertSQL);
            qry_FB.ExecSQL(InsertSQL);

Und dann sollte Firebird Prepared-Statements kennen.
Also, man verwendet parametrisierte Statements, dann parst FB einmal das SQL-Statement und man übergibt nur noch die neuen Parameter+Execute.
Außerdem kann VALUES auch mehrere Datensätze auf einmal, so muß man nicht für jeden Einzelnen den Tripp zur DB machen.

FireBird kennt auch DB-Bridges, womit es von der DB aus direkt auf eine andere DB zugreifen kann, ohne daß man alles durch ein externes Programm schleußen muß.
http://www.firebirdsql.org/refdocs/l...-execstat.html -> ON EXTERNAL ->www.firebirdfaq.org/faq16/

Zitat:

Speziell geht es um die Frage, wie sorge ich dafür, dass Windows (und alle anderen laufenden Prozesse) in der Zeit nicht lahm gelegt werden oder nur noch zögerlich reagieren?

Mit Threads kann man nur das eigene Programm vom Hängen schützen.
Mit einem Thread kann man aber niemals den Einfluss auf Windows und andere Prozesse beeinflussen, denn von denen aus läuft es bereits in einem "anderem" Thread. :stupid:

[jobo]

Ich schätze mal die 20% sind 13 % Deine Anwendung und 7% Firebird Server.
Auch wenn Du eine schnellere Platte hast wird das nicht viel ändern. Der Vorgang wird nur insgesamt nicht so lange dauern.
Mit Threading würden die CPU Zahlen steigen, sofern die Festplatte mehr Durchsatz hätte oder die Zugriffe effizienter gemacht würden.

Da Du sowieso schon parameterlose Volltext Inserts erzeugst, versuch doch mal, diese blockweise abzusetzen.
Also 1000 Datensätze einlesen, daraus 1000 Insert bauen, die in einem Schwung ausführen.
Damit reduzierst Du vermutlich den gesamten IO deutlich.

Der Vorschlag von Himitsu mit den DB Bridges klingt auch gut.

Was den späteren Betrieb mit einer lokalen DB angeht:
DB verwenden ja gern ihren Cache, um nicht immer wieder alles neu zu lesen. Das funktioniert idR ganz gut. Je mehr Cahce die DB bekommt, desto weniger Plattenzugriffe fallen an.
Andernfalls externe Server nutzen oder
2. Festplatte einsetzen oder
Datenbanktuning oder Anwendungstuning