SQL table finder_tokens ist voll

    Zitat von Rabendoktor

    Wenn ich die aktuelle 4.0.3 herunterlade sind da erstmal nur weitere zips drin???

    Im Ernst? Nutzt du ein Quickstart-Package?

    Poste mal den Inhalt deines Joomla-ZIPs! (Screenshot)



    https://downloads.joomla.org/c…ll_Package.zip?format=zip


    Nebenbei: Das was früher mal möglich war, geht nicht mehr, da bei solch einer Aktualisierung (nur per FTP) die DB-Tabellen nicht aktualisiert werden.

    Dafür gibt es die Komponente "Joomla-Aktualisierung". Damit könnte man übrigens auch die Core-Dateien "drüberbügeln", sofern man ins Backend kommt.

    Asche auf mein Haupt - beim nochmaligen Runterladen ergibt das Entpacken des Stable-Full-Package das bekannte Bild...


    Ich hatte das mit dem Sprachpaket verwechselt, tut mir leid... .


    Aber Dein Hinweis, JoomlaWunder ist natürlich spannend: an's Backend komme ich ja problemlos ran, die Seite läuft ja auch (bis auf den oben genannten Speicherfehler im Backend und die Fehlermeldung beim Anlegen des Suchindex).


    Klingt mir aktuell wie der einfachste erste Schritt - DANKE!

    DANKE - habe jetzt die 4.0.3 - bügelt grad drüber....

    ... dachte ich jedenfalls.


    Bei IONOS und mit Cyberduck hat das nicht funktoniert, Fehlermeldung, dass bestimmte Ordner nicht angelegt werden können, ich sollte meinen webhoster kontakten... X/


    Daraufhin habe ich die core-Dateien vom backend aus über die Joomla-Aktualisierung nochmal neu installiert - lief alles fein.

    Danach den Cache geleert..

    Danach versucht, den Index neu anzulegen - gleiche Fehlermeldung wie vorher....

    Die Suche ist auf meiner impf-info.de-Seite eine wichtige Funktion - was kann ich noch tun, um einen Index anlegen zu können?

    DANKE für Eure Hilfe,

    herzlich,

    Steffen

    Nothing is hidden


    (Dogen)

    Einmal editiert, zuletzt von Indigo66 () aus folgendem Grund: Ein Beitrag von Rabendoktor mit diesem Beitrag zusammengefügt.

    Nur Nachtrag: Wenn ich über Pakete drüberbügeln rede, meine ich immer https://github.com/joomla/joomla-cms/releases

    und dort das jeweilige Joomla_x.y.z-Stable-Full_Package.zip

    Keiner anderen Quelle vertraue ich persönlich bzgl. "Original". Und lass mr das auch nicht ausreden ;)


    Zu deiner Plugin-Fehlermeldung: Brauchst du denn die Kontakte-Indexierung? Wenn nicht, kannst das entsprechende Plugin vom Typ "finder" deaktivieren.

    Zitat von Rabendoktor

    mit Akeeba - weil ich damit ja die Seite in einer völlig neuen DB wieder hergestellt habe und das Problem offenbar mitgenommen habe....

    Die Tabelle wurde vermutlich leer überführt, aber halt wieder befüllt bei irgendeiner Aktion in Joomla. Dafür ist sie da bzw. MEMORY-Tabellen im Allgemeinen. So ne Art Cache. Der Indexer ist ja ständig am Tun, wenn man irgendwas bearbeitet, speichert usw.

    DANKE, Re:Later - ich habe jetzt ja zunächst versucht, von den direkt von joomla.org heruntergeladenen stable-full-package.zips aus per ftp zu bügeln (erfolglos, siehe oben, erlaubt mir IONOS offenbar nicht (mehr) ), als auch aus dem backend der Seite heraus die core-Dateien neu zu installieren. Dies wurde von Joomla mit einer Erfolgsmeldung gekrönt, der Fehler bestand allerdings weiter.


    Nein, ich brauche nur und ausschließlich die Indexierung der einzelnen Seiten der Website, nix sonst - welches Plug-In genau kann ich somit deaktivieren und wie genau mache ich das?

    DANKE nochmals - ich bin da aktuell wirklich überfordert....

    Habe jetzt wohl doch gefunden, was Du meinst - und nach dem Deaktivieren des Plugins "Suchindex - Kontakte" kam auch prompt die Fehlermeldung nicht mehr.


    Dafür jetzt eine neue, die aber in die bekannte Richtung weist:


    Es scheint alles um die j4_finder_tokens zu kreisen... .


    Ich bin doch nur nicht der einzige, der J4 bei IONOS mit 16 MB Voreinstellung als max_heap_table_size laufen hat... warum läuft die bei meiner (ja auch nicht sooooo großen) Seite dann voll und stresst? hmm

    Nothing is hidden


    (Dogen)

    Einmal editiert, zuletzt von Indigo66 () aus folgendem Grund: Ein Beitrag von Rabendoktor mit diesem Beitrag zusammengefügt.

    Weil ich jetzt nicht mehr ganz durchblicke: Die Meldung auch, wenn du die Tabelle zuvor geleert hast? Und nachdem du in den Optionen des Indexers "Tabellenspeichergröße" erheblich runtergesetzt hast?

    Zitat von Rabendoktor

    welches Plug-In genau kann ich somit deaktivieren und wie genau mache ich das?

    Unter Erweiterungen > Verwalten > Filter "Verzeichnis wählen" auf "finder". Alle Plugins, die dir unsinnig erscheinen.

    Inhalt sind Beiträge.

    Kategorien weiß ich nicht, ob sinnvoll.

    Ich habe mich - ehrlicherweise - noch nicht getraut, die Tabelle zu leeren, warte hier noch auf die Rückmeldung meines hosters - das heruntersetzen der Tabellenspeichergröße (Original 300.000, jetzt 100.000) hat nichts geändert....

    Zwischenstand mit neuen Problemen:

    IONOS kann bei shared hosting die max_heap_table_size nicht heraufsetzen...


    Eine Recherche bei github ergab als wahrscheinlichste Ursache des Problems "zu umfangreiche Artikel" und tatsächlich betrifft es bei mir ja auch nur EINEN Artikel, der zugegeben sehr lang war (Coronoia - der Blog des Archivs).


    So: heute habe ich den dann geteilt und die Hälfte (2020) per cut/past in einen neuen Artikel ausgelagert, den ich - obwohl nur halb so groß - mit der gleichen Fehlermeldung speichern konnte. Der ist jetzt, wie man unter impf-info.de "Zuletzt aktualisiert" sehen kann auch im frontend verfügbar, wird im backend unter Beiträge aber nicht angezeigt! (Der gekürzte Ursprungsartikel, jetzt "Archiv 2021" taucht in backend und frontend auf.)


    Was bedeutet das und wie kann ich das fixen???

    Gibt es irgendeine Möglichkeit diese verfluchte Datenbank zu reparieren?


    Wie genau müsste ich denn die j4_finder_tokens leeren?


    Der Suchindex hängt sich unverändert auf mit der gleichen Fehlermeldung....


    DANKE für Eure Geduld....


    Herzlich,


    Steffen

    Update: ich habe jetzt geschafft, die j4_finder_tokens zu leeren per phpMyAdmin.

    ABER: egal, ob ich dann den Blog_2021 Artikel wieder versuche zu speichern, oder ob ich (nach erneutem leeren der DB-Tabelle und Leeren des Such-Index-Index) versuche, den Such-Index neu zu indexieren:

    ich bekomme jedesmal prompt die selbe Fehlermeldung j4_finder_tokens is full - und sie ist dann auch jedesmal full mit 16,1 MB.


    Any idea what to do???


    Nachtrag: das Reduzieren der Such-Index-Plugins auf nur noch "Inhalt" hat auch keine Veränderung gebracht.....


    Nachtrag2: bei Deaktivieren des Suchindex (Komponente) wird der einzige im backend verfügbare Blog 2021 anstandslos gespeichert OHNE Fehlermeldung und die j4_finder_token bleibt leer....


    Das Problem liegt also offenbar beim Suchindex - gibt es da einen Lösungsansatz? Oder eine Alternative??

    Ich möchte hier nach diesem mittlerweile unübersichtlichen Austausch eine Zusammenfassung versuchen:


    Wenn beim Speichern umfangreicher Beiträge oder beim Anlegen des Index des Such-Index die Fehlermeldung "Tabellenpräfix_finder_token is full" auftaucht kann Folgendes versucht werden:

    • max_heap_table_size heraufsetzen (lassen) - die steht standardmäßig auf 16 MB und es gibt Berichte, dass schon die Erhöhung auf 20 MB Abhilfe schafft.
    • das Verkleinern des betroffenen Artikels - es gibt Berichte, dies habe geholfen
    • das Leeren der betroffenen Tabelle über phpMyAdmin - dies kann gefahrlos geschehen, sie wird umgehend wieder gefüllt

    In meinem Fall hat erst und nur das komplette Deaktivieren der Komponente Such-Index mit allen Bestandteilen das Problem nachhaltig gelöst.


    Nicht zielführend waren:

    • das Neuanlegen des Index für den Such-Index
    • das Verändern der Tabellengröße des Such-Index, egal ob in Richtung größer oder kleiner
    • das Deaktivieren einzelner Plugins des Such-Index
    • das Erhöhen des memory_limit per php.ini

    Ich danke von Herzen Allen, die mir auf dem Weg zu dieser Lösung geholfen haben - ohne dieses Forum wäre Joomla für Nebenerwerbs-Nerds wie mich ein no-go... so lerne ich täglich von Euch - DANKE!


    Lieber Tom, natürlich steht es Dir als Moderator frei, in diesem thread mein teilweise wirres Gestammel zu kürzen oder zu löschen...


    herzlich,


    Steffen

    Ich weiß nicht, ob Hackwar hier im Forum aktiv ist, aber von ihm stammt die Erweiterung und die "Denke" dahinter. Mit deiner Zusammenfassung muss er ja auch nicht allzuviel lesen. Es fehlt vielleicht noch der Hinweis, dass dein Provider, wie viele andere ja auch, Manipulationen an der Datenbank (max_heap_table_size) nicht bereit ist umzusetzen.

    Genau so ist es, Re:Later: IONOS sagt, beim shared hosting sind das globale Einstellungen, die sie nicht individuell anpassen können/wollen... .


    Aber ein dedizierter server ist mir für mein non-profit-Projekt dieser Seite schlicht zu teuer.....


    Herzliche Grüße,


    Steffen

    Geht mir ganz genauso. Ich sehe gar nicht ein, für die Suchfunktion auf irgendwas teurereres umzusteigen und mein persönlicher Account ist schon sehr ordentlich. Bzw. präventiv gleich was größeres zu mieten, nur, weil sie evtl. mal explodieren könnte, nachdem ich schon Tage Arbeit reingesteckt habe.


    Kunden weise ich halt darauf hin, dass unter blöden Umständen, der von ihnen gewünschte Suchindex Mehrkosten verursachen könnte. Ich empfehle einer wissenschaftlichen Seite oder "meinem" Journalisten jedenfalls nicht, kürzere Beiträge zu schreiben ;)


    EDIT: Jedenfalls verstehe ich die allgemeine Empfehlung seitens Joomla-Anbietern, -Machern nicht, auf Suchindex umzusteigen.

    DANKE - klingt, wie der entscheidende Hinweis...


    Allerdings bin ich jetzt in der Not auf EB Ajax Search umgestiegen mit exzellenter Performance und akzeptablem Preis und aktuell fehlt mir die Zeit, das zurückzustellen - aber es ist super, dass Hackwar sich dieses (offensichtlich ja gar nicht so seltenen) Problems annimmt.


    DANKE nochmal für's wieder aufgreifen,

    herzliche,


    Steffen