Problema PreparedStatement - BUG no JDBC?(URGENTE)

7 respostas
guilhermevh

Pessoal é o seguinte, estou dando manutenção em um sistema e detectei o seguinte problema:

tenho um método que faz um update em uma tabela que contém 8 milhões de registros, e se seguir o padrão recomando do PreparedStatement o processo demora cerca de 5 minutos.

Connection con = bancoDados.abrirConexao();
    
        String sql = "UPDATE transacao  SET login = ?, data=?, numeroip = ? , tipotrans = ? , hora = ?  WHERE numero = ? ";

        PreparedStatement pst = con.prepareStatement(sql);
        
        try {

            pst.setString(1, "ADMIN");
            pst.setTimestamp(2, new java.sql.Timestamp(new java.util.Date().getTime()));
            pst.setString(3, "127.0.0.1");
            pst.setString(4,"800000");
            pst.setTimestamp(5, new java.sql.Timestamp(new java.util.Date().getTime()));
            pst.setString(6, "723054");

            pst.executeUpdate();
            pst.close();

            System.out.println("Atualizado!");

        } catch (Exception e) {
            System.out.println("Erro!");
            throw new Exception("Nao foi possivel salvar transacao: " + e.getMessage());
        }

essa execução está demorando em torno de 5 minutos para ser processado, porém descobri que se eu tirar a linha pst.setString(6, “723054”); e adicionar o valor direto na query, a execução é feita em 1 segundo.

Agora pergunto eu. O porquê disso? acredito que seja bug do driver JDBC pois não encontrei nada sobre isso. E acredito que do jeito que está, é o padrão recomendado (tirando o número ser String em outras coisas)…

Se alguém tiver alguma idéia…

OBS: O banco de dados é o postgres.

Grato,
Atenciosamente,

7 Respostas

gomesrod

Este campo “numero” está no banco de dados como string (char)?

surfzera

se você colocar o numero como int , vai mais rapido ?

robinsonbsilva

jovem,

Qual o tipo de dado da coluna número?
Do jeito que está ela faz assim:

numero="1236" // ou seja, ele converte para Text essa busca, e o desempenho nesse caso é péssimo mesmo

caso seja Numérico

numero=1236 //
guilhermevh

sim…

gomesrod

Que mal :frowning:

Eu perguntei isso porque se o campo fosse numérico na tabela, já teríamos uma explicação para o que está acontecendo (post do robinsonbsilva). Como está certo (query com String e banco com char), voltamos à estaca zero.

E

a) Existe um índice cujo campo inicial é “numero”? Ou está havendo um “table scan”?

b) Qual é o número de linhas afetadas por esse comando, em média?

c) Pode ser que você tenha tentado executar o comando primeiramente com PreparedStatement e então ele demorou esse tempo todo. Depois, quando os dados relevantes já estavam na memória, você tentou executar o mesmo comando só que com um valor já “chumbado”. Nesse caso, ele é mais rápido mesmo, mas porque os dados estavam na memória, não porque o dado estava chumbado.

guilhermevh


Eu perguntei isso porque se o campo fosse numérico na tabela, já teríamos uma explicação para o que está acontecendo (post do robinsonbsilva). Como está certo (query com String e banco com char), voltamos à estaca zero.

nem fale, isso está parecendo assombração…

a) Existe um índice cujo campo inicial é “numero”? Ou está havendo um “table scan”?

b) Qual é o número de linhas afetadas por esse comando, em média?

c) Pode ser que você tenha tentado executar o comando primeiramente com PreparedStatement e então ele demorou esse tempo todo. Depois, quando os dados relevantes já estavam na memória, você tentou executar o mesmo comando só que com um valor já “chumbado”. Nesse caso, ele é mais rápido mesmo, mas porque os dados estavam na memória, não porque o dado estava chumbado.

a) não existia…e foi criado com uma melhorar, mas ainda não comparado co m alteração.
b) essa linha afeta apenas um registro.
c) não ocorreu isso, pois mesmo executando seguidas vezes esse comando ele tem a mesma demora, e logo após a alteração ele já fica rápido…


eu acho que resolveu o problema aqui, acho que não me atentei muito a uma coisa e acredito que tenha resolvido, a versão da API JDBC… :oops: (deveria ter sido a primeira coisa a olhar e testar)…

Criado 28 de outubro de 2009
Ultima resposta 28 de out. de 2009
Respostas 7
Participantes 5