Großer Datenbank-Restore/Kodierung

ill66 · 28.02.2010

Ich hoffe, das ist hier richtig....?

Also ich schlag mir jetzt bereits die 2. Nacht um die Ohren. Will euch gar nicht mit den Details behelligen (ausser vlt den Tipp, sich von dem Provider Revido eher fernzuhalten

), nur meine End-Frage:
Ich hab hier eine Datenbank, die zu groß ist (auch gepackt), um sie bei meinem neuen Provider hochzuladen und wenn ich es via mysqldumper versuche, sind die Umlaute zerschossen.
Nach ner Meeenge Handarbeit sind jetzt nur noch 2 Tabellen übrig, die (nochmal in korrekter Kodierung) hoch müssen, weigern sich aber beharrlich.

Gibt es jetzt
a.) eine Möglichkeit, mysqldumper von utf8 auf utf8 umzustellen,
b.) die kaputten Umlaute meines WBB2-Forums nachträglich mit irgendeinem SQL-Befehl zu ändern oder
c.) die SQL-Datei (automatisch bitte) zu splitten?

Export der alten DB geht nur über myadmin oder confixx (kein mysql-dumper), Import über myadmin oder dumper (kein confixx).

bigdump hab ich auch schon ausprobiert, der sagt mir aber meistens, dass ich mehr als 300 dump lines hab und will dann nicht mehr.
SSH-Zugang auf den Server und solche Späße hab ich nicht.
Ich google seit Tagen (gefühlt). o__O
Mein OS ist Linux (wegs möglicher Programm-Empfehlungen).

S.O.S.

saila · 28.02.2010

AW: Großer Datenbank-Restore/Kodierung

Hi,

fragen:
Beim neuanlegen der Datenbank, hast du da das korrekte Charset eingestellt (z.B. mit phpMyAdmin)?

haben die Tabellen bei "create" das übereinstimmende Charset?

In der Regel werden Tabellen bei vielen Providern in shwedish angelegt - warum auch immer. Deshalb ist es wichtig die Tabelle zuerst selbst neu anzulegen und das Grundcharset korrekt einzustellen. Wenn danach die Tabellen das übereinstimmende Charset besitzen, gibt es (zumindest bei mir noch nicht vorgekommen) keine Probleme.

Das kannst du auch testen, indem du eine Testtabelle anlegst und lediglich 10 Zeilen hochfährst.

ChrisvA · 28.02.2010

AW: Großer Datenbank-Restore/Kodierung

Mal versucht das ganze einfach in das SQL-Feld bei PHPMyAdmin rein zuschreiben?
Falls die Maximale Länge dabei nicht überschritten wird, sollte das gehen.
Hast du die Möglichkeit extern auf die Datenbank zuzugreifen? Dann sollte es vielleicht auch mit einem Programm wie Squirrel SQL funktionieren. (Weiß allerdings nicht, ob das auch auf Linux läuft)

ill66 · 01.03.2010

AW: Großer Datenbank-Restore/Kodierung

saila schrieb:
Beim neuanlegen der Datenbank, hast du da das korrekte Charset eingestellt (z.B. mit phpMyAdmin)?

Hm, was meinst du genau?
Wenn ich DBs in der benutzeroberfläche meines providers anlege, kann ich da kein charset wählen...

haben die Tabellen bei "create" das übereinstimmende Charset?

Was ist denn create? (sorry, in Sachen DB steck ich noch total in Kinderschuhen)

In der Regel werden Tabellen bei vielen Providern in shwedish angelegt - warum auch immer.

Das beruhigt mich zu hören - wunderte mich schon und dachte, ich hätte irgendwas vermurkst

Deshalb ist es wichtig die Tabelle zuerst selbst neu anzulegen und das Grundcharset korrekt einzustellen. Wenn danach die Tabellen das übereinstimmende Charset besitzen, gibt es (zumindest bei mir noch nicht vorgekommen) keine Probleme.

Selber anlegen - von Hand? Ich bin mir ziemlich sicher, dass ich das auf jeden Fall verhauen würde.^^°
Außerdem hat so eine Foren-DB echt ne Menge Tabellen oO

ChrisvA schrieb:
Mal versucht das ganze einfach in das SQL-Feld bei PHPMyAdmin rein zuschreiben?

Was genau schreib ich denn da?

Hast du die Möglichkeit extern auf die Datenbank zuzugreifen? Dann sollte es vielleicht auch mit einem Programm wie Squirrel SQL funktionieren. (Weiß allerdings nicht, ob das auch auf Linux läuft)

Ja hab ich. Hm, das Prog ist crossplattform. Guck ich mir mal an.

Grad hab in myAdmin entdeckt:
In der Hauptansicht der DB steht bei allen Tabellen bei Kollation zwar utf8_swedish_ci aber ganz unten in der unterlegten Zeile, die quasi alles zusammenfasst utf8_general_ci! im myAdmin des alten Providers steht da auch latin.Hm. Aber beim Erstellen konnte ich wie gesagt keine Kodierung einstellen *kopfkratz*

edit:
Letzteres konnte ich unter "Operationen" jetzt umstellen. Scheint aber keinen Einfluss zu haben.

saila · 01.03.2010

AW: Großer Datenbank-Restore/Kodierung

Also wenn du die Kollation korrekt für die Datebenbank eingestellt hast auf utf8_gerneral_ci, dann musst du nun prüfen, ob z.B. eine Tabelle korrekt in der Kollation übereinstimmt. Das bedeutet, dass du zuerste die Tabellen erstellst und dann erst die Insert's fährst.

Die Testtabelle soll eine Tabelle aus deinem Forum sein, auch der Inhalt. Wichtig ist beim exportieren, dass auch hier die Kollation korrekt eingestellt ist.

Zur Frage und Umgang mit großen Foren - jo ich kenn das Thema und vor allem das Thema, wenn der Upload bzw. das Einfügen der Daten in die Tabelle dann früher oder später abbricht, weil der timeout gerufen hat. Deshalb sollte man beim exportieren der Daten in (je nachdem wie groß die Tabelle ist) mehreren Schritten exportieren.

Beim erstellen einer Datenbank-Tabelle kann man die Kollation mit angeben. Somit wird/würde die Grundeinstellung der Datenbank für eine Tabelle überschrieben und man bekommt später keine komischen Zeichen.

ill66 · 07.03.2010

Update

Hm - offenbar reichen meine Kenntnis auf dem Gebiet noch nicht aus, das hier vorgeschlagene umzusetzen^^° Danke trotzdem! So ärgerlich solche Probleme sind, man lernt ja meist doch einiges daran

Mein Forum läuft mittlerweile wieder, wobei ich einfach in Kauf nehme, dass einige - aber nicht alle - Umlaute in einigen - ebenfalls nicht allen - Postings auf unterschiedliche Weise zerschossen sind.M anche sind komplett weg, manche durch ein ? ersetzt und manche mit diesen kryptischen Zeichen. Keine Ahnung, wie das zustande gekommen ist.
Bin grade dabei, die häufiger vorkommenden Worte mit diesem Script zu reparieren:

Code:

UPDATE bb1_posts SET message = REPLACE(message, '?ffentlich', 'öffentlich') WHERE message LIKE '%?ffentlich%';

UPDATE bb1_posts SET posttopic = REPLACE(posttopic, '?ffentlich', 'öffentlich') WHERE posttopic LIKE '%?ffentlich%';

(Hab ich im Netz für WBB3 gefunden und habs immerhin schonmal geschafft, das für mein WBB2 anzupassen, ha!^^)

Weil ich ja gern weiterlernen möchte, hätte ich noch folgende Fragen:

1. DB-Restore
Wenn ich eine DB oder eine Tabelle hochlade/restore und das bricht aus welchem Grund auch immer ab (Timeout etc) - ist dann ein Teil der Daten trotzdem eingespielt oder gibt es bei DBs nur ein "alles oder nichts"?

2. myAdmin-Timeout
Ganz merkwürdig: Wenn ich ich über myAdmin im SQL-Reiter einen befehl eingebe, endet das immer in einem Timeout. Der befehlt wurde dann aber trotzdem ausgeführt. Wenn ich hingegen zwei Befehle in das Fenster eingeb, passiert das nicht und es kommt eine praktisch Ausgabe was grade durchgeführt wurde (Anzahl der Ersetzungen etc.). Hö?

3. Link-Replace
Da das aktuelle Forum eine ziemliche Odysee an Servern und (Sub)Domains hinter sich hat, gibt es viele alte interne Links in den beiträgen, die jetzt natürlich ungültig(da absolut) sind - ich glaube, 3 verschiedene gibt es da.
Zwei der alten Domains konnte ich mit folgende Befehl fixen:

Code:

UPDATE bb1_posts SET message=REPLACE(message,'http://sub.altedomain.de/wbb/','http://neuedomain.de/');

Die dritte im Bunde enthält aber in den Links zensurbedingte Sternchen *** - ich vemrute, daran lag es, dass es in dem Fall nicht geklappt hat.
Was könnte ich da machen?

saila · 07.03.2010

AW: Großer Datenbank-Restore/Kodierung

1. Einen Teil und zwar jener welcher bis zum timeout übernommen wurde. Deshalb sollte man den ersten INSERT als Anhaltspunkt nehmen und den Rest der Tabelle aufteilen und nach und nach einspielen.

2. Keine Ahnung wieso weshalb warum.

3. Wenn eine Zensur zur URL übernommen wurde - warum soll diese nun nicht mehr erforderlich sein? Wenn nicht, kannst du ja alle URL's mit * löschen und wieder eintragen lassen (User oder Du oder wer auch immer).

ill66 · 07.03.2010

AW: Großer Datenbank-Restore/Kodierung

saila schrieb:
1. Einen Teil und zwar jener welcher bis zum timeout übernommen wurde.

Ah cool! Das erklärt Einiges, danke^^

3. Wenn eine Zensur zur URL übernommen wurde - warum soll diese nun nicht mehr erforderlich sein? Wenn nicht, kannst du ja alle URL's mit * löschen und wieder eintragen lassen (User oder Du oder wer auch immer).

Das war so:
Zwischenzeitlich hatte ich das Froum auf dem Space meines Sportvereins gelagert, mit einer Subdomain (thematisch hat das eine mit dem anderen aber null zu tun). Als die User angefangen haben, intern Threads zu verlinken, tauchte das Forum aber plötzlich in den google-Ergebnissen auf, wenn man unseren Verein gesucht hat (weil der Vereinsname in der Domain vorkam). Das war natürlich gar nicht im Sinne der Erfinderin, weswegen ich im WBB-ACP die Zensur-Funktion benutzte.
Jetzt sehen einige Links eben so aus: http://sub.****verein.de/thread.php?postid=116371
Und die hätt ich gern wieder klickbar.

Wenn nicht, kannst du ja alle URL's mit * löschen und wieder eintragen lassen (User oder Du oder wer auch immer).

Meinst du jetzt von Hand? (das wären zu viele)
Oder gibts da auch einen praktischen SQL-Befehl für?