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 tres operaciones: ANALYZE (UPDATE STATISTICS), CHECK (DBCC CHECKTABLE) y OPTIMIZE (ALTER INDEX ALL … REBUILD). No hay REPAIR —exige la base en modo de un solo usuario y puede perder datos— ni CHECKSUM. 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 dos operaciones: ANALYZE y OPTIMIZE, que ejecuta VACUUM y después REINDEX TABLE CONCURRENTLY, así que da dos filas por tabla; ninguna de las dos para la tabla. No hay CHECK —el núcleo no tiene nada parecido—, ni REPAIR, ni CHECKSUM, ni modificadores. 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 dos operaciones: CHECK, que devuelve una fila por cada parte de la tabla, y OPTIMIZE, que funde sus partes. ANALYZE, 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 una sola operación: ANALYZE, que reúne las estadísticas de la tabla y de sus índices con DBMS_STATS.GATHER_TABLE_STATS. La fila del resultado dice cuántas filas cuenta la estadística y cuándo se reunió. No hay CHECK, REPAIR, CHECKSUM ni OPTIMIZE: Oracle no tiene esas operaciones por tabla, y no se ofrecen. Sin privilegio sobre una tabla de otro esquema, la fila dice que no se pudieron reunir y debajo va el mensaje del servidor. Cancelar interrumpe también la tabla en curso: el servidor corta su DBMS_STATS (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.

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 no hay ninguno y la sección no se dibuja.

ClickHouse

Con ClickHouse el único modificador es FINAL, de OPTIMIZE, y nace apagado: 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.

Oracle

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

TiDB

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

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