necessariamente implica em hard parse, E que é o sqlplus que está
fazendo reparse (soft, mas é reparse) a cada execução, cfrme :
==> numa sessão conexão dedicada, que já está com trace ativo, vou
executar um SQL que sei que não existia ainda no cache:
[EMAIL PROTECTED]:SQL>select deptno, dname, 'fixo' from dept;
DEPTNO DNAME 'FIX
------------------ -------------- ----
10 ACCOUNTING fixo
20 RESEARCH fixo
30 SALES fixo
40 OPERATIONS fixo
77 Depto 77 fixo
78 Ação fixo
50 Pólen fixo
43 Depto 43 fixo
8 linhas selecionadas.
==> necessariamente isso gerou um hard parse, agora vou executar
EXATAMENTE o mesmo SQL na mesma sessão, veremos que o sqlplus VAI
fazer parse 9soft, mas é parse) a cada vez :
[EMAIL PROTECTED]:SQL>/
DEPTNO DNAME 'FIX
------------------ -------------- ----
10 ACCOUNTING fixo
20 RESEARCH fixo
30 SALES fixo
40 OPERATIONS fixo
77 Depto 77 fixo
78 Ação fixo
50 Pólen fixo
43 Depto 43 fixo
8 linhas selecionadas.
[EMAIL PROTECTED]:SQL>/
DEPTNO DNAME 'FIX
------------------ -------------- ----
10 ACCOUNTING fixo
20 RESEARCH fixo
30 SALES fixo
40 OPERATIONS fixo
77 Depto 77 fixo
78 Ação fixo
50 Pólen fixo
43 Depto 43 fixo
8 linhas selecionadas.
[EMAIL PROTECTED]:SQL>/
DEPTNO DNAME 'FIX
------------------ -------------- ----
10 ACCOUNTING fixo
20 RESEARCH fixo
30 SALES fixo
40 OPERATIONS fixo
77 Depto 77 fixo
78 Ação fixo
50 Pólen fixo
43 Depto 43 fixo
8 linhas selecionadas.
[EMAIL PROTECTED]:SQL>/
DEPTNO DNAME 'FIX
------------------ -------------- ----
10 ACCOUNTING fixo
20 RESEARCH fixo
30 SALES fixo
40 OPERATIONS fixo
77 Depto 77 fixo
78 Ação fixo
50 Pólen fixo
43 Depto 43 fixo
8 linhas selecionadas.
[EMAIL PROTECTED]:SQL>disc;
Desconectado de Oracle9i Enterprise Edition Release 9.2.0.5.0 - 64bit
Production
With the Partitioning option
JServer Release 9.2.0.5.0 - Production
==> como ficou no tkprof :
**********************************************************************
**********
select deptno, dname, 'fixo'
from
dept
call count cpu elapsed disk query
current rows
------- ------ -------- ---------- ---------- ---------- ----------
----------
Parse 5 0.01 0.01 0 0
0 0
Execute 5 0.00 0.00 0 0
0 0
Fetch 10 0.01 0.00 0 25
0 40
------- ------ -------- ---------- ---------- ---------- ----------
----------
total 20 0.02 0.01 0 25
0 40
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 69
Rows Row Source Operation
------- ---------------------------------------------------
8 TABLE ACCESS FULL DEPT
==> 1 miss = 1 hard parse, portanto desses 5 parses 4 foram soft. No
caso tive 5 execuções (o que é bom, indica que a aplicação está
enviando SQLs semelhantes), mas 5 parses pra essas 5 execuções, isso
é HORROROSO, num sistema produção a regra é ZERO (ou no máximo 1)
parse pra N execuções, cfrme :
==> em outra sessão crio um PL/SQL :
[EMAIL PROTECTED]:SQL>create or replace procedure P_NO_PARSE is
2 BEGIN
3 for r in (select DEPTNO, dname, 'abobora' from dept) loop
4 dbms_output.put_line(r.deptno || ',' || r.dname);
5 end loop;
6 END;
7 /
Procedimento criado.
==> e executo o SQL via stored PL/SQL 5 vezes :
[EMAIL PROTECTED]:SQL>exec P_NO_PARSE;
Procedimento PL/SQL concluído com sucesso.
[EMAIL PROTECTED]:SQL>exec P_NO_PARSE;
Procedimento PL/SQL concluído com sucesso.
[EMAIL PROTECTED]:SQL>exec P_NO_PARSE;
Procedimento PL/SQL concluído com sucesso.
[EMAIL PROTECTED]:SQL>exec P_NO_PARSE;
Procedimento PL/SQL concluído com sucesso.
[EMAIL PROTECTED]:SQL>exec P_NO_PARSE;
Procedimento PL/SQL concluído com sucesso.
[EMAIL PROTECTED]:SQL>disc;
Desconectado de Oracle9i Enterprise Edition Release 9.2.0.5.0 - 64bit
Production
With the Partitioning option
JServer Release 9.2.0.5.0 - Production
==> resultado do tkprof :
**********************************************************************
**********
SELECT DEPTNO, DNAME, 'abobora'
FROM
DEPT
call count cpu elapsed disk query
current rows
------- ------ -------- ---------- ---------- ---------- ----------
----------
Parse 1 0.01 0.00 0 0
0 0
Execute 5 0.00 0.00 0 0
0 0
Fetch 45 0.01 0.00 0 55
0 40
------- ------ -------- ---------- ---------- ---------- ----------
----------
total 51 0.02 0.00 0 55
0 40
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 69 (recursive depth: 1)
Rows Row Source Operation
------- ---------------------------------------------------
40 TABLE ACCESS FULL DEPT
==> agora estamos na boa em relação a parse, N execuções e apenas um
parse... E note também que, ALÉM de evitar parse, AUTOMAGICAMENTE o
PL/SQL já transformou o texto do meu SQL em maiúsculas (e se houvesse
teria removido eventuais brancos e itens desnecessários), é OUTRA
vantagem que vc obtém com PL/SQL. Foi este exemplo que usei na minha
apresentação na ENPO de 2005, é por isso que se recomenda SEMPRE
trabalhar com PL/SQL se possível - não é que seja impossível (LONGE
DISSO) de se obter os mesmos benefícios em SQLs armazenados em
programas java, vb, delphi, o que for, mas nessas lings todas
normalmente vc TEM QUE tomar uma ação extra, TEM QUE escrever algo a
mais, adicionar algum componente a mais, enfim, fazer algo, o que é
AUTOMÁGICO no PL/SQL com SQLs estáticos.
[]s
Chiappa
--- Em [email protected], "Andre Santos"
<[EMAIL PROTECTED]> escreveu
>
> Nelson
>
> Além disso que o Chiappa esclareceu, também há diferença
entre "hard parse"
> e "soft parse"... Como a instrução é exatamente a mesma, deverá ser
feito um
> "soft parse" (que tem um custo menor), não é?
>
> [ ]
>
> André
>
>
>
> Em 30/05/06, Nelson Cartaxo <[EMAIL PROTECTED]> escreveu:
> >
> > Mais uma vez obrigado chiappa. Vou fazer este teste.
> >
> > Abraços,
> >
> > Nelson Cartaxo
> > DBA ORACLE
> >
> >
> >
> > -----Mensagem original-----
> > De: jlchiappa [mailto:[EMAIL PROTECTED]
> > Enviada em: Monday, May 29, 2006 9:41 PM
> > Para: [email protected]
> > Assunto: [oracle_br] Re: Parse
> >
> >
> >
> > É bem simples o motivo : o sqlplus é uma tool que por definição
TEM
> > que receber SQLs ad-hoc, que não se sabe a priori quais
serão,então
> > ela TEm que usar SQL dinâmico, e SQL dinâmico implica em parse
> > sempre... Repita o teste num stored PL/SQL, repetindo exatamente o
> > mesmo SQL 50 vezes (pode ser num LOOP) que vc vai ver que aí sim
> > (claro) o SQL é estático, é CONHECIDO a priori e portanto há
> > re-aproveitamento automático e natural de SQL.
> >
> > []s
> >
> > Chiappa
> >
> > --- Em [email protected], Nelson Cartaxo
> > <[EMAIL PROTECTED]> escreveu
> > >
> > > Pessoal boa tarde,
> > >
> > > Poderiam me tirar uma duvida? Oracle versão 8.1.7.4
> > >
> > > Tenho um select simples
> > >
> > > select dt_inicio, dt_fim from tb_vigencia
> > > where co_vigencia=10
> > >
> > > Gostaria de tentar entender, do pq de quando eu executo por
exemplo
> > 50 vezes
> > > esta mesma query, com o uso do "/" dentro do sqlplus, no trace
ele
> > faz 50
> > > parses. Não deveria fazer apenas 1 parse, tendo em vista que
não
> > mudei nada
> > > na query?
> > >
> > > Segue o resultado do trace
> > >
> > > call count cpu elapsed disk query
current
> > > rows
> > > ------- ------ -------- ---------- ---------- ---------- ------
----
> > > ----------
> > > Parse 32 0.02 0.03 0
0 0
> > > 0
> > > Execute 32 0.00 0.00 0
0 0
> > > 0
> > > Fetch 64 0.00 0.00 0
64 0
> > > 32
> > > ------- ------ -------- ---------- ---------- ---------- ------
----
> > > ----------
> > > total 128 0.02 0.03 0
64 0
> > > 32
> > >
> > > Fizemos uns testes inclusive com variavel bind e mesmo assim o
numero de
> > > parses é o mesmo.
> > >
> > > Valeu pela força.
> > >
> > > Nelson Cartaxo
> > > DBA ORACLE
> > >
> >
> >
> >
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------
----------
> > ----------------------------------------------
> > Atenção! As mensagens deste grupo são de acesso público e de
inteira
> > responsabilidade de seus remetentes.
> > Acesse: http://www.mail-archive.com/[email protected]/
> >
> > ------------------------------------------------------------------
----------
> >
> > ----------------------------------------------
______________________________
> > ____________________________________
> >
> > Este Grupo recebe o apoio da SQL Magazine -
> > www.devmedia.com.br/sqlmagazine
> > __________________________________________________________________
> > O grupo Oracle_br não aceita anexos. Quando oferecer algum
arquivo, tenha
> > o
> > link do mesmo para evitar trafego(pedidos) desnecessário.
> > Links do Yahoo! Grupos
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------
--------------------------------------------------------
> > Atenção! As mensagens deste grupo são de acesso público e de
inteira
> > responsabilidade de seus remetentes.
> > Acesse: http://www.mail-archive.com/[email protected]/
> >
> > ------------------------------------------------------------------
--------------------------------------------------------
__________________________________________________________________
> >
> > Este Grupo recebe o apoio da SQL Magazine -
> > www.devmedia.com.br/sqlmagazine
> > __________________________________________________________________
> > O grupo Oracle_br não aceita anexos. Quando oferecer algum
arquivo, tenha
> > o link do mesmo para evitar trafego(pedidos) desnecessário.
> >
> >
> > *Yahoo! Grupos, um serviço oferecido por:* PUBLICIDADE
> >
> >
<http://br.ard.yahoo.com/SIG=12frhfk64/M=396559.7942981.9522421.236989
3/D=brclubs/S=2137114689:HM/Y=BR/EXP=1149001017/A=3729502/R=2/id=noscr
ipt/SIG=154dcqslu/*http://lt.dell.com/lt/lt.aspx?
CID=13040&LID=340715&DGC=BA&DGSeg=DHS&DURL=http://www1.la.dell.com/con
tent/products/category.aspx/desktops?c%3dbr%26l%3dpt%26s%3ddhs>
> > ------------------------------
> > *Links do Yahoo! Grupos*
> >
> > - Para visitar o site do seu grupo na web, acesse:
> > http://br.groups.yahoo.com/group/oracle_br/
> >
> > - Para sair deste grupo, envie um e-mail para:
> > [EMAIL PROTECTED]<oracle_br-
[EMAIL PROTECTED]>
> >
> > - O uso que você faz do Yahoo! Grupos está sujeito aos Termos
do
> > Serviço do Yahoo! <http://br.yahoo.com/info/utos.html>.
> >
> >
>
>
> [As partes desta mensagem que não continham texto foram removidas]
>
--------------------------------------------------------------------------------------------------------------------------
Atenção! As mensagens deste grupo são de acesso público e de inteira responsabilidade de seus remetentes.
Acesse: http://www.mail-archive.com/[email protected]/
--------------------------------------------------------------------------------------------------------------------------__________________________________________________________________
Este Grupo recebe o apoio da SQL Magazine - www.devmedia.com.br/sqlmagazine
__________________________________________________________________
O grupo Oracle_br não aceita anexos. Quando oferecer algum arquivo, tenha o link do mesmo para evitar trafego(pedidos) desnecessário.
| Yahoo! Grupos, um serviço oferecido por: | |
|
Links do Yahoo! Grupos
- Para visitar o site do seu grupo na web, acesse:
http://br.groups.yahoo.com/group/oracle_br/
- Para sair deste grupo, envie um e-mail para:
[EMAIL PROTECTED]
- O uso que você faz do Yahoo! Grupos está sujeito aos Termos do Serviço do Yahoo!.
