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.

ClickHouse

Avec ClickHouse, il y a deux opérations : CHECK, qui renvoie une ligne par partie de la table, et OPTIMIZE, qui fusionne ses parties. ANALYZE, REPAIR et CHECKSUM n'existent pas dans le moteur et n'apparaissent pas. Avec une seule table cochée apparaît Partition, pour optimiser une partition plutôt que la table entière.

Oracle

Avec Oracle, il n’y a qu’une opération : ANALYZE, qui collecte les statistiques de la table et de ses index avec DBMS_STATS.GATHER_TABLE_STATS. La ligne du résultat indique combien de lignes comptent les statistiques et quand elles ont été collectées. Il n’y a ni CHECK, ni REPAIR, ni CHECKSUM, ni OPTIMIZE : Oracle n’a pas ces opérations par table, et elles ne sont pas proposées. Sans privilège sur une table d’un autre schéma, la ligne indique que les statistiques n’ont pas pu être collectées, avec le message du serveur en dessous. Annuler interrompt aussi la table en cours : le serveur coupe son DBMS_STATS (ORA-01013) et cette table n’a pas de ligne dans la liste.

Avec une étiquette d’environnement en lecture seule, cet outil n’est pas proposé. Avec une étiquette qui confirme les écritures, ANALYZE, OPTIMIZE et REPAIR demandent une fois par lot ; CHECK et CHECKSUM, qui lisent, ne demandent pas.

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.

ClickHouse

Avec ClickHouse, le seul modificateur est FINAL, pour OPTIMIZE, et il est désactivé au départ : il force la table —ou la partition— en une seule partie, et le cocher affiche un avertissement : cela peut prendre des heures et demander le double d'espace disque.

Oracle

Avec Oracle, il n’y a aucun modificateur, et la section n’est pas affichée.

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