Une importation de base de données avec phpMyAdmin peut échouer pour différentes raisons. Le fichier SQL peut être trop volumineux, l'importation peut s'interrompre pendant le traitement ou MySQL peut afficher un message d'erreur spécifique concernant les tables, les autorisations, les jeux de caractères ou les enregistrements existants.
Il est important de ne pas relancer immédiatement la même opération après un échec d'importation. Une importation interrompue peut déjà avoir créé une partie des tables et des données. Une seconde importation par-dessus cet état intermédiaire peut provoquer des erreurs supplémentaires.
Dans ce guide, nous vous montrons comment analyser systématiquement un échec d'importation phpMyAdmin, classer les messages d'erreur typiques et décider de la marche à suivre en toute sécurité.
Important : Note ou copie le message d'erreur complet avant de modifier quoi que ce soit. Le message exact est beaucoup plus utile pour l'analyse des erreurs que l'information générale selon laquelle l'importation „ ne fonctionne pas “.
D'abord, déterminer à quel endroit l'importation échoue #
Tous les erreurs d'importation n'ont pas la même cause. Vérifiez donc d'abord ce qui s'est exactement passé.
Les situations typiques sont :
- Le fichier SQL ne peut pas du tout être sélectionné ou téléchargé.
- phpMyAdmin signale une erreur avant même l'importation proprement dite
- l'importation démarre, mais s'interrompt pendant le traitement
- phpMyAdmin affiche un message d'erreur MySQL ou SQL concret
- L'importation est signalée comme réussie, mais le site web ne fonctionne pas ensuite
- une partie des tableaux a été importée, le reste est manquant
Ces cas doivent être traités différemment.
Avant un nouvel essai, vérifier l'état de la base de données #
Ouvrez la base de données cible concernée dans phpMyAdmin et vérifiez si des tables existent déjà.
Si une base de données vide était présente avant l'importation et que des tableaux s'affichent maintenant, au moins une partie du fichier SQL a été traitée.
Attention : Ne relancez pas simplement un import échoué sur une base de données partiellement importée. Cela peut provoquer des erreurs dues à des tables déjà existantes ou à des doublons de données.
Lire le message d'erreur en entier #
phpMyAdmin ou le serveur de base de données fournit un message concret pour de nombreux problèmes.
Note :
- Numéro d'erreur, le cas échéant
- texte d'erreur complet
- tableau concerné
- instruction SQL concernée, le cas échéant
- endroit approximatif où l'importation a été interrompue
Une capture d'écran du message complet peut également s'avérer utile lors d'une analyse ultérieure.
Le fichier SQL est supérieur à la limite de téléchargement autorisée #
Si phpMyAdmin n'accepte que les fichiers jusqu'à une certaine taille, un fichier SQL plus volumineux ne peut pas être importé via le téléchargement normal.
La page d'importation peut afficher une taille de fichier maximale autorisée en fonction de la configuration du serveur.
Si votre fichier SQL est supérieur à cette limite, le problème ne provient pas automatiquement de la base de données elle-même. Il est possible que le fichier n'atteigne même pas entièrement phpMyAdmin.
Important : Ne modifiez pas les limites PHP au hasard. Vérifiez d'abord quelle limite est réellement atteinte et si le paramètre en question peut ou doit être modifié par vos soins dans votre environnement d'hébergement.
Compresser le fichier SQL #
Selon la configuration de phpMyAdmin et du serveur, les fichiers SQL compressés peuvent être pris en charge.
Un fichier tel que :
base_de_donnees.sql
peut être considérablement compressé selon le contenu des données.
Une variante compressée prise en charge peut par exemple se présenter comme suit :
datenbank.sql.gz
Tu peux voir si et quels formats de compression sont acceptés sur l'interface d'importation ou dans la configuration concrète du serveur.
Cependant, la compression n'aide qu'en cas de problème de taille du fichier transféré. Elle ne résout pas les erreurs SQL, de privilèges ou de tables.
Importation démarrée, mais un délai d'attente (timeout) est survenu #
Dans le cas de fichiers SQL volumineux ou complexes, l'importation peut démarrer puis s'interrompre ultérieurement en raison d'une limite de temps d'exécution.
Cela diffère d'une simple limite de téléchargement : le fichier a été accepté et au moins partiellement traité.
Vérifiez impérativement dans ce cas si des tables et des enregistrements existent déjà dans la base de données cible.
Le navigateur affiche une page blanche ou la connexion est interrompue #
Si le navigateur n'affiche plus de message de réussite normal lors d'un import long, cela ne signifie pas automatiquement qu'aucun import n'a eu lieu.
Ouvrez ensuite à nouveau la base de données cible dans phpMyAdmin et vérifiez son état.
Ne relancez l'importation que lorsqu'il aura été établi ce qui a déjà été traité.
Base de données partiellement importée #
Les fichiers SQL sont généralement traités instruction par instruction. Si le processus s'interrompt en cours de route, les instructions précédentes peuvent déjà avoir été exécutées.
La base de données cible peut alors ressembler à ceci, par exemple :
Tableau A → présent
Tableau B → présent
Tableau C → présent
Tableau D → importation interrompue ici
autres tableaux → manquantsUne telle base de données n'est plus vide, mais elle n'est peut-être pas non plus complète.
Important : Traitez un import interrompu comme un état intermédiaire possible. Vérifiez d'abord la base de données avant de supprimer, de réimporter ou d'utiliser le site Web en production avec celle-ci.
Commencer à neuf ou continuer l'importation ? #
La bonne approche dépend du fichier SQL, de l'erreur et de l'état de la base de données cible.
Dans le cas d'une base de données nouvellement créée et exclusivement destinée à cette migration, un nouveau départ propre peut s'avérer plus judicieux que d'essayer de reprendre manuellement un import partiel incertain.
Si, en revanche, la base de données contient déjà des données de production, vous ne devez en aucun cas supprimer simplement les tables existantes.
Attention : Supprimez une base de données partiellement importée, ou réinitialisez-la, uniquement s'il est clairement établi qu'elle ne contient pas de données de production requises et qu'une sauvegarde initiale appropriée existe.
Erreur #1044 – Accès à la base de données refusé #
Un message avec un numéro d'erreur #1044 indique généralement un problème de droits d'accès lié à une base de données.
Cela peut se produire, par exemple, lorsque le fichier SQL tente d'utiliser ou de créer une base de données pour laquelle l'utilisateur de base de données actuel ou le compte d'hébergement ne possède pas les droits nécessaires.
Vérifiez en particulier si le fichier SQL contient des instructions telles que :
CRÉER LA BASE DE DONNÉES ...
UTILISER ...contient et si celles-ci correspondent à l'environnement cible.
Pourquoi CREATE DATABASE peut poser problème en hébergement #
Dans un environnement d'hébergement cPanel, les bases de données sont généralement créées via cPanel et associées au compte d'hébergement.
Par conséquent, un fichier SQL importé ne devrait pas tenter, sans vérification, de créer de nouvelles bases de données arbitraires au niveau du serveur.
Créez plutôt la base de données cible requise comme dans Créer une base de données MySQL dans cPanel décrit et importe ensuite les données dans cette base de données.
L'instruction USE fait référence à un ancien nom de base de données #
Un fichier SQL provenant d'un autre environnement d'hébergement peut contenir un nom de base de données antérieur.
Par exemple :
UTILISER alteraccount_wordpress;Au nouvel emplacement, en revanche, la base de données peut par exemple :
nouveau_compte_wordpress
s'appeler.
Une telle divergence peut être pertinente lors de l'importation.
Attention : Ne supprimez pas et ne modifiez pas aveuglément les instructions SQL. Vérifiez d'abord quelles instructions sont présentes, ce qu'elles font et quelle base de données cible doit réellement être utilisée.
Erreur #1045 – Accès refusé #
Erreur #1045 indique généralement une échec d'authentification ou un accès refusé à la base de données.
Si l'erreur se produit en lien avec une application, vérifie :
- nom d'utilisateur de base de données complet
- Mot de passe de l'utilisateur de la base de données
- Hôte de base de données
- Attribution de l'utilisateur à la base de données
- Autorisations de l'utilisateur
Nous vous expliquons comment configurer correctement un utilisateur de base de données sous Créer un utilisateur MySQL et l'attribuer à une base de données.
L'importation s'est déroulée avec succès, mais le site web affiche tout de même le message « #1045 » ou « Accès refusé » #
Dans ce cas, la base de données peut être entièrement importée et seule l'application utilise de mauvais identifiants de connexion.
Sous WordPress, vous devriez alors en particulier modifier les valeurs dans :
wp-config.php
contrôler.
Cela comprend :
DB_NAME
DB_USER
DB_PASSWORD
DB_HOSTUn nouvel import de base de données ne résout pas les identifiants de connexion incorrects de l'application.
Fehler #1050 – Table already exists #
Un message tel que :
#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 #
Erreur #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
indiquer.
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.
Important : Un
#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 #
Erreur #1064 weist typischerweise auf eine SQL-Anweisung hin, die vom Datenbankserver in dieser Form nicht verarbeitet werden kann.
Les causes possibles peuvent être :
- 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.
Vérifie d'abord :
- welche Kollation die Quelldatenbank verwendet
- welche Kollation der Zielserver unterstützt
- welcher Zeichensatz damit verbunden ist
- ob die Anwendung besondere Anforderungen hat
Attention : 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 contenir.
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.
Important : 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
- Texte d'erreur
- 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.
Attention : 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 Exporter une base de données avec phpMyAdmin.
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:
base_de_donnees.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.
Les causes possibles sont par exemple :
- ä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_
commencer.
Eine Installation kann beispielsweise ein Präfix wie:
abc_
utiliser.
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.
Attention : Die Auswahl der richtigen Zieldatenbank ist bei einer SQL-Datei mit
BAISSER-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.
Cela peut par exemple inclure :
- 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 Modifier les paramètres PHP dans cPanel.
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
Règle de base : 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 #
| Problème | 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:
- domaine ou application concerné
- 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
- texte d'erreur complet
- 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.
Sécurité Übermittle keine Datenbankpasswörter und stelle SQL-Sicherungen mit sensiblen Daten nicht öffentlich zum Download bereit.
Résumé #
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 ou #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.
