TAdoTable.Open() sprengt Arbeitsspeicherlimit

**AxelO**

Hallo,

ich habe als Quereinsteiger ein großes altes Delphi-Programm übernommen, das über ADO auf Datenbanken aus je ca. 15 Tabellen zugreift. Ursprünglich war dieses Programm nur für Access-DBs gedacht, seit einigen Jahren kann es aber auch SQL Server. Die Tabellenstrukturen sind auf beiden Seiten identisch.

Im Moment habe ich folgende Situation:

• Ein Kunde möchte aus vielen kleinen Access-DBs einen einzigen großen Datenbestand auf einem SQL Server zusammenkopieren, der in einem Remote-Netzwerk "steht".
• Das Umkopieren erfolgt in einem historisch gewachsenen Mix aus Delphi/DB-API-Zugriffen und SQL-Befehlen. Das ist ein Legacy-Code, den ich bisher nur unvollständig durchschaue.

Der Showstopper ist nun folgender:

• Durch das Zusammenkopieren haben die Tabellen auf dem SQL Server inzwischen derart viele Datensätze, dass allein schon das Öffnen mit TAdoTable.Open() seehr lange dauert und bei einer bestimmten Tabelle sogar mit der Meldung „Zuwenig Arbeitsspeicher“ abbricht.
• Der PC selbst hat genug Arbeitsspeicher, es wird einfach die Obergrenze von 4 GB für 32-bit-Programme überschritten.
• Ich habe schon versucht, den Cursor der Server-Datenbank von client- auf serverseitig umzustellen (clUseServer). Dieser Modus wird von dem DB-Provider auch nicht zurückgesetzt, wenn ich das Open() ausführe. Demnach habe ich also eine gültige Kombination aus Cursorlocation und Cursortype gewählt.
• Aber auch mit dem serverseitigen Cursor wird erstmal ca. 15 Minuten lang versucht, die gesamte Tabelle ins RAM zu laden, und endet ebenfalls in diesem Abbruch wegen zuwenig Arbeitsspeicher.

Jetzt meine Fragen:

• Ich hatte es so verstanden, dass mit einem „serverseitigen Cursor“ das Open() nicht mehr versucht, die ganze Tabelle auf den lokalen PC runterzuladen. Tut es aber

. Mache ich was falsch? Muss ich eventuell noch mehr umstellen? Irgendwas an der Connection? Oder braucht man doch einen dynamischen Cursor, statt "Keyset"?
• Kann man das Open() noch irgendwie beschleunigen?
• Was ist mit dieser neuen Schnittstelle, FireDAC? Macht die das grundlegend anders?
• Eine Umstrukturierung der DB, kommt m.E. nicht in Frage, da dazu Hunderte von uralten Stellen angefasst werden müssten. Selbst wenn, würde es m.E. nur das Speicherproblem lösen, aber nicht das Geschwindigkeitsproblem.
• Gleiches gilt m.E. für eine Umstellung auf 64 bit.

Gruß
Axel

**dummzeuch**

Bist Du sicher, dass das Programm die zur Verfügung stehenden 4 GB auch nutzt? Dafür muss im PE-Header das Large Address Aware Flag gesetzt sein, sonst nutzt es nur 2 GB.

Falls es nicht gesetzt ist, reicht es vielleicht ja schon, es zu setzen, um das akute Problem zu beheben?

**Uwe Raabe**

Zitat von AxelO:

• Was ist mit dieser neuen Schnittstelle, FireDAC? Macht die das grundlegend anders?

Ein simpler Test mit einer TFDTable/TFDQuery Komponente für die betreffende Tabelle mit dem Speicherproblem sollte leicht zu bewerkstelligen sein.

Zur Kontrolle solltest du das auch mit einer TADOTable versuchen, nur um auszuschließen, dass andere Code-Sequenzen für das Laden der kompletten Tabelle in den Speicher verantwortlich sind.

**Delphi.Narium**

Statt TADOTable TADOQuery nehmen. Scheint sich (zuweilen) etwas dynamischer zu verhalten.

Benötigst Du tatsächlich alle Daten der Tabelle immer an "einem Stück"?

Was genau wird gemacht? Tabelle lesen und woanders schreiben?

Wenn die Daten nicht an einem Stück benötigt werden, sondern das Kopieren von A nach B auch in mehreren Schritten hintereinander (durchaus in einer Transaktion) erfolgen kann, dann verarbeite die Daten in einer Schleife. Gibt es einen eindeutigen Schlüssel (z. B. ID = 1:n), dann nimm immer ca. 10000 Sätze, also ID von 1 bis 10000, dann ID von 10001 bis 20000, ... Die Menge kannst Du natürlich variieren, indem Du erstmal versuchst herauszufinden, bei wievielen Sätzen der Arbeitsspeicher voll ist. Davon nimmst Du dann (vorsichtshalber) etwa die Hälfte.

Sieht irgendwie nach Gefrickel aus, hat aber in der Vergangenheit schon häufiger für Jahre (mit wachsenden Datenmengen) funktioniert.

**AxelO**

Zitat von dummzeuch:

Bist Du sicher, dass das Programm die zur Verfügung stehenden 4 GB auch nutzt? Dafür muss im PE-Header das Large Address Aware Flag gesetzt sein, sonst nutzt es nur 2 GB.

Falls es nicht gesetzt ist, reicht es vielleicht ja schon, es zu setzen, um das akute Problem zu beheben?

Ja, dieses Flag ist gesetzt (Compilerschalter IMAGE_FILE_LARGE_ADDRESS_AWARE). Ich kann auch im Taskmanager mitverfolgen, dass das Programm weit über 2 GB RAM Speicherverbrauch hinaus läuft. Der Abbruch kommt dann (z.B.) bei 3,3 GB, das variiert auch. (Wobei ich mich schon wundere, warum die Exception dann doch so "früh" kommt, also warum kommt sie nicht tatsächlich erst bei den vollen 4 GB...)

**AxelO**

Zitat von Uwe Raabe:

Zitat von AxelO:

• Was ist mit dieser neuen Schnittstelle, FireDAC? Macht die das grundlegend anders?

Ein simpler Test mit einer TFDTable/TFDQuery Komponente für die betreffende Tabelle mit dem Speicherproblem sollte leicht zu bewerkstelligen sein. [...]

Ja schon klar. Ich wollte mir halt mit einer schnellen Nachfrage die Lernkurve ersparen. Wenn jemand definitiv gesagt hätte, dass FireDAC das auch nicht grundsätzlich anders macht, bräuchte ich erst gar nicht damit anzufangen.

**himitsu**

Wenn irgendwas "zusammenhängenden" Speicher benötigt, dann muß eben auch so ein großer Block aktuell im virtuellen Speicher frei sein.

Im Extremfall kann wird das schon bei durchschnittlich 300 bis 700 MB der Fall sein.

z.B. ein Programm belegt aktull nur 10 MB Arbeitrspeicher,
aber der Speicher ist extrem fragmentiert, also die paar MB sind schön verteilt und auch die DLLs liegen kreuz und quer überall rum,
dann kann es bereits so sein, dass in den möglichen 4GB nichtmal mehr 100 MB zusammengängend frei sind,
also es bereits knallt, obwohl nur 110 MB benötigt würden.

**Uwe Raabe**

Zitat von AxelO:

Wenn jemand definitiv gesagt hätte, dass FireDAC das auch nicht grundsätzlich anders macht, bräuchte ich erst gar nicht damit anzufangen.

Das kann man aber ohne weitere Kenntnisse über den bestehenden Code nicht sagen.

In der Regel ist es kein Problem, mit FireDAC auf Datenbanken mit Millionen von Datensätzen zuzugreifen, auch wenn nicht alle Datensätze in den Hauptspeicher des Client passen würden. Es kommt halt darauf an, wie man es verwendet. Mit den Standardeinstellungen ist das Öffnen einer TFDQuery/TFDTable überhaupt kein Problem, egal wie viele Datensätze es gibt. Ohne die Datenbank allgemein zur Verfügung zustellen bist du aber der einzige hier der das prüfen kann.

Wenn das reine Öffnen in einem Testprogramm sowohl mit FireDAC als auch ADO funktioniert, dann liegt das Problem eh woanders und bedarf einer tieferen Analyse der auslösenden Vorgänge.

**AxelO**

Zitat von Delphi.Narium:

Statt TADOTable TADOQuery nehmen. Scheint sich (zuweilen) etwas dynamischer zu verhalten.

Aha, interessant. Also die ADOTable einfach durch eine ADOQuery mit Abfrage "Select * from..." ersetzen, das ist dann gleichwertig? Die Query kann auch .Edit und .Append?

Zitat:

Benötigst Du tatsächlich alle Daten der Tabelle immer an "einem Stück"?

Denke schon, da in einem Zuge auf a) Vorhandensein und b) Gleichheit der jeweiligen Quelltabellen-Zeile in der Zieltabelle geprüft und dann ggfs. die Zeile entweder eingefügt oder aktualisiert wird. Dazu muss der Vergleich ja immer die Zieltabelle als Ganzes sehen, oder?

Zitat:

Was genau wird gemacht? Tabelle lesen und woanders schreiben?

Mehrere Tabellen aus einer Quell-Datenbank werden mit den entsprechenden Tabellen in einer Ziel-Datenbank abgeglichen. Wenn die Quellzeile in der Zieltabelle nicht vorhanden ist, wird sie eingefügt, ansonsten aktualisiert. Es wird in der Zieltabelle aber nicht gelöscht, also es ist keine vollständige "Synchronisation". Zur Ermittlung der Gleichheit zweier Zeilen dient (wo vorhanden) eine proprietäre UID, ansonsten inhaltlicher Vergleich aller Spalten. Das Einfügen bzw. Aktualisieren erfolgt aber nicht mit SQL-Insert- oder SQL-Update-Befehlen, sondern über die API mit .Append bzw. .Edit. (Geht Append/Edit überhaupt mit einer Query?)

Was ich mir noch an Alternativen überlegt habe, um um das .Open() herumzukommen:

- Aus den Access-DBs auf den SQL Server nicht direkt in die riesigen Originaltabellen kopieren, sondern erstmal in leere Dummy-Zieltabellen mit derselben Struktur, denn dann geht das .Open() ja schnell. Dann ein SQL-MERGE-Kommando absetzen, das jeweils die Dummytabelle in die Originaltabelle ein"merged" (oder Kombination aus INSERT und UPDATE). Dann ist ADO außen vor und der Server macht die Arbeit selbst. Allerdings müsste ich dann die Identitätsprüfung der Zeilen in SQL selbst formulieren, das dürfte auch haarig werden.
- Ginge sowas auch mit Stored Procedures? Nur eine vage Idee.

Zitat:

Wenn die Daten nicht an einem Stück benötigt werden, sondern das Kopieren von A nach B auch in mehreren Schritten hintereinander (durchaus in einer Transaktion) erfolgen kann, dann verarbeite die Daten in einer Schleife. Gibt es einen eindeutigen Schlüssel (z. B. ID = 1:n), dann nimm immer ca. 10000 Sätze, also ID von 1 bis 10000, dann ID von 10001 bis 20000, ...

Auch wenn das funktioniert, bleibt dann immer noch das Performanceproblem...

**mkinzler**

Zitat:

Denke schon, da in einem Zuge auf a) Vorhandensein und b) Gleichheit der jeweiligen Quelltabellen-Zeile in der Zieltabelle geprüft und dann ggfs. die Zeile entweder eingefügt oder aktualisiert wird. Dazu muss der Vergleich ja immer die Zieltabelle als Ganzes sehen, oder?

Hie würde sich eher update or insert oder merge anbieten