ERROR 1017 (HY000): Can't find file: '.frm' (errno: 13) [Résolu]

[VLE2011]

Bonjour,

J'ai tenté un "test de reprise de données" mysql un peu sauvage sur une application OTRS.
L'ancienne application est installée sur un serveur windows.
La nouvelle application est installée sur un serveur linux.

Cette application possède environ 90 tables mysql mais seules 5 contiennent l'historique que je souhaite récupérer.

J'ai donc copié les 3 fichiers .frm, .MYD et .MYI des 5 tables qui m'interessent de l'ancienne application, et je les ai collé en lieu et place des fichiers de la nouvelle application.
Puis j'ai fait un restart de mysql.

Comme cela ne fonctionnait pas, j'ai remis en place les anciens fichiers. Puis j'ai fait un nouveau restart de mysql.

Malheureusement, pour chacune de ces tables, j'obtiens le message :

Code :

1
2
mysql> SELECT * FROM ticket;
ERROR 1017 (HY000): Can't find file: './otrs/ticket.frm' (errno: 13)

alors que le fichier .frm en question est bien présent.
Toutes les autres tables de la Database sont bien accessibles.

Que pourrais-je faire pour rendre mes 5 tables à nouveau accessibles ?

[Aurélien LEQUOY]

dump :
mysqldump -u root -p MA_BASE > backup.txt


load :
mysql -u root -p MA_BASE < backup.txt



MySQL a développer des bonnes fonctions autant les utilisés. Petites précision ton backup "sauvage" marche qu'avec le moteur de stockage MyISAM

[VLE2011]

Merci pour la réponse rapide.

Si je comprends bien, je peux faire :

- une récupération propre des 5 tables depuis ma "copie manuelle de sauvegarde" :

Code :

mysqldump -u root -p DATABASE_SVG table1 table2 table3 > backup_tables.txt

- et les réinjecter dans ma database qui ne marche plus :

Code :

mysql -u root -p DATABASE table1 table2 table3 < backup_tables.txt

[NicoD.]

Sincèrement, le mieux est de faire un dump complet de la base de départ, et de recharger ce dump dans la base d'arrivée.

Toute autre manière de faire me semble risquée A mon travail, un administrateur a voulu faire ce type d'opération avec des tables en INNODB. Au final, nous avons rencontré des soucis de gestion des auto_increments.

[VLE2011]

OK merci pour le conseil !

Je passe en résolu et je viendrais compléter selon le résultat de mes tests (car je vais quand même tester la restauration "table par table" qui me ferait gagner du temps).