Nosso banco de dados de bugs é publico e pode ser pesquisado por qualquer um em http://bugs.mysql.com/. Se você logar no sistema, você poderá entrar novos relatórios.
Escrever um bom relatório de erro exige paciência, e fazê-lo de forma apropriada economiza tempo para nós e para você. Um bom relatório de erros contendo um teste de caso para o bug irá torná-lo muito mais fácil para corrigí-lo no próximo release. Esta seção irá ajudá-lo a escrever seu relatório corretamente para que você não perca seu tempo fazendo coisas que não irão ajudar-nos muito ou nada.
Nós encorajamos todo mundo a usar o script
mysqlbug
para gerar um relato de erros (ou
um relato sobre qualquer problema), se possível.
mysqlbug
pode ser encontrado no diretório
scripts
na distribuição fonte, ou, para
uma distribuição binária, no diretório
bin
no diretório de instalação do
MySQL. Se você não puder utilizar o
mysqlbug
(por exemplo, se você o estiver
executando no Windows), é ainda de vital importância que
você incluia todas as informações necessárias listadas
nesta seção (o mais importante é uma descrição do sistema
operacional e a versão do MySQL).
O script mysqlbug
lhe ajudará a gerar um
relatório determinando muitas das seguintes informações
automaticamente, mas se alguma coisa importante estiver
faltando, por favor forneça-o junto de sua mensagem! Por
favor leita esta seção com cuidado e tenha certeza que todas
as informações descritas aquie estão incluídas no seu
relatório.
De preferência, você deve testar o problema usando a última
versão de produção ou desenvolvimento do Servidro MySQL
antes do envio. Qualquer um deve estar apto a repetir o erro
apenas usando 'mysql test < script
' no
caso de teste incluido ou executando o script sheel ou Perl
que é incluído no relatório de erros.
Todos os erros enviados para o banco de dados dem bugs em http://bugs.mysql.com/ serão corrigidos ou documentados na próxma distribuição do MySQL. Se apenas pequenas mudanças de código forem necessárias enviaremos um patch para corrigir o problema.
O lugar comum para relatar erros e problemas é http://bugs.mysql.com.
Se você encontrar um erro de segurança no MySQL, envie um
email para <security@mysql.com>
.
Se você tiver um relatório de erro que possa ser repetido,
relate-o no banco de dados de bugs em
http://bugs.mysql.com.
Note que mesmo neste caso é bom executar o script
mysqlbug
primeiro para ter informações
sobre o sistema. Qualquer erro que pudermos repetir tem uma
grande chance de ser corrigido na próxima distribuição do
MySQL.
Para relatar outros problemas, você pode usar a lista de email do MySQL.
Lembre-se que é possível responder a uma mensagem contendo muita informação, mas não a uma contendo muito pouca. Frequentemente pessoas omitem fatos porque acreditam que conhecem a causa do problema e assumem que alguns detalhes não importam. Um bom principio é: Se você está em dúvida sobre declarar alguma coisa, declare-a ! É milhares de vezes mais rápido e menos problemático escrever um pouco de linhas a mais no seu relatório do que ser forçado a perguntar de novo e esperar pela resposta porque você não forneceu informação sufiente da primeira vez.
Os erros mais comuns acontecem porque as pessoas não indicam o número da versão da distribuição do MySQL que estão usando, ou não indicam em qual plataforma elas tem o MySQL instalado (Incluindo o número da versão da plataforma). Essa informação é muito relevante, e em 99% dos casos o relato de erro é inútil sem ela! Frequentemente nós recebemos questões como, ``Por que isto não funciona para mim?'' então nós vemos que aquele recurso requisitado não estava implementado naquela versão do MySQL, ou que o erro descrito num relatório foi resolvido em uma versão do MySQL mais nova. Algumas vezes o erro é dependente da plataforma; nesses casos, é quase impossível corrigir alguma coisa sem conhecimento do sistema operacional e o número da versão da plataforma.
Lembre-se também de fornecer informações sobre seu compilador, se isto for relacionado ao problema. Frequentemente pessoas encontram erros em compiladores e acreditam que o problema é relacionado ao MySQL. A maioria dos compiladores estão sobre desenvolvimento todo o tempo e tornam-se melhores a cada versão. Para determinar se o seu problema depende ou não do compilador, nós precisamos saber qual compilador foi usado. Note que todo problema de compilação deve ser estimado como relato de erros e, consequentemente publicado.
É de grande ajuda quando uma boa descrição do problema é incluída no relato do erro. Isto é, um bom exemplo de todas as coisas que o levou ao problema e a correta descrição do problema. Os melhores relatórios são aqueles que incluem um exemplo completo mostrando como reproduzir o erro ou o problema See Secção E.1.6, “Fazendo um Caso de Teste Se Ocorre um Corrompimento de Tabela”.
Se um programa produz uma mensagem de erro, é muito importante incluir essas mensagens no seu relatório! Se nós tentarmos procurar por algo dos arquivos usando programas, é melhor que as mensagens de erro relatadas sejam exatamente iguais a que o programa produziu. (Até o caso deve ser observado!) Você nunca deve tentar lembrar qual foi a mensagem de erro; e sim, copiar e colar a mensagem inteira no seu relatório!
Se você tem um problema com o MyODBC, você deve tentar gerar um arquivo para rastremento de erros (trace) do MyODBC. See Secção 12.2.7, “Relatando Problemas com MyODBC”.
Por favor lembre-se que muitas das pessoas que lerão seu
relatório podem usar um vídeo de 80 colunas. Quando estiver
gerando relatórios ou exemplos usando a ferramenta de linha
de comando mysql
, então deverá usar a
opção --vertical
(ou a instrução
terminadora \G
) para saída que irá
exceder a largura disponível para este tipo de vídeo (por
exemplo, com a instrução EXPLAIN SELECT
;
veja exemplo abaixo).
Por favor inclua a seguinte informação no seu relatório:
O número da versão da distribuição do MySQL que está
em uso (por exemplo, MySQL Version 3.22.22). Você poderá
saber qual versão vocês está executando, usando o
comando mysqladmin version
.
mysqladmin
pode ser encontrado no
diretório bin
sob sua instalação
do MySQL.
O fabricante e o modelo da máquina na qual você está trabalhando.
O nome do sistema operacional e a versão. Para a maioria
dos sistemas operacionais, você pode obter esta
informação executando o comando Unix uname
-a
. Se você trabalho no Windows, você pode
normalmente conseguir o nome e o número da versão com um
duplo clique sobre o ícone ''Meu Computador'' e em
seguida no menu ''Ajuda/Sobre o Windows''.
Algumas vezes a quantidade de memória (real e virtual) é relevante. Se estiver em dúvida, inclua esses valores.
Se você estiver usando uma distribuição fonte do MySQL, é necessário o nome e número da versão do compilador usado. Se você estiver usando uma distribuição binária, é necessário o nome da distribuição.
Se o problema ocorre durante a compilação, inclua a(s) exata(s) mensagem(s) de erro(s) e também algumas linhas do contexto envolvendo o código no arquivo onde o erro ocorreu.
Se o mysqld
finalizou, você deverá
relatar também a consulta que travou o
mysqld
. Normalmente você pode
encontrar isto executando mysqld
com o
log habilitado. See Secção E.1.5, “Usando Arquivos de Log para Encontrar a Causa dos Erros no mysqld”.
Se alguma tabela do banco de dados estiver relacionado ao
problema, inclua a saída de mysqldump --nodata
nome_db nome_tbl1 nome_tbl2...
. Isto é muito
fácil de fazer e é um modo poderoso de obter
informações sobre qualquer tabela em um banco de dados
que irá ajudar-nos a criar uma situação parecida da que
você tem.
Para problemas relacionados à velocidade ou problemas com
instruções SELECT
, você sempre deve
incluir a saída de EXPLAIN SELECT ...
e ao menos o número de linhas que a instrução
SELECT
produz. Você também deve
incluir a saída de SHOW CREATE TABLE
nome_tabela
para cada tabela envolvida. Quanto
mais informação você fornecer sobre a sua situação,
mais fácil será para alguém ajudar-lo! A seguir um
exemplo de um relatório de erros muito bom (ele deve ser
postado com o script mysqlbug
):
Exemplo de execução usando a ferramenta de linha de
comando mysql
(perceba o uso do
instrução terminadora \G
para
instruções cuja largura de saída deva ultrapassar 80
colunas):
mysql>SHOW VARIABLES;
mysql>SHOW COLUMNS FROM ...\G
<saida para SHOW COLUMNS> mysql>EXPLAIN SELECT ...\G
<saida para EXPLAIN> mysql>FLUSH STATUS;
mysql>SELECT ...;
<Uma pequena versão da saída do SELECT, incluindo a hora em que a consulta foi executada> mysql>SHOW STATUS;
<saida do SHOW STATUS>
Se um erro ou problema ocorrer quando estiver executando o
mysqld, tente fornecer um
script de entrada que irá reproduzir a anomalia. Este
script deve incluir qualquer arquivo de fonte necessário.
Quanto mais próximo o script puder reproduzir sua
situação, melhor. Se você puder fazer uma série de
testes repetidos, você poderá postá-lo para o
<bugs@lists.mysql.com>
para um tratamento de
alta prioridade!
Se não puder fornecer o script, você ao menos deve
incluir a saída de mysqladmin variables
extended-status processlist
na sua mensagem para
fornecer alguma informação da performance do seus
sistema.
Se você não puder produzir um caso de teste em algumas
linhas, ou se a tabela de testes for muito grande para ser
enviada por email para a lista de mensagens (mais de 10
linhas), você deverá dar um dump de suas tabelas usando
o mysqldump
e criar um arquivo
README
que descreve seu problema.
Crie um arquivo comprimido de seus arquivos usando
tar
e gzip
ou
zip
, e use o ftp
para transferir o arquivo para
ftp://support.mysql.com/pub/mysql/secret/.
E envie uma pequena descrição do problema para
<bugs@lists.mysql.com>
.
Se você achar que o MySQL produziu um resultado estranho para uma consulta, não inclua somente o resultado, mas também sua opinião de como o resultado deve ser, e uma conta descrevendo o base de sua opinião.
Quando fornecer um exemplo do problema, é melhor usar os
nomes de variáveis, nomes de tabelas, etc. utilizados na
sua situação atual do que enviar com novos nomes. O
problema pode ser relacionado ao nome da variável ou
tabela! Esses casos são raros, mas é melhor prevenir do
que remediar. Além disso, será mais fácil para você
fornecer um exemplo que use sua situação atual, que é o
que mais importa para nós. No caso de ter dados que não
deseja mostrar para outros, você pode usar o
ftp
para transferi-lo para
ftp://support.mysql.com/pub/mysql/secret/.
Se os dados são realmente confidenciais, e você não
deseja mostrá-los nem mesmo para nós, então vá em
frente e providencie um exemplo usando outros nome, mas,
por favor considere isso como uma única chance.
Inclua, se possível, todas as opções fornecidas aos
programas relevantes. Por exemplo, indique as opções que
você utiliza quando inicializa o daemon
mysqld
e aquelas que são utilizadas
para executar qualquer programa cliente MySQL. As opções
para programas como o mysqld
e
mysql
, e para o script
configure
, são frequentemente chaves
para respostas e são muito relevantes! Nunca é uma má
idéia incluí-las de qualquer forma! Se você usa algum
módulo, como Perl ou PHP por favor forneça o número da
versão deles também.
Se sua questão é relacionada ao sistema de privilégios,
por favor forneça a saída de
mysqlaccess
, a saída de
mysqladmin reload
, e todas as mensagens
de erro que você obteve quando tentava conectar! Quando
você testar seus privilégios, você deve primeiramente
executar mysqlaccess
. Depois, execute
mysqladmin reload version
e tente
conectar com o programa que gerou o problema.
mysqlaccess
pode ser encontrado no
diretório bin
sob seu diretório de
instalação do MySQL.
Se você tiver um patch para um erro, isso é bom, mas não assuma que o patch é tudo que precisamos, ou que iremos usá-lo, se você não fornecer algumas informações necessárias, como os casos de testes mostrando o erro que seu patch corrige. Nós podemos encontrar problemas com seu patch ou nós podemos não entendê-lo ao todo; se for assim, não podemos usá-lo.
Se nós não verificarmos exatamente o que o patch quer dizer, nós não poderemos usá-lo. Casos de testes irão ajudar-nos aqui. Mostre que o patch irá cuidar de todas as situações que possam ocorrer. Se nós encontrarmos um caso (mesmo que raro) onde o patch não funcionaria, ele pode ser inútil.
Palpites sobre qual é o erro, porque ocorre, ou do que ele depende, geralmente estão errados. Mesmo o time MySQL não pode adivinhar antecipadamente tais coisas sem usar um debugger para determinar a causa real do erro.
Indique na sua mensagem de e-mail que você conferiu o manual de referência e o arquivo de mensagens para que outros saibam que você tentou solucionar o problema.
Se você obter um parse error
, por
favor confira sua sintaxe com atenção! Se você não
conseguiu encontrar nada errado com ela, é extremamente
provável que que sua versão corrente do MySQL não
suporte a consulta que você está utilizando. Se você
estiver usando a versão recente e o manual em
http://www.mysql.com/documentation/manual.php não cobrir
a sintaxe que você estiver usando, o MySQL não suporta
sua consulta. Neste caso, suas unicas opções são
implementar você mesmo a sintaxe ou enviar uma mensagem
para <mysql-licensing@mysql.com>
e perguntar
por uma oferta para implementá-lo!
Se o manual cobrir a sintaxe que você estiver usando, mas você tiver uma versão mais antiga do MySQL, você deverá conferir o histórico de alterações do MySQL para ver quando a sintaxe foi implementada. Neste caso, você tem a opção de atualizar para uma nova versão do MySQL. See Apêndice D, Histórico de Alterações do MySQL.
Se você tiver um problema do tipo que seus dados aparecem
corrompidos ou você obtem erros quando você acessa
alguma tabela em particular, você deverá primeiro checar
depois tentar reparar suas tabelas com
myisamchk
ou CHECK
TABLE
e REPAIR TABLE
. See
Capítulo 4, Administração do Bancos de Dados MySQL.
Se você frequentemente obtém tabelas corrompidas, você
deve tentar encontrar quando e porque isto acontece! Neste
caso, o arquivo
mysql-data-directory/'hostname'.err
deve conter algumas informações sobre o que aconteceu.
See Secção 4.10.1, “O Log de Erros”. Por favor forneça
qualquer informação relevante deste arquivo no seu
relatório de erro! Normalmente o
mysqld
NUNCA deverá danificar
uma tabela se nada o finalizou no meio de uma
atualização! Se você puder encontrar a causa do fim do
mysqld
, se torna muito mais fácil para
nós fornecemos a você uma solução para o problema! See
Secção A.1, “Como Determinar o Que Está Causando Problemas”.
Se possível, faça o download e instale a versão mais recente do MySQL para saber se ela resolve ou não o seu problema. Todas versões do MySQL são muito bem testadas e devem funcionar sem problemas! Acreditamos em deixar tudo, o mais compátivel possível com as versões anteriores, e você conseguirá mudar de versões MySQL em minutos! See Secção 2.2.4, “Qual versão do MySQL deve ser usada”.
Se você é um cliente de nosso suporte, por favor envio o seu
relatório de erros em <mysql-support@mysql.com>
para tratamento de alta prioritário, bem como para a lista de
mensagens apropriada para ver se mais alguém teve
experiências com (e talvez resolveu) o problema.
Para informações sobre relatar erros no MyODBC, veja Secção 12.2.4, “Como Relatar Problemas com o MyODBC”.
Para soluções a alguns problemas comuns, veja See Apêndice A, Problemas e Erros Comuns.
Quando respostas são enviadas para você individualmente e não para a lista de mensagens, é considerado boa etiqueta resumir as respostas e enviar o resumo para a lista de mensagens para que outras possam ter o benefício das respostas que você recebeu que ajudaram a resolver seu problema!
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.