SQLite 3 Out of Memory

[Monday]

Hallo,

ich möchte den Speicherplatz eine Datenbank verkleinern. Ich nutze dafür "vacuum;" Dieser bricht dann mit der Meldung "Out of Memory" ab.
Die DB ist ca. 1 GB groß. Tatsächlich sollte sie aber kleiner sein, da ich eine große Tabelle gelöscht habe. Nach dem Löschen der Tabelle ist die Datei nicht kleiner geworden.

Offenbar schreibt die DB temporär die DB neu (vacuum). So habe ich es beobachten können. Und zwar in Laufwerk C.

Die Datenbank liegt auf Laufwerk D (mehrere GB frei). Auf Laufwerk C habe ich fast keinen freien Speicherplatz mehr (ein paar Hundert). Sodass ein neuerstellen auf Laufwerk C nicht geht und "Out of Memory" zwangsläufig kommen muss.

Wie kann ich den Speicherplatz trotzdem verkleinern? Also die SQL Datei.

Würde er die DB temporär auf Laufwerk D machen, wäre das kein Problem. Da könnte er das 10 mal machen. Wie kann ich ihn dazu bewegen?

Windows 7
SQlite 3
NTFS


Ursprünglich wollte ich bei einer Tabelle Indizes anlegen. Aber hier meldet er auch Out of Memory. Ob er das über den Arbeitsspeicher macht oder auch über das Laufwerk, konnte ich nicht herausfinden. Arbeitsspeicher habe ich 16 GB, dass sollte eigentlich auch reichen. Daher verstehe ich nciht ganz wo es hängt. Deshalb wollte ich die SQL Datei erstmal verkleinern; Falls Windows, Dateisysten o.ä. Größenbegrenzungen hat?!.
Daher auch hier die Frage, wie kann ich ihn bewegen Indizes anzulegen? Das Laufwerk auf das die DB liegt, dort ist sind noch mehrere GB frei. Wo soll "out of memory" den sein?!


LG
Monday

[Medium]

Meine Erfahrung beruht zwar nicht auf SQLite sondern MariaDB/MySQL bzw. InnoDB insbesondere, aber bei meinen Recherchen zu ähnlichen Problemen hier bin ich auf eine recht "fundamentale Weisheit" gestoßen: Wenn das DBMS keinen Platz mehr hat die größte der betroffenen Tabellen mindestens zu duplizieren, sieht es meistens recht schlecht aus. Das gilt zuweilen sogar wenn man die Voraussicht hatte, die Tabellen zu partitionieren. Viele DBMS scheinen extrem an dem Plattenplatz zu hängen, den sie je zur Verfügung hatten, und geben nur sehr unfreiwillig solchen ans OS zurück.

In meinem Fall hatte ich das Glück, noch Platz für je eine größte Tabelle zu haben. Lösung war dann: Alles, was ich behalten will in eine neue Tabelle kopieren, und dann ganz schnell die alte umbenennen, die neu kopierte zur bisherigen benennen, und letztlich die alte Tabelle zu droppen. Dann erst war InnoDB bereit den Platz freizugeben. Trotz aktivierter in-place "Defragmentierungsoption" bei OPTIMIZE TABLE in den neueren Versionen. In meinem Fall musste das ganze sogar im laufenden Betrieb passieren - die ca. 10min die zum Kopieren verloren gingen waren pro Tabelle aber zum Glück okay in meinem Fall.

Da deine Datenplatte noch genügend Platz zu haben scheint, wäre das ggf. auch für dich eine Möglichkeit. Bei mir waren die (ca. 400) Tabellen die es zu verkleinern galt je ca. 9GB groß (jap, eine knapp 4TB große DB... fragt nicht...), die letztlich kopierte Größe war rund 2GB pro Tabelle. Jeweils 10-15min auf einem RAID 6 von 6 SAS Platten. Könnte also relativ zügig gehen, sogar im laufenden Betrieb.

[pertzschc]

Schau mal hier: https://www.sqlitetutorial.net/sqlite-vacuum/. Insbesondere bei: "VACUUM with an INTO clause". Ich denke, dass hilft in Deinem Fall.

[hoika]

Hallo,
wen auf c kein Platz mehr ist,
setze das Temp-Laufwerk (also %TEMP%) doch auf D.

[Bernhard Geyer]

Wenns wirklich Dateien im Temp-Verzeichnis sind, hilft evtl. dieser Artikel
https://www.sqlite.org/tempfiles.html

[hoika]

Hallo,
OK,
dann würde das Setzen der Umgebungsvariable SQLITE_TMPDIR helfen.

[Bernhard Geyer]

Zitat von hoika:

Hallo,
OK,
dann würde das Setzen der Umgebungsvariable SQLITE_TMPDIR helfen.

Ist besser als das Systemweit umzusetzen.

[Der schöne Günther]

Zitat von Monday:

Arbeitsspeicher habe ich 16 GB, dass sollte eigentlich auch reichen.

Und deine Anwendung ist auch 64 Bit und nicht 32?

[jziersch]

Zitat von Monday:

Die Datenbank liegt auf Laufwerk D (mehrere GB frei). Auf Laufwerk C habe ich fast keinen freien Speicherplatz mehr (ein paar Hundert). Sodass ein neuerstellen auf Laufwerk C nicht geht und "Out of Memory" zwangsläufig kommen muss.

Hast Du probiert bei VACUUM mit INTO die Ziel datei anzugeben?

[Monday]

Hallo

Ich habe jetzt etwas herumgetüfftelt.

Zuerst hatte ich das Windows Temp Verzeichnis geändert. Das war wirkungslos.

Danach habe ich PRAGMA temp_store_directory = 'D:\...'; gesetzt. Auch das blieb wirkungslos.
Ich hatte allerdings dazu einen SQL Editor (SQLStudio) verwendet und auch über die Anwendung versucht. Bei beiden hat er trotzdem vacuum auf Laufwerk C angewendet.

Erst nachdem ich über die SQL Shell gegangen bin hat er das Verzeichnis angenommen!
Dann lief auch Vacuum schön und in aller Kürze durch. Die DB war nach vacuum um 90 % kleiner!
Sollte mal der Festplattenspeicher nicht ausreichen, ist es also denkbar einen USB Stick oder externe Festplatte dran zu hängen und dann über den Festplattenspeicher zu bewerkstelligen. Habe gesehen, man kann auch einstellen dass es rein über den Arbeitsspeicher geht. Wenn die SQL Datei klein genug ist, wäre es sogar denkbar es komplett über den Arbeitsspeicher zu machen. Man muss daran denken, dass er aber immer die komplette Datei laden will.


Da ich schon fast die Hoffnung aufgegeben hatte, wollte ich eine neue DB erstellen. Und die Daten mittels export/import neu erstellen. Mit dem SQLStudio und SQL Administrator lief der export/import schleppend langsam. Mit der SQL Shell lief es rasent schnell durch.
Spontan würde ich sagen, wenn man große DB über 100 MB hat, ist es wohl am schnellsten wenn man immer über die Shell arbeitet.

Eine SQlite Shell GUI wäre noch nice.

Indizes erstellt er offenbar immer über Laufwerk C. Allein über die Shell wenn ich mit PRAGMA temp_store_directory = 'D:\...'; nimmt er das Laufwerk an. Ich hatte gehofft, einmal temp_store_directory zu setzen und dann ist es standartmäßig. Aber das muss ich wohl immer setzen, wenn ich es brauche.


Ich hatte auch in der Doku nachgesehen wo die Grenzen und Limits liegen; Weil ich dachte das es hier limits gibt. Ich habe gesehen SQL kann durchaus mit 3-4 stelligen Terabyte umgehen.

LG
Monday