MariaDB / REPAIR TABLE

Bienvenidos sean a este post, en el post anterior vimos como chequear pero hoy veremos como reparar.

Como dijimos esta instruccion nos da la posibilidad de poder reparar una tabla sin necesidad de reiniciar al servidor, los siguiente motores soportan a esta instruccion:

• MyIsam
• Aria
• Archive
• CSV

Nota: 
InnoDB no soporta esta instruccion

Pasemos a ver su sintaxis:

REPAIR NO_WRITE_TO_BINLOG TABLE <lista_tablas> [QUICK] [EXTENDED] [USE_FRM]

Tal como vimos en el post anterior esta instruccion tambien nos permite reparar particiones, veamos su sintaxis:

ALTER TABLE <lista_tablas> REPAIR PARTITION <lista_particiones> [QUICK] [EXTENDED]

Siendo muy similar a cuando hablamos de CHECK TABLE en el post anterior donde tanto lista_tablas, la cual almacena las tablas que veremos, como lista_particiones, donde estaran las particiones a reparar, tendran los valores separados por comas, son de caracter obligatorio y debemos pasar al menos una tabla y una particion en ambos casos de instrucciones y la otra diferencia entre uno y otro es que en el caso de las reparaciones de particiones no podemos usar a USE_FRM, pasemos a hablar sobre las tres opciones disponibles.

La opcion QUICK hace que la instruccion solo repare los archivos de indices, esta opcion es mas util de lo que creen dado que los indices se dañan mas seguido que los datos.

En cambio EXTENDED hace que la instruccion regenere los indices de una forma mas lenta pero segura aunque esto podria generar muchas filas basura y por esta razon no se deberia utilizar al menos que sea completamente necesario.

Por ultimo la opcion USE_FRM nos permite permite recuperar archivos de indice de MyIsam (.MYI) cuando estos desaparecen o son eliminados, por ejemplo por un chequeo de disco del sistema operativo o por un intento fallido de REPAIR TABLE que «cuelga» al servidor y deja archivos indices vacios, siendo ambas situaciones incomodas, por esta razon siempre es bueno tener un backup de la informacion. Con esta opcion se eliminan los enlaces con todos los bloques borrados, lo cual hara que no podamos reclamar ese espacio disponible con la instruccion OPTIMIZE TABLE, tambien podemos perder valores AUTO INCREMENTE de la tabla, por estas razones no deberia usarse si hay otras alternativas disponibles, tampoco deberian usarse en tablas comprimidas porque las dañaran, una opcion alternativa seria tanto a myisamcheck o aria_chk en su lugar.

Por ultimo con NO_WRITE_TO_BINLOG TABLE hace que la instruccion no sea escrita en el log binario, esto nos sera especialmente util en un ambiente de replicacion para que la instruccion no sea replicado en los esclavos, siendo LOCAL un sinonimo de esta, antes de finalizar veamos un ejemplo basico de como reparar una tabla:

MariaDB [(none)]> repair local table base1.tabla4;
+--------------+--------+----------+----------+
| Table        | Op     | Msg_type | Msg_text |
+--------------+--------+----------+----------+
| base1.tabla4 | repair | status   | OK       |
+--------------+--------+----------+----------+
1 row in set (0.002 sec)

MariaDB [(none)]>

Aqui les paso para los casos cuando no es soportado por la instruccion:

MariaDB [(none)]> repair local table base3.tabla_comp\G
*************************** 1. row ***************************
   Table: base3.tabla_comp
      Op: repair
Msg_type: note
Msg_text: The storage engine for the table doesn't support repair
1 row in set (0.003 sec)

MariaDB [(none)]>

En resumen, hoy hemos visto como reparar tablas, cuales son los motores que lo soportan, como trabaja, sus opciones, sus alcances y un ejemplo simple de como usarlo, espero les haya sido de utilidad sigueme en tumblr, Twitter o Facebook para recibir una notificacion cada vez que subo un nuevo post en este blog, nos vemos en el proximo post.