Prob : comment enlever innodb quand toutes mes tables sont en myisam

Bonjour,

j'espère être dans le bon forum et poser la bonne question, sinon, je m'en excuse.
J'ai regardé toutes les infos que j'ai trouvé sur les tables et innodb, et c'est parce que je ne vois pas de lien avec mon problème que je vous sollicite, quelque chose m'échappe mais je ne ais pas ce que je cherche.

J'explique, l'hébergeur d'un de mes sites change sa plate-forme et nous propose un système de migration automatique.
La nouvelle plateforme n'ayant plus le moteur Innodb, j'ai un message d'erreur avant la migration.
J'ai donc regardé mes tables avec phpmyadmin : elles sont toutes en MyIsam
j'ai fait un dump au cas où tous les engins appelés sont en MyIsam
J'ai demandé de l'aide à l'hébergeur en question et il m'a renvoyé sur l'état du serveur qui indique des variables innodb, mais aucune table
Hors, la seule commande que j'ai trouvé est alter table, donc il faut avoir une table à altérer pour ne plus avoir innodb.

j'ai des vues, mais elles ne semblent pas liées à un engin.

Du coup, je me dis que sur un mutualisé, ce n'est pas mon intervention qui va pouvoir enlever le innodb si toutes les variables sont des innodb_buffer, innodb_data etc. mais peut-être que je ne comprends pas qqch ?

pourriez-vous m'aider ?

merci

Tu as essayé ça ?

Code:

---

SELECT TABLE_NAME,ENGINE FROM information_schema.TABLES WHERE ENGINE="InnoDB"

---

Bonjour,

tout d'abord merci, je ne connaissais pas cette syntaxe
je viens de la tester textuellement j'ai eu ce retour :

MySQL n'a retourné aucun enregistrement. (Traitement en 1.2589 sec.)

j'en déduit qu'aucune table n'utilise innodb dans ma base.
alors pourquoi est-ce que ce moteur semble tourner ?
aurais-je du cache que je pourrais supprimer sans affecter ma base, est-ce que ça se fait ?
est-ce que cela pourrais venir du fait que j'ai des vues ?

merci

Lance cette requête, à la fin il y a des choses intéressantes :

Code:

---

SHOW ENGINE INNODB STATUS

---

Chez moi j'ai ça :

Code:

---

1 2 3 4 5 6 7

ROW OPERATIONS -------------- 0 queries inside InnoDB, 0 queries in queue 0 read views open inside InnoDB Main thread id 2548, state: sleeping Number of rows inserted 2422823, updated 130126, deleted 369791, read 699579124 0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s

---

Tu peux aussi chercher INNODB dans les triggers et les procédures :

Code:

---

SELECT * FROM INFORMATION_SCHEMA.ROUTINES WHERE upper(routine_definition) LIKE "%INNODB%"

---

Code:

---

SELECT * FROM INFORMATION_SCHEMA.TRIGGERS WHERE upper(action_statement) LIKE "%INNODB%"

---

Bonjour,
désolée du retard j'ai eu qqs soucis de pc

donc à la 1ère requête j'ai comme réponse

Citation:

---

Erreur

requête SQL:

SHOW ENGINE INNODB STATUS

MySQL a répondu:Documentation
#1227 - Access denied; you need the SUPER privilege for this operation

---

à la 2ème :

Citation:

---

MySQL n'a retourné aucun enregistrement. (Traitement en 0.0020 sec.)
requête SQL:
SELECT *
FROM INFORMATION_SCHEMA.ROUTINES
WHERE upper( routine_definition ) LIKE "%INNODB%"
LIMIT 0 , 30

---

et à la 3ème :

Citation:

---

MySQL n'a retourné aucun enregistrement. (Traitement en 1.2521 sec.)
requête SQL:
SELECT *
FROM INFORMATION_SCHEMA.TRIGGERS
WHERE upper( action_statement ) LIKE "%INNODB%"
LIMIT 0 , 30

---

ce qui me laisse à penser très sérieusement que le problème vient du serveur et non de ma base et comme je suis sur un mutualisé que c'est à mon hébergeur de faire le nécessaire et non à moi.

est-ce que je peux en toute bonne foi insister auprès d'eux après ces tests ou bien dois-je encore me poser la question ?

merci encore

Je pense effectivement que c'est la faute de l'hébergeur qui avait déjà commis la première faute en voulant interdire InnoDB.

C'est bien ce que j'avais dit : Change d'hébergeur ! :aie:

bonjour,

Hmm je ne serai pas aussi tranchant.

D'apres ceci :

Citation:

---

Erreur

requête SQL:

SHOW ENGINE INNODB STATUS

MySQL a réponduocumentation
#1227 - Access denied; you need the SUPER privilege for this operation

---

Vous utilisez une utilisateur qui n'a pas tous les droits.

Du coup vos requêtes sur les vues de "INFORMATION_SCHEMA" ne vont pas vous retourner tous les résutlats.

Cf la doc : http://dev.mysql.com/doc/refman/5.0/...on-schema.html

Citation:

---

Chaque utilisateur MySQL a le droit d'accéder à ces tables, mais seules les lignes concernant des objets pour lesquels il a des droits seront visibles.

---

J'imagine bien que l'hébergeur ne donne pas le droit SUPER aux clients dont il héberge les sites sur des serveurs mutualisés !

Donc c'est logique que la requête retourne ce résultat et il faut renvoyer la balle chez l'hébergeur en lui disant que le problème avec InnoDB, c'est lui ! :aie:

Bonjour,

tout d'abord connaissant mal ce moteur et son intérêt vis à vis de ce site en particulier (à priori aucun vu que mes tables ne sont pas basées dessus) je ne voyais pas en quoi cette réponse simpliste "si ton hébergeur retire innodb changes-en" pouvait me permettre de faire ce choix.

ça manquait d'explications, je trouve.

tu es effectivement modérateur et tu es beaucoup plus participatif que moi sur ce forum, tu as donc indéniablement plus de crédit que moi ici, mais malheureusement 1 ce n'était pas l'info que je recherchais en priorité, moi je voulais comprendre ce qui se passait et 2 ça n'était pas suffisant pour moi, car concrètement ça ne signifiait rien pour moi.

mais merci d'avoir pris le temps de développer dans ce nouveau message que d'après plusieurs avis plus compétents que le mien le problème vient surement d'eux.

bonne continuation tout de même

Citation:

---

Envoyé par virgrennes

J'ai demandé de l'aide à l'hébergeur en question et il m'a renvoyé sur l'état du serveur qui indique des variables innodb, mais aucune table
Hors, la seule commande que j'ai trouvé est alter table, donc il faut avoir une table à altérer pour ne plus avoir innodb.

---

Peux tu être plus précis, car ces deux point ne sont pas bien clairs.
Qu'est ce que ton hébergeur t'a envoyé précisément ?

Bonjour,

donc je pose la question à l'hébergeur de pourquoi j'ai un problème avec innodb car mes tables sont en myisam, il répond :

Citation:

---

Bonjour Virginie,

Il y' a plusieurs requêtes en Innodb. Vous pouvez vérifier cela dans serveur mysql -> état -> requêtes Innodb.
Merci donc de passer en myisam.

---

et il me propose un lien pour les corriger, qui en fait invite à faire un

Citation:

---

alter table

---

je lui ai indiqué aussi le script de ma base si je l'exporte, de manière à bien lui montrer que tout est en myisam et pour qu'il me dise quelles autres tables je suis censée chercher.
mais je n'ai pas eu de réponse.

du coup, soit les variables innodb travaillent sur des tables auxquelles je n'ai pas accès et je le sais une fois pour toute, soit c'est du cache et, en ce cas, je peux peut-être exporter ma base, tout supprimer et vider, la réimporter, mais je préfère éviter de faire ça inutilement.

soit, et je viens d'y penser, mes tables ont beau être en myisam, cela viendrait de mes requêtes depuis mon code php ? et en ce cas, c'est la manière donc je consulte la base qui poserait problème ?

qu'en pensez-vous ?

merci

InnoDB est un moteur de base de données. On déclare qu'on veut utiliser ce moteur pour une table à la création de la table.

Alors à moins que ton code applicatif crée des tables en précisant ENGINE=InnoDB, je ne vois pas comment une autre requête pourrait spécifier du InnoDB ! 8O

c'est ce que j'avais cru comprendre aussi, mais au bout d'un moment, à force de chercher, je sèche ...

Certaines de tes requêtes ont probablement besoin de tables temporaires (créés automatiquement par Mysql). Peut être qu'il les créent en InnoDB...

Chez moi, cette requête me retourne "InnoDB" :

Code:

---

show variables like "default_storage_engine"

---

Citation:

---

Il y' a plusieurs requêtes en Innodb. Vous pouvez vérifier cela dans serveur mysql -> état -> requêtes Innodb.

---

Ça t'a donné quoi comme requêtes ?

donc à la requête "show variables like "default_storage_engine"" le système me répond

Citation:

---

Votre requête SQL a été exécutée avec succès (Traitement en 0.0006 sec.)

---

;)

je crois que c'est le problème de droit super utilisateur ou plutôt la limite de droit de mon utilisateur.

quant à l'état du serveur, j'ai 2 tableaux :
un tableau "requête sql" et un tableau "innodb"

dans le tableau "innodb", j'ai ces variables là :

Citation:

---

Variable Valeur Description
Variables État InnoDB Documentation
Innodb_buffer_pool_pages_data 8 132 Le nombre de pages contenant des données.
Innodb_buffer_pool_pages_dirty 0 Le nombre de pages contenant des données "dirty"
Innodb_buffer_pool_pages_flushed 2 191 k Le nombre de pages de mémoire-tampon qui ont été effacées.
Innodb_buffer_pool_pages_free 1 Le nombre de pages libres
Innodb_buffer_pool_pages_latched 0 Le nombre de pages dans la réserve InnoDB qui sont actuellement en train d'être lues ou écrites, ou qui ne peuvent être supprimées pour une autre raison.
Innodb_buffer_pool_pages_misc 59 Le nombre de pages occupées car elles ont été déallouées en raison de verrous sur les enregistrements. Cette valeur peut également être calculée comme suit: Innodb_buffer_pool_pages_total - Innodb_buffer_pool_pages_free - Innodb_buffer_pool_pages_data.
Innodb_buffer_pool_pages_total 8 192 Taille totale de la réserve, en pages.
Innodb_buffer_pool_read_ahead_rnd 87 k Le nombre de lectures discontinues effectuées par InnoDB. Ceci survient lorsqu'une requête doit balayer une large portion de table en ordre discontinu.
Innodb_buffer_pool_read_ahead_seq 37 k Le nombre de lectures séquentielles effectuées par InnoDB. Ceci survient quand InnoDB fait un parcours séquentiel intégral de la table.
Innodb_buffer_pool_read_requests 5 115,87 M Le nombre de requêtes de lectures "logiques" effectuées par InnoDB.
Innodb_buffer_pool_reads 11 M Le nombre de lectures que InnoDB n'a pu faire à partir de la réserve, menant à une lecture directe d'une page.
Innodb_buffer_pool_wait_free 0 Normalement, l'écriture dans la réserve InnoDB se passe en arrière-plan. Cependant, s'il est nécessaire de lire ou de créer une page et qu'aucune page n'est disponible, InnoDB doit attendre que des pages soient libérées. Ceci compte le nombre de fois qu'une telle attente a été nécessaire. Si la taille de la réserve est adéquate, cette valeur devrait être petite.
Innodb_buffer_pool_write_requests 12 M Le nombre d'écritures faites dans la réserve InnoDB.
Innodb_data_fsyncs 3 362 k Le nombre d'opérations fsync() faites jusqu'à présent.
Innodb_data_pending_fsyncs 0 Le nombre d'opérations fsync() actuellement en attente.
Innodb_data_pending_reads 0 Le nombre actuel de lectures en attente.
Innodb_data_pending_writes 0 Le nombre actuel d'écritures en attente.
Innodb_data_read 275,66 G La quantité d'octets lus jusqu'à présent.
Innodb_data_reads 12 M Le nombre total de lectures de données.
Innodb_data_writes 4 138 k Le nombre total d'écritures de données.
Innodb_data_written 73,99 G La quantité d'octets écrits jusqu'à présent.
Innodb_dblwr_pages_written 2 191 k Le nombre de pages utilisées pour des écritures "doublewrite".
Innodb_dblwr_writes 333 k Le nombre d'écritures "doublewrite" effectuées.
Innodb_log_waits 0 Le nombre d'attentes en raison d'un tampon du fichier témoin trop petit; il fallait attendre qu'il se libère avant de continuer.
Innodb_log_write_requests 2 999 k Le nombre de requêtes d'écritures sur le fichier témoin.
Innodb_log_writes 1 618 k Le nombre d'écritures physiques au fichier témoin.
Innodb_os_log_fsyncs 1 877 k Le nombre d'écritures fsync() sur le fichier témoin.
Innodb_os_log_pending_fsyncs 0 Le nombre de fsync() du fichier témoin en attente.
Innodb_os_log_pending_writes 0 Le nombre d'écritures du fichier témoin en attente.
Innodb_os_log_written 2 055 M Le nombre d'octets écrits sur le fichier témoin.
Innodb_page_size 16 k La taille de page InnoDB telle que compilée (16 Ko par défaut). Plusieurs valeurs sont comptées par page; la taille de page leur permet d'être facilement converties en octets.
Innodb_pages_created 34 k Le nombre de pages créées.
Innodb_pages_read 17 M Le nombre de pages lues.
Innodb_pages_written 2 191 k Le nombre de pages écrites.
Innodb_row_lock_current_waits 0 Le nombre de verrous d'enregistrements actuellement en attente.
Innodb_row_lock_time 311 k Le temps total utilisé pour acquérir un verrou, en millisecondes.
Innodb_row_lock_time_avg 724 Le temps d'attente moyen pour acquérir un verrou, en millisecondes.
Innodb_row_lock_time_max 12 k Le temps d'attente maximum pour acquérir un verrou, en millisecondes.
Innodb_row_lock_waits 430 Le nombre de fois qu'on a dû attendre pour un verrou.
Innodb_rows_deleted 179 k Le nombre d'enregistrements supprimés des tables InnoDB.
Innodb_rows_inserted 759 k Le nombre d'enregistrements insérés dans des tables InnoDB.
Innodb_rows_read 15,92 G Le nombre d'enregistrements lus dans des tables InnoDB.
Innodb_rows_updated 1 109 k Le nombre d'enregistrements mis à jour dans des tables InnoDB.

---

on y voit effectivement une activité sur des tables innodb, mais sans que leur nom soit précisé...

j'ai mis en pièce jointe l'impression d'écran de la liste (très courte, c'est un site simple) des tables que j'utilise et leur type.

La bonne question est :
Peux t'on obtenir ces variables par base de donnée ?
A mon avis, non. Donc si ton Mysql est mutualisé, ça ne prouve pas que c'est toi qui utilises InnoDB...

De plus, si tu avais été seule, vu que tu as 369 enregistrement dans ta base, je me demande comment tu aurais pu avoir de telles valeurs :

Citation:

---

Innodb_data_written 73,99 G La quantité d'octets écrits jusqu'à présent.
Innodb_rows_inserted 759 k Le nombre d'enregistrements insérés dans des tables InnoDB.

---

Bonsoir, merci beaucoup pour tout ça, si cela ne vous dérange pas, je vais indiquer toutes ces infos à mon hébergeur et prendre la décision qui s'impose en conséquence.

en tout cas j'ai appris beaucoup et je vous remercie de votre patience et de votre aide.

bonne continuation