Obrigado pela informação Chiappa. Eu estou usando sqlplus com o toad. Mas nessa query o toad me deu um olé. rs
Fiscalize o Congresso: http://www.congressoemfoco.ig.com.br Fique com Deus. Um grande abraço. Att. Alexandre Brum ________________________________ De: jlchiappa <jlchia...@yahoo.com.br> Para: oracle_br@yahoogrupos.com.br Enviadas: Terça-feira, 14 de Julho de 2009 18:01:09 Assunto: [oracle_br] Re: Tempo de Extração dos dados da query Ah, ok : eu como disse estava pensando em rede mesmo, ou em plano ineficiente demorando pra retornar todas as linhas (tipo NESTED LOOP, as primeiras linhas claro vêm super-rápido, mas quantas linhas mais a ineficiência aparece), mas o cenário que vc descreve também faz todo o sentido : um plano complexo, com várias partes, assim que ele libera as primeiras linhas, que são rápidas, a toolzinha gráfica (como foi programada pra fazer) pára a execução, sim ... É um cenário que pode acontecer, até lá na ENPO quando eu fiz a minha apresentação sobre sqlplus, muita gente não acreditou mas sim pra , tunning e testes o sqlplus é parte integrante do toolset... []s Chiappa --- Em oracle...@yahoogrup os.com.br, Alexandre Brum <alexandre_brum@ ...> escreveu > > > Grande Chiappa > > Foi isso mesmo que aconteceu. Essa query tinha um union all. O Toad > apresentava logo um punhado de registros. Quando a começava a execução da > segunda parte, digo, após o union all, então começava a demorar. Pois nessa > segunda parte tinha um hint que estava provocando toda essa demora. Retirei, > fiz o teste no sqlplus e agora o tempo correto é de 1 minuto e 32 segundos. > > Muito Obrigado. > > Colega, primeiro de tudo : como Exatamente vc está medindo esse tempo de > execução, é com alguma tool que executa a query e traz os dados do início ao > fim (como por exemplo no sqlplus pedindo set timing on e executando na > íntegra, sem pause, sem nada) , ou é com SQL Navigator/TOAD/ SQL Developer ou > quetais ??? SE for com esses últimos, não pode estar acontecendo o seguinte, > esses caras são Programados pra iniciar a execução do SQL, trazer um > punhadinho de registros e PARAR a execução, quando vc clicka em Mais/Avançar/ > whatever aí sim é que eles fazem o fetch de mais registros... . Num caso > desses FACILMENTE vc pode estar sendo "tapeado& quot;, o problema é o > tempo de fetch (ie, a recuperação e o envio efetivo de registros do banco > para o cliente) que está alto, se foi isso em princípio não tem ** NADA ** a > ver com tablespace temporária, e sim com config de rede E com utilização > eficiente de rede (ie, cliente usando ARRAY > PROCESSING com quantidade adequada de registros, SQL ** NÃO ** sendo > executado row-by-row num PL/SQL, é por aí. > Meu conselho então é que vc faça o teste NO SQLPLUS, com timing on e setando > arraysize, etc, e se preciso fazendo um trace+tkprof dessa execução completa > pra ver os waits de sql*net... O "teste& quot; que vc fez com SELCT > COUNT(*) eu acho que é INVÀLIDO num cenário desses, pois o COUNT não vai > trazer os registros todos (vc não verá portanto o tempo de fetch subir, via > de regra) e além do que ele pode ser re-escrito internamente pelo banco , se > vc quer fazer tunning dfo SQL X, é X que vc tem que executar/tracejar/ ver os > planos e estatísticas de execução na V$SQL, ver os waits... > > []s > > Chiappa > --- Em oracle...@yahoogrup os.com.br , Alexandre Brum <alexandre_ brum@ > ...> escreveu > > > > > > Prezados (as) > > > > Boa tarde. > > > > Tenho uma query que o seu TEMPO DE EXECUÇÃO estava com mais de 2h. Fiz > algumas alterações, criei alguns índices e executei o analyze. O seu TEMPO DE > EXECUÇÃO passou para > > > ____________ _________ _________ _________ _________ _________ _ > Veja quais são os assuntos do momento no Yahoo! +Buscados > http://br.maisbusca dos.yahoo. com > ____________________________________________________________________________________ Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com [As partes desta mensagem que não continham texto foram removidas]
