Maintenance des tables
Ouvrir dans CalíopeAnalysez, 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 appuyez 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 quatre opérations : ANALYZE (UPDATE STATISTICS), CHECK (DBCC CHECKTABLE), OPTIMIZE (ALTER INDEX ALL … REBUILD) et CHECKSUM (CHECKSUM_AGG(BINARY_CHECKSUM(*)), sur la table entière). La somme ne compte pas les colonnes text, ntext, image, xml ni celles d’un type comme geometry, et le résultat les nomme à côté : deux tables qui ne diffèrent que là donnent la même somme. Une table sur un schéma de partition propose de reconstruire une seule partition. Il n’y a pas de REPAIR : il exige la base en mode mono-utilisateur et peut perdre des données. 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 trois opérations : ANALYZE, OPTIMIZE, qui exécute VACUUM puis REINDEX TABLE CONCURRENTLY, et donne donc deux lignes par table, et CHECK, avec l’extension amcheck : bt_index_check sur chaque index B-tree et, depuis la 14, verify_heapam sur la table. Sans l’extension, CHECK donne une note avec CREATE EXTENSION amcheck. Aucune n’arrête la table. Il n’y a ni REPAIR ni CHECKSUM. VACUUM FULL, la seule qui rend de l’espace au système, est laissée de côté exprès : elle verrouille toute la table pendant qu’elle la réécrit. Sur un serveur antérieur à la 12, OPTIMIZE s’arrête au VACUUM et la ligne de l’index dit pourquoi.
ClickHouse
Avec ClickHouse, il y a trois opérations : CHECK, qui renvoie une ligne par partie de la table ; OPTIMIZE, qui fusionne ses parties ; et ANALYZE, qui calcule les statistiques de colonne dont l'optimiseur se sert pour ordonner les filtres : ADD STATISTICS avec tdigest et uniq sur les colonnes de nombres et de dates, uniq sur celles de texte, et MATERIALIZE STATISTICS, qui attend la fin. Un Array ou un Map ne prennent pas de statistiques, et une table sans colonne qui les accepte le dit. 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 y a trois opérations. ANALYZE rassemble les statistiques de la table et de ses index avec DBMS_STATS.GATHER_TABLE_STATS, et la ligne du résultat dit combien de lignes comptent les statistiques et quand elles ont été rassemblées ; sans privilège sur une table d’un autre schéma, elle dit qu’elles n’ont pas pu être rassemblées et le message du serveur suit. CHECK est ANALYZE TABLE … VALIDATE STRUCTURE CASCADE ONLINE : il vérifie la table et ses index sans bloquer les écritures. Sur une table partitionnée, c’est CASCADE FAST, qui dit s’il y a un dommage sans le détailler, car la forme complète demande une table INVALID_ROWS dans votre schéma. OPTIMIZE est ALTER TABLE … SHRINK SPACE CASCADE : il compacte en ligne la table et ses index et rend l’espace libre. Si la table n’avait pas ROW MOVEMENT, Calíope l’active pour l’opération puis le désactive. Si la table n’accepte pas SHRINK (ORA-10631 ou ORA-10635 : un index basé sur une fonction, une vue matérialisée ON COMMIT au-dessus, un tablespace sans ASSM), Calíope la réécrit avec MOVE ONLINE et la ligne le dit. Sur une table partitionnée, vous pouvez choisir une partition (MODIFY PARTITION … SHRINK SPACE CASCADE). Il n’y a ni REPAIR ni CHECKSUM : Oracle n’a pas ces opérations par table. Annuler interrompt aussi la table en cours : le serveur coupe son instruction (ORA-01013) et cette table ne reçoit pas de ligne dans la liste.
TiDB
Avec TiDB, il y a deux opérations : ANALYZE et CHECK, qui exécute ADMIN CHECK TABLE —il compare les index aux lignes— une table à la fois. S’il ne trouve rien, la ligne dit que la table ne présente aucun problème ; s’il trouve quelque chose, c’est le message du serveur, qui nomme l’index. Il n’y a ni REPAIR, ni CHECKSUM, ni OPTIMIZE : TiDB ne les a pas —son stockage se compacte seul— et ils ne sont pas proposés.
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.
MySQLMariaDBAurora
Avec une seule table cochée, OPTIMIZE permet de choisir l’une de ses partitions. Calíope la reconstruit avec REBUILD PARTITION et l’analyse avec ANALYZE PARTITION, car sur InnoDB OPTIMIZE PARTITION reconstruirait la table entière. Cette opération va dans le binlog même si vous cochez le modificateur qui l’évite : ALTER TABLE ne l’accepte pas.
Mots-clés : ANALYZE, CHECK, OPTIMIZE, REPAIR, maintenance, CHECKSUM