Menu de navegação

[rwarstatParticipante]

Estou fazendo um teste com a dbms_profiler para tenta identificar onde uma package de carga está demorando. Essa carga está sendo executada de um schema para outro do banco, sendo que estou executando em uma máquina com windows XP e Oracle 10g – 10.2.0.1.0.
Iniciei o profiler e em seguinda iniciei a minha carga. Após o procedimento ter sido efetuado, verifiquei que o profiler registrou 3 blocos anônimos sendo que durante o processo eu chamo 30 procedures (estão todas dentro da package), e várias são chamadas repetidas vezes. O profiler não deveria registrar a quantidade de vezes de cada uma dessas procedures?

Abraço,
Roberto

[IshiiParticipante]

Olá,

Ainda não usei o dbms_profiler, mas a demora da carga pode estar no método de carga (dblink por exemplo) e não nas procedures, como, pelo que entendi, o resultado do dbms_profiler deveria ser onde estão as queries mais pesadas, pode ser que as procedures não estejam sendo afetadas na performance ou estejam até otimizadas.

Verifique os traces (Banco Oracle e Client se tiver o dblink) para tentar identificar o ponto de lentidão…Lembrando que em alguns casos, pode não estar no Oracle e sim na Infra num geral.

[]s Ishii

[rwarstatParticipante]

Ishii,
A carga é feita no mesmo banco, mas em esquemas diferentes, descartando assim problemas de rede.
Pelo que entendi do dbms_profiler (http://www.oracleutilities.com/Packages … filer.html e http://download.oracle.com/docs/cd/B193 … profil.htm) deveria ser mostrado todas as chamadas pl/sql existentes. Mas no meu caso só apareceu blocos anônimos e foram 3.

Estou colocando abaixo o conteúdo de cada uma das 3 tabelas do profiler

Tabela plsql_profiler_runs

 RUNID RELATED_RUN RUN_O RUN_DATE RUN_COMMENT                             

---

RUN_TOTAL_TIME RUN_SYSTEM RUN_COMMEN SPARE1

---

     2           0 TESTE 20/10/09 Teste da carga do custos - comp 01/2009 

51392592506172

Tabela plsql_profiler_units

 RUNID UNIT_NUMBER UNIT_TYPE            UNIT_OWNER                      

---

UNIT_NAME UNIT_TIM TOTAL_TIME SPARE1 SPARE2

---

     2           1 ANONYMOUS BLOCK                           
                                    0                      

     2           2 ANONYMOUS BLOCK                           
                                    0                      

     2           3 ANONYMOUS BLOCK                           
                                    0     

Tabela plsql_profiler_data

 RUNID UNIT_NUMBER      LINE# TOTAL_OCCUR TOTAL_TIME   MIN_TIME   MAX_TIME

---

SPARE1     SPARE2     SPARE3     SPARE4

---

     2           1          1           1        651        651        651


     2           2          1           3      19237        676      12826


     2           3          1           2   13766146       3994   13758036

Abraço,
Roberto

[IshiiParticipante]

Olá,

Então a query

select line#,
decode (a.total_occur,null,0,0,0,
a.total_time/a.total_occur/1000) as Avg,
substr(c.text,1,20) as Source
from plsql_profiler_data a, plsql_profiler_units b, user_source c
where a.runid = 1
and a.unit_number = 3
and a.runid = b.runid
and a.unit_number = b.unit_number
and b.unit_name = c.name
and a.line# = c.line
and rownum < 11
order by a.total_time desc ;

Qual o resultado dela?

Então poderemos ver quais as queries que mais consomem recursos…

[]s Ishii

[rwarstatParticipante]

Como o profiler colocou todos os códigos como sendo bloco anônimo, não tenho como descobrir quais as queries que levaram mais tempo.

Estava vendo em http://www.dbasupport.com/oracle/ora10g … iler.shtml que ele faz a chamada do profiler de dentro da procedure/bloco anônimo que ele quer. Acredito que se eu alterar a minha package para que ela inicie o profiler eu consiga alguma coisa mais esclarecedora.

Para tentar explicar melhor:
– agora estou fazendo assim e traz os resultados que postei anteriormente.
exec dbms_profiler.start_profiler(‘Teste’);
exec pkg_custos.pr_carrega_custos;
exec dbms_profiler.stop_profiler();

• se eu colocar “dbms_profiler.start_profiler(‘Teste’);” dentro da pr_carrega_custos, acredito que terei informações mais precisas.

[]´s
Roberto

[IshiiParticipante]

Olá,

Entendi, 😀

Coloque depois os resultados para podermos ver tb!

[]s Ishii

[rwarstatParticipante]

Coloquei o início do profiler dentro da minha package e executei um pedaço da carga. Depois rodei o select para ver os 10 sql´s com maior tempo.

Conforme o resultado abaixo, tem linhas que são referidas que não são sql´s, mas comentários.
Alguma sugestão?

 LINE# TOTAL_OCCUR        AVG

---

SOURCE

    15           1 571578,921
    delete from root.movimentos                                             

    15           1 571578,921
Alterado: As rotinas pr_carrega_materiais_fia, pr_carrega_materiais_baa e pr

_carrega_materiais_cc foram

    20           1   7508,365

*/

    18           1    797,641
          pegue a movimentac?o dos fracionados, fazendo com que esse tipo de

movimento seja pego somente na

    22           1     94,856
procedure pr_carrega_custos (pdt_ini in date, pdt_fim in date);             


 LINE# TOTAL_OCCUR        AVG

---

SOURCE

    13           1      54,38
    dbms_application_info.SET_MODULE('pr_excluir_competencia', 'excluindo mo

vimentação’);

    13           1      54,38
Data: 16/04/2009                                                            

     3           0          0
Objetivo: Agrupar todas as procedures necessarias para efetuar a carga das t

abelas do modulo de custos.

     3           0          0
PROCEDURE pr_excluir_competencia (p_competencia  IN VARCHAR2,               

    24           1      4,816
procedure pr_salva_blob(p_caminho_arq in varchar2);

[]´s
Roberto

[Autor]

Posts