Skip navigation links
5.8.3.10 Optimización de tablas »
Section Navigation      [Toggle]

5.8.3.9. Cómo reparar tablas

La discusión en esta sección describe cómo usar myisamchk en tablas MyISAM (extensiones .MYI y .MYD).

También puede ( y debe, si es posible) usar los comandos CHECK TABLE y REPAIR TABLE para chequear y reparar tablas MyISAM . Consulte Sección 13.5.2.3, “Sintaxis de CHECK TABLE” y Sección 13.5.2.6, “Sintaxis de REPAIR TABLE”.

Los síntomas de tablas corruptas incluyen consultas que abortan inesperadamente y errores observables como los siguientes:

  • tbl_name.frm is locked against change

  • Can't find file tbl_name.MYI (Errcode: ###)

  • Unexpected end of file

  • Record file is crashed

  • Got error ### from table handler

Para obtener ejecución acerca de los errores puede ejectuar perror ###, donde ### es el número de error. El siguiente ejemplo muestra cómo usar perror para encontrar el significado de la mayoría de errores comunes que indican un problema con la tabla: 

shell> perror 126 127 132 134 135 136 141 144 145
126 = Index file is crashed / Wrong file format
127 = Record-file is crashed
132 = Old database file
134 = Record was already deleted (or record file crashed)
135 = No more room in record file
136 = No more room in index file
141 = Duplicate unique key or constraint on write or update
144 = Table is crashed and last repair failed
145 = Table was marked as crashed and should be repaired

Tenga en cuenta que el error 135 (no more room in record file) y el error 136 (no more room in index file) no son errores que puedan arreglarse con una simple reparación. En este caso, debe usar ALTER TABLE para incrementar los valores de las opciones de tabla MAX_ROWS y AVG_ROW_LENGTH: 

ALTER TABLE tbl_name MAX_ROWS=xxx AVG_ROW_LENGTH=yyy;

Si no conoce los valores actuales de las opciones de tabla, use SHOW CREATE TABLE o DESCRIBE.

Para los otros errores, debe reparar las tablas. myisamchk normalmente detecta y arregla la mayoría de problemas que ocurren.

El proceso de reparación incluye hasta cuatro etapas, descritas aquí. Antes de empezar, debe cambiar la localización al directorio de la base de datos y comprobar los permisos de los ficheros de las tablas. En Unix, asegúrese que puede leerlos el usuario con el que corre mysqld (y con su usuario, ya que necesita acceder a los ficheros que está comprobando). En caso que necesite modificar ficheros, debe tener también permiso de escritura.

Las opciones que puede usar para el mantenimiento de tablas con myisamchk y isamchk se describen en varias de las primeras subsecciones de Sección 5.8.3, “Mantenimiento de tablas y recuperación de un fallo catastrófico (crash)”.

La siguiente sección es para los casos en los que los comandos anteriores fallen o si quiere usar las características extendidas que myisamchk y isamchk proporcionan.

Si va a reparar una tabla desde la línea de comandos, debe parar el servidor mysqld en primer lugar. Tenga en cuenta que cuando ejectua mysqladmin shutdown en un servidor remoto, el servidor mysqld todavía está activo durante un periodo de tiempo una vez que mysqladmin devuelve el control, hasta que todas las consultas están paradas y todas las claves se han volcado a disco.

Etapa 1: Comprobación de tablas

Ejecute myisamchk *.MYI o myisamchk -e *.MYI si tiene más tiempo. Use la opción -s (silencio) para suprimir información innecesaria.

Si el servidor mysqld está parado, debe usar la opción --update-state para decirle a myisamchk que marque la tabla como 'comprobada'.

Debe reparar sólo las tablas en que myisamchk anuncia un error. Para estas tables, pase a la Etapa 2.

Si obtiene errores extraños al hacer la comprobación (tales como errores out of memory), o si myisamchk cae, pase a la Etapa 3.

Etapa 2: Reparación sencilla

Nota: Si quiere que una operación de reparación sea mucho más rápida, debe cambiar los valores de las variables sort_buffer_size y key_buffer_size al 25% aproximado de la cantidad de memoria disponible al ejecutar myisamchk o isamchk.

En primer lugar, intente myisamchk -r -q tbl_name (-r -q significa ``modod de recuperación rápido''). Intenta reparar el fichero de indexación sin tocar el fichero de datos. Si el fichero de datos contiene todo lo que debería y los vínculos de borrado apuntan a la localización correcta dentro del fichero de datos, esto debería funcionar, y la tabla estaría reparada. Empiece a reparar la siguiente tabla. Si no es así, use el siguiente procedimiento:

  1. Haga una copia de seguridad del fichero de datos antes de continuar.

  2. Use myisamchk -r tbl_name (-r significa ``modo de recuperación''). Esto elimina registros incorrectos y registros borrados del fichero de datos y recunstruye el fichero de indexación.

  3. Si el paso precedente falla, use myisamchk --safe-recover tbl_name. El modo de recuperación seguro usa un método de reucperación antiguo que soporta algunos casos que los metodos normales de recuperación no soportan (pero es más lento).

Si obtiene errores extraños al reparar (tales como errores out of memory ), o si myisamchk cae, pase a la Etapa 3.

Etapa 3: Reparaciones complicadas

Debe llegar a esta etapa sólo si el primer bloque de 16KB en el fichero de indexación está destruido o contiene información incorrecta, o si el fichero de indexación no se encuentra. En este caso, es necesario crear un nuevo fichero de indexación. Hágalo así:

  1. Mueva el fichero de datos a una ubicación segura.

  2. Use el fichero descriptor de la tabla para crear unos ficheros de datos e indexación nuevos (vacíos): 

    shell> mysql db_name
mysql> SET AUTOCOMMIT=1;
mysql> TRUNCATE TABLE tbl_name;
mysql> quit

    Si su versión de MySQL no soporta TRUNCATE TABLE, use DELETE FROM tbl_name en su lugar.

  3. Copie el antiguo fichero de datos otra vez sobre el nuevo fichero de datos (recién creado). (No se limite a mover el fichero antiguo sobre el nuevo; debe guardar una copia por si algo falla.)

Vuelva a la Etapa 2. myisamchk -r -q debería funcionar. (Este no debería ser un bucle sin fin.)

Puede usar REPAIR TABLE tbl_name USE_FRM, que realiza el proceso completo automáticamente.

Etapa 4: Reparaciones muy complicadas

Debe llegar a esta etapa sólo si el fichero de descripción .frm ha tenido problemas. Esto no debería ocurrir nunca, ya que el fichero de descripción nunca cambia una vez que la tabla se crea:

  1. Restaure el fichero de descripción desde una copia de seguridad y vuelva a la Etapa 3. También puede restaurar el fichero índice y volver a la Etapa 2. En este último caso, puede comenzar con myisamchk -r.

  2. Si no tiene una copia de seguridad pero sabe exactamente cómo se creó la tabla, cree una copia de la tabla en otra base de datos. Borre el nuevo fichero de datos, luego mueva los ficheros .frm de descripción y .MYI de indexación desde la otra base de datos a la base de datos que tiene problemas. Esto le da unos nuevos ficheros de descripción e indexación, pero deja el fichero de datos .MYD solo. Vuelva a la Etapa 2 y trate de reconstruir el fichero de indexación.

Ésta es una traducción del manual de referencia de MySQL, que puede encontrarse en dev.mysql.com. El manual de referencia original de MySQL está escrito en inglés, y esta traducción no necesariamente está tan actualizada como la versión original. Para cualquier sugerencia sobre la traducción y para señalar errores de cualquier tipo, no dude en dirigirse a mysql-es@vespito.com.