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.1111/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:0::::P11_QUESTION_ID:1434984500346471382 para discussão a respeito...
[oracle_br] Re: Estimar tempo de execução de query
jlchia...@yahoo.com.br [oracle_br] Sun, 16 Sep 2018 06:25:54 -0700
- [oracle_br] Estimar tempo de execuçã... Neto pr neto...@gmail.com [oracle_br]
- [oracle_br] Re: Estimar tempo d... jlchia...@yahoo.com.br [oracle_br]
- [oracle_br] Re: Estimar tempo d... jlchia...@yahoo.com.br [oracle_br]
- [oracle_br] Re: Estimar tempo d... jlchia...@yahoo.com.br [oracle_br]