1 votes

La décharge de données échoue avec le code de sortie 1

Je suis dans mySQL Workbench en train d'essayer d'importer un datadump dans un fichier .sql (généré par phpMyAdmin) dans mySQL (administration du serveur>datadump>importer depuis le disque), et ça échoue avec la sortie suivante :

10:47:14 Restauration de C:\monfichier\localhost.sql ( )

En cours d'exécution : mysql.exe --host=127.0.0.1 --user=root --password=xxxxxxx --port=3306 --commentaires < C:\monfichier\localhost.sql

L'opération a échoué avec le code de sortie 1

10:47:15 L'importation de C:\monfichier\localhost.sql est terminée

Quand je consulte le schéma, il semble avoir importé 6 tables (sur environ 50) et presque aucune donnée du tout.

Errata :

  1. Il ne semble pas y avoir de contraintes ni de relations. Toutes les données sont ajoutées via plusieurs DROP TABLE IF EXISTS; CREATE TABLE; INSERT INTO séries avec des valeurs codées en dur.
  2. Le fichier contient un nombre substantiel de gros morceaux. Et le fichier lui-même fait plus de 400 Mo.
  3. Quand j'ai vérifié manuellement si l'effet de n'importe quelle clause du fichier fonctionne, j'ai découvert qu'il bute sur le INSERT INTO sql avec les très gros morceaux codés en dur. Pas sûr si c'est significatif ou non ?
  4. J'ai également remarqué que certains des morceaux ont une longueur supérieure à 32768, y a-t-il une limite supérieure sur la longueur des morceaux ?

2voto

Aaron Bush Points 237

Je n'ai pas réussi à remonter jusqu'à la cause première de ce problème, mais j'ai trouvé la source du problème. J'avais une très grande table de pièces jointes qui était écrite avec INSERT VALUES. J'ai supprimé cette table puis j'ai essayé de l'exécuter simplement en tant que script SQL. Mais j'ai obtenu une nouvelle erreur (dont je ne me souviens plus pour le moment.) En recherchant sur Google la nouvelle erreur, j'ai compris que le script était trop long pour s'exécuter sans augmenter la variable max_allowed_packet. En augmentant cette valeur à un nombre vraiment élevé, le script a pu s'exécuter.

0 votes

Je suis déjà tombé sur cela auparavant, et dans mon cas, le fait d'augmenter la taille du paquet dans les paramètres réseau de l'instance à une valeur plus grande a résolu le problème. J'oublie comment j'en suis arrivé à cette solution cependant... mais je me souviens qu'il y avait un raisonnement solide :)

1voto

Catherine MacInnes Points 1968

Avez-vous des contraintes de clé étrangère dans votre base de données? Si c'est le cas, vous devez vous assurer d'importer les tables dans un ordre qui permet l'application des clés étrangères. Si vous essayez de créer une table qui a une clé étrangère qui référence une table qui n'a pas encore été créée, vous obtiendrez ce genre d'erreur. Si c'est le problème, vous devrez soit manipuler votre fichier de sauvegarde pour l'obtenir dans l'ordre "correct", soit refaire la sauvegarde, une table à la fois dans un ordre qui sera acceptable. J'ai un script qui fait cela pour ma base de données, mais je n'ai jamais essayé de le faire via phpMyAdmin.

0 votes

Salut Catherine, Merci de t'intéresser :) J'ai ajouté plus d'informations à mon message en espérant que cela serait utile.

0 votes

Merci pour votre aide, je vous donnerais un vote positif pour votre peine, mais je n'ai pas encore 15 ans :)

0 votes

Pas de problème. Je suis content(e) que tu l'aies compris.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X