Maintenance des tables

Analysez, vérifiez, optimisez ou réparez les tables sélectionnées, avec les opérations dont dispose le serveur.

Où le trouver : Espace de travail › Outils › Maintenance des tables

Ouvrez Maintenance des tables depuis la barre latérale du workspace. Sélectionnez les tables dans l'arborescence de gauche (la case d'une base coche toutes ses tables, ou cochez-les une à une), choisissez l'opération en haut — ANALYZE, CHECK, CHECKSUM, OPTIMIZE ou REPAIR — et cliquez sur Exécuter. À côté du bouton, vous voyez combien de tables sont sélectionnées.

Les résultats apparaissent en dessous, une ligne par message que le serveur renvoie pour chaque table : les avertissements sont surlignés en orange et les erreurs en rouge. Sur InnoDB, OPTIMIZE répond par une note : il reconstruit la table et l'analyse à la place. CHECKSUM donne un nombre par table ; le même nombre sur deux serveurs signifie les mêmes lignes. REPAIR ne s'exécute que sur les tables dont le moteur de stockage sait se réparer : MyISAM, Aria, ARCHIVE et CSV. Avant de le lancer, une ligne sous les modificateurs indique combien de tables sélectionnées seront ignorées, et chacune reçoit une ligne qui explique pourquoi ; sur InnoDB, la ligne suggère OPTIMIZE, qui reconstruit la table. Sur le Mac, cliquez sur l'en-tête d'une colonne pour trier les résultats ; Effacer les résultats vide la liste. Pendant qu'une opération s'exécute, une barre de progression et Annuler apparaissent à côté d'Exécuter ; les tables sont traitées une à une, donc annuler s'arrête avant la suivante.

L’arbre dispose d’un filtre par nom dans son en-tête, comme celui de l’Éditeur SQL : saisissez une partie du nom d’une base ou d’une table pour restreindre la liste. Chaque base charge ses tables la première fois que vous la dépliez ; si vous filtrez alors que des bases ne sont pas dépliées, le pied du panneau indique combien il en manque et propose de les charger. Tout sélectionner parcourt toutes les bases du serveur sauf ses bases système, que vous pouvez cocher à la main, et peut prendre quelques secondes. Si le serveur refuse l'opération sur une table, cette table reçoit une ligne d'erreur avec le message du serveur.

SQL Server

Il y a trois opérations : ANALYZE (UPDATE STATISTICS), CHECK (DBCC CHECKTABLE) et OPTIMIZE (ALTER INDEX ALL … REBUILD). Il n'y a pas de REPAIR —il exige la base en mode mono-utilisateur et peut perdre des données— ni de CHECKSUM. OPTIMIZE verrouille la table pendant la reconstruction : la reconstruction en ligne n'existe que dans l'édition Enterprise, et pas avec des index spatiaux.

PostgreSQL

Il y a deux opérations : ANALYZE et OPTIMIZE, qui exécute VACUUM puis REINDEX TABLE CONCURRENTLY et donne donc deux lignes par table ; aucune des deux n'arrête la table. Il n'y a ni CHECK —le noyau n'a rien de tel—, ni REPAIR, ni CHECKSUM, ni modificateurs. VACUUM FULL, le seul qui rend de l'espace au système, est laissé de côté à dessein : il verrouille toute la table pendant qu'il la réécrit. Sur un serveur antérieur à la version 12, OPTIMIZE s'arrête au VACUUM et la ligne de l'index dit pourquoi.

Mots-clés : ANALYZE, CHECK, OPTIMIZE, REPAIR, maintenance, CHECKSUM

Modificateurs d'opération

Options supplémentaires qui modifient le comportement de l'opération.

Où le trouver : Maintenance des tables › Grille de modificateurs

Sous l'opération, la grille de modificateurs : LOCAL (sans binlog), FOR UPGRADE, QUICK, FAST, MEDIUM, EXTENDED, CHANGED et USE_FRM. Chaque opération n'active que ceux qu'elle accepte, et changer d'opération les décoche. Par exemple, QUICK accélère CHECK en ne parcourant pas les lignes à la recherche de liens incorrects, FOR UPGRADE vérifie la compatibilité avec la version actuelle du serveur, et LOCAL garde ANALYZE, OPTIMIZE et REPAIR hors du journal binaire, pour que les répliques ne les répètent pas. Avec CHECKSUM, QUICK ne renvoie que la somme qu'une table tient à jour en direct, et la plupart n'en tiennent aucune. USE_FRM reconstruit l'index d'une table MyISAM à partir de sa définition, en dernier recours.

La grille n'affiche que les modificateurs dont dispose le moteur. Avec SQL Server, CHECK accepte PHYSICAL_ONLY (seulement la structure, plus rapide) et EXTENDED_LOGICAL_CHECKS ; avec PostgreSQL, il n'y en a aucun et la section n'est pas dessinée.

Mots-clés : QUICK, EXTENDED, FOR UPGRADE, LOCAL, modificateurs