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] Como recuperar bind variable de um sql_id em determinado horário
Olá Pessoal, Gostaria de saber se tem outra forma de pegar bind variable de uma query que já foi executada num determinado horário. Pelo que entendi esta view mostra a última captura da query. SELECT sql_id, NAME,TO_CHAR(LAST_CAPTURED,'DD/MM/ HH24:MI:SS'),VALUE_STRING, t.* FROM V$SQL_BIND_CAPTURE t; Grato Eriovaldo
Re: [oracle_br] Re: Upgrade 9i to 10gR2
Chiappa, muito obrigado pelas informações.
Em sábado, 15 de setembro de 2018 18:00:24 BRT, jlchia...@yahoo.com.br
[oracle_br] escreveu:
Uma obs final : eu fui olhar no metalink e o patch 8202632 (que é quem provê o
Patchset
10.2.0.5 FOR ORACLE DATABASE SERVER) existe ** SIM ** para AIX (no caso 64 bits
em PowerPC, vc não diz mas CREIO que é o seu caso), E a nota metalink / My
Oracle Support "Oracle Database (RDBMS) on Unix AIX,HP-UX,Linux,Mac OS
X,Solaris,Tru64 Unix Operating Systems Installation and Configuration
Requirements Quick Reference 8.0.5 to 11.2" (Doc ID 169706.1) indica que pra
usar 10.2 vc só precisa que teu AIX seja "5.2 ML4 or higher, 5..3 ML2 or
higher, 6.1" - como vc diz que teu AIX já é 5.3 basta simplemnte aplicar os
patches IBM que vão deixar ele em mainteinance level 2 ou maior e vc JÁ VAI
PODER USAR o 10.2.0.5...
Isso é CRÍTICO, pois houveram bugfixes Seríssimos (tanto de Segurança quanto
de performnace e também erros de false results) no 10.2.0.5 : não faz Sentido
usar 10.2.0.4 nesse cenário..
[]s
Chiappa
#yiv2215539328 #yiv2215539328 -- #yiv2215539328ygrp-mkp {border:1px solid
#d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv2215539328
#yiv2215539328ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv2215539328
#yiv2215539328ygrp-mkp #yiv2215539328hd
{color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px
0;}#yiv2215539328 #yiv2215539328ygrp-mkp #yiv2215539328ads
{margin-bottom:10px;}#yiv2215539328 #yiv2215539328ygrp-mkp .yiv2215539328ad
{padding:0 0;}#yiv2215539328 #yiv2215539328ygrp-mkp .yiv2215539328ad p
{margin:0;}#yiv2215539328 #yiv2215539328ygrp-mkp .yiv2215539328ad a
{color:#ff;text-decoration:none;}#yiv2215539328 #yiv2215539328ygrp-sponsor
#yiv2215539328ygrp-lc {font-family:Arial;}#yiv2215539328
#yiv2215539328ygrp-sponsor #yiv2215539328ygrp-lc #yiv2215539328hd {margin:10px
0px;font-weight:700;font-size:78%;line-height:122%;}#yiv2215539328
#yiv2215539328ygrp-sponsor #yiv2215539328ygrp-lc .yiv2215539328ad
{margin-bottom:10px;padding:0 0;}#yiv2215539328 #yiv2215539328actions
{font-family:Verdana;font-size:11px;padding:10px 0;}#yiv2215539328
#yiv2215539328activity
{background-color:#e0ecee;float:left;font-family:Verdana;font-size:10px;padding:10px;}#yiv2215539328
#yiv2215539328activity span {font-weight:700;}#yiv2215539328
#yiv2215539328activity span:first-child
{text-transform:uppercase;}#yiv2215539328 #yiv2215539328activity span a
{color:#5085b6;text-decoration:none;}#yiv2215539328 #yiv2215539328activity span
span {color:#ff7900;}#yiv2215539328 #yiv2215539328activity span
.yiv2215539328underline {text-decoration:underline;}#yiv2215539328
.yiv2215539328attach
{clear:both;display:table;font-family:Arial;font-size:12px;padding:10px
0;width:400px;}#yiv2215539328 .yiv2215539328attach div a
{text-decoration:none;}#yiv2215539328 .yiv2215539328attach img
{border:none;padding-right:5px;}#yiv2215539328 .yiv2215539328attach label
{display:block;margin-bottom:5px;}#yiv2215539328 .yiv2215539328attach label a
{text-decoration:none;}#yiv2215539328 blockquote {margin:0 0 0
4px;}#yiv2215539328 .yiv2215539328bold
{font-family:Arial;font-size:13px;font-weight:700;}#yiv2215539328
.yiv2215539328bold a {text-decoration:none;}#yiv2215539328 dd.yiv2215539328last
p a {font-family:Verdana;font-weight:700;}#yiv2215539328 dd.yiv2215539328last p
span {margin-right:10px;font-family:Verdana;font-weight:700;}#yiv2215539328
dd.yiv2215539328last p span.yiv2215539328yshortcuts
{margin-right:0;}#yiv2215539328 div.yiv2215539328attach-table div div a
{text-decoration:none;}#yiv2215539328 div.yiv2215539328attach-table
{width:400px;}#yiv2215539328 div.yiv2215539328file-title a, #yiv2215539328
div.yiv2215539328file-title a:active, #yiv2215539328
div.yiv2215539328file-title a:hover, #yiv2215539328 div.yiv2215539328file-title
a:visited {text-decoration:none;}#yiv2215539328 div.yiv2215539328photo-title a,
#yiv2215539328 div.yiv2215539328photo-title a:active, #yiv2215539328
div.yiv2215539328photo-title a:hover, #yiv2215539328
div.yiv2215539328photo-title a:visited {text-decoration:none;}#yiv2215539328
div#yiv2215539328ygrp-mlmsg #yiv2215539328ygrp-msg p a
span.yiv2215539328yshortcuts
{font-family:Verdana;font-size:10px;font-weight:normal;}#yiv2215539328
.yiv2215539328green {color:#628c2a;}#yiv2215539328 .yiv2215539328MsoNormal
{margin:0 0 0 0;}#yiv2215539328 o {font-size:0;}#yiv2215539328
#yiv2215539328photos div {float:left;width:72px;}#yiv2215539328
#yiv2215539328photos div div {border:1px solid
#66;min-height:62px;overflow:hidden;width:62px;}#yiv2215539328
#yiv2215539328photos div label
{color:#66;font-size:10px;overflow:hidden;text-align:center;white-space:nowrap;width:64px;}#yiv2215539328
#yiv2215539328reco-category {font-size:77%;}#yiv2215539328
#yiv2215539328reco-desc {font-size:77%;}#yiv2215539328 .yiv2215539328replbq
{margin:4px;}#yiv2215539328 #yiv2215539328ygrp-actbar div
