Físico ou lógico

Nota 27 de 41 · 4 min de leitura

Uma manutenção pode terminar com o resultado OK e a busca do sistema continuar errada, porque o comando tratou uma parte diferente do problema. Separar o defeito físico da incoerência lógica indica qual ação alcança a causa.

O defeito físico

O defeito físico atinge a forma como o engine guarda os dados nos arquivos. São exemplos uma página danificada no arquivo de dados, um arquivo ausente e um índice cujas entradas não correspondem às linhas.

Os sinais costumam ser mensagens de erro na leitura, a mensagem de tabela MyISAM marcada como danificada, mensagens de corrupção no log de erros do MySQL ou a parada do serviço ao acessar uma tabela. Uma queda de energia ou um encerramento abrupto do serviço não prova, sozinho, um dano. O InnoDB costuma se recuperar sem perda, e uma tabela MyISAM pode ser marcada como danificada sem ter um dano permanente.

A incoerência lógica

A incoerência lógica atinge o significado dos dados ou os controles da aplicação, com os arquivos em perfeito estado. São exemplos:

uma ordem registrada na tabela de controle com uma condição errada;
uma coluna derivada desatualizada depois de uma correção feita por SQL;
uma marca de exclusão gravada na linha errada;
registros órfãos, que apontam para linhas que não existem mais;
identificadores renumerados sem a atualização das tabelas que apontam para eles;
o total de uma venda diferente da soma dos itens.

Nesses casos, os valores estão legíveis, e o banco não tem como saber qual deveria ser o valor certo. Um índice registrado na tabela de controle e ausente no banco também é uma divergência de definição, e não um defeito de uma estrutura existente.

O alcance dos comandos de manutenção

CHECK TABLE vendas;: procura os defeitos físicos que o engine consegue verificar;
REPAIR TABLE vendas;: reconstrói a estrutura física, nos engines que oferecem o reparo, como o MyISAM;
OPTIMIZE TABLE vendas;: reorganiza a tabela e pode devolver espaço ao disco, conforme o engine;
ANALYZE TABLE vendas;: atualiza as estatísticas usadas pelo otimizador.

Nenhum desses comandos conhece as regras da aplicação, as ligações mantidas só no código ou a regra de uma coluna derivada. O resultado OK do CHECK TABLE indica que a verificação não encontrou os problemas que ela examina. Ele não prova que a tabela está livre de qualquer dano, nem que os dados fazem sentido.

Uma busca que não encontra

Quando a tabela está acessível, o CHECK TABLE não aponta erro e a busca do sistema não encontra um registro, as hipóteses lógicas vêm primeiro:

o SQL enviado pela aplicação, com as condições e a ordem;
a condição registrada para a ordem usada na busca;
a marca de exclusão da linha;
o valor das colunas derivadas usadas na busca.

Se o log de erros também mostra falhas de leitura ou de corrupção, a investigação física continua. A decisão combina as evidências, e um único teste não descarta uma causa.

No suporte

Convém descrever o que foi observado e qual parte do problema isso alcança. A frase “o CHECK TABLE não encontrou erro” é diferente de “a tabela está íntegra”, e a frase “a coluna derivada contém o valor antigo” é uma conclusão mais útil do que “a busca está errada”.

Para guardar

O defeito físico atinge a forma como o engine guarda os dados nos arquivos.
A incoerência lógica atinge o significado dos dados e os controles da aplicação, com os arquivos íntegros.
Os comandos de manutenção do MySQL não conhecem as regras da aplicação.
O resultado OK do CHECK TABLE tem alcance limitado.
A decisão combina os sintomas, as definições, os logs e o SQL das consultas.

O CHECK TABLE da tabela vendas retorna OK, mas a busca do sistema não encontra uma venda que existe. Onde investigar?

Nas hipóteses lógicas: o SQL enviado pela aplicação, a condição da ordem usada, a marca de exclusão da linha e as colunas derivadas da busca. O resultado OK não descarta as evidências físicas de outras fontes, como o log de erros, mas indica que a explicação provavelmente está na lógica.

Depois de uma queda de energia, uma tabela InnoDB voltou a funcionar sem nenhum erro. A queda danificou a tabela?

Não necessariamente. O InnoDB usa os registros de alterações para se recuperar depois de uma queda, e a tabela pode ter ficado íntegra. O log de erros do MySQL mostra se a recuperação encontrou algum problema, e o CHECK TABLE confirma a estrutura da tabela.