Suscríbase a la newsletter o feed RSS para recibir automáticamente las actualizaciones de blog!

La reparación de tablas corruptas en MYSQL



Hace unos días empecé a detectar una gran cantidad de errores en php-las estadísticas relacionadas con la imposibilidad de ejecutar una serie de preguntas de diferentes tablas.
Los mensajes recibidos eran de este tipo:
# 1016 - No se puede abrir el file: 'nometabella.MYI' (errno: 130)
Al principio yo estaba esperando era un problema debido a una saturación del espacio disponible para el PP, por lo que me han reasignado otro par de MB, pero no notar las mejoras después de dos días comenzó a preocuparse. Búsqueda en Google para el mensaje de error anterior, sólo he encontrado un documento importante sobre la que informó de un problema similar y sugirió que groped para resolver el problema ejecutando los siguientes comandos SQL:

 REPAIR TABLE nometabella; 

En mi caso he logrado salvar sólo uno de los tres cuadros y corruptos, pero luego me pidió un consejo (y también acerca de las aclaraciones), en apoyo de Tophost que respondieron podrían estar interesadas en el comando:

 REPAIR TABLE nometabella USE_FRM; 

En este caso, la reparación ha tenido éxito y las estadísticas php-parece haber tomado para funcionar correctamente. Más tarde, sin embargo, yo quería tratar de entender algunos "mejor al menos en el significado y las posibles consecuencias de estas acciones para restablecer el respeto y que me ponga una búsqueda en" MySQL 5.0 Reference Manual "que en el" Sintaxis de REPAIR TABLE "es bastante exhaustiva .
Por lo tanto, yo podría entender que:

  • La causa de la corrupción cuadros, o más precisamente índice, casi siempre es debido a un repentino accidente del PP; necesidad de comprender cuál es el porcentaje de la responsabilidad corre a cargo de la acogida ...
  • El comando REPAIR TABLE nometabella; simplemente tratar de reconstruir el archivo de índice;
  • El comando REPAIR TABLE nometabella USE_FRM; ser utilizado en los casos en que el archivo de índice no es más o cuando la cabecera está dañada. La opción USE_FRM causas el archivo. MYI ser recreado desde el archivo. FRM, de modo que esta medida es más radical y peligrosa. La misma referencia de MySQL dice: "Utilice este modo sólo si no puede usar los modos de regular REPARACIÓN. El. MYI cabecera de la tabla contiene metadatos (en particular, el actual valor AUTO_INCREMENT y eliminar enlace) que se pierden en los talleres de reparación ... USE_FRM. No utilice USE_FRM si la tabla se comprime porque esta información también se almacena en el archivo. MYI archivo ".


¿Te ha gustado este artículo? Regístrese ahora para recibir actualizaciones de noticias o artículos:
Suscribirse a feeds RSS escribir en el feed RSS


Aún no comentario "

Comentarios feed RSS para este puesto. TrackBack URI

Déjanos tu comentario

XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>


Nothing2Hide © 2006 Todos los derechos reservados.

Licencia | Descargo de responsabilidad

Cerrar
Enviar e-mail