Menu de navegação

[auzenphParticipante]

Vê só galera, vou tentar ser conciso, mas a duvida é meio complexa.
Resumindo:
Eu trabalho num sistema Web desenvolvido em JSP (Java) com servers Tomcat.
O acesso ao banco de dados pela aplicação JSP é todo configurado via Hibernate.
E o SGBD é Oracle 10g. A versao do java é 5. Eu faço parte da equipe de BD. Os desenvolvedores Java, recentemente se depararam com um problema e pediram uma solução:

O problema:
1)Eles têm uma consulta SQL (bem grande por sinal), em um dos arquivos JSP, que fica processando indefinidamente no banco e não retorna nunca, nunca acaba.

Parametros de conhecimento:
1)Eles têm outras consultas (grandes também, muito grandes), no MESMO arquivo (mesma classe JSP) e que funcionam perfeitamente.

2)Eu e o DBA vimos no Enterprise manager que a sessão fica trabalhando indefinidamente e não termina nunca, ocupando um poder computacional gigante

3)Pegamos os traces e vimos que ele fica lendo indefinidamente os DATA Files (sequencial read e scatter read)

4)Não achamos problemas nenhum na consulta, pois EU MESMO criei uma classe Java (sem ser JSP), só com um MAIN e uma conexão ORACLE com o driver que eles usam e a consulta retornou certinha.

5)Rodei a consulta no PL/SQL Developer e ela retornou.

6)Trocamos a string do SQL da consulta que não funciona para a string da consulta que funciona, e ela continuou sem funcionar (ou seja, poderiamos pensar que era alguma coisa no codigo java, mas subsituindo a consulta q funciona pela que não funciona, continua sem funcionar…)

7)O mesmo sistema JSP no ambiente de produção tem comportamento diferente do ambiente de desenvolvimento. Em desenvolvimento ele fica indefinindo. em produção ele ocupa todo o tablespace com a consulta..e começa a abrir sessoes uma atras da outra…e vira uma bola de neve.

8) Aconteceu com um fato que pode ajudar na investigação:
Uma consulta apresentou o mesmo problema e o DBA conseguiu fazer ela funcionar somente aumentando o Tablespace
Podemos pensar que é problema de performance entao. Mas em ambiente de Desenvolvimento a consulta problemática não chega a ocupar todo o Tablespace, então aumentá-lo não é a soluçao.

Voces tem alguma ideia do que pode ser?
Se for performance…que parametros podem ser modificados?

Obrigado pela atenção!

Att.
Marcelo

[Marcio68AlmeidaParticipante]

Se você alterar as colunas do select por um Select count(*) ele traz alguma coisa ?
Pode ser a parte do FETCH que demora demais para trazer a resposta…

[auzenphParticipante]

O DBA falou que colocando um limite no numero de registros retornados ele retorna.

tipo um ROWNUM < 500 por exemplo

ai quando coloca pra voltar tudo …trava de novo

esse do count(*) não testamos

[Marcio68AlmeidaParticipante]

Bom, nem precisa testar o count, já está bastante claro que o problema está no retorno das informações.
Você está trazendo uma massa de dados muito grande que não está sendo devidamente tratada pelo programa, por isso a aparência de travamento.
É necessário voltar essa massa de dados ?
Vocês já tentaram utilizar o cursor para esse processo ?

[Rodrigo AlmeidaParticipante]

Olá,

Dúvida 1

Quando você menciona OCUPAÇÂO da tablespace, estamos falando da tablespace TEMPORÁRIA, certo?

Apenas um SELECT!!!

Solução 1:

Aumenta a tablespace temporária.

Solução 2:

Veja a estatísticas das tabelas e índices, se estiver desatualizado, retire uma nova estatística.

Dúvida 2

Porquê não foi analisado o plano de execução da Query, e comparado com o ambiente de desenvolvimento e produção, pode ser falta de índice.

Dúvida 3

Faça um trace de sessão, passe um tkprof, e veja os planos que serão gerados e seus resultados.

Sugestão 1

Verifique a configuração do Hibernate de desenvolvimento e produção, pode ter diferenças no JDBC Pool ou até mesmo no formato de conexão.

Abraços,
Rodrigo Almeida

[auzenphParticipante]

solução 1) ja fizemos, nao muda nada…a tablespace nao é completamente ocupada…e o sistema continua pesado e sem destravar

solução 2)estao todos atualizados e com indices

solução 3)ja passamos TKPROF ja comparamos os arquivos…e tem um pedaço faltando em 1…e parece ser algo de permissoes, porem nao deu pra tirar conclusao alguma sobre isso

solução 4)essa é a mais interessante…o pessoal do java precisa revisar essas configurações…mas o etranho é que NA MESMA CLASSE uma consulta funciona e outra nao (tendo em vista que a consulta que funciona eh maior e retorna mais registros que a consulta que NAO funciona)

[auzenphParticipante]

Vocês já tentaram utilizar o cursor para esse processo ?

Tipo, nao adianta muito essas modificações pontuais, pois como eu disse:
Tem uma outra consulta na mesma classe que é muito maior, retorna mais dados e nao trava.

Vamos tentar trocar o driver oracle.

[vieriParticipante]

Simplesmente a consulta do hibernate está sentando a máquina.

coloque ai o plano de execução gerados pelo
duvido que seja menor que 10 mil !!
e que não esteja fazendo algum FTS..

[vieriParticipante]

*pelo TKPROF

[Marcio68AlmeidaParticipante]

[quote=”auzenph”:1q7cwwes]solução 4)essa é a mais interessante…o pessoal do java precisa revisar essas configurações…mas o etranho é que NA MESMA CLASSE uma consulta funciona e outra nao (tendo em vista que a consulta que funciona eh maior e retorna mais registros que a consulta que NAO funciona)[/quote]

As duas consultas trazem o mesmo número de colunas ?
É estranho que uma que traga mais linhas funcione e uma que traga menos linhas não funcione…

[Autor]

Posts