Beleza mestre chiappa, obrigado mais uma vez.
________________________________ De: J. Laurindo Chiappa <jlchia...@yahoo.com.br> Para: oracle_br@yahoogrupos.com.br Enviadas: Quarta-feira, 28 de Agosto de 2013 15:47 Assunto: [oracle_br] Re: Análise de desempenho Tudo jóia ? Então, realmente o procedimento único para se poder prever a performance antes de se executar em prod é mesmo vc executar a rotina em questão num ambiente o MAIS IDÊNTICO possível à produção, com a mesma capacidade, com mesma carga de trabalho e concorrência/sessões simultâneas, mesmo hardware no mais possível, mesma exata camada de softwares, mesmo volume de dados (inclusive, essa é a própria DEFINIÇÃO de Homologação) e monitorar/levantar os indicadores de performance, sim.... O TEMPO DE RESPOSTA medido no relógio também é importante, claro, mas são os indicadores que vão te mostrar se o consumo de recursos do SQL está razoável/aceitável... Porém, o ponto questionável aí no seu texto é usar o ASH/AWR e o OEM, apenas : a questão é que esses caras te dão indicadores GERAIS, para o database como um todo, e absolutamente Não Há como vc extrair informação particular de uma sessão(a sessão que está executando a rotina, no caso) com informações gerais, né não ?? Então, além dos indicadores gerais, eu NECESSARIAMENTE lanço mão de indicadores Específicos da sessão em análise, como : waits e blocos acessados via trace+tkprof (vide manual de tuning) , consulta da diferença dos valores dos waits e estatísticas de sessão (mais ou menos cfrme http://asktom.oracle.com/pls/asktom/ASKTOM.download_file?p_file=6551378329289980701 ) , plano de execução (REAL e extendido, com temp space consumida, a-rows e e-rows) e estatísticas do SQL (obtidos da v$sql, v$sql_plan, da execução do DBMS_PLAN, etc) .... okdoc ?? E que fique Claro, o objetivo destas ações é evidenciar que : - os SQLs são de boa qualidade, não fazendo montes absurdos de I/O para cada linha processada - o processamento não incorre em nenhum volume absurdo de nenhum wait , nem as estatísticas da sessão degradam notavelmente - os SQLs mais importantes/menos performáticos não está fazendo nenhuma operação absurda, tipo construir uma tabela hash de grandes proporções ou fazer um table scan/index scan em ambiente OLTP, coisas do tipo blz ? []s Chiappa --- Em mailto:oracle_br%40yahoogrupos.com.br, Rafael Mendonca <raffaell.ti77@...> escreveu > > Senhores, bom dia. > > Gostaria saber de vocês, o que normalmente qual é o procedimento que vocês > fazem quando: > > - Uma pessoa que está implementando uma nova requisição no sistema que irá > para aplicação e que pede para você analisar se irá ocorrer algum problema de > desempenho no SGBD de homologação antes de ir para produção, e pede para > monitorar e gerar um relatório se os testes foram satisfatórios ou não. No > caso, ele abre várias sessões e manda vários e vários testes para averiguar > se irá ocorrer problema de desempenho. > > > No meu caso, eu abro o EM na página de desempenho e acompanho em tempo real > pelos gráficos aonde está ocorrendo maior problema de desempenho e daí vejo > os SQL ID que estão consumindo mais I/O, concorrência, uso de CPU etc. > > Fora isso, eu também gero um relatório AWR no intervalo dos testes realizados > para me dar um pouco mais de informação. > > > Alguém aqui faz diferente ou poderia me dar uma dica? > > Eu também estava pensando em gerar uma baseline do comportamento normal do > SGBD e depois gerar um AWR no intervalo dos testes realizados, para fins de > comparação, não sei se também seria uma boa idéia. > > [As partes desta mensagem que não continham texto foram removidas] > [As partes desta mensagem que não continham texto foram removidas]
