KeyHelp Community

Bearbeite Deine SQL Datei und füge folgende Zeilen an den Anfang:

SET AUTOCOMMIT = 0;
SET FOREIGN_KEY_CHECKS=0;

Folgende Zeilen ganz ans Ende:

Code: Select all

SET FOREIGN_KEY_CHECKS = 1;
COMMIT;
SET AUTOCOMMIT = 1;

Das beschleunigt den Import oft deutlich.

Bei 1 MiB würde ich die Datei dann ungepackt hochladen.

hase wrote: ↑Wed 24. Oct 2018, 09:30 Hallo,
danke für die Antworten soweit.

Aktuell sind u.a. folgende Werte eingestellt:
memory_limit 128M
pm.max_children = 10
pm.max_requests = 0

Ist es ratsam die Werte für eine bessere Performence bzw. mehr Leistung zu ändern/erhöhen?
Hat vielleicht jemand dafür Erfahrungswerte?

Muss das Thema nochmal anschieben

Mehr RAM hat wenig mit "schneller" zu tun.
Es ermöglicht lediglich komplexere Skripte mit umfangreichen Berechnungen.

Je nachdem wieviel Subrequests diese Skripte auslösen kann es hilfreich sein die Zahl der Max-Requests und Children zu erhöhen.

Es gibt dafür aber keine verbindlichen Empfehlungen. Denn zuviele Children und Requests belegen dann ihrerseits mit Nichtstun Systemressourcen welche dann nicht mehr für andere Prozesse zur Verfügung stehen.

Meine persönliche Empfehlung wäre die Einstellungen so zu belassen und erst dann moderat anzuheben wenn auch weiterhin Ausfälle auftreten.

Tobi wrote: ↑Thu 25. Oct 2018, 17:13 Meine persönliche Empfehlung wäre die Einstellungen so zu belassen und erst dann moderat anzuheben wenn auch weiterhin Ausfälle auftreten.

Dann werde ich die Werte auch so belassen. Dachte nur das man durch eine Änderung dieser Werte etwas mehr Leistung herrausholen könnte.
Oder sollte man vielleicht an den MYSQL-Einstellungen etwas schrauben?

hase wrote: ↑Thu 25. Oct 2018, 19:24 Oder sollte man vielleicht an den MYSQL-Einstellungen etwas schrauben?

Ohne akkute Notwendigkeit würde ich auch dies lassen.
Datenbank auf SSD statt HDD bringt einen Schub.

hase wrote: ↑Thu 25. Oct 2018, 19:24 Oder sollte man vielleicht an den MYSQL-Einstellungen etwas schrauben?

Du kannst Dir das Perl Skript mysqltuner installieren (per apt-get).
Der gibt in der Regel gute Vorschläge aus.

Servus zusammen,

jetzt habe ich das Problem das sich meine Datenbank (182 MB ungepackt und 15 MB gepackt) nicht importieren lässt. Habe an den Benutzereinstellungen schon herumgeschraubt und bekomme die Fehlermeldung 504 Gateway Timeout.

Achso: Ich habe Upload filesize auf 640 MB hochgesetzt und in Phpmyadmin zeigt er mir an 64MB? Übernimmt er die einstellungen etwa nicht? Dann kann es daran liegen das es nicht klappt (nur eine Vermutung)

Wenn ich versuche per SSH zu importieren, dann bekomme ich die Fehlermeldung irgendwas mit ASCII und binary-mode (Bitte ein großes Sorry - bin gerade auf arbeit und hatte das zu hause schnell versuchen wollen, hat aber leider nicht geklappt ;()
Leider klappt das nun auch nicht - bin erst heute abend wieder daheim - vielleicht gibts da schon eine Lösung

Danke Euch

Gerne poste ich den Link immer wieder

https://www.ozerov.de/bigdump/ ist dein Freund

.

Du kannst in der Konfiguration von bigdump unter anderem den Zeichensatz für die Datenbankverbindung anpassen.
Damit sollte dein Ascii Problem lösbar sein.

Danke für die schnelle Antwort.

Ich werde heute Abend probieren und berichten

Danke

Ich berichte mal,

das Tool selbst ist Super, aber:

Code: Select all

Stopped at the line 644.

At this place the current query includes more than 300 dump lines. That can happen if your dump file was created by some tool which doesn't place a semicolon followed by a linebreak at the end of each query, or if your dump contains extended inserts or very long procedure definitions. Please read the BigDump usage notes for more infos. Ask for our support services in order to handle dump files containing extended inserts.

Ich sollte mich wohl von meiner Datenbank verabschieden

Hallo,

für umfangreiche Datenbankdumps würde ich jederzeit für einen Import über die Shell raten:

mysql -u DBUSER -p DBNAME < dumpfile.sql

(Danach wird das DB Passwort abgefragt)

So ihr lieben,

kurze Rückmeldung: Datenabnk ist eingespielt und funktioniert auch.

Problem das ich die Datenbank nicht per Shell einspielen konnte war, daß die Datenbank .gz gepackt war. Ich habe die DB dann entpackt und per Shell eingespielt und nun läuft es.

Danke Euch

Martin wrote: ↑Thu 6. Aug 2020, 00:32 Hallo,

für umfangreiche Datenbankdumps würde ich jederzeit für einen Import über die Shell raten:

mysql -u DBUSER -p DBNAME < dumpfile.sql

(Danach wird das DB Passwort abgefragt)

Ich kenne das mit ...

Code: Select all

mysql -uDBUSER -pDBPASSWD DBNAME < dump.sql

(keine Leerzeichen bei '-uDBUSER' und '-pDBPASSWD')

Hallo,

geht natürlich auch, aber bei der Abfrage (wenn man das Passwort nicht direkt angibt) taucht dies dann auch nicht mit in der Bashhistory auf.

Hallo,

trollolol wrote: ↑Thu 6. Aug 2020, 06:19 Problem das ich die Datenbank nicht per Shell einspielen konnte war, daß die Datenbank .gz gepackt war. Ich habe die DB dann entpackt und per Shell eingespielt und nun läuft es.

Ergänzend auf der Konsole bei umfangreichen Datenbanken (zb. 30..60 Gb oder mehr) kann man diese auch wunderbar gleich aus dem Archiv importieren.

Code: Select all

gunzip < DB-timestamp.sql.gz | mysql -uroot -pXyZ DB_NAME

KeyHelp Community

DB Import Probleme!

Re: DB Import Probleme!

Re: DB Import Probleme!

Re: DB Import Probleme!

Re: DB Import Probleme!

Re: DB Import Probleme!

Re: DB Import Probleme!

Re: DB Import Probleme!

Re: DB Import Probleme!

Re: DB Import Probleme!

Re: DB Import Probleme!

Re: DB Import Probleme!

Re: DB Import Probleme! [GELÖST]

Re: DB Import Probleme!

Re: DB Import Probleme!

Re: DB Import Probleme!