Irrsinnige SQLite-"Datenbank" in digikam

22/05/2008 - 19:42 von Heinz-Stefan Neumeyer | Report spam
Hallo an alle Mitleser

digikam verwaltet z.Z. bei mir einen Bestand von ganzen 11 Bilder in einer
Gesamtgröße von 875 kb (Kilobite). Die interne Verwaltungsdatenbank im
SQLite3-Format hat dagegen inzwischen die stolze Größe von 11,9 MB
(Megabite) erreicht.
Öffne ich die Datenbank mit einem Tool wie knoda, dann werden mir exakt
die Datensàtze für die 11 Bilder angezeigt - was nach menschlichen
Ermessen einem Speicherplatzbedarf im einstelligen kb-Bereich bedeuten
würde.

Lade ich dagegen die (binàre) Datei

digikam3.db

in einen Editor, dann zeigt die Ausgabe mir in dem ganzen Zeichensalat,
daß offenbar immer noch alle Eintràge für làngst gelöschte Bilder
vorhanden sind.


Frage deshalb:
Wie bekomme ich diese "Datenbank" wieder auf eine dem wirklichen
Bilderbestand entsprechende Größe "geschrumpfte", also diese toten
Eintràge endgültig gelöscht. Und wie kann generell so ein ungezügeltes
Größenwachstum verhindert werden.
Die Datei digikam3.db selbst zu löschen und dann alles neu einzulesen,
wàre natürlich der einfachste Weg!
Aber mich interessiert mehr, wie man ein derart hinrissiges Verhalten von
vorne herein verhindern kann.

digikam ist Vers. 0.8.2 auf Debian 4.0.r3 - aber das dürfte
IMHO eigentlich unerheblich sein.


btw:
Ähnliches hatte ich vor làngerer Zeit auch schon mal mit der
SQLite-Datenbank von amaroK beobachtet. Da hat dann aber die dort
mögliche Nutzung von MySQL dazu geführt, daß ich nicht weiter nach den
Ursachen geforscht habe.

Meine Rechtschreibfehler unterliegen nicht dem Urheberrecht.
Wer sie findet, darf sie weiterverwenden.
 

Lesen sie die antworten

#1 Martin Schmitz
22/05/2008 - 21:25 | Warnen spam
Heinz-Stefan Neumeyer wrote:
Wie bekomme ich diese "Datenbank" wieder auf eine dem wirklichen
Bilderbestand entsprechende Größe "geschrumpfte", also diese toten
Eintràge endgültig gelöscht. Und wie kann generell so ein ungezügeltes
Größenwachstum verhindert werden.
Die Datei digikam3.db selbst zu löschen und dann alles neu einzulesen,
wàre natürlich der einfachste Weg!



Wohl kaum.

Aber mich interessiert mehr, wie man ein derart hinrissiges Verhalten
von vorne herein verhindern kann.



sqlite ist vor allem dazu ausgelegt, schnell und robust zu sein. Das
Verhalten ist alles andere als "hirnrissig".

Wo Du doch schon so viel über das Backend weißt, hàttest Du ja auch auf
die Idee kommen können, daß das eine FAQ ist.

,[ http://sqlite.org/faq.html#q12: ]
|
| (12) I deleted a lot of data but the database file did not get any
| smaller. Is this a bug?
|
| No. When you delete information from an SQLite database, the unused
| disk space is added to an internal "free-list" and is reused the next
| time you insert data. The disk space is not lost. But neither is it
| returned to the operating system.
|
| If you delete a lot of data and want to shrink the database file, run
| the VACUUM command. VACUUM will reconstruct the database from scratch.
| This will leave the database with an empty free-list and a file that
| is minimal in size. Note, however, that the VACUUM can take some time
| to run (around a half second per megabyte on the Linux box where
| SQLite is developed) and it can use up to twice as much temporary disk
| space as the original file while it is running.
|
| As of SQLite version 3.1, an alternative to using the VACUUM command
| is auto-vacuum mode, enabled using the auto_vacuum pragma.
'...

Martin

Ähnliche fragen