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 MySQL versão 3.23.14, você pode reparar tabelas
          MyISAM com o comando REPAIR TABLE. See
          Secção 4.5.5, “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 MySQL versão 3.23.16 e
          superior, você pode (e deve) usar os comandos
          CHECK e REPAIR para
          conferir e corrigir tabelas MyISAM. See
          Secção 4.5.4, “Sintaxe de CHECK TABLE”. See
          Secção 4.5.5, “Sintaxe do REPAIR TABLE”.
        
          A seção do manual sobre manutenção de tabelas inclui as
          opções para
          isamchk/myisamchk. See
          Secção 4.5.6, “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:
        
Faça um backup do arquivo de dados antes de continuar.
              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.
            
              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:
Mova o arquivo de dados para algum lugar seguro.
Use o arquivo de descrição de tabelas para criar novos arquivos (vazios) de dados e índices:
shell>mysql nome_bdmysql>SET AUTOCOMMIT=1;mysql>TRUNCATE TABLE nome_tabela;mysql>quit
              Se sua versão do MySQL não possuir TRUNCATE
              TABLE, utilize DELETE FROM
              nome_tabela.
            
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 MySQL 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:
              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.
            
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.
This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.

