OkDoc, agora tá bem mais claro o que vc quer e o que tem : muito bem, no cenário que vc descreve acho que pra analisar SQLs a ferramenta básica é consultar a V$SQL (abaixo eu vou falar um pouco disso), mas antes de mais nada :
a) quero deixar Claro que , em paralelo a esse trabalho que vc vai fazer, de checagem geral, vc ** TEM ** que fazer o trabalho que, provavelmente, será MUITO muito mais útil pros seus usuários, que é a Análise focada nos mais importantes programas/telas/relatórios do aplicativo ... O fato é, o usuário se lixa pra se o banco de modo geral tá bom ou ruim, o que ele quer é o programa x, o relatório y , a tela z importantes pra ele funcionem bem, e absolutamente não é garantido que analisar SQLs em geral, e saúde do banco e geral, vá alterar o comportamento da query x, da tela y .... Esse tipo de análise envolve primeiro muuuuita conversa com o usuário, pra se entender o que ele faz, o que é mais importante pro negócio, e uma vez isso identificado vc captura os SQLs, os WAITs e acomnpanha a execução desses progs/telas/reports específicos - isso pode ser com TRACE+TKPROF , http://www.oracle-base.com/articles/10g/SQLTrace10046TrcsessAndTkprof10g.php mostra algumas possibilidades, e o manual de Tuning também b) os SQLs / programas / processos ineficientes que vc localizou (seja na análise geral, seja na análise focada) tem claro, que ser corrigidos : como é sistema de terceiros, antes de sair mexendo em qquer coisa que seja vc TEM que acionar o Suporte do fornecedor e pedir permissão c) a melhoria pode implicar em alteração de estruturas físicas, e/ou em re-escrita de SQL, e/ou em uso de determinadas features do banco, não importa : é o fornecedor em princípio que deve atuar, SEMPRE, o sistema Absolutamente Não é Teu, vc ALUGA o direito de uso, certo ? Até pode haver casos aonde o Fornecedor se recusa a mexer, aí sim, DEPOIS de autorizado vc pode fazer por conta... Muito bem, isso dito , a sua resposta : já que vc não tem direito a usar o OEM, vc até pode usar também as tools mais genéricas (como o statspack), mas imho o negócio é vc levantar os SQLs manualmente - claro, sendo OLTP vc tem tipicamente muitos e muitos SQLs diferentes em execução mas eles são relativamente simples, então adote, digamos, 100 como o TOP para os SQLs, e a técnica básica é executar na tua tool cliente de preferência algo tipo : SELECT * FROM (Select colunasdesejadas FROM V$SQL ORDER BY ordenaçãodesejada) WHERE ROWNUM < 101; consulte o manual de Referência, vc vai ver que a V$SQL tem o texto e diversas informações de performance sobre cada SQL (tipo, CPU gasta, qtdade de linhas processadas, tempo de execução gasto, qtdade de I/Os, etc) - a idéia é vc executar algumas vezes a consulta colocando como ordenação ELAPSED_TIME (isso te dpá as queies mais demoradas), algumas vezes ordenando por CPU_TIME, depois algumas por EXECUTIONS (pra saber as mais executadas), assim por diante... []s Chiappa --- Em oracle_br@yahoogrupos.com.br, Jose Luis Ramos <jose.ramos.cajuru@...> escreveu > > Chiappa, respondendo ás suas perguntas. > > Em 30 de junho de 2011 19:09, José Laurindo <jlchiappa@...>escreveu: > > > ** > > > > > > Oi, isso DEPENDE exatamente dos detalhes que vc não diz : primeiro, fale um > > pouco sobre o seu ambiente, é OLTP (montes de SQLs curtos mas em grande > > qtdade) ou é DW (poucos SQLs mas cabeludos) ?? > > > é um sistema que podemos definir como OLTP. É um sistema de geração e > emissão de nota fiscais e controle de estoque. > > > Qual SO ? > > > Linux Enterprise Red Hat 5.3 > > > Aplicação de terceiros ou desenvolvida dentro da Empresa mesmo, com > > código-fonte ?? > > > Aplicação de terceiros > > > Qual é a sua Exata versão de database , com 4 dígitos ?? > > > 10.2.0.4 > > > E a Edição, é Enterprise (o fullzão), Standard ou o capadinho do XE ?? > > > Enterprise > > > Instalação default ?? > > > Sim > > > Vc tem instalado (e tem direito de usar) o OEM ?? > > > Não tenho direito de usar > > > Vc quer inicialmente focar nos TOP-n SQLs mais mal-educados (10 ou 20, > > digamos) ?? E finalmente, defina "gasto de Recursos" pra vc : é I/O, CPU, > > qtdade de linhas lidas, qtdade de vezes que o SQL é executado, rede, memória > > , tempo de execução efetivo OU (como normalmente ocorre) vc quer saber de > > tudo isso - digamos, ter uma lista dos SQLs que mais fazem I/O, uma dos SQLs > > que mais consomem RAM, outra dos SQLs que mais fizeram envio pela rede, e > > assim por diante ?? > > > > Creio que o que eu queria é o que voce disse por ultimo, uma visão geral > para identificar o que pode estar ruim > > Obrigado e abs, > > -- > Jose Luis Ramos Jr > Campinas - SP - Brazil > Database Administrator > Fone: +55-21-19-91916882 > > > [As partes desta mensagem que não continham texto foram removidas] >
