Re: [oracle_br] Re: Estimar tempo de execução de query
Ola Pessoal, era isso que precisava saber mesmo. Para o meu caso, somente a estimativa do Explain serve. Eu sei que essa estimativa não consegue identificar concorrência, dados em cache e memoria. Eu perguntei, pois tem outros bancos de dados, como PostgreSQL entre outros, que não tem essa estimativa de tempo. Somente sabera o tempo, apos a execução. []`s Neto Em sáb, 15 de set de 2018 às 03:35, jlchia...@yahoo.com.br [oracle_br] < oracle_br@yahoogrupos.com.br> escreveu: > > > > Blz ? Então, uma alternativa Possível é vc fazer que nem algumas > ferramentas de pesquisa de dados (tipo a Oracle Discoverer, vide > https://docs.oracle.com/cd/E14571_01/bi./b32519/query_prediction.htm#BIDAG753) > fazem, ie : Estimar (ou até, sendo mais sincero, ** CHUTAR **) em cima do > plano de execução e/ou dos recursos do CBO > A idéia é tipo vc medir na sua máquina quanto tempo levou (digamos) um > FULL TABLE SCAN de mil linhas e extrapolar: se vc ver na query a > analisar/prever um FULL TABLE SCAN de 10 mil linhas, estime que esse passo > vai levar 10 vezes o tempo que vc mensurou... A questão é que vc tem no > RDBMS Oracle ** PELO MENOS ** umas duas dúzias de Operações possíveis > possíveis alpem do full table scan (como HASH JOIN, NESTED LOOPS, MERGE > JOIN, SORT GROUP BY, HASH GROUP BY, WINDOW, INDEX SCAN, INDEX RANGE SCAN, > etc etc etc) que vc teria que Mensurar uma vez no seu ambiente pra servirem > de 'métrica de base' pra tua rotina de estimativa de tempoÉ um trabalho > de LOUCO MANSO, mas tecnicamente falando é Possível, sim Como programar > e implementar tal lógica no seu ambiente se a sua tool cliente de execução > de SQLs e/ou a sua linguagem de programação não tem nada pronto nesse > sentido, ficaria POR SUA CONTA, completamente : não há NADA nativo / pronto > pra isso no RDBSM Oracle (e em NENHUM outro RDBMS, afaik) > > Essa é a sua resposta à sua pergunta, mas eu TENHO que fazer algumas obs > importantes sobre Viabilidade e Efetividade disso : > > a. o EXPLAIN PLAN é uma Estimativa ALTAMENTE GROSSEIRA em vários casos, > em especial quando há BINDs e/ou quando o RDBMS faz alguma Otimização na > sessão : > https://asktom.oracle.com/Misc/when-explanation-doesn-sound-quite.html > explica bem isso > > b. Não Há como nem sequer Estimar se os objetos a serem acessados estão > em CACHE ou não, se o datafile (supondo uma Operação que implica em leitura > do disco) tem algum tipo de 'fragmentação'/issue que cause performance > inferior no I/O > > c. Não Há como prever concorrência de nenhum tipo : ABSOLUTAMENTE NADA > impede que alguns segundos depois que a query analisada começou, OUTROS > USUÁRIOS disparem SQLs pesados que INTERFIRAM na performance desse SQL > aí... Este ponto é FREQUENTEMENTE ignorado (bobamente) , o pessoal > 'esquece' que o RDBMS Oracle é Completamente Multi-usuário > > ==> sendo assim, o que DEVERIA ACONTECER num ambiente profissionalmente e > corretamente administrado / gerenciado é : PRIMEIRO, nenhum SQL deveria ir > pra Produção ANTES de ser analisado (E TESTADO, ** executando-o ** no > ambiente HOMOLOGAÇÂO preferencialmente) pelos DBAs em conjunto com os > Analistas/desenvolvedores pra tentar prever issues de performance, e em > SEGUNDO lugar, DEVERIA haver algum mecanismo (Profiles, Resource Manager, > simples job que dispara de 5 em 5 minutos, o que puder ter) que ELIMINE > eventuais SQLs 'doidões', que demorem mais do que um tempo pré-determinado, > que eventualmente tenham Escapado da fase de Homologação > > []s > >Chiappa > > OBS : é claro, em algumas versões há a possibilidade de obter uma > Estimativa de Tempo diretamente pra cada Operação executada no plano : > OBVIAMENTE, é uma Estimativa quase sempre FURADA mas existe também, veja > https://asktom.oracle.com/pls/apex/f%3Fp%3D100:11:0P11_QUESTION_ID:1434984500346471382 > para discussão a respeito... > > ---Em oracle_br@yahoogrupos.com.br, escreveu: > > Pessoal, > Vejam se podem me tirar um duvida. > O comando Explain plan do Oracle, somente faz uma estimativa do > custo de > execução de uma consulta, ou também, faz estimativa de tempo para execução > dela? > > Eu preciso de uma estimativa (aproximada) mas que não precise esperar > para executar a consulta, pois o ambiente que tenho as consultas > demoram muito. Como eu faria para ter uma estimativa de tempo de > execução, sem necessitar esperar a execução? > > []`s Neto > > >
[oracle_br] Re: Estimar tempo de execução de query
Blz ? Então, uma alternativa Possível é vc fazer que nem algumas ferramentas de pesquisa de dados (tipo a Oracle Discoverer, vide https://docs.oracle.com/cd/E14571_01/bi./b32519/query_prediction.htm#BIDAG753) fazem, ie : Estimar (ou até, sendo mais sincero, ** CHUTAR **) em cima do plano de execução e/ou dos recursos do CBO A idéia é tipo vc medir na sua máquina quanto tempo levou (digamos) um FULL TABLE SCAN de mil linhas e extrapolar: se vc ver na query a analisar/prever um FULL TABLE SCAN de 10 mil linhas, estime que esse passo vai levar 10 vezes o tempo que vc mensurou... A questão é que vc tem no RDBMS Oracle ** PELO MENOS ** umas duas dúzias de Operações possíveis possíveis alpem do full table scan (como HASH JOIN, NESTED LOOPS, MERGE JOIN, SORT GROUP BY, HASH GROUP BY, WINDOW, INDEX SCAN, INDEX RANGE SCAN, etc etc etc) que vc teria que Mensurar uma vez no seu ambiente pra servirem de 'métrica de base' pra tua rotina de estimativa de tempoÉ um trabalho de LOUCO MANSO, mas tecnicamente falando é Possível, sim Como programar e implementar tal lógica no seu ambiente se a sua tool cliente de execução de SQLs e/ou a sua linguagem de programação não tem nada pronto nesse sentido, ficaria POR SUA CONTA, completamente : não há NADA nativo / pronto pra isso no RDBSM Oracle (e em NENHUM outro RDBMS, afaik) Essa é a sua resposta à sua pergunta, mas eu TENHO que fazer algumas obs importantes sobre Viabilidade e Efetividade disso : a. o EXPLAIN PLAN é uma Estimativa ALTAMENTE GROSSEIRA em vários casos, em especial quando há BINDs e/ou quando o RDBMS faz alguma Otimização na sessão : https://asktom.oracle.com/Misc/when-explanation-doesn-sound-quite.html explica bem isso b. Não Há como nem sequer Estimar se os objetos a serem acessados estão em CACHE ou não, se o datafile (supondo uma Operação que implica em leitura do disco) tem algum tipo de 'fragmentação'/issue que cause performance inferior no I/O c. Não Há como prever concorrência de nenhum tipo : ABSOLUTAMENTE NADA impede que alguns segundos depois que a query analisada começou, OUTROS USUÁRIOS disparem SQLs pesados que INTERFIRAM na performance desse SQL aí... Este ponto é FREQUENTEMENTE ignorado (bobamente) , o pessoal 'esquece' que o RDBMS Oracle é Completamente Multi-usuário ==> sendo assim, o que DEVERIA ACONTECER num ambiente profissionalmente e corretamente administrado / gerenciado é : PRIMEIRO, nenhum SQL deveria ir pra Produção ANTES de ser analisado (E TESTADO, ** executando-o ** no ambiente HOMOLOGAÇÂO preferencialmente) pelos DBAs em conjunto com os Analistas/desenvolvedores pra tentar prever issues de performance, e em SEGUNDO lugar, DEVERIA haver algum mecanismo (Profiles, Resource Manager, simples job que dispara de 5 em 5 minutos, o que puder ter) que ELIMINE eventuais SQLs 'doidões', que demorem mais do que um tempo pré-determinado, que eventualmente tenham Escapado da fase de Homologação []s Chiappa OBS : é claro, em algumas versões há a possibilidade de obter uma Estimativa de Tempo diretamente pra cada Operação executada no plano : OBVIAMENTE, é uma Estimativa quase sempre FURADA mas existe também, veja https://asktom.oracle.com/pls/apex/f%3Fp%3D100:11:0P11_QUESTION_ID:1434984500346471382 para discussão a respeito...
[oracle_br] Re: Estimar tempo de execução de query
Blz ? Então, uma alternativa Possível é vc fazer que nem algumas ferramentas de pesquisa de dados (tipo a Oracle Discoverer, vide https://docs.oracle.com/cd/E14571_01/bi./b32519/query_prediction.htm#BIDAG753) fazem, ie : Estimar (ou até, sendo mais sincero, ** CHUTAR **) em cima do plano de execução e/ou dos recursos do CBO A idéia é tipo vc medir na sua máquina quanto tempo levou (digamos) um FULL TABLE SCAN de mil linhas e extrapolar: se vc ver na query a analisar/prever um FULL TABLE SCAN de 10 mil linhas, estime que esse passo vai levar 10 vezes o tempo que vc mensurou... A questão é que vc tem no RDBMS Oracle ** PELO MENOS ** umas duas dúzias de Operações possíveis possíveis alpem do full table scan (como HASH JOIN, NESTED LOOPS, MERGE JOIN, SORT GROUP BY, HASH GROUP BY, WINDOW, INDEX SCAN, INDEX RANGE SCAN, etc etc etc) que vc teria que Mensurar uma vez no seu ambiente pra servirem de 'métrica de base' pra tua rotina de estimativa de tempoÉ um trabalho de LOUCO MANSO, mas tecnicamente falando é Possível, sim Como programar e implementar tal lógica no seu ambiente se a sua tool cliente de execução de SQLs e/ou a sua linguagem de programação não tem nada pronto nesse sentido, ficaria POR SUA CONTA, completamente : não há NADA nativo / pronto pra isso no RDBSM Oracle (e em NENHUM outro RDBMS, afaik) Essa é a sua resposta à sua pergunta, mas eu TENHO que fazer algumas obs importantes sobre Viabilidade e Efetividade disso : a. o EXPLAIN PLAN é uma Estimativa ALTAMENTE GROSSEIRA em vários casos, em especial quando há BINDs e/ou quando o RDBMS faz alguma Otimização na sessão : https://asktom.oracle.com/Misc/when-explanation-doesn-sound-quite.html explica bem isso b. Não Há como nem sequer Estimar se os objetos a serem acessados estão em CACHE ou não, se o datafile (supondo uma Operação que implica em leitura do disco) tem algum tipo de 'fragmentação'/issue que cause performance inferior no I/O c. Não Há como prever concorrência de nenhum tipo : ABSOLUTAMENTE NADA impede que alguns segundos depois que a query analisada começou, OUTROS USUÁRIOS disparem SQLs pesados que INTERFIRAM na performance desse SQL aí... Este ponto é FREQUENTEMENTE ignorado (bobamente) , o pessoal 'esquece' que o RDBMS Oracle é Completamente Multi-usuário ==> sendo assim, o que DEVERIA ACONTECER num ambiente profissionalmente e corretamente administrado / gerenciado é : PRIMEIRO, nenhum SQL deveria ir pra Produção ANTES de ser analisado (E TESTADO, ** executando-o ** no ambiente HOMOLOGAÇÂO preferencialmente) pelos DBAs em conjunto com os Analistas/desenvolvedores pra tentar prever issues de performance, e em SEGUNDO lugar, DEVERIA haver algum mecanismo (Profiles, Resource Manager, simples job que dispara de 5 em 5 minutos, o que puder ter) que ELIMINE eventuais SQLs 'doidões', que demorem mais do que um tempo pré-determinado, que eventualmente tenham Escapado da fase de Homologação []s Chiappa
[oracle_br] Re: Estimar tempo de execução de query
Blz ? Então, uma alternativa Possível é vc fazer que nem algumas ferramentas de pesquisa de dados (tipo a Oracle Discoverer, vide https://docs.oracle.com/cd/E14571_01/bi./b32519/query_prediction.htm#BIDAG753) fazem, ie : Estimar (ou até, sendo mais sincero, ** CHUTAR **) em cima do plano de execução e/ou dos recursos do CBO A idéia é tipo vc medir na sua máquina quanto tempo levou (digamos) um FULL TABLE SCAN de mil linhas e extrapolar: se vc ver na query a analisar/prever um FULL TABLE SCAN de 10 mil linhas, estime que esse passo vai levar 10 vezes o tempo que vc mensurou... A questão é que vc tem no RDBMS Oracle ** PELO MENOS ** umas duas dúzias de Operações possíveis possíveis alpem do full table scan (como HASH JOIN, NESTED LOOPS, MERGE JOIN, SORT GROUP BY, HASH GROUP BY, WINDOW, INDEX SCAN, INDEX RANGE SCAN, etc etc etc) que vc teria que Mensurar uma vez no seu ambiente pra servirem de 'métrica de base' pra tua rotina de estimativa de tempoÉ um trabalho de LOUCO MANSO, mas tecnicamente falando é Possível, sim Como programar e implementar tal lógica no seu ambiente se a sua tool cliente de execução de SQLs e/ou a sua linguagem de programação não tem nada pronto nesse sentido, ficaria POR SUA CONTA, completamente : não há NADA nativo / pronto pra isso no RDBSM Oracle (e em NENHUM outro RDBMS, afaik) Essa é a sua resposta à sua pergunta, mas eu TENHO que fazer algumas obs importantes sobre Viabilidade e Efetividade disso : a. o EXPLAIN PLAN é uma Estimativa ALTAMENTE GROSSEIRA em vários casos, em especial quando há BINDs e/ou quando o RDBMS faz alguma Otimização na sessão : https://asktom.oracle.com/Misc/when-explanation-doesn-sound-quite.html explica bem isso b. Não Há como nem sequer Estimar se os objetos a serem acessados estão em CACHE ou não, se o datafile (supondo uma Operação que implica em leitura do disco) tem algum tipo de 'fragmentação'/issue que cause performance inferior no I/O c. Não Há como prever concorrência de nenhum tipo : ABSOLUTAMENTE NADA impede que alguns segundos depois que a query analisada começou, OUTROS USUÁRIOS disparem SQLs pesados que INTERFIRAM na performance desse SQL aí... Este ponto é FREQUENTEMENTE ignorado (bobamente) , o pessoal 'esquece' que o RDBMS Oracle é Completamente Multi-usuário ==> sendo assim, o que DEVERIA ACONTECER num ambiente profissionalmente e corretamente administrado / gerenciado é : PRIMEIRO, nenhum SQL deveria ir pra Produção ANTES de ser analisado (E TESTADO, ** executando-o ** no ambiente HOMOLOGAÇÂO preferencialmente) pelos DBAs em conjunto com os Analistas/desenvolvedores pra tentar prever issues de performance, e em SEGUNDO lugar, DEVERIA haver algum mecanismo (Profiles, Resource Manager, simples job que dispara de 5 em 5 minutos, o que puder ter) que ELIMINE eventuais SQLs 'doidões', que demorem mais do que um tempo pré-determinado, que eventualmente tenham Escapado da fase de Homologação []s Chiappa OBS : é claro, em algumas versões há a possibilidade de obter uma Estimativa de Tempo diretamente pra cada Operação executada no plano : OBVIAMENTE, é uma Estimativa quase sempre FURADA mas existe também, veja https://asktom.oracle.com/pls/apex/f%3Fp%3D100:11:0P11_QUESTION_ID:1434984500346471382 para discussão a respeito... ---Em oracle_br@yahoogrupos.com.br, escreveu: Pessoal, Vejam se podem me tirar um duvida. O comando Explain plan do Oracle, somente faz uma estimativa do custo de execução de uma consulta, ou também, faz estimativa de tempo para execução dela? Eu preciso de uma estimativa (aproximada) mas que não precise esperar para executar a consulta, pois o ambiente que tenho as consultas demoram muito. Como eu faria para ter uma estimativa de tempo de execução, sem necessitar esperar a execução? []`s Neto
