Mantenimiento de tablas

Analiza, comprueba, optimiza o repara las tablas seleccionadas, con las operaciones que tiene el servidor.

Dónde está: Espacio de Trabajo › Herramientas › Mantenimiento de tablas

Abre Mantenimiento de tablas desde la barra lateral del workspace. Selecciona las tablas en el árbol de la izquierda (la casilla de una base marca todas sus tablas, o márcalas una a una), elige la operación arriba —ANALYZE, CHECK, CHECKSUM, OPTIMIZE o REPAIR— y pulsa Ejecutar. Junto al botón ves cuántas tablas hay seleccionadas.

Los resultados aparecen debajo, una fila por cada mensaje que el servidor devuelve para cada tabla: los avisos se resaltan en naranja y los errores en rojo. En InnoDB, OPTIMIZE responde con una nota: reconstruye la tabla y la analiza en su lugar. CHECKSUM da un número por tabla; el mismo número en dos servidores significa las mismas filas. REPAIR sólo se ejecuta sobre tablas cuyo motor de almacenamiento sabe repararse: MyISAM, Aria, ARCHIVE y CSV. Antes de ejecutarlo, una línea bajo los modificadores dice cuántas de las tablas marcadas se saltarán, y cada una recibe una fila que explica por qué; en InnoDB la fila sugiere OPTIMIZE, que reconstruye la tabla. En el Mac, pulsa la cabecera de una columna para ordenar los resultados; Limpiar resultados vacía la lista. Mientras una operación corre, junto a Ejecutar aparecen una barra de progreso y Cancelar; las tablas se procesan de una en una, así que cancelar se detiene antes de la siguiente.

El árbol tiene un filtro por nombre en su cabecera, igual que el del Editor SQL: escribe parte del nombre de una base o de una tabla para acotar la lista. Cada base carga sus tablas la primera vez que la despliegas, así que si filtras con bases sin desplegar, el pie del panel te dice cuántas faltan y ofrece cargarlas. Seleccionar todo recorre todas las bases del servidor salvo las de sistema del propio servidor, que puedes marcar a mano, y puede tardar unos segundos. Si el servidor rechaza la operación sobre una tabla, esa tabla sale con una fila de error y el mensaje del servidor.

SQL Server

Hay cuatro operaciones: ANALYZE (UPDATE STATISTICS), CHECK (DBCC CHECKTABLE), OPTIMIZE (ALTER INDEX ALL … REBUILD) y CHECKSUM (CHECKSUM_AGG(BINARY_CHECKSUM(*)), de la tabla entera). La suma no cuenta las columnas text, ntext, image, xml ni las de un tipo como geometry, y el resultado las nombra al lado: dos tablas que sólo difieran ahí dan la misma suma. Una tabla en un esquema de partición ofrece reconstruir una sola partición. No hay REPAIR: exige la base en modo de un solo usuario y puede perder datos. OPTIMIZE bloquea la tabla mientras la reconstruye: la reconstrucción en línea sólo existe en la edición Enterprise, y no con índices espaciales.

PostgreSQL

Hay tres operaciones: ANALYZE, OPTIMIZE, que ejecuta VACUUM y después REINDEX TABLE CONCURRENTLY, así que da dos filas por tabla, y CHECK, con la extensión amcheck: bt_index_check en cada índice B-tree y, desde la 14, verify_heapam en la tabla. Sin la extensión, CHECK da una nota con CREATE EXTENSION amcheck. Ninguna para la tabla. No hay REPAIR ni CHECKSUM. VACUUM FULL, la única que devuelve espacio al sistema, se deja fuera a propósito: bloquea la tabla entera mientras la reescribe. En un servidor anterior a la 12, OPTIMIZE se queda en el VACUUM y la fila del índice dice por qué.

ClickHouse

Con ClickHouse hay tres operaciones: CHECK, que devuelve una fila por cada parte de la tabla; OPTIMIZE, que funde sus partes; y ANALYZE, que calcula las estadísticas de columna que usa el optimizador para ordenar los filtros: ADD STATISTICS con tdigest y uniq en las columnas de números y fechas, uniq en las de texto, y MATERIALIZE STATISTICS, que espera a terminar. Un Array o un Map no llevan estadísticas, y una tabla sin columnas que las admitan lo dice. REPAIR y CHECKSUM no existen en el motor y no aparecen. Con una sola tabla marcada sale Partición, para optimizar una partición en lugar de la tabla entera.

Oracle

Con Oracle hay tres operaciones. ANALYZE reúne las estadísticas de la tabla y de sus índices con DBMS_STATS.GATHER_TABLE_STATS, y la fila del resultado dice cuántas filas cuenta la estadística y cuándo se reunió; sin privilegio sobre una tabla de otro esquema, dice que no se pudieron reunir y debajo va el mensaje del servidor. CHECK es ANALYZE TABLE … VALIDATE STRUCTURE CASCADE ONLINE: comprueba la tabla y sus índices sin bloquear las escrituras. En una tabla particionada va CASCADE FAST, que dice si hay daño sin detallarlo, porque la forma completa pide una tabla INVALID_ROWS en tu esquema. OPTIMIZE es ALTER TABLE … SHRINK SPACE CASCADE: compacta en línea la tabla y sus índices y devuelve el espacio libre. Si la tabla no tenía ROW MOVEMENT, Calíope lo enciende para la operación y lo vuelve a apagar. Si la tabla no admite SHRINK (ORA-10631 o ORA-10635: un índice basado en función, una vista materializada ON COMMIT encima, un tablespace sin ASSM), Calíope la reescribe con MOVE ONLINE y la fila lo dice. En una tabla particionada puedes elegir una partición (MODIFY PARTITION … SHRINK SPACE CASCADE). No hay REPAIR ni CHECKSUM: Oracle no tiene esas operaciones por tabla. Cancelar interrumpe también la tabla en curso: el servidor corta su sentencia (ORA-01013) y esa tabla no recibe fila en la lista.

TiDB

Con TiDB hay dos operaciones: ANALYZE y CHECK, que ejecuta ADMIN CHECK TABLE —contrasta los índices con las filas— una tabla cada vez. Si no encuentra nada, la fila dice que la tabla no tiene incidencias; si encuentra algo, va el mensaje del servidor, que nombra el índice. No hay REPAIR, CHECKSUM ni OPTIMIZE: TiDB no los tiene —su almacén compacta solo— y no se ofrecen.

Con una etiqueta de entorno de solo lectura, esta herramienta no se ofrece. Con una que confirma lo que escribe, ANALYZE, OPTIMIZE y REPAIR preguntan una vez por tanda; CHECK y CHECKSUM, que leen, no preguntan.

MySQLMariaDBAurora

Con una sola tabla marcada, OPTIMIZE deja elegir una de sus particiones. Calíope la reconstruye con REBUILD PARTITION y la analiza con ANALYZE PARTITION, porque en InnoDB OPTIMIZE PARTITION reconstruiría la tabla entera. Esa operación va al binlog aunque marques el modificador que lo evita: ALTER TABLE no lo admite.

Palabras clave: ANALYZE, CHECK, OPTIMIZE, REPAIR, mantenimiento, CHECKSUM

Modificadores de operación

Opciones adicionales que modifican el comportamiento de la operación.

Dónde está: Mantenimiento de tablas › Cuadrícula de modificadores

Debajo de la operación, la cuadrícula de modificadores: LOCAL (sin binlog), FOR UPGRADE, QUICK, FAST, MEDIUM, EXTENDED, CHANGED y USE_FRM. Cada operación activa sólo los que acepta, y cambiar de operación los desmarca. Por ejemplo, QUICK acelera CHECK porque no recorre las filas buscando enlaces incorrectos, FOR UPGRADE verifica la compatibilidad con la versión actual del servidor, y LOCAL deja ANALYZE, OPTIMIZE y REPAIR fuera del registro binario, para que las réplicas no los repitan. Con CHECKSUM, QUICK sólo informa de la suma que la tabla mantiene en vivo, y casi ninguna la mantiene. USE_FRM reconstruye el índice de una tabla MyISAM a partir de su definición, como último recurso.

La rejilla enseña sólo los modificadores que tiene el motor. Con SQL Server CHECK admite PHYSICAL_ONLY (sólo la estructura, más rápido) y EXTENDED_LOGICAL_CHECKS; con PostgreSQL, OPTIMIZE admite FREEZE, SKIP_LOCKED e INDEX_CLEANUP OFF (las dos últimas desde la 12) y ANALYZE, SKIP_LOCKED, que salta la tabla que otro tiene bloqueada en vez de esperarla.

ClickHouse

Con ClickHouse son tres, los tres de OPTIMIZE y apagados al empezar. FINAL obliga a dejar la tabla —o la partición— en una sola parte, y al marcarlo un aviso dice que puede tardar horas y pedir el doble de disco. DEDUPLICATE quita las filas idénticas en todas sus columnas, y va siempre con FINAL: sin él sólo deduplica lo que el servidor iba a fundir. CLEANUP es de una ReplacingMergeTree con columna de borrado: tira las filas marcadas como borradas, y la tabla tiene que permitirlo con un ajuste propio; si no es de ese motor o no lo permite, la fila del resultado dice por qué y no se manda nada.

Oracle

Con Oracle hay tres. FAST, en CHECK, pide CASCADE FAST también en una tabla sin particiones. MOVE ONLINE, en OPTIMIZE, reescribe el segmento entero (ALTER TABLE … MOVE ONLINE, o MOVE PARTITION … ONLINE) en vez de compactarlo, y los índices siguen utilizables. NO_INVALIDATE, en ANALYZE, deja vivos los cursores que ya usan la estadística vieja (no_invalidate => TRUE).

TiDB

Con TiDB no hay ningún modificador, y la sección no se dibuja.

SQL Server

Con SQL Server, CHECKSUM no tiene modificadores: la suma es de la tabla entera.

Palabras clave: QUICK, EXTENDED, FOR UPGRADE, LOCAL, modificadores