Re: [oracle_br] Re: Eventos em espera
es de linhas. Cuidado com a concorrência, neste caso somente um
> usuário poderia disparar esta rotina.
>
> Se é uma tela de consulta/relatório, a hora de verificar é durante a execução.
>
> Pontos a considerar:
> - tunning da query: vc conhece TUNNING_TASK
> (dbms_sqltune.create_tuning_task)? Isto pode te ajudar bastante, a analizar
> sua query, sugerindo indices ou melhor escolha do plano de execução criando
> um profile otimizado do sql.
> - Verificar LOCK durante a execução (tem o script UTLLOCKT.sql na área de
> rdbms/admin). Se está havendo lock entre sessões, uma delas ficará aguardando
> com a execução parada ...
> - Verificar V$SESSION_LONGOPS (monitorar query´s demoradas):
>
> SELECT TO_CHAR(s.sid) sid,
> TO_CHAR(s.serial#) serial,
> s.username,
> SUBSTR(DECODE(target_desc,NULL,DECODE(target,NULL,opname, concat(opname,
> concat (' - ',target))),
> DECODE(target,NULL,concat(opname, concat (' : ',target_desc)),
> concat(opname, concat (' : ',concat(target_desc, concat (' -
> ',target)),1,25) "Processo" ,
> TO_CHAR(start_time,'dd/mm/ hh24:mi:ss') "Inicio",
> TO_CHAR(elapsed_seconds,'999') "Tempo(s)" ,
> DECODE(sofar, 0, 0, ROUND(elapsed_seconds*(totalwork-sofar)/sofar)) "Blocos
> Processados"
> FROM v$session_longops l,
> v$session s
> WHERE sofar < totalWork
> AND s.sid =l.sid;
>
> Espero ter ajudado, sei que esta situação é complicadíssima pois já senti na
> pele.
>
> Forte abraço.
>
> Ederson Elias
> DBA Oracle
> http://br.linkedin.com/pub/ederson-elias/24/8b/8b0
>
>
> --- Em oracle_br@yahoogrupos.com.br, Rafael Vieira escreveu
> >
> > Chiappa, gostaria de mais uma ajuda sua...
> > Esse batch rodou ontem pela manhã durante 40 minutos, e a tarde rodou em 8
> > horas, o pessoal veio argumentar que a aplicação não mudou absolutamente
> > nada, e que queria uma explicação por conta desse tempo, está todo mundo
> > colocando a culpa no database, mas eu não mudei absolutamente nada, não foi
> > feita nenhuma alteração e nenhum ajuste foi feito no database, o argumento
> > do pessoal é que o o mesmo batch que rodou em 40 minutos e a tarde foi
> > colocado novamente em execução e acabou em 8 horas. O meu argumento está
> > sendo que o problema é a query que detectei mal escrita que está dando o
> > problema e que eh executada dezenas de vezes, mas eles voltam a argumentar
> > o tempo que foi rodado antes em 40 minutos, teria algo a acrescentar em
> > defesa do database? Preciso de uma justificativa à dar sobre isso, eu sei
> > que é difícil pra uma pessoa que está de fora e não tem nem noção da
> > infra-estrutura, nem idéia do modelo e de como é o processo,
> > mas se tiver algo a acrescentar, eu agradeceria e MUITO, pois isso vai pra
> > diretoria e preciso de algo para me justificar. O grande problema é que não
> > tenho à quem recorrer além do Blog e dos amigos.
> >
> >
> >
> > De: Rafael Vieira
> > Para: "oracle_br@yahoogrupos.com.br"
> > Enviadas: Quinta-feira, 10 de Maio de 2012 9:35
> > Assunto: Re: [oracle_br] Re: Eventos em espera
> >
> >
> >
> > Chiappa, muito obrigado pela ajuda.
> >
> > Realmente, achei muito interessante essa criação da view materializada,
> > realmente essae query busca milhões de linhas todas as vezes que é
> > consultada, e como falei anteriormente ela é rodada centenas de vezes( que
> > segundo o pessoal realmente é necessário). Irei fazer sim esse teste junto
> > com os desenvolvedores, tomara que dê certo, pelo que li sobre o que vc
> > escreveu no prórpio grupo sobre MV's é uma excelente alternativa.
> >
> > Quanto ao paralelismo em tabelas não existe, existe sim paralelismo em
> > índices onde a maioria está setada para 8 que é o total de processadores
> > que nós temos, como esse banco é expecífico para esse BATCH, quando o
> > processo inicia ninguém mais se conecta no banco por questão de
> > concorrência etc...
> >
> > No caso para aumentar a memória para SORT's e HASH's vc se refere a PGA? Eu
> > sou muito novo na área e estou aprendendo aos poucos, eu me encontro em uma
> > situação dificil pois não tem outro DBA para me auxiliar.
> > Então alguns termos as vezes não fica claro para mim.
> >
> > As estatísticas, todas estão sim atualizadas.
> >
> >
> > De: J. Laurindo Chiappa
> > Para: oracle_br@yahoogrupos.com.br
> > Enviadas: Quarta-f
Re: [oracle_br] Re: Eventos em espera
Olha que estranho... é uma base OLTP, mas que ninguém se conecta, e a única coisa que rodam é essa batch? Ou seja... ela não tem característica de base OLTP. Diante desse cenário eu acredito que seja possível SIM ajustar a base para que essa batch rode mais rápido. Só que eu não sei o que faz essa batch (se é muito insert, se é muito update, se são tabelas muito grandes, ou se são muitas operações em um monte de tabelas pequenas...), então fica complicado opinar. Exemplos: tabelas MUITO grandes, usar particionamento. Selects retornando muitos dados: TALVEZ alterar o tamanho do bloco, criar uma tablespace com bloco de 32k... Aumentar a Large Pool ou alguma outra estrutura de memória dependendo do que acontece nesse batch... Enfim, tudo DEPENDE. 2012/5/10 Rafael Vieira > ** > > > Milton, obrigado pelo retorno. > > 1 - OLTP > > 2 - É manual, não tem um horário certo, mas o pessoal costuma a rodar pela > manhã e a tarde, às vezes deixam a noite também. > > 3 - Nos dois horários apenas um usuário estava conectado pela aplicação > rodando o BATCH. > > 4 - Creio que não, eu não acompanhei o processo inteiro, pois tinha outros > fazeres, mas o tempo que acompanhei, não tinha ninguém concorrendo com o > BATCH, apenas ele estava sendo executado. > > > De: Milton Bastos Henriquis Jr. > Para: oracle_br@yahoogrupos.com.br > Enviadas: Quinta-feira, 10 de Maio de 2012 11:35 > > Assunto: Re: [oracle_br] Re: Eventos em espera > > 1 - Essa base é OLTP ou OLAP? > > 2 - Essa Batch roda de quanto em quanto tempo? É automático ou manual? > > 3 - Quantos usuários tinham conectados e trabalhando "ontem de manhã", > quando rodou em 40 minutos? > E quantos tinham a tarde, quando rodou em 8 horas? > > 4 - Haviam OUTROS processos concorrentes dessa batch a tarde que não tinham > de manhã? > > 2012/5/10 Rafael Vieira > > > ** > > > > > > > Chiappa, gostaria de mais uma ajuda sua... > > Esse batch rodou ontem pela manhã durante 40 minutos, e a tarde rodou em > 8 > > horas, o pessoal veio argumentar que a aplicação não mudou absolutamente > > nada, e que queria uma explicação por conta desse tempo, está todo mundo > > colocando a culpa no database, mas eu não mudei absolutamente nada, não > foi > > feita nenhuma alteração e nenhum ajuste foi feito no database, o > argumento > > do pessoal é que o o mesmo batch que rodou em 40 minutos e a tarde foi > > colocado novamente em execução e acabou em 8 horas. O meu argumento está > > sendo que o problema é a query que detectei mal escrita que está dando o > > problema e que eh executada dezenas de vezes, mas eles voltam a > argumentar > > o tempo que foi rodado antes em 40 minutos, teria algo a acrescentar em > > defesa do database? Preciso de uma justificativa à dar sobre isso, eu sei > > que é difícil pra uma pessoa que está de fora e não tem nem noção da > > infra-estrutura, nem idéia do modelo e de como é o processo, > > mas se tiver algo a acrescentar, eu agradeceria e MUITO, pois isso vai > pra > > diretoria e preciso de algo para me justificar. O grande problema é que > não > > tenho à quem recorrer além do Blog e dos amigos. > > > > > > De: Rafael Vieira > > Para: "oracle_br@yahoogrupos.com.br" > > Enviadas: Quinta-feira, 10 de Maio de 2012 9:35 > > Assunto: Re: [oracle_br] Re: Eventos em espera > > > > > > > > > > Chiappa, muito obrigado pela ajuda. > > > > Realmente, achei muito interessante essa criação da view materializada, > > realmente essae query busca milhões de linhas todas as vezes que é > > consultada, e como falei anteriormente ela é rodada centenas de vezes( > que > > segundo o pessoal realmente é necessário). Irei fazer sim esse teste > junto > > com os desenvolvedores, tomara que dê certo, pelo que li sobre o que vc > > escreveu no prórpio grupo sobre MV's é uma excelente alternativa. > > > > Quanto ao paralelismo em tabelas não existe, existe sim paralelismo em > > índices onde a maioria está setada para 8 que é o total de processadores > > que nós temos, como esse banco é expecífico para esse BATCH, quando o > > processo inicia ninguém mais se conecta no banco por questão de > > concorrência etc... > > > > No caso para aumentar a memória para SORT's e HASH's vc se refere a PGA? > > Eu sou muito novo na área e estou aprendendo aos poucos, eu me encontro > em > > uma situação dificil pois não tem outro DBA para me auxiliar. > > Então alguns termos as vezes não fica claro para mim. > > > > As estatísticas, todas estão
Re: [oracle_br] Re: Eventos em espera
Ederson, obrigado pela ajuda, irei fazer essa análise sim.
De: ederson2001br
Para: oracle_br@yahoogrupos.com.br
Enviadas: Quinta-feira, 10 de Maio de 2012 11:51
Assunto: [oracle_br] Re: Eventos em espera
Rafael e Chiappa,
Permitam-me dar minha opinião.
Uma query rodando em 40 minutos, prá mim é um tempo longo se ela não for um
relatório/report. Se está em uma tela de consulta e com o sistema aberto para o
usuário da ponta rodá-la, pode olhar que esta rotina é uma séria candidata a um
refactoring, nem que seja para uma mudança de estratégia.
Outro ponto: levar 8 horas para rodar? só se for um processo batch que atualiza
zilhões de linhas. Cuidado com a concorrência, neste caso somente um usuário
poderia disparar esta rotina.
Se é uma tela de consulta/relatório, a hora de verificar é durante a execução.
Pontos a considerar:
- tunning da query: vc conhece TUNNING_TASK (dbms_sqltune.create_tuning_task)?
Isto pode te ajudar bastante, a analizar sua query, sugerindo indices ou melhor
escolha do plano de execução criando um profile otimizado do sql.
- Verificar LOCK durante a execução (tem o script UTLLOCKT.sql na área de
rdbms/admin). Se está havendo lock entre sessões, uma delas ficará aguardando
com a execução parada ...
- Verificar V$SESSION_LONGOPS (monitorar query´s demoradas):
SELECT TO_CHAR(s.sid) sid,
TO_CHAR(s.serial#) serial,
s.username,
SUBSTR(DECODE(target_desc,NULL,DECODE(target,NULL,opname, concat(opname, concat
(' - ',target))),
DECODE(target,NULL,concat(opname, concat (' : ',target_desc)),
concat(opname, concat (' : ',concat(target_desc, concat (' -
',target)),1,25) "Processo" ,
TO_CHAR(start_time,'dd/mm/ hh24:mi:ss') "Inicio",
TO_CHAR(elapsed_seconds,'999') "Tempo(s)" ,
DECODE(sofar, 0, 0, ROUND(elapsed_seconds*(totalwork-sofar)/sofar)) "Blocos
Processados"
FROM v$session_longops l,
v$session s
WHERE sofar < totalWork
AND s.sid =l.sid;
Espero ter ajudado, sei que esta situação é complicadíssima pois já senti na
pele.
Forte abraço.
Ederson Elias
DBA Oracle
http://br.linkedin.com/pub/ederson-elias/24/8b/8b0
--- Em oracle_br@yahoogrupos.com.br, Rafael Vieira
escreveu
>
> Chiappa, gostaria de mais uma ajuda sua...
> Esse batch rodou ontem pela manhã durante 40 minutos, e a tarde rodou em 8
> horas, o pessoal veio argumentar que a aplicação não mudou absolutamente
> nada, e que queria uma explicação por conta desse tempo, está todo mundo
> colocando a culpa no database, mas eu não mudei absolutamente nada, não foi
> feita nenhuma alteração e nenhum ajuste foi feito no database, o argumento do
> pessoal é que o o mesmo batch que rodou em 40 minutos e a tarde foi colocado
> novamente em execução e acabou em 8 horas. O meu argumento está sendo que o
> problema é a query que detectei mal escrita que está dando o problema e que
> eh executada dezenas de vezes, mas eles voltam a argumentar o tempo que foi
> rodado antes em 40 minutos, teria algo a acrescentar em defesa do database?
> Preciso de uma justificativa à dar sobre isso, eu sei que é difícil pra uma
> pessoa que está de fora e não tem nem noção da infra-estrutura, nem idéia do
> modelo e de como é o processo,
> mas se tiver algo a acrescentar, eu agradeceria e MUITO, pois isso vai pra
> diretoria e preciso de algo para me justificar. O grande problema é que não
> tenho à quem recorrer além do Blog e dos amigos.
>
>
> ________________
> De: Rafael Vieira
> Para: "oracle_br@yahoogrupos.com.br"
> Enviadas: Quinta-feira, 10 de Maio de 2012 9:35
> Assunto: Re: [oracle_br] Re: Eventos em espera
>
>
>
> Chiappa, muito obrigado pela ajuda.
>
> Realmente, achei muito interessante essa criação da view materializada,
> realmente essae query busca milhões de linhas todas as vezes que é
> consultada, e como falei anteriormente ela é rodada centenas de vezes( que
> segundo o pessoal realmente é necessário). Irei fazer sim esse teste junto
> com os desenvolvedores, tomara que dê certo, pelo que li sobre o que vc
> escreveu no prórpio grupo sobre MV's é uma excelente alternativa.
>
> Quanto ao paralelismo em tabelas não existe, existe sim paralelismo em
> índices onde a maioria está setada para 8 que é o total de processadores que
> nós temos, como esse banco é expecífico para esse BATCH, quando o processo
> inicia ninguém mais se conecta no banco por questão de concorrência etc...
>
> No caso para aumentar a memória para SORT's e HASH's vc se refere a PGA? Eu
> sou muito novo na área e estou aprendendo aos poucos, eu me encontro em uma
> situação dificil pois não tem outro DBA para me auxiliar.
> Então alguns termos as vezes não fica claro para mim.
>
>
Re: [oracle_br] Re: Eventos em espera
Milton, obrigado pelo retorno. 1 - OLTP 2 - É manual, não tem um horário certo, mas o pessoal costuma a rodar pela manhã e a tarde, às vezes deixam a noite também. 3 - Nos dois horários apenas um usuário estava conectado pela aplicação rodando o BATCH. 4 - Creio que não, eu não acompanhei o processo inteiro, pois tinha outros fazeres, mas o tempo que acompanhei, não tinha ninguém concorrendo com o BATCH, apenas ele estava sendo executado. De: Milton Bastos Henriquis Jr. Para: oracle_br@yahoogrupos.com.br Enviadas: Quinta-feira, 10 de Maio de 2012 11:35 Assunto: Re: [oracle_br] Re: Eventos em espera 1 - Essa base é OLTP ou OLAP? 2 - Essa Batch roda de quanto em quanto tempo? É automático ou manual? 3 - Quantos usuários tinham conectados e trabalhando "ontem de manhã", quando rodou em 40 minutos? E quantos tinham a tarde, quando rodou em 8 horas? 4 - Haviam OUTROS processos concorrentes dessa batch a tarde que não tinham de manhã? 2012/5/10 Rafael Vieira > ** > > > Chiappa, gostaria de mais uma ajuda sua... > Esse batch rodou ontem pela manhã durante 40 minutos, e a tarde rodou em 8 > horas, o pessoal veio argumentar que a aplicação não mudou absolutamente > nada, e que queria uma explicação por conta desse tempo, está todo mundo > colocando a culpa no database, mas eu não mudei absolutamente nada, não foi > feita nenhuma alteração e nenhum ajuste foi feito no database, o argumento > do pessoal é que o o mesmo batch que rodou em 40 minutos e a tarde foi > colocado novamente em execução e acabou em 8 horas. O meu argumento está > sendo que o problema é a query que detectei mal escrita que está dando o > problema e que eh executada dezenas de vezes, mas eles voltam a argumentar > o tempo que foi rodado antes em 40 minutos, teria algo a acrescentar em > defesa do database? Preciso de uma justificativa à dar sobre isso, eu sei > que é difícil pra uma pessoa que está de fora e não tem nem noção da > infra-estrutura, nem idéia do modelo e de como é o processo, > mas se tiver algo a acrescentar, eu agradeceria e MUITO, pois isso vai pra > diretoria e preciso de algo para me justificar. O grande problema é que não > tenho à quem recorrer além do Blog e dos amigos. > > > De: Rafael Vieira > Para: "oracle_br@yahoogrupos.com.br" > Enviadas: Quinta-feira, 10 de Maio de 2012 9:35 > Assunto: Re: [oracle_br] Re: Eventos em espera > > > > > Chiappa, muito obrigado pela ajuda. > > Realmente, achei muito interessante essa criação da view materializada, > realmente essae query busca milhões de linhas todas as vezes que é > consultada, e como falei anteriormente ela é rodada centenas de vezes( que > segundo o pessoal realmente é necessário). Irei fazer sim esse teste junto > com os desenvolvedores, tomara que dê certo, pelo que li sobre o que vc > escreveu no prórpio grupo sobre MV's é uma excelente alternativa. > > Quanto ao paralelismo em tabelas não existe, existe sim paralelismo em > índices onde a maioria está setada para 8 que é o total de processadores > que nós temos, como esse banco é expecífico para esse BATCH, quando o > processo inicia ninguém mais se conecta no banco por questão de > concorrência etc... > > No caso para aumentar a memória para SORT's e HASH's vc se refere a PGA? > Eu sou muito novo na área e estou aprendendo aos poucos, eu me encontro em > uma situação dificil pois não tem outro DBA para me auxiliar. > Então alguns termos as vezes não fica claro para mim. > > As estatísticas, todas estão sim atualizadas. > > > De: J. Laurindo Chiappa > Para: oracle_br@yahoogrupos.com.br > Enviadas: Quarta-feira, 9 de Maio de 2012 18:10 > Assunto: [oracle_br] Re: Eventos em espera > > > Colega, lamento ser o desmancha-prazeres, mas é um Fato que : > > - não existe um "parâmetro", um setting que vc aplique e faça qquer tarefa > no banco de dados ficar "rápida" > > - como qquer software, se vc mandar o banco de dados fazer uma asneira > (exemplo, ler a mesma informação vezes e vezes sem conta, repetidas vezes, > ou não usar o melhor construto SQL para uma solicitação, ou acessar um > modelo falho, etc ), ele VAI burramente fazer, não tem por onde > > ==> Então, a partir do momento que vc identificou um processamento que de > cara não parece ser bem-feito E ainda por cima é repetido N vezes, pouco vc > tem fazer no banco de dados em si - com certeza, algum tipo de Tuning no > processo vai ser inescapável E que fique Claro, esse Tuning tanto pode > envolver alterações no SQL envolvido (o que é comum), quanto também pode > envolver no modelo (por exemplo, de-normalizando alguns pontos, > criando/remo
Re: [oracle_br] Re: Eventos em espera
Chiappa, gostaria de mais uma ajuda sua... Esse batch rodou ontem pela manhã durante 40 minutos, e a tarde rodou em 8 horas, o pessoal veio argumentar que a aplicação não mudou absolutamente nada, e que queria uma explicação por conta desse tempo, está todo mundo colocando a culpa no database, mas eu não mudei absolutamente nada, não foi feita nenhuma alteração e nenhum ajuste foi feito no database, o argumento do pessoal é que o o mesmo batch que rodou em 40 minutos e a tarde foi colocado novamente em execução e acabou em 8 horas. O meu argumento está sendo que o problema é a query que detectei mal escrita que está dando o problema e que eh executada dezenas de vezes, mas eles voltam a argumentar o tempo que foi rodado antes em 40 minutos, teria algo a acrescentar em defesa do database? Preciso de uma justificativa à dar sobre isso, eu sei que é difícil pra uma pessoa que está de fora e não tem nem noção da infra-estrutura, nem idéia do modelo e de como é o processo, mas se tiver algo a acrescentar, eu agradeceria e MUITO, pois isso vai pra diretoria e preciso de algo para me justificar. O grande problema é que não tenho à quem recorrer além do Blog e dos amigos. De: Rafael Vieira Para: "oracle_br@yahoogrupos.com.br" Enviadas: Quinta-feira, 10 de Maio de 2012 9:35 Assunto: Re: [oracle_br] Re: Eventos em espera Chiappa, muito obrigado pela ajuda. Realmente, achei muito interessante essa criação da view materializada, realmente essae query busca milhões de linhas todas as vezes que é consultada, e como falei anteriormente ela é rodada centenas de vezes( que segundo o pessoal realmente é necessário). Irei fazer sim esse teste junto com os desenvolvedores, tomara que dê certo, pelo que li sobre o que vc escreveu no prórpio grupo sobre MV's é uma excelente alternativa. Quanto ao paralelismo em tabelas não existe, existe sim paralelismo em índices onde a maioria está setada para 8 que é o total de processadores que nós temos, como esse banco é expecífico para esse BATCH, quando o processo inicia ninguém mais se conecta no banco por questão de concorrência etc... No caso para aumentar a memória para SORT's e HASH's vc se refere a PGA? Eu sou muito novo na área e estou aprendendo aos poucos, eu me encontro em uma situação dificil pois não tem outro DBA para me auxiliar. Então alguns termos as vezes não fica claro para mim. As estatísticas, todas estão sim atualizadas. De: J. Laurindo Chiappa Para: oracle_br@yahoogrupos.com.br Enviadas: Quarta-feira, 9 de Maio de 2012 18:10 Assunto: [oracle_br] Re: Eventos em espera Colega, lamento ser o desmancha-prazeres, mas é um Fato que : - não existe um "parâmetro", um setting que vc aplique e faça qquer tarefa no banco de dados ficar "rápida" - como qquer software, se vc mandar o banco de dados fazer uma asneira (exemplo, ler a mesma informação vezes e vezes sem conta, repetidas vezes, ou não usar o melhor construto SQL para uma solicitação, ou acessar um modelo falho, etc ), ele VAI burramente fazer, não tem por onde ==> Então, a partir do momento que vc identificou um processamento que de cara não parece ser bem-feito E ainda por cima é repetido N vezes, pouco vc tem fazer no banco de dados em si - com certeza, algum tipo de Tuning no processo vai ser inescapável E que fique Claro, esse Tuning tanto pode envolver alterações no SQL envolvido (o que é comum), quanto também pode envolver no modelo (por exemplo, de-normalizando alguns pontos, criando/removendo índices, utilizando GTT sendo inseridas em APPEND-MODE para "separar" os dados, etc), quanto pode também envolver uso dos recursos do banco de dados para diminuir o I/O sendo feito (exemplo, particionamento da informação, uso de View materializadas que já trazem o resultado desejado para Evitar ter que ler e ler e ler a informação, etc, etc) Respondendo porém a sua pergunta sobre os eventos : os eventos com PX como prefixo são relacionados à SQL executando em parallel mode , e cfrme http://www.confio.com/blog/oracle-wait-event-explained-direct-path-read-temp , o evento de direct path read indica que ou o SQL está ordenando dados, ou está criando um área temporária em disco (para hash, talvez), ou simplesmente está fazendo paralelismo... TODAS essas operações dificilmente podem ser feitas em RAM, no caso de Parallel SQL é por definição : o modelo de paralelismo de SQL no RDBMS Oracle é dividir um segmento por intervalos e ter N slaves lendo o mesmo segmento, cada um lendo uma porção diferente de extents e cada slave enviando o que leu para a sessão MASTER, que é aquela de onde o Parallel SQL se originou, e se lê extents logicamente NÃO pode confiar no cache, que contém BLOCOS isolados O que eu diria pra vc fazer de momento então é : 1. CONFIRMAR que vc está solicitando um grau de paralelismo razoável n
