[German] Optimierung der Datenbank dauert sehr lange

[Viscus]

Nachdem ich bei sehr vielen Bildern eine Anpassung der Zeitstempel gemacht habe, wollte ich wieder mal die Datenbankoptimierung durchlaufen lassen. Die letzte Optimierung dauerte knapp vier Stunden.
Beim ersten Versuch führte es dazu, dass Imatch mehr als 24h Stunden lief und dann zwar ca 11% CPU brauchte, der Memorverbrauch sehr tief war und kein Disk IO mehr im Taskmanager sichtbar war.
In der Zwischenzeit habe ich verschiedene Versuche unternommen unter anderem die ganze DB aus einem Backup vom Februar genommen, diese gepackt, entpackt und dann nochmals neu das Packen gestartet und diesmal wieder den Haken für die Optimierung angewählt. Gestartet habe ich gestern Nacht und der letzte Zeitstempel in den Logs ist von 4 Uhr. Der Prozess von Pack and Go ist immer noch am Laufen und braucht aktuell wieder ca 11% CPU Last, der Speicherverbrauch liegt bei 30.4MB und Disk IO ist mal sporadisch 0.1% zu sehen.
Die DB selber liegt bei 50 Gigabyte.
Diese schaut für mich soweit in Ordnung aus. Gibt es da noch irgend eine Möglichkeit, den Indexprozess durchlaufen zu lassen, oder was würde allenfalls helfen?
Ich bin mir bewusst, dass ich sehr viele Bilddaten in der Zwischenzeit aktiv drin habe.

Hier noch die letzten Einträge aus dem Diag Log. Das ist ungezippt zu gross
Checking Visual Query Data:
      Data items:  2'742'280
Completed.

Checking Favorites:
Completed.

Checking photools.com metadata:
    Result: 0 files with missing data updated.

Checking photools.com metadata tags for consistency:
Completed.

Trimming Tag Data:
Completed. Nothing to do.
    Clearing oid cache.

Analyzing database:

Optimizing Database, rebuilding optimial index structures and query plans:

[Mario]

Die Datenbank hat knapp 700,000 Dateien.
Bei meiner 900,000 Dateien Datenbank dauert die Optimierung weniger als 40 Minuten und die Diagnose weniger als 10 Minuten!
Datebank auf einer m2 SSD.

Hast Du im Virenchecker eine Ausnahme für das Datenbankverzeichnis eingetragen?

[Viscus]

Hast Du im Virenchecker eine Ausnahme für das Datenbankverzeichnis eingetragen?

Eine gute Frage. Prüfe ich. Ob der allenfalls da noch reingrätscht.

[Viscus]

Leider habe ich wieder die gleiche Situation

Start:
03.06 20:53:47+382953 [13F8] 00  I> # Logfile opened.
und dann
03.06 21:11:39+    0 [5C34] 00  M>           > 10 CIMEngine5Diagnosis::Analyze  'V:\develop\IMatch5\src\IMEngine\IMEngine5Diagnosis.cpp(2781)'
03.07 00:12:10+10831203 [5C34] 10  I>           Integríty Check completed
03.07 00:12:10+    0 [5C34] 10  I>                   Begin ANA

Würde es etwas bringen, alle Metadaten der Bilder zu löschen und alles neu einzulesen?

[sinus]

Die Datenbank hat knapp 700,000 Dateien.
Bei meiner 900,000 Dateien Datenbank dauert die Optimierung weniger als 40 Minuten und die Diagnose weniger als 10 Minuten!
Datebank auf einer m2 SSD.

Hast Du im Virenchecker eine Ausnahme für das Datenbankverzeichnis eingetragen?

Hmm, bei mir mit meinen rund 345'000 Dateien braucht die Diagnose immer rund doppelt so viel Zeit wie die Optimierung, bei Dir scheint es genau umgekehrt zu sein.
Compact and Optimize braucht bei mir rund 12 Minuten, die Diagnose 25 Minuten.

[Mario]

Würde es etwas bringen, alle Metadaten der Bilder zu löschen und alles neu einzulesen?

Nein.
Die Optimierung ist der langsame Teil. Hierbei kopiert das Datenbanksystem die ganze Datenbank und entfernt alle nicht mehr benötigten Blöcke, optimiert die Indizes usw.
Auf welcher Art von Datenträger (E:) ist die Datenbank gespeichert?
Wie lange dauert die Diagnose, wenn Du beim drücken auf OK im Dialog die STRG-Taste gedrückt hälst (das überspringt die Optimierung am Ende)?

Der Schritt CheckGroups (Kategorien prüfen) braucht über 10 Minuten, bei nur knapp 4,000 Kategorien.
Ich sehe auch einige Meldungen des Datenbanksystems über langsame Transaktionen. Das bedeutet normalerweise, das der Datenträger nicht "mitkommt".

[Viscus]

Ich habe es nun auf die andere Sata Disk rübergenommen. Die bringt ca 10MB/s

IMatch database diagnosis logfile created: 07.03.2022 23:08:13

Application Info:
    Version:                      21.14.0.4
    Filename:                     C:\Program Files\photools.com\imatch6\IMatch2021x64.exe

General Database Info:
    Database file name:           F:\Imatch-DB\IMatch Datenbank.imd5
    Database file size on disk:   48.80 GB
    Number of folders:            17'382
    Number of files:              688'693
    Number of categories:         3'040
    Clearing oid cache.

IMatch database diagnosis logfile closed: 07.03.2022 23:18:00 (00:09.47)

Mal schauen, was das Reorganisieren macht.

[Viscus]

Leider erfolglos. Irgendwann im Verarbeiten stoppt die Verarbeitung auf der Disk. Gemäss Process Explorer sind die Prozesse aktiv, aber es finden keine Zugriffe mehr auf die DB statt.

Ich habe Sata Platten drin. Meinte mit 5400 Umdrehungen. Komisch ist nur, dass mit etwas weniger Datensätzen der Reorgprozess noch durchlief. Also müsste in der DB eine Stelle sein, die den Prozess zum Aufhängen bringt, der mit dem Check nicht gefunden wird.

[sinus]

...

Ich habe Sata Platten drin. Meinte mit 5400 Umdrehungen. Komisch ist nur, dass mit etwas weniger Datensätzen der Reorgprozess noch durchlief. Also müsste in der DB eine Stelle sein, die den Prozess zum Aufhängen bringt, der mit dem Check nicht gefunden wird.

Und  Du kannst nicht mehr eruieren, welche Dateien Du in der letzten Zeit dazugefügt hast?
Oder einen Backup-Datensatz mit weniger Dateien, so dass Du rausfinden könntest, ab wann das nicht mehr ging?

So grob habe ich ja die Hälfte der Dateien wie Du sie hast. Aber mein Optimierungsprozess dauert rund 12 Minuten, mal eine Minute weniger oder mehr.
OK, ich habe SSD-Disks, trotzdem dürfte es nicht so lange dauern wie bei Dir. Nicht annähernd.

[Viscus]

Und  Du kannst nicht mehr eruieren, welche Dateien Du in der letzten Zeit dazugefügt hast?
Oder einen Backup-Datensatz mit weniger Dateien, so dass Du rausfinden könntest, ab wann das nicht mehr ging?

So grob habe ich ja die Hälfte der Dateien wie Du sie hast. Aber mein Optimierungsprozess dauert rund 12 Minuten, mal eine Minute weniger oder mehr.
OK, ich habe SSD-Disks, trotzdem dürfte es nicht so lange dauern wie bei Dir. Nicht annähernd.

Das ist eine leicht ältere Version. Aber nicht mehr weiter zurück leider :-(. Ich habe in diesem Zeitraum nur gewisse DNG noch dazugefügt, da ich bei einigen älteren Bildern bemerkt habe, dass der Zeitstempel bei den .thm Files (Canon RAW EOS10) nicht mehr stimmte, weil ich die Synchronisierung der Daten falsch aufgehängt hatte. Und war die Werte am Korrigieren in dem ich die Werte aus einem anderen Datumsfeld umkopierte. Es waren in der DB viele Transaktionen die da liefen.
Gibt es keine Möglichkeit die Felder mit den Exif, XMP etc Daten zu löschen und diese basierend auf den Bilddaten neu einzulesen?
Also eine leere Datenbank, die zwar die Verweise auf die Verzeichnisse hat, aber sonst alles leer ist um dann den Index neu aufzubauen?
Die Daten habe ich immer auf die Bilder runtergeschrieben, so dass in der DB nicht mehr Informationen sind, als ich sowieso in den Metadaten der Bilder habe.

[Mario]

Die Diagnose dauert nun knapp 10 Minuten.
Das ist ziemlich normal für eine Datenbank mit 700,000 Dateien.

[Viscus]

Ich bin jetzt etwas weiter. Nachdem ich einiges an den Jahresverzeichnissen aus der DB gelöscht habe konnte ich das Reindexing durchführen und es lief durch.
Ich habe vorher noch Files gehabt, die nicht runterschrieben waren, wobei diese Bilder in den betroffenen Jahren (2005) war. Jetzt schaue ich nochmals mit der vollen DB und sonst probiere ich mal einzelne Jahre zu löschen bei denen ich in den letzten Wochen aktiv viele Daten bearbeitet habe. Ob allenfalls dort irgendwo Metadaten vorhanden waren, die das Reindexing zum stolpern brachten.


IMatch database diagnosis logfile created: 09.03.2022 01:16:49

Application Info:
    Version:                      21.14.0.4
    Filename:                     C:\Program Files\photools.com\imatch6\IMatch2021x64.exe

General Database Info:
    Database file name:           E:\Imatch-DB\imatch5\IMatch Datenbank.imd5
    Database file size on disk:   48.78 GB
    Number of folders:            10'452
    Number of files:              449'879
    Number of categories:         2'694
    Clearing oid cache.

-----
Optimizing Database, rebuilding optimial index structures and query plans:
Completed in 4387s with 4856159 counts.

WriteTest:
Completed.

Results:
    Errors:    0
    Warnings:  0

IMatch database diagnosis logfile closed: 09.03.2022 02:41:32 (01:24.43)

[Mario]

1 Stunde und 13 Minuten für das Optimieren der Datenbank?
Das ist im Prinzip nur ein Kopieren der Datenbank mit Weglassen von nicht mehr benötigten Inhalten.
Also 50 GB kopieren. Warum dauerst dass auf E: so lange? Ist das eine SSD? Normale Platte? Externe Platte?
Virenchecker geprüft?

[Viscus]

Bin heute dran am genauer Schauen.

Schritt 1 war von E auf D eine Kopie ins Temp Verzeichnis und jetzt läuft ein Prozess und die IMatch Datenbank.imd5-shm wächst an. Dies aber nur sehr langsam. Am Disk-IO kann es nicht liegen. Diese ist nicht ausgelastet. Sind max. 20-30% also 15MB/s bis 20MB/s. Hingegen ist die CPU gut ausgelastet. Und AV habe ich jetzt testhalber deaktiviert, aber das hat aber keine Auswirkung auf die Geschwindigkeit.
Interessanterweise wird sowohl von D: als auch aus dem E: gelesen.

Mal schauen, wie lange das jetzt geht bis alles durch ist.

[Mario]

Die IMatch-Datenbank sollte immer auf dem schnellsten Datenträger (SSD!) liegen.

[Viscus]

Wird schwierig. Da ist meine SATA Disk aktuell zu klein  . Die waren zum damaligen Zeitpunkt als ich den PC baute, noch einiges teurer.
So lange noch ein Prozess läuft und Aktivitäten vorhanden sind ist ja alles gut. Nur war es ja so, dass irgendwann einfach kein IO mehr vorhanden war. Also entweder was verklemmt in der DB (noch vorhandene Schreibaktivitäten wegen Datumsfelder, die dann Probleme machen?).
Aber zumindest kriege ich es irgendwie hoffentlich mal hin.

[Mario]

Eine normale Fesplatte kann bis zu 100 x langsamer sein als eine SSD.
Eine 512 GB SSD kostet weniger als 50€...

[Viscus]

Habe den Hinweis verstanden :-). Mein Anbieter des Vertrauens hatte gerade lustigerweise eine Aktion am Laufen. 2 TB Disk ist bestellt.
Aber trotzdem. Es erklärt nicht, wieso am Schluss des gesamten Kopierprozess, der Abschluss nicht mehr stattfindet. Denn die Tempdatei wurde gelöscht, aber die erstellte -shm und -wal Datei blieb bestehen. Der Zeitstempel bei der .imd5 Datei wurde dann noch geändert. Diesen Screenshot habe ich nicht mehr.
Auf dem Processexplorer sah ich auch keine aktiven Schreib-/Leseprozesse mehr. Abgesehen von der sehr langen Zeitdauer, die alles braucht, ist da noch was anderes was Probleme macht. Ich lösche jetzt mal das Verzeichnis in dem ich zuletzt die letzten massiven Anpassungen an den Files machte. Möglicherweise machen irgendwelche Daten in der DB hier Probleme?
Leider gibt es keine Logdaten, die da einen Hinweis auf Probleme geben.

[Viscus]

Ich habe nun ein Jahr (2005) aus der DB gelöscht und dann das Reindexing nochmals gestartet. Und siehe da es lief durch. Also müssen wohl irgendwelche Daten da den Prozess ins Stolpern gebracht haben. Ich habe wie erwähnt für 2004 und 2005 Korrekturen bei den Datumsfeldern machen müssen, da ich in den .thm Daten vor sehr langer Zeit mal fälschlicherweise diese Werte überschrieben habe. (Kopie von CRW nach THM, anstatt das Masterfile .thm und dann Kopie auf .CRW und .JPG.). Date Created war mit 0er Werten vorhanden und ich kopiere diese von Date Digitized.
Ich lese jetzt den ganzen Ordner neu ein und schaue dann ob die Probleme noch weiterhin auftreten.

[Viscus]

Ich habe nun eine neue SSD gekauft und das Profilverzeichnis und die DB nun da drauf. Heute Abend habe ich wieder die Datenbankdiagnose durchlaufen lassen (die geht jetzt viel schneller) und die Optimierung ist nun angelaufen. Mir ist aber jetzt mit dem Process Explorer aufgefallen, dass Imatch in einer Endlosschleife beim Auslesen der Verzeichnisse ist. Sobald die zuletzt eingelesenen Verzeichnisse durch sind, fängt die Geschichte wieder von Vorne an.

Das wird wohl ewig so laufen, wenn ich es nicht abbrechen würde.

Das noch zur Info wegen Durchlaufzeit

IMatch database diagnosis logfile created: 14.03.2022 21:41:03

Application Info:
    Version:                      21.14.0.4
    Filename:                     C:\Program Files\photools.com\imatch6\IMatch2021x64.exe

General Database Info:
    Database file name:           C:\_Imatch-DB\imatch5\IMatch Datenbank.imd5
    Database file size on disk:   49.35 GB
    Number of folders:            17'383
    Number of files:              688'725
    Number of categories:         3'040
    Clearing oid cache.


----


Analyzing database:

Optimizing Database, rebuilding optimial index structures and query plans:
Completed in 10429s with 1463559396932 counts.

Results:
    Errors:    0
    Warnings:  0
Database diagnosis aborted by user!
IMatch database diagnosis logfile closed: 15.03.2022 00:37:30 (02:56.27)

[Viscus]

Nachtrag. Ich kann mir nur erklären, dass irgendwo in den Bilddaten Zeitstempel drin sind, die nicht sauber geschrieben sind und da die DB ins Stolpern bringen. Die Probleme begannen wieder als ich die letzten zwei Quartale eingelesen habe.

[thrinn]

Hast du eventuell File Relations mit Propagation definiert? Du hast im Verlauf dieses Topics ja etwas davon erwähnt, dass du Zeitstempel zwischen THM/CRW/JPG hin- und herkopiert hast. Nicht, dass es durch eine dieser Regeln beim Einlesen zu einer Art Endlosschleife kommt.

Mir ist allerdings auch nicht ganz klar, ob es hauptsächlich um die DB-Optimierung / -Diagnose geht (dabei werden aber keine Ordner oder Dateien neu eingelesen) oder um das Einlesen/Neu-Einlesen ganzer Ordner. Im letzten Fall würde ich einmal probieren, eventuelle File Relations zu deaktivieren und auch besonderes Augenmerk darauf richten, ob du die Option für Immediate Writeback aktiviert hast.

(Sorry für die Mischung aus Deutsch und Englisch, aber ich habe IMatch immer mit englischer Oberfläche laufen und nur die englischen Bezeichnungen im Kopf. Andererseits ist DEnglisch ja modern...).

[Mario]

Die Optimierung ist ein Datenbabnk-interner Prozess. Das Datenbanksystem kopiert hierbei die Datenbank in eine neue Datei um, entfernt dabei nicht mehr benötigter Daten, baut die Inizes neu auf usw.
Dabei wird nicht auf Verzeichnisse zugegriffen. IMatch ruft den Befehl auf und wartet dann, bis das Datenbanksystem fertig ist. Das Datenbanksystem weiß nichts über Verzeichnisse.

IMatch prüft Verzeichnisse auf Ihre Existenz beim Laden der Datenbank und wenn Windows Veränderungen meldet. Das passiert automatisch und im Hintergrund.

Hänge bitte immer die ganze Diagnoseprotokolldatei an (zippen). Auszüge sind nicht

Welchen Virenchecker nutzt Du?
Auf welcher Platte liegt das TEMP-Verzeichnis? Auch auf der neuen SSD?

[Viscus]

Die Optimierung ist ein Datenbabnk-interner Prozess. Das Datenbanksystem kopiert hierbei die Datenbank in eine neue Datei um, entfernt dabei nicht mehr benötigter Daten, baut die Inizes neu auf usw.
Dabei wird nicht auf Verzeichnisse zugegriffen. IMatch ruft den Befehl auf und wartet dann, bis das Datenbanksystem fertig ist. Das Datenbanksystem weiß nichts über Verzeichnisse.

IMatch prüft Verzeichnisse auf Ihre Existenz beim Laden der Datenbank und wenn Windows Veränderungen meldet. Das passiert automatisch und im Hintergrund.

Hänge bitte immer die ganze Diagnoseprotokolldatei an (zippen). Auszüge sind nicht

Welchen Virenchecker nutzt Du?
Auf welcher Platte liegt das TEMP-Verzeichnis? Auch auf der neuen SSD?

Als Virenchecker habe ich Avast. Das Verzeichnis auf C: (SSD) habe ich auch auf die ausschliessen Liste genommen.
Das Profilverzeichnis habe ich jetzt auch wieder auf C genommen. Das war vorhin auf die Disk gemappt. Das Temp Verzeichnis ist innerhalb des Profil unter Appdata. Komischerweise hat es gestern beim Reorgprozess effektiv keine Kopie der DB ins Temp gemacht, was mich gewundert hat.

Ich bereinige mal die Bilddaten mit den Daten und schaue dann die Reorganisation durchläuft.

[Viscus]

Ich habe mal testhalber einen Quartalsordner aus dem 2005 gelöscht, nachdem ich die Bereinigung gemacht habe. Aber ich denke da gibt es nicht zwingend einen Zusammenhang.

Auf jeden Fall habe ich heute mal den ProcessMonitor beim Reindexen mitlaufen lassen.
Ganz am Schluss wenn alles durch ist, sollte ja eigentlich Imatch die Dialogbox für den erfolgreichen Abschluss bringen?
Nur scheint mir, dass es sich aufhängt. Denn sobald ich auf Abbrechen klicke kommt dann von Seiten Imatch auch die Meldung für den Erfolg des Reindex und man sieht auch im Process Explorer, dass Imatch geladen wird (reindex5). Vorher befindet sich der Prozess ImatchChromiumHelper.exe in einem Loop.

[Viscus]

Anbei noch das Logfile

[Viscus]

Noch ein Nachtrag. Ich habe nun 2 Quartale gelöscht und nochmals die Datenbankdiagnose durchlaufen lassen. Diese lief nun durch. Kann es sein, dass die Anzahl der Bilder in der DB allenfalls eine Grenze stösst?
Ich teste gerade mit löschen von anderen Ordnern (Reduktion der Bilder) von Q1und2 im gleichen Jahr und schaue dann was passiert. Wenn es wieder durchläuft würde es die Theorie bestätigen.

[Viscus]

Der Scan lief schon durch. Und diesmal erfolgreich mit weniger Bildern als in der gesamten DB. Diesmal aber mit anderen fehlenden Bildern. Somit kann ich ausschliessen, dass es den Bildern selber liegt.

[sinus]

Heisst, dass diesmal, mit diesen Bildern (664'759) alles ok ist?
Das Optimieren hat rund 30 Minuten gedauert und das scheint mir in Ordnung.

Was heisst denn "diesmal aber mit anderen fehlenden Bildern"?

Sorry, wenn ich das nicht so ganz verstehe.

[Mario]

Kann es sein, dass die Anzahl der Bilder in der DB allenfalls eine Grenze stösst?

Meine größte Testdatenbank verwaltet nun knapp 1 Millionen Dateien. Meine Zeiten für Optimierung und Diagnose für diese DB siehe oben.
Es gibt eine ganze Reihe von Anwendern die 1.5 bis 2 Millionen Bilder verwalten.
Die größte mir bekannte Datenbank managed 6 Millionen Dateien - auf einer sehr leistungsfähigen Workstation.

Es ist sehr sehr sehr unwahrscheinlich, aber vielleicht hat die Datenbank, bei der das so lange dauert, eine spezielle Kombination von "Dingen", die diesen Effekt hervorrufen und das Datenbanksystem irgendwie verwirren. Ich habe so einen Fall bisher aber nur einmal erlebt und das ist Jahre her (und der Bug wurde damals vom Hersteller behoben). Das kann ich aber nur selbst testen, wenn ich die Datenbank hier im Labor habe und dann an den Hersteller senden kann. Was bei 40GB nahezu unmöglich ist.

ChromiumHelper ist ein IMatch-Hilfsprozess, der den Chromium Browser enthält. Pro App Panel und App View wird einer dieser Prozesse gestartet. Die haben aber nichts mit der DB-Optimierung zu tun.
Du kannst ggf. mal alle App-Panel schließen und IMatch mit Media & Folder View als aktive View starten. Dann wird die People View und Event View nicht geladen.

[Viscus]

Zur Frage von sinus: Angehängt ist die Directorystruktur des Jahres bei dem ich Daten gelöscht habe. Einmal Test mit Löschen von 2005-3 und 2005-4 (26'376 Bilder) und das andere Mal mit Löschen von 2005-1 und 2005-2 (24'245 Bilder).

Die Werte für die volle DB mit allen Daten sind aktuell

    Database file size on disk:   49.46 GB
    Number of folders:            17'388
    Number of files:              689'004
    Number of categories:         3'040

@Mario: Ich hätte schon eine Möglichkeit dies online zu stellen. Komprimiert sind es um die 30Gigabyte. Komisch ist ja nur, dass wenn ich explizit manuell beende es dann auch nach dem Scan sauber abschliesst. Scheint als ob ich damit leben muss.

[Mario]

Wenn Du die Optimierung vorzeitig beendest, rollt das Datenbanksystem alles zurück. Die Optimierung erzeugt wie gesagt eine Kopie der Datenbank. Wenn das nicht beendet wird, ist die Originaldatenbank, nicht optimiert, weiterhin vorhanden.

[Viscus]

Wenn Du die Optimierung vorzeitig beendest, rollt das Datenbanksystem alles zurück. Die Optimierung erzeugt wie gesagt eine Kopie der Datenbank. Wenn das nicht beendet wird, ist die Originaldatenbank, nicht optimiert, weiterhin vorhanden.

Ich habe beim letzten Versuch von Seiten Imatch eine Meldung erhalten, dass die Synchronisierung erfolgreich war. Es war ja nach dem gesamten Kopierprozess und der Bereinigung. Nur eben, dass die Meldung nicht erscheint. Wenn ein Rollback gewesen wäre hätte ich dies ja im Process Explorer gesehen, da die Schreib- und Leseprozesse wieder losgegangen wären. Das war ja nicht der Fall.

[thrinn]

Ich muss noch einmal nachfragen bzw. einmal zusammenfassen, was ich glaube verstanden zu haben:

   
• Deine DB liegt jetzt auf C:, d.h. auf der neuen SSD?
• Die Bilder verteilen sich auf verschiedene Festplatten? Ich sehe D:, E:, F: in einem der Logs. Sind das verschiedene physische Platten (keine SSDs, nehme ich an) oder nur Partitionen?

Es geht in diesem Thread um verschiedene Probleme:

   
• Die Datenbank-Diagnose war am Anfang langsam, ist mit der neuen SSD aber akzeptabel schnell geworden, richtig?
• "Compact & Optimize" waren nun 30 Minuten und damit auch akzeptabel, richtig?

Aber diese beiden Punkte sollten nach meinem Verständnis nicht davon abhängen, wo welche Bilder-Ordner liegen. Sondern nur davon, wie schnell der Zugriff auf die Datenbank ist. Wenn diese nun auf einer SSD liegt und das Verzeichnis mit der Datenbank als Ausnahme im Virenscanner definiert ist und auch IMatch2021x64.exe als Ausnahme im Virenscanner definiert ist und dann noch %TEMP% auf der SSD liegt, dann sollte dies doch das bestmögliche Ergebnis bringen.

Ein anderes Thema ist dann das "Einlesen der Ordner" bzw. "Reindexing", wie du schreibst. Das erfolgt aber doch, nachdem die Diagnose bzw. die Optimierung (je nachdem, was du angestoßen hast) beendet ist und IMatch wieder die Datenbank ganz normal geöffnet hat. Ist das jetzt noch ein Performance-Problem?

Tut mir leid, dass ich so detailliert nachfrage, aber ich versuche mir ein Bild davon zu machen, an welchem Punkt du gerade stehst.

[Viscus]

Ich muss noch einmal nachfragen bzw. einmal zusammenfassen, was ich glaube verstanden zu haben:

   
• Deine DB liegt jetzt auf C:, d.h. auf der neuen SSD?

[/tt]

Ja

   

• Die Bilder verteilen sich auf verschiedene Festplatten? Ich sehe D:, E:, F: in einem der Logs. Sind das verschiedene physische Platten (keine SSDs, nehme ich an) oder nur Partitionen?

[/tt]

Es sind 3 verschiedene Disken. Aufgrund von Platzgründen habe ich diese so aufteilen müssen. Das war noch zu Zeiten als grosse SATA Platten nicht erhältlich waren und auch preislich nicht erschwinglich. Wobei das Wachstum der letzten zwei Jahre massiv weniger war.

[/list]Es geht in diesem Thread um verschiedene Probleme:

   
• Die Datenbank-Diagnose war am Anfang langsam, ist mit der neuen SSD aber akzeptabel schnell geworden, richtig?

Um dies ging es mir eigentlich gar nicht. Denn die Diagnose lief grundsätzlich immer gut durch. Aber jetzt schneller

   

• "Compact & Optimize" waren nun 30 Minuten und damit auch akzeptabel, richtig?

Es ist zeitlich nicht immer gleich. Hängt davon ab, was ich jetzt genau wo gelöscht habe. Es sind jetzt bis zu 1h 30 min.
Es bleibt aber hängen, sobald der Prozess durch ist. Also das Fenster bleibt wie im angehängten Screenshot. Ich sehe im Process Monitor, dass die Kopierprozesse eigentlich abgeschlossen sind.


[/list]Aber diese beiden Punkte sollten nach meinem Verständnis nicht davon abhängen, wo welche Bilder-Ordner liegen. Sondern nur davon, wie schnell der Zugriff auf die Datenbank ist. Wenn diese nun auf einer SSD liegt und das Verzeichnis mit der Datenbank als Ausnahme im Virenscanner definiert ist und auch IMatch2021x64.exe als Ausnahme im Virenscanner definiert ist und dann noch %TEMP% auf der SSD liegt, dann sollte dies doch das bestmögliche Ergebnis bringen.

Was auch der Fall ist. Und der Virenscanner dürfte nicht das Problem sein.

Ein anderes Thema ist dann das "Einlesen der Ordner" bzw. "Reindexing", wie du schreibst. Das erfolgt aber doch, nachdem die Diagnose bzw. die Optimierung (je nachdem, was du angestoßen hast) beendet ist und IMatch wieder die Datenbank ganz normal geöffnet hat. Ist das jetzt noch ein Performance-Problem?

Das Reindexing funktioniert immer, nur ist das Verhalten abhängig von der Anzahl der Bilder in der DB unterschiedlich. Aber erst wenn ich einen Teil der in der Datenbank enthaltenen Daten lösche, geht imatch wieder weiter und startet die Dialogbox für die Meldung. Egal ob ich die Diagnose starte, die auch das Reindexing anstösst, oder direkt nur das Reindexing anstosse.

Ich habe es nur mit den Ordnern von 2005 probiert. Ich mache dies gerade aktuell mit den Daten von 2022 und 2021 auch nochmals. Denn nur 2022 löschen half nicht.
Im ersten Moment als ich alles geschrieben habe, war ich davon ausgegangen, dass ich Daten von 2004 oder 2005 in der DB habe, die allenfalls inkonsistent wären und so das Löschen dieser allenfalls helfen würde. Aufgrund meiner Tests stellte ich aber fest, dass jetzt eine Reduktion der Anzahl der Bilder zumindest von 2005 hilft, dass der Prozess sauber durchläuft. Da das Reindexing immer etwas Zeit braucht und ich noch die Daten von 2005 bereinigen wollte, brauche ich immer etwas Zeit für eine Rückmeldung.


Tut mir leid, dass ich so detailliert nachfrage, aber ich versuche mir ein Bild davon zu machen, an welchem Punkt du gerade stehst.

Alles gut. Mario hat ja zumindest bestätigt, dass die DB mit grösseren Datenmengen umgehen kann. Ich kann ja nur von "aussen" via Process Monitor sehen, was im Hintergrund läuft. Was jetzt aber genau der Fehler ist, dass der letzte Prozessschritt vom Reindexing nicht abgeschlossen wird, oder Imatch wieder normal lädt das ist für mich nicht nachvollziehbar und vielleicht auch nicht verständlich rübergebracht.

DBs sind jetzt beruflich nicht mein Kernmetier. Eher das auf dem Netzwerk läuft.

[Viscus]

@thrinn

Fürs Verständnis. Ich habe nun gestern die Daten von 2022 und 2021 gelöscht. Und das Reindexing gestartet. Leider nicht mit dem gewünschten Ergebnis. Also der Prozess wurde nicht abgeschlossen.
Um 01:11 hätte es fertig sein sollen. Bzw. war es auch aber es erscheint immer noch das Fenster, dass die DB Komprimiert und optimiert wird, was aber nicht stimmt.

[sinus]

@thrinn

Fürs Verständnis. Ich habe nun gestern die Daten von 2022 und 2021 gelöscht. Und das Reindexing gestartet. Leider nicht mit dem gewünschten Ergebnis. Also der Prozess wurde nicht abgeschlossen.
Um 01:11 hätte es fertig sein sollen. Bzw. war es auch aber es erscheint immer noch das Fenster, dass die DB Komprimiert und optimiert wird, was aber nicht stimmt.

Gut, dass Du nachgefragt hast, thrinn.
Aber sorry, ich verstehe das immer noch nicht ganz.

Was hat denn das Reindexing mit dem "Komprimiere und optimiere die Datenbank" zu tun?
Aus meinen Verständnis gar nichts, aber wahrscheinlich verstehe ich den Begriff "Reindexing" nicht. 

Unter Reindexing verstehe ich das Einlesen von Ordnern/Bildern.
Und das hat nichts mit dem Tool "Komprimiere und optimiere die Datenbank" zu tun, aus meiner Sicht.

Aus meiner Sicht war und ist das Problem das, was im Titel des threads steht. "Optimierung der Datenbank dauert sehr lange".
Und weiter habe ich verstanden (weiss aber eben nicht, ob ich das richtig verstanden habe) , dass dieses Tool zwar durchläuft, aber am Schluss bleibt die Box einfach stehen, anstatt selbst aufzuhören und die Datenbank wieder laden.
Und wenn Du auf Abbrechen drückst, geht das zwar, aber gemäss Auskunft Mario wird dann einfach die DB vom Start wieder neu geladen.

Heisst, das Hauptproblem ist die Box, die stehenbleibt?

[Viscus]

Heisst, das Hauptproblem ist die Box, die stehenbleibt?

Richtig. Entschuldige die Verwirrung. Die Box bleibt stehen aber ich sehe von Seiten Process Monitor und Zeitstempel, dass der Prozess eigentlich abgeschlossen ist und die Dialogbox mit der Info kommen müsste, dass der Prozess durchgelaufen ist.

Ich habe nur heute morgen auch festgestellt (was sonst nicht der Fall war), dass nach dem Abbrechen die Meldung kam, dass die DB nicht sauber geschlossen wurde. Danach ist mir Imatch eingefroren. Jetzt lasse ich die Datenbankdiagnose, die am Schluss ja auch die Optimierung vornimmt, durchlaufen.
Das Ergebnis sehe ich aber erst heute Abend. Tagsüber bin ich da nicht am PC daheim.

[Viscus]

Noch als Nachtrag. Ich könnte auch damit leben, die DB neu aufzubauen. Also alle Metadaten wie Verknüpfungen der Files (RAW, CR2 zu Buddydateien), Kategorien und andere Informationen zu exportieren und diese dann entsprechend wieder zu importieren. Ist ein gewisser Aufwand, aber möglicherweise der einzige Weg.

[Mario]

Wenn der Dialog sich nicht schließt, hat die Datenbank noch nicht den Abschluss der Optimierung gemeldet.
Kannst Du das IMatch Logfile und das Diagnosis Logfile von dieser Sitzung mal anhängen?

[Viscus]

Anbei die Logs, die über die Datenbankdiagnose erzeugt wurden.

Diese habe ich heute morgen gestartet und war bis vorhin nicht beendet. Erst als ich auf Abbrechen geklickt habe wurden die letzten Zeilen ins Log geschrieben (pre und post)

Der Teil kam erst beim Abbruch

Optimizing Database, rebuilding optimial index structures and query plans:
Completed in 48826s with 11850232969544 counts.

Results:
    Errors:    0
    Warnings:  0
Database diagnosis aborted by user!
IMatch database diagnosis logfile closed: 24.03.2022 21:32:48 (13:38.24)


Ich habe nun die Ordner von 2022 und 2021 gelöscht. Interessanterweise bleibt es hier hängen, was nicht der Fall war als ich die Ordner von 2005 gelöscht habe.

[Mario]

This looks all pretty normal.
Except for the very long time it takes to run the analyze & optimize step. Very strange.

Did you run a Compact (Database menu  > Database Tools > Compact & Optimize) on that database?

[akirot]

Just my two cents:

Habe nicht alles gelesen - aber

- die IMatch DB hat 50GB
- habe keine Angabe über die Speichergröße des Rechners (RAM) gesehen
- der Prozess wird definitiv "swappen" (, da er die DB nicht vollständig im RAM halten kann)
- soweit der Prozess auf die "drehenden" Festplatten swapped, dauert das extrem lange

Ich würde sicherstellen, dass ausschließlich auf die neue SSD geswapped wird - habe die Konfiguration des Filesystems nicht mehr vor Augen, sonst würde ich es direkt angeben.
(Müsste selber jetzt wieder in der MS Hilfe oder internet suchen.)

[Mario]

Guter Punkt. Kann man im TaskManager überprüfen (für den photools.com IMatch Prozess).

Das zuletzt angehängte Logfile endet mit dem Aufruf der Datenbankoptimierung am Ende der Diagnose. Also vor dem spannenden Teil.
Bis dahin hat IMatch maximal (Peak) 1GB RAM belegt. Für eine Datenbank mit knapp 700,000 Dateien ist das normal.
Die Analyse/Optimierung ist eine atomare Operation des Datenbanksystems, IMatch ruft sie auf und wartet dann bis das Datenbank Vollzug meldet.

Der Rechner hat 32GB RAM und wenn IMatch startet sind davon 36% belegt. Sieht OK aus.

Es hat meins Wissens kein Anwender ähnliches berichtet und 50GB-Datenbanken gibt es etliche.
Meine größte Testdatenbank hat keine 50GB, aber knapp über 40. Bei der Diagnose bleibt die Hauptspeicherausnutzung gleich, keine Spitzen.
Das muss was total spezielles sein. Ein Database > Tools > Compact & Optimize kopiert ja die ganze Datenbank in eine neue Datei und entfernt Ballast. Vielleicht hilft das ja.
Die Optimierung in der Diagnose frischt die Indizes auf und prüft die Datenbank auf Probleme. Nur so lassen sich beispielsweise beschädigte Blöcke in selten benutzen Bereichen der Datenbankdatei finden.

[Viscus]

Ich würde sicherstellen, dass ausschließlich auf die neue SSD geswapped wird - habe die Konfiguration des Filesystems nicht mehr vor Augen, sonst würde ich es direkt angeben.

Das ist noch ein richtiger Punkt. Die Swap Datei liegt noch auf der Disk. Der Arbeitsspeicher wird aber vor allem beim Einlesen von Fotos ausgelastet. Ansonsten sind die 32 Gig wie von Mario erwähnt ausreichend.

Der Prozess ist ja so:
Kopie der DB ins User Temp (etilqs_xxxxxxxxxxxx)
Lesen der Datei und er erstellt dann das File im Imatch Ordner mit IMatch Datenbank.imd5-shm. (bzw das wird grösser)
Danach wächst die -wal Datei an und im Process Explorer sehe ich ja dann die Schreibprozesse zurück ins File IMatch Datenbank.imd5

Anbei das letzte Log File mit reduzierten Daten (2020, 2021 und 2022 gelöscht) nachdem ich Datenbank > Datenbankwerkzeuge > Komprimieren und Optimieren angewählt habe.

Ich habe heute Morgen mit der reduzierten DB nochmals die fehlenden Verzeichnisse importiert und schaue jetzt nochmals ob es wieder Probleme gibt. (Prozess wird nicht abgeschlossen) Der Prozess braucht doch jeweils über 1h 30 bis jeweils alles durch ist.
Falls dem so ist baue ich die DB neu auf und muss halt die Settings kopieren. Ich komme sonst auf keinen grünen Zweig.
Dann sehe ich ob ich dann wieder ins gleiche Problem laufe oder es dann erwartungsgemäss durchläuft.
Das werde ich aber erst übernächste Woche anfangen können. Nächste Woche komme ich nicht dazu.

[Mario]

Hast Du Mal Database > Database Tools > Compact & Optimize laufen lassen?

[Viscus]

Hast Du Mal Database > Database Tools > Compact & Optimize laufen lassen?

Ja immer wieder. Mit mehr oder weniger Erfolg. Es lief durch oder blieb hängen. Gestern Abend wieder nachdem ich wieder die Ordner von 2020, 2021 und 2022 eingelesen habe.

Siehe IMATCH6_LOG.TXT

Aber ich habe dann auch noch die Datenbankdiagnose laufen lassen und das Ergebnis ist im File 20220326-logfile1.zip. Und dies musste ich heute morgen abbrechen. Diese lief auf dem letzten Punkt in einer Endlosschleife. Sprich die Verzeichnisstruktur der Bildorder wurde repetitiv gescannt ohne dass dies gestoppt wurde. Das lief jetzt die ganze Nacht durch.

[Mario]

Please switch IMatch to Debug via Help menu > Support. This produces larger but more informative log files.

I did run a diagnosis while running SysInternals Process Monitor.

After the diagnosis has ended, IMatch invalidates the file system cache (which contains cached data about folders and files).
This is normal and IMatch does this every 5 minutes anyhow.
The next time the folder sweeper task in IMatch runs (to check the online state of folders) this causes file system access to fetch the folder data.
I can see this in process monitor. IMatch asks for file system data for each folder in the database.
Your database has 17,393 folders with 689,105 files. This averages only about 40 files per folder.

I don't know if these 18,000 folders are on your local disk, external disk, remove storage...might take a while for 18K folders.
On the other hand, IMatch does the same shortly after the database has been opened (to establish the initial state for each folder), and occasionally in the background when it receives messages about changed folders from Windows. This should not do anything or block IMatch. It probably takes longer due to Process Monitor running and logging everything.

That the virus checker does not interfere with IMatch has been checked?

Let's establish the thing that is causing the issue.
When you hold down CTRL when clicking the Start button in the diagnosis (to skip the Optimize step), how long does it take?

[Viscus]

Ich habe nun die Datenbankdiagnose ohne Optimierung durchlaufen lassen. Die Details sind im angehängten Logfile.

Die Ordner liegen auf 3 verschiedenen lokalen SATA Platten. (SSDs liegen nicht drin, da zu teuer, bzw. als ich diese verbaute gab es noch gar keine in dieser Grössenordnung)

Würde es etwas bringen wenn ich alle Daten aus den Verzeichnissen lösche und neu einlese? Dann könnte ich die Datenbankhülle ohne Daten auch mal zur Verfügung stellen.

Den Process Explorer lasse ich jeweils nur kurz laufen um zu sehen, was gerade im Hintergrund läuft. Somit ist der Impact auf die Performance nur gering. Diese Nacht war der nicht aktiv. Ich habe nur kurz heute morgen geschaut, was jetzt gerade los ist. Da habe ich gesehen, dass immer noch der Scan der Verzeichnisse durchläuft.

Hier noch kurz die Zeit für die Diagnose:

IMatch database diagnosis logfile created: 26.03.2022 10:21:46

Application Info:
    Version:                      21.15.0.2
    Filename:                     C:\Program Files\photools.com\imatch6\IMatch2021x64.exe

General Database Info:
    Database file name:           C:\_Imatch-DB\imatch5\IMatch Datenbank.imd5
    Database file size on disk:   49.45 GB
    Number of folders:            17'393
    Number of files:              689'105
    Number of categories:         3'040
    Clearing oid cache.

IMatch database diagnosis logfile closed: 26.03.2022 10:25:06 (00:03.20)

[Mario]

Die Diagnose läuft in 3 Minuten durch, wenn das Datenbanksystem keine Validierung der Datenbank durchführt.

C: ist eine SSD nehme ich an?