[oracle_br] Re: Estimar tempo de execução de query

[jlchia...@yahoo.com.br [oracle_br]]

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...