Ersatz für SQLite

    SQLite-Manager....

    Meine places.sqlite hat aktuell 61440 KB....die Cookies 512...davon sind geschätzte 480 sicher zu viel...habe leider vergessen vor dem Update nochmals die Sachen zu cleanen...bzw. zu komprimieren.

    Black-Cab993,
    was willst du eigentlich?
    Mit diesem Thread-Titel kann ich bezogen auf die aktuellen Mozillen-Browser nichts anfangen.

    Richtungsweisend sind die Nachfragen in Antwort #1 bzw. #2.

    Wenn du also die SQLITE- Datenbanken des Browserprofils *reorganisieren* und vllt. damit auch in der augenscheinlichen Größe *optimieren* möchtest, dann gibt es Hilfsmittel [1]. Entweder als SQLITE-SW im OS oder mit gewissen Leistungsumfang als Extension!

    Nur für Bookmarks + History ist sicherlich sowas wie Places Maintenance (einmalig) ausreichend. Für alle SQLITE-Datenbanken des Profils sicherlich sowas wie SQLite Manager.

    Die SQLITE- Datenbanken kannst im Interesse eines funktionierenden Browserprofils nicht einem anderen Datenbanksystem ersetzen!

    [1] http://www.sqlite.org/lang.html ff

    Anscheinend bringt das "Eindampfen" mittels vacuum nicht mehr so viel. S. dazu https://www.camp-firefox.de/forum/viewtopi…=776919#p776919

    so hat alles geklappt. beim Update von 3.6 auf 11 hat Firefox den SQLite-Manager als inkompatibel angezeigt.

    aufgrund des Hinweises von MaximaleEleganz habe ich die neue Version 0.7.7 geladen und konnte wie gehabt über ein 2. Profil die Datenbanken im Hauptprofil komprimieren.

    es drängt sich aber der Verdacht auf, dass Firefox feste Werte für die sqlite-dateien vorgibt. so kann ich bestätigen, dass die places.sqlite immer in 10.240er KB-Schritten angepasst wird. nach oben oder nach unten.

    die Cookies beispielsweise werden über SQLite-Manager auf 128 KB komprimiert. sind nach erster Nutzung aber sofort wieder auf 512 KB. denke, dass ist die Mindestgröße?

    die signons.sqlite ist interessanterweise sogar größer geworden...416 KB (vorher irgendwas um 230).

    Die sqlite Dateien sind im Grunde nur Zwischenspeicher. Firefox startet, läd die Inhalte der sqlite-Dateien in den Speicher, ergänzt fehlende oder leere Inhalte mit Standardwerten, arbeitet dann im Speicher und beim Beenden wird das war im Speicher steht, wieder in die sqlite-Dateien gespeichert, egal was dort noch so drin stand. Man kann die Dateien also optimieren und beim nächsten Beenden vom Firefox wird dann doch wieder die interne Formatierung vom Firefox hinterlegt.

    Die places.sqlite wird immer auf 10240 KibiByte angelegt / ausgerichtet, bzw. um 10240 KibiByte erweitert. Das soll den Benutzer erfreuen, denn dann sind die Teile der places.sqlite nicht in kleinen Sektoren auf der Platte verstreut gelagert.

    Das Gerücht, der Fx würde seine Daten erst beim Beenden speichern hält sich zwar hartnäckig, ist aber falsch.
    Die Daten werden sofort nach dem Anfall geschrieben. Man kann dabei zusehen, wenn man parallel zum Fx einen geeigneten Dateimanager aufgerufen hat.

    Obgleich es sich bei der places.sqlite aus Sicht des OS um eine Datei handelt, ist es real eine Datenbank. Es werden immer nur die Zeilen der Tabellen geschrieben, die sich einer Änderung erfreuten. Andere Areale werden nicht verändert.

    Zitat von .Hermes

    Das Gerücht, der Fx würde seine Daten erst beim Beenden speichern hält sich zwar hartnäckig, ist aber falsch.

    Dann beobachte den Firefox mal beim Beenden im Taskmanager deiner Wahl...

    Zitat von Boersenfeger

    Dann beobachte den Firefox mal beim Beenden im Taskmanager deiner Wahl...

    Welch wertvolle und auch eventuell neue Erkenntnis soll man nun deinem Beitrag entnehmen ?

    Du hast es mal durchgeführt? Dann wird dir aufgefallen sein, das die firefox.exe und ggf. die plugin-container.exe erst nach einer gewissen Zeit verschwinden. In dieser Zeit werden diverse Dateien im Firefox zurückgeschrieben oder beendet. Noch genauer kannst du dies beobachten, wenn du den Ordner des benutzten Profils beim Beenden geöffnet hast.
    BTW: Woher beziehst du eigentlich deine Behauptung?

    Dummerweise ist seine Aussage korrekt. Müsst also nicht auf ihm rumtrampeln. ; )

    Ich hab das aus Gründen der einfacheren Darstellung absichtlich unterschlagen. Würde Firefox nicht ständig zwischendurch die Änderungen auf der Platte, sprich in den sqlite-Dateien, ablegen, würde bei einem Absturz oder Ähnlichem alle Änderungen verloren gehen. Spätestens bei der Tab-Recovery nach einem Crash sollte klar sein, dass dem nicht so ist.

    Das ändert allerdings nicht daran, dass das Datanbankabbild im Speicher das relevante Abbild ist. Und das landet am Ende gedumpt in den sqlite-Dateien. Darum soll man auch nicht im laufenden Betrieb die Dateien mit externen Programmen bearbeiten. Im Zweifel werden die Änderungen beim Beenden von Firefox wieder mit den Daten im Speicher überschrieben.

    Das die Dateien Standardgrößen haben, hat auch viele Vorteile. Was nicht "komprimiert" ist, muss nicht erst entpackt werden. Raw-Files (also rohe Dateien), sind immer schneller zu öffnen und zu lesen, als welche die über entsprechende Verfahren "optimiert" wurden. Denn am Ende muss eh alles wieder in ein Raw-Format in den Speicher geladen werden. Die Konvertierungsvorgänge sind mit unter recht leistungsintensiv und kosten Zeit. Und wenn man schnell sein will (Browserstart) ist das eher hinderlich. Genauso ist das mit Fragmentierung der Datei auf dem physischen Datenträger. Einziger wirkliche Nachteil dieser Methode ist der Verlust von Festplattenkapazität. Aber 10-20 MB sollten in Zeiten von Terabyte-Platten jetzt niemanden umbringen...

    Danke für die Darstellung..
    Für mich: Meine Beobachtungen sind also nicht korrekt? Was passiert dann beim Beenden im Profilordner
    BTW: Ich trampele nicht, nur mag ich diese Art und Weise nicht... da reicht mir schon einer hier im Forum...

    Soweit ich das weiß, werden die sqlite-Dateien nicht bei jeder kleinen Änderung direkt bei dem Vorgang der Änderung angepasst. Manches geschieht periodisch. Ich kann dir aber nicht aufschlüsseln, welche Datei in welchem Intervall oder nach welchem Rhythmus/Logik gehandhabt wird. Damit hab ich mich damit zu wenig beschäftigt. Aber das folgt ähnlichen Ansätzen wie Sync. Das speichert auch nicht alles immer direkt.

    Und natürlich ist deine Beobachtung richtig. Speziell beim Beenden wird dann nochmal alles (sicher ist sicher!) komplett in die Dateien überführt. Komplettes Speichern ist natürlich ein größerer und damit länger dauernder Prozess, warum die exe auch noch was länger im Hintergrund verweilt (und je größer/mehr Informationen verarbeitet werden, desto länger dauerts. Beim Start natürlich das selbe). Kleinere Änderungen im Betrieb sind dabei selten auffällig.

    Beide Beobachtungen/Darstellungen schießen sich also nicht aus sondern ergänzen sich quasi. ; )