Tabellen-Wartung
In Calíope öffnenAnalysiert, prüft, optimiert oder repariert die ausgewählten Tabellen, mit den Operationen, die der Server hat.
Wo es zu finden ist: Workspace › Werkzeuge › Tabellenwartung
Öffne Tabellenwartung über die Seitenleiste des Workspace. Wähl die Tabellen im Baum links aus (das Kästchen einer Datenbank markiert alle ihre Tabellen, oder du markierst sie einzeln), wähl oben die Operation — ANALYZE, CHECK, CHECKSUM, OPTIMIZE oder REPAIR — und drück auf Ausführen. Neben dem Button siehst du, wie viele Tabellen ausgewählt sind.
Die Ergebnisse erscheinen darunter, eine Zeile pro Meldung, die der Server für jede Tabelle zurückgibt: Warnungen sind orange hervorgehoben, Fehler rot. Bei InnoDB antwortet OPTIMIZE mit einem Hinweis: Es baut die Tabelle neu auf und analysiert sie stattdessen. CHECKSUM liefert eine Zahl pro Tabelle; dieselbe Zahl auf zwei Servern bedeutet dieselben Zeilen. REPAIR läuft nur auf Tabellen, deren Speicher-Engine sich reparieren kann: MyISAM, Aria, ARCHIVE und CSV. Bevor du es ausführst, sagt eine Zeile unter den Modifikatoren, wie viele der ausgewählten Tabellen übersprungen werden, und jede bekommt eine Zeile mit dem Grund; bei InnoDB schlägt die Zeile OPTIMIZE vor, das die Tabelle neu aufbaut. Auf dem Mac sortierst du die Ergebnisse per Klick auf einen Spaltenkopf; Ergebnisse leeren leert die Liste. Während eine Operation läuft, erscheinen neben Ausführen ein Fortschrittsbalken und Abbrechen; die Tabellen werden nacheinander verarbeitet, also hält Abbrechen vor der nächsten an.
Der Baum hat einen Filter nach Namen in der Kopfzeile, genau wie im SQL-Editor: Tipp einen Teil eines Datenbank- oder Tabellennamens ein, um die Liste einzugrenzen. Jede Datenbank lädt ihre Tabellen beim ersten Aufklappen; filterst du bei noch nicht aufgeklappten Datenbanken, nennt die Fußzeile die fehlende Anzahl und bietet an, sie zu laden. Alles auswählen durchläuft alle Datenbanken des Servers außer seinen Systemdatenbanken, die du von Hand markieren kannst, und kann einige Sekunden dauern. Lehnt der Server die Operation für eine Tabelle ab, bekommt diese Tabelle eine Fehlerzeile mit der Meldung des Servers.
SQL Server
Es gibt vier Operationen: ANALYZE (UPDATE STATISTICS), CHECK (DBCC CHECKTABLE), OPTIMIZE (ALTER INDEX ALL … REBUILD) und CHECKSUM (CHECKSUM_AGG(BINARY_CHECKSUM(*)), über die ganze Tabelle). Die Prüfsumme zählt Spalten vom Typ text, ntext, image und xml und solche eines Typs wie geometry nicht mit, und das Ergebnis nennt sie daneben: Zwei Tabellen, die sich nur dort unterscheiden, ergeben dieselbe Summe. Eine Tabelle auf einem Partitionsschema bietet an, eine einzelne Partition neu aufzubauen. REPAIR gibt es nicht: Es verlangt die Datenbank im Einzelbenutzermodus und kann Daten verlieren. OPTIMIZE sperrt die Tabelle, während es sie neu aufbaut: Den Online-Neuaufbau gibt es nur in der Enterprise-Edition, und nicht mit räumlichen Indizes.
PostgreSQL
Es gibt drei Operationen: ANALYZE, OPTIMIZE, das VACUUM und danach REINDEX TABLE CONCURRENTLY ausführt und daher zwei Zeilen pro Tabelle liefert, und CHECK mit der Erweiterung amcheck: bt_index_check auf jedem B-Tree-Index und ab 14 verify_heapam auf der Tabelle. Ohne die Erweiterung liefert CHECK eine Notiz mit CREATE EXTENSION amcheck. Keine hält die Tabelle an. Es gibt kein REPAIR und kein CHECKSUM. VACUUM FULL, die einzige, die dem System Platz zurückgibt, fehlt mit Absicht: Sie sperrt die ganze Tabelle, während sie sie neu schreibt. Auf einem Server vor 12 bleibt OPTIMIZE beim VACUUM, und die Zeile des Index sagt, warum.
ClickHouse
Mit ClickHouse gibt es drei Operationen: CHECK, das für jeden Part der Tabelle eine Zeile liefert; OPTIMIZE, das ihre Parts zusammenführt; und ANALYZE, das die Spaltenstatistiken berechnet, mit denen der Optimierer die Filter ordnet: ADD STATISTICS mit tdigest und uniq auf Zahlen- und Datumsspalten, uniq auf Textspalten, und MATERIALIZE STATISTICS, das bis zum Ende wartet. Ein Array oder eine Map bekommen keine Statistiken, und eine Tabelle ohne Spalte, die sie annimmt, sagt es. REPAIR und CHECKSUM gibt es in der Engine nicht, und sie erscheinen nicht. Ist nur eine Tabelle angehakt, erscheint Partition, um eine Partition statt der ganzen Tabelle zu optimieren.
Oracle
Mit Oracle gibt es drei Operationen. ANALYZE sammelt die Statistiken der Tabelle und ihrer Indizes mit DBMS_STATS.GATHER_TABLE_STATS, und die Ergebniszeile sagt, wie viele Zeilen die Statistik zählt und wann sie gesammelt wurde; ohne Berechtigung auf eine Tabelle eines anderen Schemas sagt sie, dass sie nicht gesammelt werden konnte, darunter steht die Meldung des Servers. CHECK ist ANALYZE TABLE … VALIDATE STRUCTURE CASCADE ONLINE: Es prüft die Tabelle und ihre Indizes, ohne Schreibvorgänge zu blockieren. Bei einer partitionierten Tabelle läuft CASCADE FAST, das sagt, ob ein Schaden vorliegt, ohne ihn aufzuschlüsseln, denn die vollständige Form verlangt eine Tabelle INVALID_ROWS in Ihrem Schema. OPTIMIZE ist ALTER TABLE … SHRINK SPACE CASCADE: Es verdichtet die Tabelle und ihre Indizes online und gibt den freien Platz zurück. Hatte die Tabelle kein ROW MOVEMENT, schaltet Calíope es für die Operation ein und danach wieder aus. Akzeptiert die Tabelle kein SHRINK (ORA-10631 oder ORA-10635: ein funktionsbasierter Index, eine materialisierte View ON COMMIT darüber, ein Tablespace ohne ASSM), schreibt Calíope sie mit MOVE ONLINE neu, und die Zeile sagt es. Bei einer partitionierten Tabelle kannst du eine Partition wählen (MODIFY PARTITION … SHRINK SPACE CASCADE). REPAIR und CHECKSUM gibt es nicht: Oracle hat diese Operationen pro Tabelle nicht. Abbrechen unterbricht auch die laufende Tabelle: Der Server bricht ihre Anweisung ab (ORA-01013), und diese Tabelle bekommt keine Zeile in der Liste.
TiDB
Mit TiDB gibt es zwei Operationen: ANALYZE und CHECK, das ADMIN CHECK TABLE ausführt — es vergleicht die Indizes mit den Zeilen —, eine Tabelle nach der anderen. Findet es nichts, sagt die Zeile, dass die Tabelle ohne Befund ist; findet es etwas, steht dort die Meldung des Servers, die den Index nennt. REPAIR, CHECKSUM und OPTIMIZE gibt es nicht: TiDB hat sie nicht — sein Speicher verdichtet sich selbst — und sie werden nicht angeboten.
Mit einem schreibgeschützten Umgebungsetikett wird dieses Werkzeug nicht angeboten. Bei einem, das Schreibzugriffe bestätigt, fragen ANALYZE, OPTIMIZE und REPAIR einmal pro Durchgang; CHECK und CHECKSUM, die lesen, fragen nicht.
MySQLMariaDBAurora
Bei einer einzigen markierten Tabelle lässt OPTIMIZE eine ihrer Partitionen wählen. Calíope baut sie mit REBUILD PARTITION neu und analysiert sie mit ANALYZE PARTITION, denn bei InnoDB würde OPTIMIZE PARTITION die ganze Tabelle neu aufbauen. Dieser Vorgang landet im Binlog, auch wenn du den Modifikator markierst, der das vermeidet: ALTER TABLE akzeptiert ihn nicht.
Stichwörter: ANALYZE, CHECK, OPTIMIZE, REPAIR, Wartung, CHECKSUM