Cenários práticos

Os problemas reais raramente chegam com o nome da causa. Uma busca que falha, caixas parados ou um servidor que não inicia podem ter origens diferentes, e o caminho certo depende das evidências reunidas. Os cenários a seguir mostram como as peças estudadas se combinam em situações comuns.

A busca não encontra um produto que existe

O balcão 01 procura um produto pela descrição, e o sistema não o encontra, embora uma consulta feita direto no banco mostre a linha. Não há nenhuma mensagem de erro. O caminho passa por estas conferências:

• o SQL enviado pela aplicação, no registro da camada de acesso a dados;
• a marca de exclusão da linha e a condição da ordem usada na busca;
• a coluna derivada da busca, comparada com a descrição;
• alguma correção recente feita direto no banco.

Se a coluna derivada ficou com o texto antigo depois de um UPDATE direto, a correção usa a rotina da aplicação que recalcula essa coluna. Um reparo da tabela não resolve, porque os arquivos estão íntegros.

Os caixas param no fim da tarde

Todos os caixas da filial 01 param ao mesmo tempo, sem mensagem de erro, e voltam a funcionar meia hora depois. O servidor da loja responde, e a rede funciona. O caminho passa por estas conferências:

• a lista de conexões durante o sintoma, com as conexões paradas, o estado e o tempo de cada uma;
• nas tabelas InnoDB, a conexão que bloqueia, que costuma estar em Sleep, com uma transação aberta;
• nas tabelas MyISAM, a conexão que bloqueia, que costuma estar executando um comando longo, enquanto as outras aparecem no estado Locked, no MySQL 5.1, ou Waiting for table level lock;
• a origem dessa conexão, como uma ferramenta de consulta com a confirmação automática desligada ou um relatório longo sobre uma tabela MyISAM.

A liberação imediata pode exigir o encerramento da conexão que bloqueia, depois da identificação dela e do trabalho pendente. A prevenção pede a mudança do hábito ou da rotina que deixou a transação aberta, ou outro horário para o relatório.

A tabela MyISAM danificada depois de uma queda de energia

Depois de uma queda de energia, o servidor da loja, com o MySQL 5.1, volta a funcionar, mas uma tela mostra a mensagem de tabela marcada como danificada. As tabelas InnoDB do mesmo banco funcionam. O caminho segue esta ordem:

1. a parada do serviço e a cópia dos arquivos da tabela;
2. o início do serviço e a anotação das medidas que ainda puderem ser lidas;
3. o reparo com a opção QUICK e a leitura do resultado completo;
4. o modo padrão, se a mensagem indicar um dano nos dados;
5. a comparação da contagem, do maior identificador e do contador com os valores anotados;
6. o teste da aplicação.

Se o resultado traz o aviso de mudança no número de linhas, as linhas descartadas são localizadas na cópia preservada ou em outra fonte, como os dados já enviados à matriz.

O servidor não inicia depois de uma queda

O serviço do MySQL não inicia no servidor da loja depois de uma queda de energia, e nenhuma estação conecta. O caminho passa por estas conferências:

• o log de erros, na pasta de dados;
• as causas simples antes das graves, como o disco cheio, a porta ocupada e uma opção inválida na configuração;
• nas versões antigas, uma mudança recente no tamanho dos arquivos de registro do InnoDB, feita só na configuração;
• diante de páginas danificadas, a cópia completa da pasta de dados, com o serviço parado, e a recuperação forçada com a equipe responsável.

Com a recuperação forçada, o objetivo é exportar os dados e montar uma instalação nova. A opção não fica na configuração do servidor em operação.

A lentidão depois de uma restauração

Depois da restauração de uma tabela, as telas que usam essa tabela ficam muito lentas, sem nenhum erro. O caminho passa por estas conferências:

• os índices da tabela, comparados com os da mesma tabela em outra loja;
• uma recriação feita com CREATE TABLE ... SELECT, que não cria os índices;
• em uma tabela MyISAM, os índices desativados por uma importação interrompida, que aparecem com a palavra disabled na coluna Comment do SHOW INDEX;
• a correspondência entre a tabela de controle das ordens e os índices do banco.

O arquivo gerado pelo mysqldump desativa os índices comuns das tabelas MyISAM antes de carregar as linhas e os reativa no fim. Uma importação interrompida deixa esses índices desativados, e o comando a seguir os reconstrói:

• ALTER TABLE vendas ENABLE KEYS;

Quando o desacordo está entre a tabela de controle e os índices, a correção passa pela rotina de recriação da aplicação, depois de resolvido qualquer dano físico.