Hi zusammen !

Musste meinen Server neu aufsetzen - Bin von Suse zu Debian gewechselt... Selbstverständlich habe ich noch einen MySQL-Dump gemacht.

Jetzt habe ich eine 300mb "localhost.php", die, wenn ich sie über phpmyadmin, mysqldumper oder direkt mittels "mysql -u root -p db < localhost.sql" einspielen will, fehler produziert ->

 server version for the right syntax to use near 'DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci' at line

Problem in 1. Linie: die 300mb Datei lässt sich halt nicht im Editor/Notepad öffnen.... Da spiel der Speicher nicht mit. Mein versuch, die Datei über ein kleines PHP-Skript in 2 bearbeitbar-große Teile zu halbieren scheiterte auch kläglich

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 314107224 bytes) in /home/mxpprojekte/testfirma/www/html/kopie.php on line 3

jemand ne Idee, wie ich die Datei gesplittet/bearbeitbar bekomme ?

Gruß, Tobi

Das sieht mir eher nach einem Versionsproblem aus. Also deine neue MySQL-Version ist älter als die vorherige. Was für eine Debian Version hast du denn? Auch Sarge sollte den bemängelten Begriff schon verstehen. Bei mir war es immer umgekehrt, dass der Suse Linux Enterprise Server mit diesem Ausdruck im MySQL-Dump nichts anfangen konnte.

Ansonsten: Änder die Datei doch direkt auf dem Server.

apt-get install vim

Also ich finde vim ist besser zu benutzen als nur vi. Damit sollte es gehen, weil AFAIK nicht die komplette Datei in den speicher geladen wird, wie das bei Notepad geschieht.

:# vi mySQL.dump

Oder du benutzt sed, einen Kommandozeilen-Texteditor also mal ohne Gewähr:

:# sed "s/DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci//g" < mySQL.dump > mySQL.dump.new

Zu der Aufteilung mit PHP:

In der php.ini gibts keinen Parameter der festlegt wieviel Speicher das Skript beanspruchen darf.

SED-Methode:

Hatte ich zuerst auch probiert, funktionierte aber irgendwie nicht. Sed hat bei mir die Zeichenkette nicht ersetzt. Dazu komm noch dass man nicht weiss, ob nicht vll. >100 Ersetzungen getaetigt werden muessen bevor der Import klappt. Das waer mir etwas zu hampelig gewesen.

Eventuelle Loesung:

Ich hatte dass selbe Problem mit mit nem Dump eines Telefonbuches.

Das Problem bestand darin, dass der Dump auf einem Mysqld in der Verision 5.x erstellt worden war und der nicht kompatibel zu einem in der Version 4.x ist.

Ich hab dann erst wieder den Dump auf einen Mysqld in der Version 5.x importiert und dann mit Hilfe von

mysqldump -u foo -p --compatible=mysql40 -D database > foo.sql

einen neuen erstellt, der kompatibel war zum Mysql 4.0.

MySQL AB :: MySQL 5.1 Referenzhandbuch :: 8.10 mysqldump — Programm zur Datensicherung

SED-Methode:

Hatte ich zuerst auch probiert, funktionierte aber irgendwie nicht. Sed hat bei mir die Zeichenkette nicht ersetzt. Dazu komm noch dass man nicht weiss, ob nicht vll. >100 Ersetzungen getaetigt werden muessen bevor der Import klappt. Das waer mir etwas zu hampelig gewesen.

Wenn es nicht funktioniert hat, dann musst du wohl was falsch gemacht haben (Das Beispiel oben war nur aus dem Kopf, ohne dass ich es mit den Werten so schon mal gemacht habe) Und über dir Option g (für global) kannst du ja angeben, dass er alle Vorkommen ersetzen soll. Also egal ob >100 Ersetzungen oder nicht.

EDIT:

wobei die Kompatibilitäts-Methode auf jeden Fall die beste Lösung ist, wenn noch möglich.

Wenn es nicht funktioniert hat, dann musst du wohl was falsch gemacht haben (Das Beispiel oben war nur aus dem Kopf, ohne dass ich es mit den Werten so schon mal gemacht habe) Und über dir Option g (für global) kannst du ja angeben, dass er alle Vorkommen ersetzen soll. Also egal ob >100 Ersetzungen oder nicht.

EDIT:

wobei die Kompatibilitäts-Methode auf jeden Fall die beste Lösung ist, wenn noch möglich.

>100 == >100 verschiedene Ersetzungen (Wobei 100 etwas uebertrieben sein koennte.)

Ich meine damit das evt. noch mehrere unterschiedliche Befehle in der Datei sein koennten, die mit der MySQL-Version nicht kompatibel sind. Dann geht das Gefrickel los.

Ich konnte auch per Google nicht herausfinden, ob sed eine maximale Dateigroeße der zu parsenden Datei hat, bzw. ob es die Datei am Stueck oeffnet oder immer teilweise.

Ich konnte auch per Google nicht herausfinden, ob sed eine maximale Dateigroeße der zu parsenden Datei hat, bzw. ob es die Datei am Stueck oeffnet oder immer teilweise.

OK, das mit den anderen Problemen könnte natürlich sein, sagte ja, der Kompatibilitätsmodus ist der sicherere Weg.

Zur Dateigröße:

Weiß nicht ob sed das hat, aber sed hat auf jeden Fall eine Option um den Speicherverbrauch zu minimieren:

-u, --unbuffered

load minimal amounts of data from the input files and flush

the output buffers more often

Aber wir diskutieren hier über unnötiges Wenn er die Möglichkeit hat, soll er es mit der Kompatibilität probieren, wenn nicht kann er sed verwenden, wobei es dann natürlich noch mehr Probleme geben kann, die aber auf dieselbe Art zu lösen wären.