Ein Datenbankimport mit phpMyAdmin kann aus unterschiedlichen Gründen fehlschlagen. Die SQL-Datei kann zu groß sein, der Import kann während der Verarbeitung abbrechen oder MySQL kann eine konkrete Fehlermeldung zu Tabellen, Berechtigungen, Zeichensätzen oder vorhandenen Datensätzen ausgeben.
Wichtig ist, nach einem fehlgeschlagenen Import nicht sofort denselben Vorgang erneut zu starten. Ein abgebrochener Import kann bereits einen Teil der Tabellen und Daten angelegt haben. Ein zweiter Import über diesen Zwischenstand kann zusätzliche Fehler verursachen.
In dieser Anleitung zeigen wir dir, wie du einen fehlgeschlagenen phpMyAdmin-Import systematisch analysierst, typische Fehlermeldungen einordnest und entscheidest, wie du sicher weiter vorgehst.
Wichtig: Notiere beziehungsweise kopiere die vollständige Fehlermeldung, bevor du etwas veränderst. Die genaue Meldung ist für die Fehleranalyse wesentlich hilfreicher als die allgemeine Information, dass der Import „nicht funktioniert“.
Zuerst feststellen, an welcher Stelle der Import scheitert #
Nicht jeder Importfehler hat dieselbe Ursache. Prüfe deshalb zuerst, was genau passiert.
Typische Situationen sind:
- die SQL-Datei lässt sich gar nicht auswählen oder hochladen
- phpMyAdmin meldet bereits vor dem eigentlichen Import einen Fehler
- der Import startet, bricht aber während der Verarbeitung ab
- phpMyAdmin zeigt eine konkrete MySQL- oder SQL-Fehlermeldung
- der Import wird als erfolgreich gemeldet, aber die Website funktioniert danach nicht
- ein Teil der Tabellen wurde importiert, der Rest fehlt
Diese Fälle müssen unterschiedlich behandelt werden.
Vor einem neuen Versuch den Zustand der Datenbank prüfen #
Öffne in phpMyAdmin die betreffende Zieldatenbank und kontrolliere, ob bereits Tabellen vorhanden sind.
Wenn vor dem Import eine leere Datenbank vorhanden war und jetzt Tabellen angezeigt werden, wurde zumindest ein Teil der SQL-Datei verarbeitet.
Achtung: Starte einen fehlgeschlagenen Import nicht einfach erneut über eine teilweise importierte Datenbank. Dadurch können Fehler wegen bereits vorhandener Tabellen oder doppelter Datensätze entstehen.
Fehlermeldung vollständig lesen #
phpMyAdmin beziehungsweise der Datenbankserver liefert bei vielen Problemen eine konkrete Meldung.
Notiere:
- Fehlernummer, falls vorhanden
- vollständigen Fehlertext
- betroffene Tabelle
- betroffene SQL-Anweisung, sofern angezeigt
- ungefähre Stelle, an der der Import abgebrochen ist
Ein Screenshot der vollständigen Meldung kann bei einer späteren Analyse ebenfalls hilfreich sein.
Die SQL-Datei ist größer als das erlaubte Upload-Limit #
Wenn phpMyAdmin nur Dateien bis zu einer bestimmten Größe akzeptiert, kann eine größere SQL-Datei nicht über den normalen Upload importiert werden.
Die Importseite kann abhängig von der Serverkonfiguration eine maximal zulässige Dateigröße anzeigen.
Ist deine SQL-Datei größer als dieses Limit, liegt das Problem nicht automatisch an der Datenbank selbst. Die Datei erreicht phpMyAdmin möglicherweise gar nicht vollständig.
Wichtig: Ändere PHP-Limits nicht wahllos. Prüfe zuerst, welches Limit tatsächlich erreicht wird und ob die betreffende Einstellung in deiner Hosting-Umgebung überhaupt selbst verändert werden sollte.
SQL-Datei komprimieren #
Abhängig von der phpMyAdmin- und Serverkonfiguration können komprimierte SQL-Dateien unterstützt werden.
Eine Datei wie:
datenbank.sql
kann sich je nach Dateninhalt deutlich komprimieren lassen.
Eine unterstützte komprimierte Variante kann beispielsweise so aussehen:
datenbank.sql.gz
Ob und welche Kompressionsformate akzeptiert werden, erkennst du an der Importoberfläche beziehungsweise der konkreten Serverkonfiguration.
Komprimieren hilft allerdings nur bei einem Größenproblem der übertragenen Datei. Es löst keine SQL-, Berechtigungs- oder Tabellenfehler.
Import startet, läuft aber in einen Timeout #
Bei großen oder komplexen SQL-Dateien kann der Import starten und später wegen einer Laufzeitbegrenzung abbrechen.
Das unterscheidet sich von einem reinen Upload-Limit: Die Datei wurde angenommen und zumindest teilweise verarbeitet.
Prüfe in diesem Fall unbedingt, ob bereits Tabellen und Datensätze in der Zieldatenbank vorhanden sind.
Browser zeigt eine leere Seite oder Verbindung bricht ab #
Wenn der Browser während eines langen Imports keine normale Erfolgsmeldung mehr anzeigt, bedeutet das nicht automatisch, dass überhaupt nichts importiert wurde.
Öffne die Zieldatenbank anschließend erneut in phpMyAdmin und kontrolliere deren Zustand.
Starte den Import erst dann erneut, wenn geklärt ist, was bereits verarbeitet wurde.
Teilweise importierte Datenbank #
SQL-Dateien werden normalerweise Anweisung für Anweisung verarbeitet. Bricht der Vorgang währenddessen ab, können die vorherigen Anweisungen bereits ausgeführt worden sein.
Die Zieldatenbank kann dann beispielsweise so aussehen:
Tabelle A → vorhanden
Tabelle B → vorhanden
Tabelle C → vorhanden
Tabelle D → Import hier abgebrochen
weitere Tabellen → fehlenEine solche Datenbank ist nicht mehr leer, aber möglicherweise auch nicht vollständig.
Wichtig: Behandle einen abgebrochenen Import als möglichen Zwischenzustand. Prüfe zuerst die Datenbank, bevor du löschst, erneut importierst oder die Website damit produktiv verwendest.
Sauber neu beginnen oder Import fortsetzen? #
Welche Vorgehensweise richtig ist, hängt von der SQL-Datei, dem Fehler und dem Zustand der Zieldatenbank ab.
Bei einer neu angelegten, ausschließlich für diese Migration bestimmten Datenbank kann ein sauberer Neustart sinnvoller sein als der Versuch, einen unklaren Teilimport manuell fortzusetzen.
Enthält die Datenbank dagegen bereits produktive Daten, darfst du vorhandene Tabellen keinesfalls einfach entfernen.
Achtung: Lösche eine teilweise importierte Datenbank nur dann beziehungsweise setze sie nur dann zurück, wenn eindeutig feststeht, dass darin keine benötigten produktiven Daten vorhanden sind und eine geeignete Ausgangssicherung existiert.
Fehler #1044 – Zugriff auf die Datenbank verweigert #
Eine Meldung mit Fehlernummer #1044 weist typischerweise auf ein Berechtigungsproblem im Zusammenhang mit einer Datenbank hin.
Das kann beispielsweise auftreten, wenn die SQL-Datei versucht, eine Datenbank zu verwenden oder zu erstellen, für die der aktuelle Datenbankbenutzer beziehungsweise Hosting-Account nicht die erforderlichen Rechte besitzt.
Prüfe insbesondere, ob die SQL-Datei Anweisungen wie:
CREATE DATABASE ...
USE ...enthält und ob diese zur Zielumgebung passen.
Warum CREATE DATABASE beim Hosting problematisch sein kann #
In einer cPanel-Hosting-Umgebung werden Datenbanken normalerweise über cPanel erstellt und dem Hosting-Account zugeordnet.
Eine importierte SQL-Datei sollte deshalb nicht ungeprüft versuchen, beliebige neue Datenbanken auf Serverebene anzulegen.
Erstelle die benötigte Zieldatenbank stattdessen wie in MySQL-Datenbank in cPanel erstellen beschrieben und importiere die Daten anschließend in diese Datenbank.
USE-Anweisung verweist auf einen alten Datenbanknamen #
Eine SQL-Datei aus einer anderen Hosting-Umgebung kann einen früheren Datenbanknamen enthalten.
Beispielsweise:
USE alteraccount_wordpress;Am neuen Standort kann die Datenbank dagegen beispielsweise:
neueraccount_wordpress
heißen.
Eine solche Abweichung kann beim Import relevant sein.
Achtung: Entferne oder verändere SQL-Anweisungen nicht blind. Prüfe zuerst, welche Anweisungen vorhanden sind, was sie bewirken und welche Zieldatenbank tatsächlich verwendet werden soll.
Fehler #1045 – Access denied #
Fehler #1045 steht typischerweise für eine fehlgeschlagene Authentifizierung beziehungsweise einen verweigerten Datenbankzugriff.
Wenn der Fehler im Zusammenhang mit einer Anwendung auftritt, prüfe:
- vollständigen Datenbankbenutzernamen
- Passwort des Datenbankbenutzers
- Datenbankhost
- Zuweisung des Benutzers zur Datenbank
- Berechtigungen des Benutzers
Wie du einen Datenbankbenutzer korrekt einrichtest, erklären wir unter MySQL-Benutzer erstellen und einer Datenbank zuweisen.
Import erfolgreich, Website meldet trotzdem #1045 oder Access denied #
In diesem Fall kann die Datenbank vollständig importiert sein und lediglich die Anwendung falsche Zugangsdaten verwenden.
Bei WordPress solltest du dann insbesondere die Werte in:
wp-config.php
kontrollieren.
Dazu gehören:
DB_NAME
DB_USER
DB_PASSWORD
DB_HOSTEin erneuter Datenbankimport löst falsche Zugangsdaten der Anwendung nicht.
Fehler #1050 – Table already exists #
Eine Meldung wie:
#1050 - Table already exists
bedeutet, dass die SQL-Datei eine Tabelle erstellen möchte, die in der Zieldatenbank bereits vorhanden ist.
Das tritt häufig auf, wenn:
- ein Import bereits teilweise durchgeführt wurde
- derselbe Import ein zweites Mal gestartet wurde
- die Zieldatenbank vor dem Import nicht leer war
- bereits eine andere Installation dieselben Tabellennamen verwendet
Bei #1050 Tabellen nicht sofort löschen #
Prüfe zuerst, warum die Tabelle bereits existiert.
Wenn es sich um eine produktive Tabelle handelt, könnte deren Löschung Datenverlust verursachen.
Wenn die Datenbank dagegen ausschließlich für eine neue Migration erstellt wurde und ein erster Import nachweislich abgebrochen ist, kann ein sauberer Neustart eine mögliche Vorgehensweise sein.
Die Entscheidung hängt vom tatsächlichen Zustand der Datenbank ab.
Fehler #1062 – Duplicate entry #
Fehler #1062 weist typischerweise darauf hin, dass ein Wert eingefügt werden soll, der aufgrund eines eindeutigen Schlüssels bereits vorhanden ist.
Eine Meldung kann beispielsweise sinngemäß auf:
Duplicate entry
hinweisen.
Das kann unter anderem auftreten, wenn Daten bereits importiert wurden und anschließend erneut eingefügt werden sollen.
Warum ein zweiter Import #1062 verursachen kann #
Wenn der erste Import bereits Datensätze angelegt hat, kann ein erneuter Import versuchen, dieselben IDs oder andere eindeutige Werte noch einmal einzufügen.
Die Datenbank verhindert dies, wenn entsprechende Eindeutigkeitsregeln definiert sind.
Wichtig: Ein
#1062-Fehler ist kein Grund, eindeutige Schlüssel auf Verdacht zu entfernen. Diese sind Bestandteil der Datenbankstruktur und können für die korrekte Funktion der Anwendung entscheidend sein.
Fehler #1064 – SQL-Syntaxfehler #
Fehler #1064 weist typischerweise auf eine SQL-Anweisung hin, die vom Datenbankserver in dieser Form nicht verarbeitet werden kann.
Mögliche Ursachen können sein:
- eine beschädigte oder unvollständige SQL-Datei
- eine manuell fehlerhaft veränderte SQL-Anweisung
- inkompatible Syntax
- ein Problem an einer bestimmten Stelle der Exportdatei
Die Fehlermeldung nennt häufig eine Stelle beziehungsweise einen Ausschnitt, in dessen Nähe der Fehler erkannt wurde.
Bei Syntaxfehlern nicht wahllos Zeilen löschen #
Eine scheinbar problematische Zeile kann Teil einer größeren SQL-Anweisung sein.
Wenn du einzelne Zeilen auf Verdacht entfernst, kann die Datei anschließend an einer anderen Stelle fehlschlagen oder unvollständige Daten importieren.
Prüfe zuerst die genaue Fehlermeldung und die Herkunft der SQL-Datei.
Fehler wegen unbekannter Kollation #
Beim Import einer Datenbank aus einer anderen Serverumgebung kann eine Meldung erscheinen, dass eine bestimmte Kollation nicht bekannt beziehungsweise nicht unterstützt wird.
Das kann beispielsweise vorkommen, wenn Quelle und Ziel unterschiedliche Datenbankserver-Versionen oder unterschiedliche unterstützte Kollationen verwenden.
Die Fehlermeldung kann sinngemäß enthalten:
Unknown collation
Kollation nicht blind ersetzen #
Es finden sich im Internet zahlreiche Anleitungen, die empfehlen, eine Kollation in der gesamten SQL-Datei pauschal durch eine andere zu ersetzen.
Das kann in einem konkreten Fall funktionieren, ist aber keine universelle Lösung.
Prüfe zuerst:
- welche Kollation die Quelldatenbank verwendet
- welche Kollation der Zielserver unterstützt
- welcher Zeichensatz damit verbunden ist
- ob die Anwendung besondere Anforderungen hat
Achtung: Zeichensatz und Kollation betreffen die Speicherung und Verarbeitung von Text. Unüberlegte Änderungen können zu falsch dargestellten Zeichen oder unerwartetem Vergleichs- und Sortierverhalten führen.
Umlaute und Sonderzeichen sind nach dem Import falsch #
Wenn Zeichen wie:
ä
ö
ü
é
ànach dem Import falsch dargestellt werden, kann ein Zeichensatzproblem vorliegen.
Prüfe, ob das Problem bereits in der SQL-Datei vorhanden ist oder erst nach dem Import auftritt.
Ändere nicht sofort die gesamte Datenbankkollation. Die Ursache kann an unterschiedlichen Stellen der Export- und Importkette liegen.
Fehler wegen unbekanntem Zeichensatz #
Auch ein nicht unterstützter Zeichensatz kann einen Import verhindern.
In diesem Fall sollte zuerst geklärt werden, mit welchem Datenbanksystem beziehungsweise welcher Version die SQL-Datei erzeugt wurde und welche Zeichensätze das Zielsystem unterstützt.
Fehler bei DEFINER-Anweisungen #
SQL-Exporte können bei bestimmten Datenbankobjekten Angaben zu einem DEFINER enthalten.
Diese können auf einen Benutzer der ursprünglichen Serverumgebung verweisen, der auf dem Zielsystem nicht existiert beziehungsweise dort nicht verwendet werden darf.
Beispielsweise kann eine SQL-Datei einen serverbezogenen Benutzer enthalten, der nur auf dem bisherigen System vorhanden war.
Wenn eine Fehlermeldung ausdrücklich auf DEFINER oder entsprechende Berechtigungen verweist, sollte genau dieser Teil der SQL-Datei beziehungsweise der betroffenen Datenbankobjekte geprüft werden.
Wichtig: Entferne nicht pauschal sämtliche
DEFINER-Angaben aus jeder SQL-Datei. Prüfe zuerst, welche Objekte betroffen sind und ob diese für die Anwendung benötigt werden.
Fehler wegen fehlender Berechtigungen #
Ein SQL-Export aus einer Umgebung mit weitreichenden Datenbankrechten kann Anweisungen enthalten, die in einer normalen Hosting-Umgebung nicht zulässig sind.
Das bedeutet nicht automatisch, dass dein Hosting-Account falsch konfiguriert ist.
Bestimmte serverweite administrative Aktionen sind bei Shared Hosting bewusst nicht für einzelne Hosting-Accounts freigegeben.
Import bricht bei einer bestimmten Tabelle ab #
Wenn der Fehler immer bei derselben Tabelle auftritt, notiere:
- Tabellenname
- Fehlernummer
- Fehlertext
- ungefähre Position innerhalb des Imports
Damit lässt sich wesentlich gezielter unterscheiden, ob beispielsweise die Tabellenstruktur, ein Datensatz oder eine nicht unterstützte SQL-Anweisung das Problem verursacht.
Import bleibt scheinbar bei einer großen Tabelle hängen #
Einzelne Tabellen können sehr viel größer sein als der Rest einer Datenbank.
Bei WordPress können beispielsweise Protokoll-, Statistik-, Cache- oder andere von Erweiterungen angelegte Tabellen erhebliche Datenmengen enthalten.
Breche einen Import nicht allein deshalb ab, weil eine große Tabelle länger benötigt.
Prüfe, ob phpMyAdmin tatsächlich einen Fehler meldet oder der Vorgang noch verarbeitet wird.
Sehr große SQL-Dateien aufteilen? #
Das Aufteilen einer SQL-Datei kann in bestimmten Situationen eine technische Lösung sein, sollte aber nicht durch willkürliches Zerschneiden an beliebigen Stellen erfolgen.
SQL-Anweisungen können sich über viele Zeilen erstrecken. Wird eine Anweisung mitten im Befehl getrennt, entstehen ungültige Dateien.
Achtung: Teile große SQL-Dateien nur mit einem dafür geeigneten Verfahren beziehungsweise ausreichenden SQL-Kenntnissen auf. Ein normaler Texteditor und eine beliebige Zeilennummer sind dafür keine sichere Methode.
SQL-Datei ist möglicherweise unvollständig #
Wenn bereits der ursprüngliche Export abgebrochen wurde, kann die erzeugte SQL-Datei unvollständig sein.
Ein späterer Import kann dann ebenfalls abbrechen, obwohl mit der Zieldatenbank nichts falsch ist.
Wenn die Quelle noch verfügbar ist, kann ein neuer vollständiger Export die bessere Lösung sein.
Wie du einen Export korrekt erstellst, erklären wir unter Datenbank mit phpMyAdmin exportieren.
SQL-Datei hat 0 Byte oder ist ungewöhnlich klein #
Eine leere oder unerwartet kleine Datei kann darauf hinweisen, dass bereits beim Export etwas nicht wie erwartet funktioniert hat.
Die Dateigröße allein ist zwar kein sicherer Beweis für Vollständigkeit, offensichtliche Abweichungen solltest du aber vor dem Import untersuchen.
Falsches Dateiformat #
Prüfe, ob es sich tatsächlich um einen geeigneten Datenbankexport handelt.
Eine Datei mit der Endung:
.sql
ist ein typisches Format für einen SQL-Export.
Eine beliebige CSV-, XML-, ZIP- oder Textdatei ist nicht automatisch ein vollständiger SQL-Datenbankexport.
Komprimierte Datei wird nicht akzeptiert #
Wenn phpMyAdmin eine komprimierte Datei nicht akzeptiert, prüfe zunächst, welche Kompressionsformate in der Importoberfläche tatsächlich unterstützt werden.
Ändere nicht einfach die Dateiendung.
Das Umbenennen von:
datenbank.zip
in:
datenbank.sql
wandelt den Inhalt nicht in eine SQL-Datei um.
Import ist erfolgreich, aber Website zeigt einen Datenbankfehler #
Ein erfolgreicher Import und eine funktionierende Datenbankverbindung sind zwei unterschiedliche Dinge.
Wenn die Tabellen vorhanden sind, die Website aber keine Verbindung herstellen kann, prüfe die Zugangsdaten der Anwendung.
Bei WordPress insbesondere:
DB_NAME
DB_USER
DB_PASSWORD
DB_HOSTPrüfe außerdem, ob der Datenbankbenutzer der richtigen Datenbank zugewiesen wurde.
Import erfolgreich, aber Website zeigt falsche Inhalte #
Wenn die Website nach dem Import funktioniert, aber nicht die erwarteten Inhalte enthält, solltest du prüfen, ob tatsächlich der richtige Sicherungsstand importiert wurde.
Mögliche Ursachen sind beispielsweise:
- ältere SQL-Sicherung verwendet
- falsche Quelldatenbank exportiert
- Anwendung greift auf eine andere Datenbank zu
- Import war unvollständig
Importiere nicht sofort eine weitere Sicherung darüber. Kläre zuerst, welche Datenbank die Anwendung aktuell verwendet.
Import erfolgreich, aber Website verwendet weiterhin die alte Datenbank #
Das Erstellen und Importieren einer neuen Datenbank ändert nicht automatisch die Konfiguration deiner Website.
Die Anwendung verwendet weiterhin die Datenbankzugänge, die in ihrer Konfiguration hinterlegt sind.
Bei WordPress ist dies normalerweise:
wp-config.php
Fehler nach Änderung des Datenbankpassworts #
Wenn du während der Migration das Passwort des Datenbankbenutzers geändert hast, muss das neue Passwort auch in der Anwendung hinterlegt werden.
Eine Änderung in cPanel aktualisiert die Konfigurationsdateien deiner Website nicht automatisch.
Import erfolgreich, aber Tabellen fehlen #
Wenn nur ein Teil der erwarteten Tabellen vorhanden ist, prüfe zuerst die ursprüngliche SQL-Datei und die Importmeldung.
Mögliche Ursachen sind:
- unvollständiger Export
- abgebrochener Import
- nur ausgewählte Tabellen wurden exportiert
- Fehler während des Imports
Gehe nicht allein anhand einer erwarteten Tabellenanzahl davon aus, dass Tabellen fehlen. Anwendungen und Plugins können unterschiedlich viele Tabellen verwenden.
WordPress-Präfix nicht mit fehlenden Tabellen verwechseln #
Bei WordPress müssen Tabellen nicht mit:
wp_
beginnen.
Eine Installation kann beispielsweise ein Präfix wie:
abc_
verwenden.
Prüfe deshalb die tatsächlichen Tabellennamen, bevor du annimmst, dass keine WordPress-Daten vorhanden sind.
Import überschreibt nicht automatisch alle alten Daten #
Ob vorhandene Tabellen beziehungsweise Datensätze ersetzt werden, hängt von den SQL-Anweisungen in der Importdatei ab.
Eine SQL-Datei kann beispielsweise:
- neue Tabellen erstellen
- Datensätze einfügen
- vorhandene Tabellen löschen und neu erstellen
- bestehende Daten verändern
Deshalb solltest du niemals davon ausgehen, dass jeder Import automatisch einen identischen Datenbankzustand erzeugt.
DROP TABLE in der SQL-Datei #
Enthält die Sicherung Anweisungen wie:
DROP TABLE ...können vorhandene Tabellen vor ihrer Neuerstellung entfernt werden.
Das kann bei einer gezielten Wiederherstellung sinnvoll sein, ist bei einer falschen Zieldatenbank jedoch besonders gefährlich.
Achtung: Die Auswahl der richtigen Zieldatenbank ist bei einer SQL-Datei mit
DROP-Anweisungen besonders wichtig.
INSERT-Fehler nach einem abgebrochenen Import #
Wenn ein erster Import bereits Datensätze eingefügt hat, kann ein zweiter Versuch an denselben Datensätzen scheitern.
Das ist ein weiterer Grund, warum ein fehlgeschlagener Import nicht einfach wiederholt werden sollte.
Fehler wegen Fremdschlüsseln #
Bestimmte Anwendungen verwenden Beziehungen zwischen Tabellen, die durch sogenannte Fremdschlüssel abgesichert werden können.
Wenn ein Import gegen solche Beziehungen verstößt, kann der Datenbankserver eine entsprechende Fehlermeldung ausgeben.
Deaktiviere solche Prüfungen nicht auf Verdacht. Sie können die Konsistenz zusammengehöriger Daten schützen.
SQL_MODE- oder Versionsunterschiede #
Eine SQL-Datei aus einer anderen Datenbankserver-Version kann Anweisungen oder Daten enthalten, die vom Zielsystem strenger oder anders verarbeitet werden.
Wenn die Fehlermeldung auf einen konkreten SQL-Modus, Datentyp oder ungültigen Wert hinweist, sollte die Kompatibilität zwischen Quell- und Zielumgebung geprüft werden.
Serverweite Datenbankeinstellungen sollten nicht allein zur Umgehung eines einzelnen Importfehlers verändert werden.
Import aus sehr alter Hosting-Umgebung #
Bei Datenbanken aus deutlich älteren Serverumgebungen können Kompatibilitätsunterschiede häufiger auftreten.
Dazu können beispielsweise gehören:
- alte Zeichensätze
- abweichende Kollationen
- veraltete SQL-Syntax
- unterschiedliche Datenbankserver-Versionen
- alte Anwendungsstrukturen
In solchen Fällen ist die konkrete Fehlermeldung entscheidend für die weitere Vorgehensweise.
Import aus neuerer Datenbankserver-Version #
Auch der umgekehrte Fall kann problematisch sein: Eine SQL-Datei wurde auf einem System erzeugt, das Funktionen oder Kollationen unterstützt, die auf dem Zielsystem nicht vorhanden sind.
Prüfe deshalb bei Kompatibilitätsfehlern sowohl die Quell- als auch die Zielumgebung.
Nicht jede Fehlermeldung ist ein phpMyAdmin-Fehler #
phpMyAdmin ist die Oberfläche, über die du den Import startest. Viele angezeigte Fehlermeldungen stammen jedoch vom darunterliegenden Datenbankserver.
Ein Fehler während eines Imports bedeutet deshalb nicht automatisch, dass phpMyAdmin selbst defekt ist.
PHP-Limits und Datenbankfehler unterscheiden #
Ein Upload- oder Laufzeitlimit betrifft den technischen Importvorgang über die Weboberfläche.
Ein Fehler wie:
#1050 - Table already exists
betrifft dagegen die Verarbeitung der SQL-Anweisungen innerhalb der Datenbank.
Eine Erhöhung eines PHP-Limits löst einen solchen SQL-Fehler nicht.
PHP-Einstellungen nicht für jeden Importfehler ändern #
Wenn tatsächlich ein Upload- oder Laufzeitlimit relevant ist, können PHP-Einstellungen eine Rolle spielen.
Wie PHP-Einstellungen in cPanel verwaltet werden, behandeln wir später unter PHP-Einstellungen in cPanel ändern.
Prüfe aber zuerst die konkrete Fehlermeldung. SQL-Syntax-, Tabellen- oder Berechtigungsfehler werden durch größere PHP-Limits nicht behoben.
Wann ein neuer sauberer Import sinnvoll sein kann #
Ein neuer Import in eine saubere Datenbank kann insbesondere dann sinnvoll sein, wenn:
- die Zieldatenbank ausschließlich für diese neue Migration erstellt wurde
- keine produktiven Daten darin vorhanden sind
- der vorherige Import nachweislich nur teilweise ausgeführt wurde
- die Ursache des Abbruchs behoben wurde
- eine vollständige Ausgangssicherung vorhanden ist
Bevor du Daten entfernst, müssen diese Voraussetzungen eindeutig geklärt sein.
Wann du die bestehende Datenbank nicht leeren solltest #
Leere beziehungsweise lösche eine Datenbank nicht, wenn:
- eine aktive Website sie verwendet
- du nicht sicher weißt, wem sie gehört
- neue produktive Daten darin entstanden sein könnten
- keine aktuelle Sicherung vorhanden ist
- du den bisherigen Importzustand noch nicht analysiert hast
Grundregel: Unklarer Datenbankzustand bedeutet zuerst analysieren – nicht löschen.
Systematische Fehlersuche bei einem fehlgeschlagenen Import #
- Import nicht sofort erneut starten.
- Vollständige Fehlermeldung sichern.
- Richtige Zieldatenbank kontrollieren.
- Prüfen, ob bereits Tabellen importiert wurden.
- Größe und Format der SQL-Datei kontrollieren.
- Unterscheiden, ob ein Upload-, Laufzeit-, SQL-, Berechtigungs- oder Kompatibilitätsproblem vorliegt.
- Bei SQL-Fehlern Fehlernummer und betroffene Anweisung prüfen.
- Bei einer teilweise importierten Datenbank deren Zustand dokumentieren.
- Ursache beheben.
- Erst danach entscheiden, ob der Import fortgesetzt oder sauber neu begonnen wird.
Schnelle Einordnung typischer Fehler #
| Problem | Wahrscheinlicher Bereich |
|---|---|
| Datei lässt sich wegen Größe nicht hochladen | Upload-Limit |
| Import startet und bricht später ab | Laufzeit, Größe oder SQL-Fehler |
#1044 | Datenbankberechtigung / nicht erlaubte Datenbankoperation |
#1045 | Authentifizierung / Zugriff |
#1050 | Tabelle existiert bereits |
#1062 | Doppelter eindeutiger Wert |
#1064 | SQL-Syntax |
Unknown collation | Kompatibilität / Kollation |
| Falsche Umlaute oder Sonderzeichen | Zeichensatz / Export-Import-Kette |
| Website meldet Datenbankverbindungsfehler | Zugangsdaten / Benutzerzuweisung |
| Tabellen fehlen nach Import | Teilimport oder unvollständiger Export |
Vor einer Supportanfrage nichts „reparieren“ #
Wenn du die Ursache nicht eindeutig erkennst, ist es häufig besser, den aktuellen Zustand unverändert zu lassen.
Durch zusätzliche Lösch-, Import- oder SQL-Versuche können wichtige Hinweise auf die ursprüngliche Ursache verloren gehen.
Notiere beziehungsweise sichere deshalb zuerst die Fehlermeldung und den aktuellen Datenbankzustand.
Welche Informationen benötigt der Support? #
Für eine gezielte Analyse sind insbesondere folgende Angaben hilfreich:
- betroffene Domain beziehungsweise Anwendung
- vollständiger Name der Zieldatenbank
- Größe der SQL-Datei
- Dateiformat beziehungsweise Komprimierung
- ob die Datenbank vor dem Import leer war
- ob bereits Tabellen importiert wurden
- genaue Fehlernummer
- vollständiger Fehlertext
- betroffene Tabelle, sofern angezeigt
- ob es sich um Migration oder Wiederherstellung handelt
- aus welcher Hosting- beziehungsweise Datenbankumgebung die Sicherung stammt, sofern bekannt
Ein Screenshot der Fehlermeldung kann zusätzlich hilfreich sein.
Sicherheit: Übermittle keine Datenbankpasswörter und stelle SQL-Sicherungen mit sensiblen Daten nicht öffentlich zum Download bereit.
Zusammenfassung #
Wenn ein phpMyAdmin-Import fehlschlägt, solltest du ihn nicht sofort erneut starten. Prüfe zuerst die vollständige Fehlermeldung und kontrolliere, ob die Zieldatenbank bereits teilweise importierte Tabellen oder Datensätze enthält.
Probleme vor dem eigentlichen Import deuten häufig auf Dateigröße, Upload oder Format hin. Bricht ein bereits laufender Import ab, können Laufzeitgrenzen, SQL-Fehler oder Kompatibilitätsprobleme eine Rolle spielen.
Fehler wie #1044, #1045, #1050, #1062 oder #1064 weisen auf unterschiedliche Ursachen hin und sollten entsprechend der konkreten Meldung behandelt werden. Eine Erhöhung von PHP-Limits ist deshalb keine allgemeine Lösung für Datenbankfehler.
Besondere Vorsicht ist bei teilweise importierten Datenbanken erforderlich. Lösche bestehende Tabellen oder Datenbanken nur dann, wenn eindeutig feststeht, dass keine benötigten produktiven Daten betroffen sind und eine geeignete Sicherung vorhanden ist.
Die wichtigste Regel bei einem fehlgeschlagenen Import lautet deshalb: Fehlermeldung sichern, Datenbankzustand prüfen, Ursache bestimmen – und erst danach den nächsten Importversuch starten.
