Plantage jeedom a 1h31

[sangohan123]

si je lance l’optimisation de la table « historyArch » je fait tout planté les autre RAS …
on approche du problème…

$table = historyArch;
$scenario->setLog('DB '.$table);
		 DB::Prepare('OPTIMIZE TABLE `' . $table . '`', array(), DB::FETCH_TYPE_ROW);
$scenario->setLog('optimize DB OK');

Que faire avec cette table ?

[jpty]

Essayez de la réparer: Message d'erreur jeedom history sur MAJ Jeedom - #10 par bobaxx
Déjà voir si mysqlcheck trouve une erreur.
Il fonctionne avec l’utilisateur jeedom et le mdp en bas de la page Réglages / Système / Configuration onglet >_OS/DB

Ou la droper si vous pouvez perdre les historiques suivi d’une vérification de la bdd pour la recréer vide.

[sangohan123]

Bien joué jpty,
la procédure de Bobaxx, semble faire effet,

j’ai pus lancer 3/4 fois le scenario dans jeedom pas eu de problème …
et j’ai lancé le cron a la mano pas de problème !!!

A voir dans les prochains jour

Merci a tout le monde 142 messages en 1jours bravo vive Jeedom !

[jpty]

Le fait de passer le moteur de la DB d’InnoDB à MyISAM dans la procédure de bobaxx simplifie l’optimize.
En InnoDB, il fait une copie puis analyse. Ce qui ne fonctionne pas chez moi. Il y a toujours autant d’espace libre dans la table 30Mo / 190 pour historyArch

La vérification de la bdd ne repasse pas les tables en InnoDB. Je ne connais pas l’impact de MyIsam vs InnoDB pour Jeedom. Pour mes 2 tables qui ne s’optimisaient pas, je les ai repassées en InnoDB après optimisation en MyISAM.

Il doit quand même y avoir un pb hardware. L’erreur d’inode au début est totalement anormale. fsck ?