Como Reparar Tabelas

Na seção seguinte nós só falaremos do uso do myiasmchk em tabelas MyISAM (extensões .MYI e .MYD). Se você estiver usando tabelas ISAM (extensões .ISM e .ISD), você deve usar a ferramenta isamchk.

A partir do MariaDB versão 3.23.14, você pode reparar tabelas MyISAM com o comando REPAIR TABLE. Leia "Sintaxe do REPAIR TABLE".

Os sintomas de uma tabela corrompida incluem pesquisas que abortam inesperadamente e erros como estes:

• nome_tabela.frm is locked against change
• Can't find file nome_tabela.MYI (Errcode: ###)
• Unexpected end of file
• Record file is crashed
• Got error ### from table handler

  Para obter mais informações sobre o erro você pode executar perror ###. Aqui estão os erros mais comuns que indicam um problema com a tabela:

  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
  

  Note que o erro 135 (não mais no arquivo de registro), não é um erro que pode ser corrigido por um simples reparo. Neste caso você deve fazer:

  ALTER TABLE tabela MAX_ROWS=xxx AVG_ROW_LENGTH=yyy;
  

  Você também pode usar esta técnica para o erro 136 (não mais no arquivo de índice).

Em outros casos, você deve reparar suas tabelas. myisamchk pode normalmente detectar a maioria dos problemas que ocorrem.

O processo de reparo involve até quatro estágios, descritos abaixo. Antes de começar, você deve mudar para o diretório do banco de dados e conferir as permissões dos arquivos de tabelas. Tenha certeza que eles possam ser lidos pelo usuário do Unix com o qual mysqld é executado (e para você, porque você precisa acessar os arquivos que está conferindo). Se não estiverem, você precisa alterar os arquivos, eles também devem ter a permissão de escrita para você.

Se você estiver utilizando o MariaDB versão 3.23.16 e superior, você pode (e deve) usar os comandos CHECK e REPAIR para conferir e corrigir tabelas MyISAM. See "Sintaxe de CHECK TABLE". Leia "Sintaxe do REPAIR TABLE".

A seção do manual sobre manutenção de tabelas inclui as opções para isamchk/myisamchk. Leia "Utilizando myisamchk para Manutenção de Tabelas e Recuperação em Caso de Falhas".

A seguinte seção são para os casos onde o comando acima falhar ou se você desejar usar os recursos extendidos que o isamchk e myisamchk fornecem.

Se você for reparar uma tabela da linha de comandos, deve primeiro desligar o servidor mysqld. Perceba que quando você executa mysqladmin shutdown em um servidor remoto, o servidor mysqld irá continuar funcionando por um tempo depois do mysqladmin retornar, até que todas as queries parem e todas as chaves sejam descarregadas no disco.

Estágio 1: Verificando suas tabelas

Execute myisamchk *.MYI ou myisamchk -e *.MYI se você tiver tempo disponível. Utilize a opção -s (silencioso) para suprimir informações desnecessárias.

Se o servidor mysqld parar, deve ser utilizada a opção --update para dizer ao myisamchk marcar a tabela como 'checada'.

Você deve reparar somente as tabelas em que o myisamchk indicar um erro. Para tais tabelas, vá para o estágio 2.

Se você obter erros estranhos na verficação (como nos erros out of memory), ou se o myisamchk quebrar, vá para o estágio 3.

Estágio 2: Reparo simples e seguro

NOTA: Se você deseja que os reparos sejam mais rápidos, devem ser usadas as opções: -O sorf_buffer=# -O key_buffer=# (onde # seria 1/4 da memória disponível) para todos comandos isamchk/myisamchk.

Primeiro, tente usar myisamchk -r -q nome_tabela (-r -q significa modo de recuperação rápida). Ele tentará reparar o arquivo de índice sem mexer no arquivo de dados. Se o arquivo de dados estiver normal e os links apagados apontam nas localizações corretas dentro do arquivo de dados, isto deve funcionar e a tabela será corrigida. Inicie o reparo da próxima tabela. Outra maneira seria utilizar os seguintes procedimentos:

1. Faça um backup do arquivo de dados antes de continuar.
2. Utilize myisamchk -r nome_tabela (-r significa modo de recuperação). Isto removerá registros incorretos e deletados do arquivo de dados e reconstroi o arquivo de índices.
3. Se o passo anterior falhar, utilize myisamchk --safe-recover nome_tabela. O modo de recuperação segura utiliza um metódo de recuperação antiga que trata de alguns casos que o modo de recuperação comum não consegue (porém é mais lento).

Se você obter erros estranhos no reparo (como em erros out of memory), ou se o myisamchk falhar, vá para o estágio 3.

Estágio 3: Reparo difícil

Você só deve atingir este estágio se o primeiro bloco de 16K do arquivo de índice estiver destruído ou conter informações incorretas, ou se o arquivo de índice não existir. Neste caso, é necessário criar um novo arquivo de índice. Faça como a seguir:

1. Mova o arquivo de dados para algum lugar seguro.
2. Use o arquivo de descrição de tabelas para criar novos arquivos (vazios) de dados e índices:

   shell> mysql nome_bd
   mysql> SET AUTOCOMMIT=1;
   mysql> TRUNCATE TABLE nome_tabela;
   mysql> quit
   

   Se sua versão do MariaDB não possuir TRUNCATE TABLE, utilize DELETE FROM nome_tabela.

3. Copie o antigo arquivo de dados de volta para o novo arquivo de dados criado. (Não só mova o antigo arquivo de volta para o novo arquivo; você deve uma cópia no caso de algo der errado.)

Volte ao estágio 2. myisamchk -r -q deve funcionar agora. (Isto não deve ser um loop eterno.)

No MariaDB 4.0.2 você também pode utilizar REPAIR ... USE_FRM o qual realiza todo o procedimento automaticamente.

Estágio 4: Reparo muito difícil

Você deve atingir este estágio somente se o arquivo de descrição também falhar. Isto nunca deve acontecer, porque o arquivo de descrição não é alterado depois da tabela ser criada:

1. Restaure o arquivo de descrição de um backup e volte ao estágio 3. Você pode também restaurar o arquivo de índice e voltar ao estágio 2. No último caso, você deve iniciar com myisamchk -r.
2. Se você não tem um backup mas sabe exatamente como a tabela foi criada, crie uma cópia da tabela em outro banco de dados. Remova o novo arquivo de dados, e então mova a descrição e arquivos de índice do outro banco de dados para o banco de dados com problemas. Isto lhe fornece um novo arquivos índice e descrição, mas mantêm o arquivo de dados da mesma forma. Volte ao estágio 2 e tente reconstruir o arquivo de índices.

Retornar