Menu de navegação

[Anônimo]

Boa tarde pessoal!

Seguinte eu estou com um sério problema de desempenho em uma procedure que é disparada a cada minuto por um job. Já criei tudo quanto eh tipo de índice necessário nas tabelas, criei tabelas temporárias pra auxiliar no processamento dos registros, porém não consigo obter o desempenho necessário. Sei que ta muito genérico meu problema, mas gostaria de saber o que mais posso fazer pra melhorar o desempenho desta procedure, tipo de análise, testes, modificações…

Desde já agradeço a atenção de todos!

[]s,

Rafael

[IshiiParticipante]

Rafael,

Melhor colocar as queries da Procedure que estão causando a Lentidão e verificar o Stats Pack da Oracle sobre a execução da Procedure e postar os resultados aqui. Com estas informações fica mais fácil ajudar….
[]s Ishii

[IshiiParticipante]

complementando… ainda assim pode ser que alguns indíces estejam mais atrapalhando que ajudando…

[]s Ishii

[Anônimo]

Ishii, primeiramente obrigado pela ajuda.
Cara eu sou meio iniciante ainda com Oracle, como eu faço essas verificações? Como eu verifico esse Stats Packs? A ferramenta que estou utilizando aqui para visualização do banco eh o TOAD…

[]s,

Rafael

[IshiiParticipante]

Rafael,

http://mportes.blogspot.com/2005/05/sta … setup.html
http://mportes.blogspot.com/2005/05/sta … roduo.html

Tem um assunto Statspacks que tem mais um link.
[]s Ishii

[Anônimo]

Cara, consegui um trace da execução da procedure, porém não estou conseguindo interpretá-lo, vc pode me ajudar? Creio que com este trace é possível descobrir onde a coisa ta pegando né? O problema é que o arquivo é meio grande e acho q não dá pra postar aqui, como posso fazer?
Obrigado pela ajuda!

[]s,

Rafael

[IshiiParticipante]

Veja se consegue colocar em:

http://www.4shared.com

Crie uma conta e depois mande o link.

[]s Ishii

[IshiiParticipante]

Outra coisa… utilize o tkprof e coloque o resultado:

no prompt do DOS:

c:tkprof explain=user/pass@host tracefile= outputfile= sys=no sort=exeela

Com isso o resultado (outputfile) fica mais fácil de analisar. a opção sys=no remove os resultados do Oracle como extensão de tablespace, leitura de procedures etc e o sort na opção exeela demonstra exatamente as queries que estão mais lentas primeiro..

[]s Ishii

[Anônimo]

Oi Ishii,

Segue o link do arquivo de trace:

http://www.4shared.com/dir/5398388/c451 … aring.html

[]s,

Rafael

[Marcio68AlmeidaParticipante]

Bom…
Pelo que eu vi, você está executando um processo a cada minuto, porém o teu processo demora mais do que um minuto para ser executado, o que está gerando lock e consequentemente uma demora maior a cada novo processo iniciado.
Vi que os teus processos de insert, update e select são extremamente demorados, o ideal é reve-los individualmetne.
Se há muitos índices para determinada tabela, poderá degradar os processos de insert e update.

[Anônimo]

Olá Márcio,

Pela análise deste trace, vc consegue me dizer qual pode estar sendo o pronto crítico? Sei que podem existir diversos fatores que contribuem para o mal desempenho de uma procedure, mas vc sabe me dizer se nesse caso existe um ponto crítico? Mais uma duvida, o tempo de execução da rotina eh informada no “Elapsed” ou no “Total Waited”? O que quer dizer cada um destes campos?

Obrigadão pela ajuda!

[]s,

Rafael

[IshiiParticipante]

Rafael,

Você saberia me informar qual o tamanho dos arquivos de Redo do seu banco de Dados? E você poderia enviar no http://www.4shared.com o arquivo trc gerado pois pode ser que tenha mais informações sobre o Oracle mesmo.

O principal ponto crítico está no primeiro insert mesmo, mas parece-me que a sua procedure tem outros pontos complexos e parece-me ainda que o cursor dela precisa ser otimizado.

A informação do Redo Log é bastante importante para sabermos se há necessidade de aumentar o tamanho ou não…

O ideal é ir resolvendo uma query de cada vez…

[]s Ishii

[Marcio68AlmeidaParticipante]

Bom… o que aparenta é que o insert é um dos grandes “vilões” do processo, seguido de perto pelo delete…
Você vai ter que rever todos os passos do processo individualmente.
No caso do delete, você pode executar um count para ver se há registros a serem excluídos, pois o delete dá um lock na tabela, se você contar antes e não houver necessidade de delete, um lock a menos…
De resto, é trabalho de formiguinha…

[Anônimo]

Olá Márcio,

Mas o que pode deixar um simples insert tão pesado para o oracle executar? Ok, a tabela está realmente grande (particionada e com índices)…mas insert é um comando certeiro no banco, certo?
No caso do delete, ele realmente é obrigatório, pq a cada registro que é processado, sua linha correspondente na tabela xdrs_01 deve ser removido para não ser reprocessado novamente. Porém para este delete, estou utilizando como condição o rowid, isto tbm não deveria ser rápido para o banco?
Uma outra coisa que reparei é que o select inicial da procedure (select from xdrs_01) tbm está lendo. A tabela está com mais ou menos 44 milhoes de registros. Estou utilizando indice e de acordo com o Explain Plan ele está usando o index na hora da consulta. O que eu poderia fazer para melhorar este select?

Obrigadão pela ajuda!

Rafael

[Marcio68AlmeidaParticipante]

Bom…
Para o insert se tornar excessivamente lento, temos algumas possibilidades…
1. A rede pode atrapalhar principalmente se você está fazendo uma carga de informações entre bancos distintos.
2. A memória pode ser pouca ou estar fragmentada (um simples reiniciar do banco pode ajudar)
3. A gravação no disco pode estar comprometida por “n” motivos.
4. A inserção de novos registros pode estar em concorrência cou algum outro processo, isto é, está aguardando um processo terminar para concluir.
5. A tabela pode estar excessivamente fragmentada, então na hora de inserir novos registros o banco fica “procurando” espaços disponíveis para o processo.
6. Os índices podem estar fragmentados ou sem analyze.
Pode ainda haver outros motivos…

Ficar inserindo e removendo registros fragmenta MUITO as tabelas e causa degradação de todo processo, você poderia avaliar a possibilidade de inserir um flag indicativo de processo terminado.

Quanto à consulta, nem sempre o índice é o melhor caminho, mas com tabelas muito grandes a melhor opção é particionar as tabelas E os índices dela…

[Autor]

Posts