awk ‘{ print $0}’ clean_files.txt | xargs rm

1.Der typo3 recycler funktioniert nicht bei Versionierung, siehe: http://forge.typo3.org/projects/show/extension-recycler

Wie werde ich meine Datensätze – zb. uralt tt_news Einträge – trotzdem los?

2. In der DB-Überprüfung bei Database Relations habe ich massig Fehlermeldungen nach folgendem Muster (zum Teil deshalb, weil ich bei übersetzten tt_news die übersetzte Seite nicht vor dem Löschen der tt_news Seite mit der Standardsprache gelöscht habe)

There are 5 records pointing to this missing or deleted record; [tt_news][623]

Dabei handelt es sich immer um endgültig gelöschte Seiten, im recycler ist überhaupt nichts mehr, aber in der Datenbank sind eben – wg. Frage 1 – noch alle alten Sachen drin.

Hier bin ich schonmal fündig geworden, aber leider bricht der Lösungsansatz ab:
http://www.mail-archive.com/typo3-german@lists.typo3.org/msg01973.html

Mein Versuch, in der Datenbank direkt zu bearbeiten, führte zu Fehlermeldungen im Protokoll, siehe hier:
http://www.typo3forum.net/forum/typo3-4-x-fragen-probleme/46579-db-berpr-fung-macht-probleme.html

So, jetzt meine Frage:

Wie ist die Vorgehensweise beim Reparieren des Referenz Index?

gruss g.k.

in den Unterordner “typo3″ wechseln, dort
./cli_dispatch.phpsh lowlevel_cleaner lost_files -r –refindex update –AUTOFIX –YES -s

ausführen. Das löscht automatisch alle Dateien im Uploads Ordner, die nicht mehr referenziert sind. Ausführung auf eigene Gefahr.

Grüsse, Michael

2. @author: zu sys_history würde ich noch sys_log hinzunehmen. aber auch hier sei darauf aufmerksam gemacht: dort werden bestimmte logging daten gespeichert, die dann natürlich weg sind.

kj_recycler: Ist mit Vorsicht zu geniessen. Ich habe es noch nicht 100% verifiziert (also den code genau angeschaut), aber es scheint, als ob die extension bilder die in flexformfeldern referenziert werden nicht als solche erkennt und löscht. und das ist eher übel. auch wenn ich kaum extensions kenne die das mit flexform lösen, ausser einer eigenentwicklung.
Allerdings scheint es im TYPO3 internen Tool das selbe Prob zu geben.

wenn wir auf das thema performance eingehen: die simple pagehit statistic deinstallieren, config.stat_mysql=0 eintragen, und die tabelle sys_stat löschen.
Das Modul ist für den professionellen Einsatz völlig ungeeignet, und müllt nur die Datenbank zu. Vom HDD IO will ich jetzt mal gar nicht reden …

Die Performance Einbußen können durch das Nichtlöschen von generierten PDFs kommen. Wenn der Ordner sehr voll ist, dauert ein Dateizugriff natürlich auch dementsprechend.

Das pauschale Löschen der angegeben DB-Tabellen cache_* oder gar index_* hat den Vorteil, dass die index_search auch gleiche deinstalliert werden kann.

Alles in allem halte ich den Ratschlag so allgemein zu geben für ziemlich leichtsinnig.

Gruss.

Die Extension macht im Endeffekt das Gleiche wie die vom Autor genannte Extension und löscht alle Datensätze, die in der Datenbank nur mit einem entsprechenden Flag versehen wurden.

Falls jemand die Crawler-extension benutzt sollte er die zugehörige DB Tabelle (tx_crawler_queue) ebenfalls regelmäßig leeren.

Ich mach das alles mit einem kleinen Cronjob:

#! /bin/sh
#
# loescht die cache & index tabellen

# declaring the constants
PATH=/bin:/sbin:/usr/bin:/usr/sbin
MYSQL_USER=”DB_USERXX”
MYSQL_USER_PASSWORD=”XXX”
MYSQL_DATABASE=”typo3″
SCRIPT_NAME=”mysql_cache_index_leeren_cmds”

mysql –user=$MYSQL_USER –password=$MYSQL_USER_PASSWORD –database=$MYSQL_DATABASE –force < /mnt/hdd2/scripts/$SCRIPT_NAME;

// Script mysql_cache_index_leeren_cmds
// leert mit TRUNCATE die entsprechenden Tabellen + quit

TRUNCATE cache_extensions \G
TRUNCATE cache_hash \G
TRUNCATE cache_imagesizes \G
TRUNCATE cache_md5params \G
TRUNCATE cache_pages \G
TRUNCATE cache_pagesection \G
TRUNCATE cache_typo3temp_log \G
TRUNCATE index_fulltext \G
TRUNCATE index_grlist \G
TRUNCATE index_phash \G
TRUNCATE index_rel \G
TRUNCATE index_section \G
TRUNCATE index_words \G
TRUNCATE tx_crawler_queue \G
\q

Danke!