Datenbankabfrage um alle PNs vor 2010 zu löschen ?

[ranseyer]

Hallo zusammen,

ich möchte alle älteren PNs löschen weil diese doppelt so viel Platz brauchen wie die Inhalte in den öffentlichen Boards...

Bei der "Konkurenz" hab ich das in diesem Board gesehen:

select * from smf_personal_messages pm, smf_pm_recipients pmr
where pm.id_pm=pmr.id_pm
and pm.id_member_from=12345
and pmr.id_member=54321

In der Tabelle smf_personal_messages gibt es das Feld:  msgtime. Mustereintrag: "1148074670".

Somit wäre ich für nen Tipp dankbar wie das SQL Statement auszusehen hat, und vor allem einen Hinweis dazu, ob mir das die SMF-Software übelnehmen wird. (Die neueren PNs möchte ich ja erhalten...)

Danke im Vorraus.


Edit: Was mich wundert ist, dass SMF dazu keine Funktion mitbringt (oder ich bin blind)...

[Christian Land]

Ich übernehme keinerlei Garantien, da ich wirklich ziemlich aus dem Thema raus bin aber

Code: [Auswählen]

DELETE FROM smf_personal_messages WHERE msgtime <= UNIX_TIMESTAMP('2010-01-01 00:00:00');
sollte alle PMs löschen die älter als der 1.1.2010 sind. Problematisch wird die Sache dadurch, dass dann die pm_recipients-Tabelle Murks enthält.

Die aufzuräumen ist ein wenig Tricky... aber wozu gibt es Subqueries in SQL

Code: [Auswählen]

DELETE FROM
                smf_pm_recipients AS r2
WHERE
        r2.ID_PM IN(
                        SELECT
                                r.ID_PM
                        FROM
                                smf_pm_recipients AS r
                        LEFT JOIN
                                smf_personal_messages AS p ON (r.ID_PM = p.ID_PM)
                        WHERE
                                ISNULL(p.ID_PM)
                )               
sollte alle Datensätze aus der pm_recipients-Tabelle löschen zu denen keine Nachricht mehr existiert.

Am sinnvollsten wäre wohl wenn jemand mit Testforum das Ganze ausprobieren könnte damit ich keine Katastrophe anrichte

[ranseyer]

Kann ich gut verstehen, dass das keiner für mich testen will.

Ich hab auch nen lokalen Server und hab das erst mal mit ner quasi leeren Foren-DB versucht:

Fehler

SQL-Befehl: Dokumentation

DELETE FROM smf_pm_recipients AS r2 WHERE r2.ID_PM IN (
SELECT r.ID_PM
FROM smf_pm_recipients AS r
LEFT JOIN smf_personal_messages AS p ON ( r.ID_PM = p.ID_PM )
WHERE ISNULL( p.ID_PM )
)

MySQL meldet: Dokumentation
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'AS r2
WHERE
        r2.ID_PM IN(
                        SELECT
         ' at line 2

Somit macht es vermutlich erst dann Sinn das mit ner Kopie der Foren-DB zu testen wenns generell läuft. Der gepackte Dump der Foren DB ist etwas größer und noch nicht auf meiner Platte...

Für Hinweise wäre ich Dankbar !

Meine lokale Umgebung:

# Server Version: 5.0.51a-24+lenny2

[xduugu]

Es sollte auch reichen, wenn du die erste Query ausführst und dann nachher eine Reparatur anstößt (ACP→Forenwartung→Fehler finden und reaparieren oder so etwas).

[ranseyer]

@xduugu: Danke: So hab ich das auf meiner test-DB erfolgreich getestet. Da waren es zwei PNs die gelöscht würden, und bei der Repartur gabs auch ne Meldung dass zwei Einträge in der passenden Tabelle repariert wurden 


Trotzdem Mist !

jetzt hab ich das auf die Produktive DB angewendet, und ne Menge Platz gewonnen. Problem: Die Reparaturfunktion findet keine Fehler. Dierse läuft nur so gute 5 Minuten und meldet dann keine Fehler gefunden...

Somit hab ich nun ne inkonsistente DB produktiv und keine Lösung. Umso froher wäre ich deshalb über Tipps 
(Und möglichst nicht in beiden Tabellen alle Einträge löschen...)

[ranseyer]

Problem glöst. Nur kann ich nicht zu 100% sagen wie !

Ich habe jetzt nochmals laufen gelassen:

1) Alle totalen Forumswerte und Statistiken neu auszählen
und dann erst nochmal: 2) Fehler finden und reparieren


Bei Punkt 2 kam dann "Fehler gefunden: "" reparieren ja/nein"
Das hat das Thema dann gelöst.

Danke !

[Christian Land]

Meh... und ich hab extra neue SQL-Queries gebastelt *lol* Da warst Du wohl schneller *g*

Das Problem hätte man vermutlich auch mit

Code: [Auswählen]

UPDATE smf_pm_recipients AS t1 LEFT JOIN smf_personal_messages AS t2 ON t1.ID_PM = t2.ID_PM SET t1.ID_PM = 0 WHERE t2.ID_PM IS NULL;

DELETE FROM smf_pm_recipients WHERE ID_PM = 0;
gelöst Die erste Query hätte alle herrenlosen PMs auf ID = 0 verbogen und die zweite hätte die dann gelöscht...

Keine Ahnung warum die andere Query nicht ging.

[ranseyer]

Danke an alle für euren Beistand 


@Christian, ich werde das beim nächsten Mal testen !

[Jorin]

Wurde dein Problem gelöst, markiere das Thema bitte dementsprechend. Eine Anleitung hierzu findest du hier. Danke.

[Neakro]

jetzt hab ich das auf die Produktive DB angewendet, und ne Menge Platz gewonnen. Problem: Die Reparaturfunktion findet keine Fehler. Dierse läuft nur so gute 5 Minuten und meldet dann keine Fehler gefunden...

Warum macht eigentlich niemand Backups vor so riesigen Eingriffen?!

[ranseyer]

Backup hab ich schon, nur mag ich das nicht restoren, weil das 30 Minuten Downtime bedeuten würde... Dann lieber 2-3 Tage auf die Reparatur warten...

[ranseyer]

geht auch nicht. Ich werd es wieder manuell reparieren...

#1062 - Duplicate entry '0-132' for key 1

Meh... und ich hab extra neue SQL-Queries gebastelt *lol* Da warst Du wohl schneller *g*

Das Problem hätte man vermutlich auch mit

Code: [Auswählen]

UPDATE smf_pm_recipients AS t1 LEFT JOIN smf_personal_messages AS t2 ON t1.ID_PM = t2.ID_PM SET t1.ID_PM = 0 WHERE t2.ID_PM IS NULL;

DELETE FROM smf_pm_recipients WHERE ID_PM = 0;
gelöst Die erste Query hätte alle herrenlosen PMs auf ID = 0 verbogen und die zweite hätte die dann gelöscht...

Keine Ahnung warum die andere Query nicht ging.