Abfrage von großen Datenmengen

[stahli]

Ich kann mir das Projekt gerade nicht ansehen, aber vielleicht gibt es ein Memoryleak o.ä. (dass z.B. dynamisch immer neue Verbindungen hinzugefügt werden oder so)?

EDIT @Christian:
Bist Du auf MySQL festgelegt? Sonst teste doch mal Firebird...

[Sir Rufo]

Diese redundaten (Adress-) Daten in der Buchungen Tabelle sind ja nun auch nicht wirklich hilfreich und haben in der Tabelle "buchungen" eigentlich nichts verloren.

Die Adressinformationen gehören in eine Belegtabelle und die Referenz auf den Beleg gehört in die Buchungstabelle.

Ich würde hier einfach mal ordentlich normalisieren und dann wieder zu diesem Problem zurückkommen - wahrscheinlich hat sich dieses Problem dann schon erledigt.

Alle Spalten als varchar(500) ist auch nicht gerade kreativ ...

[Sir Rufo]

da kommt mir doch ein Gedanke wegen der Größe ...

73 Felder mit VARCHAR(500)

Wenn die Datenbankkomponente jetzt die Felder in maximaler Größe und als Unicode in den Speicher holt dann sind das bei 20000 Zeilen:

Code:

73 {Felder} * 500 {CHAR} * 2 {Unicode} * 20000 {Zeilen} = 1460000000 Bytes
1,360GB

[Uwe Raabe]

Zitat von p80286:

Zitat von Uwe Raabe:

...verwendest lediglich ein TSQLDataSet (das ist unidirektional und somit nicht in einem Grid darstellbar).

Warum sollte man es nicht in einem TStringgrid darstellen können?

Gemeint war natürlich ein TDBGrid! Das kann mit unidirektionalen DataSets nichts anfangen.

Zitat von Bernhard Geyer:

Zitat von Uwe Raabe:

Das Simple-/ClientDataSet lädt stndardmäßig das komplette Abfrageergebnis in den Hauptspeicher und da knallt es natürlich ab einer gewissen Menge.

Bei MySQL ist das egal da es hier keine serverseitigen Curser gibt.

Das hat damit nichts zu tun. Das ClientDataSet schickt eine Anfrage an den DataSetProvider, der diese wiederum an das SQLDataSet weitergibt. Dieses liefert eine Ergebnismenge, die der DataSetProvider an das ClientDataSet weitergibt. Intern wird dabei das MyBase-Format (Midas) zum Transport verwendet, bei dem die gesamte Datenmenge im Hauptspeicher vorliegt.

Zitat von Bernhard Geyer:

20.000 Datensätze sollten aber (wenn keine größeren Blobs) beteiligt sind selbst in einem 32-Bit Prozess noch keine Probleme darstellen.

Prinzipiell ist das richtig, aber wenn so mit den Feldgrößen geast wird. Wie Sir Rufo treffend bemerkt, hat die Buchungstabelle 73 Felder vom Typ VarChar(500). Das sind selbst bei AnsiChar ca. 37000 Byte pro Record. Bei 20000 Records kommen wir da schon auf fast 750MB. Wenn die intern beim Transport auch nur einmal by-value kopiert oder in einen Memorystream geschrieben wird, sind wir schon bei 1,5 GB.

[Bernhard Geyer]

Zitat von Uwe Raabe:

Prinzipiell ist das richtig, aber wenn so mit den Feldgrößen geast wird. Wie Sir Rufo treffend bemerkt, hat die Buchungstabelle 73 Felder vom Typ VarChar(500). Das sind selbst bei AnsiChar ca. 37000 Byte pro Record. Bei 20000 Records kommen wir da schon auf fast 750MB. Wenn die intern beim Transport auch nur einmal by-value kopiert oder in einen Memorystream geschrieben wird, sind wir schon bei 1,5 GB.

Das wollte ich auch schon ausrechnen.
Seine Testdaten zeigen aber keine annähernde füllung dieser jeweils 500 Byte (Backup ist insgesamt ca. 500 MB groß) so das ich denke das diese 20.000 Datensätze kein 1,5 GB (wenn keine Fehler vorhanden sind) füllen würden.

[p80286]

Es soll ja auch schon vorgekommen sein das varchar500 als 500 Blanks über die Leitung gehen, intern aber wirklich nur ein Blank groß sind.

Vielleicht hilft da der Debugger weiter?

Gruß
K-H

[stahli]

Es kann natürlich sein, dass die Datenbank (File) leere Einträge packt, der Treiber die DataSet-VarChar-Felder aber immer mit Leerzeichen auffüllt bzw. einfach maximal viel Speicherplatz reserviert.

[dARKeAGLE]

Zitat von stahli:

Ich kann mir das Projekt gerade nicht ansehen, aber vielleicht gibt es ein Memoryleak o.ä. (dass z.B. dynamisch immer neue Verbindungen hinzugefügt werden oder so)?

EDIT @Christian:
Bist Du auf MySQL festgelegt? Sonst teste doch mal Firebird...

Nein auf MySQL bin ich nicht festgelegt. Habe auch die Treiber für Oracle und MSSQL.
Der eigentliche Fehler in der Produktivanwendung war auf Oracle, da sind des sogar 250 000 Datensätze.

Zitat von Sir Rufo:

da kommt mir doch ein Gedanke wegen der Größe ...
73 Felder mit VARCHAR(500)

Wenn die Datenbankkomponente jetzt die Felder in maximaler Größe und als Unicode in den Speicher holt dann sind das bei 20000 Zeilen:

Code:

73 {Felder} * 500 {CHAR} * 2 {Unicode} * 20000 {Zeilen} = 1460000000 Bytes
1,360GB

Die Größe der Felder mit VARCHAR(500) wurde frei gewählt, und ich sehe es nun auch ein, dass es totaler Blödsinn war.
Ich hoffe, man möge es mir verzeihen.

Zitat von Sir Rufo:

Diese redundaten (Adress-) Daten in der Buchungen Tabelle sind ja nun auch nicht wirklich hilfreich und haben in der Tabelle "buchungen" eigentlich nichts verloren.

Die Adressinformationen gehören in eine Belegtabelle und die Referenz auf den Beleg gehört in die Buchungstabelle.

Ich würde hier einfach mal ordentlich normalisieren und dann wieder zu diesem Problem zurückkommen - wahrscheinlich hat sich dieses Problem dann schon erledigt.

Alle Spalten als varchar(500) ist auch nicht gerade kreativ ...

Natürlich sollen die Daten nichts representieren, sondern nur für die Fülle von Daten stehen.



Gibt es bei einer TSQLQuery die Möglichkeit eine Master-Detail-Beziehung aufzubauen (Kann es leider nicht nachprüfen, da ich nur im Unternehmen eine Delphi-Version habe)?

Das mit dem Debugger werde ich gleich mal morgen ausprobieren.

Viele Grüße

[p80286]

Zitat von dARKeAGLE:

Der eigentliche Fehler in der Produktivanwendung war auf Oracle, da sind des sogar 250 000 Datensätze.

Da kann die Datenbank eigentlich nichts für.

vielleicht solltest Du mal ganz von Anfang an erzählen, um was es geht. Mir scheint hier wird nur an den Symptomen herum gemacht.
(nicht pers. gemeint)

Gruß
K-H

[dARKeAGLE]

Ist OK. Also es war einmal .... ne nur Spaß.


Es gibt zwei Anwendungen. Die Eine, ein ERP-System (Java), bereitet Daten für ein Report-Template auf. Anschließend wird die zweite Anwendung gestartet. Diese Anwendung ladet die Daten und erstellt ein PDF aus den Daten mit Hilfe des Templates. Aktuelle gibt es ca. 90 verschiedene Templates mit ca. 40 verschiedenen SQL-Abfragen. Von diesen Abfragen werden je nach Template 2-3 Abfragen benötigt. Ja, manche Templates haben das selbe Abfrage.


Da das Laden der SQL-Abfrage und das Zusammenbauen der Master-Detail-Beziehungen dynamisch geschieht, sollte es halt eine einheitliche Lösung sein.


Nun zum Problem:

Aktuell soll ein Report generiert werden, welcher im Detail ca. 250 000 Datensätze besitzt. Hierbei kommt es zur der Exception, dass nicht genügend Speicher vorhanden ist, also die Exception auf dem dieser Thread basiert. Die Datenbank an dem der Fehler auftrat war Oracle. Da ich den Fehler "schnell" reproduzieren wollte, habe ich kurzer Hand ein paar Testdaten geniert. Dadurch auch die Problematik mit Felder VARCHAR(500). Sollte quick'n'dirty sein.

Die Anzahl der Spalten im Produktivsystem liegen so bei 50 Stück mit unterschiedlichen Datentyp.


Da ich den Reportbuilder von Digital Methaphors verwende benötige ich ein Dataset (siehe http://www.digital-metaphors.com:8080/Data_Access).


Vielleicht gibt es auch eine andere Lösung, solange es meine Master-Detail-Beziehung nicht gefährdet.

Hoffe ich habe alles erklärt und auch verständliche erklärt.
Falls noch einige Einzelheiten fehlen werde ich diese gerne nachreichen.


Vielen Dank im Voraus.

Viele Grüße

Christian