Entendendo o que se lê…

Não basta ler, tem que entender…

Olá Amigos DBAs, profissionais de TI, gerentes de projetos, pessoas, fãs do blog, amigos, inimigos… Hoje irei comentar a respeito de algo que é muito importante para qualquer processo de estudo, eu costumo sempre falar isso, os leitores que já foram meus alunos provavelmente já me ouviram falar um dia. “Ler só não basta, é preciso entender”. Sim, é exatamente isso. Vou citar algo bem simples e que demonstra cem porcento o que estou falando. Imagine um idioma que você não conhece nada, exemplo, o francês… Ok! Tá bom, você sabe falar francês? “Bon pour vous”, então imagine um outro idioma diferente. Já parou pra pensar que você conseguirá ler a maioria das palavras? E entender você conseguirá? BINGO! Essa é a idéia. Ler não é entender. Pensando assim procure ler muito, porém entendendo cada palavra, não adianta passar uma noite inteira lendo para estudar e no final das contas perceber que aprendeu muito pouco.
Talvez você não deve estar entendendo porque eu levantei este assunto agora não é mesmo? Simples, pois começaremos a comentar a leitura e interpretação de um arquivo de trace. Lembra do processo da nossa usuária? Então, fizemos o trace, geramos o arquivo .trc até aqui tudo beleza, agora precisamos fazer ele legível, ou seja, ele tem que nos dizer alguma coisa.
Existem diversas ferramentas fazendo firulas mil nos arquivos de trace para deixá-los mais “bonitos” e legíveis, porém eu gosto bastante de usar a nativa do Oracle mesmo o TKPROF.

Por ser ferramenta nativa você não vai precisar instalar ele, já está pronto para usar e é free, ou seja, já vem com a instalação do Oracle independente da versão utilizada. Portanto vamos a ele.


Utilizando o TKPROF.

Como já comentei anteriormente, o trace gerado fica em um padrão que nos faz encontrá-lo pelo SPID do processo. Sua máscara de criação (modelo) é:

ORACLESID_ora_SPID.trc.

Exemplo para um banco de dados chamado ORCL e com o SPID no sistema operacional 10144: ORCL_ora_10144.trc

Ok! Sei que talvez você pense: “Mas Raul, como vou localizar o exato arquivo??”
Eu já pensei nisso! Para ajudar vou passar um script sql que costumo utilizar para localizar o arquivo de trace que eu preciso e já montar o script em tempo real. Que beleza não é mesmo??? Montar o script em tempo real é tudo que a gente precisa para facilitar nossa vida. Vai lá então:

SELECT ‘tkprof orcl_ora_’||p.SPID||’.trc orcl_ora_’||p.SPID||’.txt explain=system/zse4nji9 sys=yes waits=yes table=sys.plan_table$ sort=fchela’
FROM v$process p,v$session s
WHERE s.paddr = p.addr
AND s.sid in (select SID from v$session where OSUSER = ‘ELISANGELA’);


Comentário: O que este script faz é localizar o SPID do processo e montar o script do TKPROF para rodar no sistema operacional. Basicamente irá me trazer o exato nome do arquivo trc gerado pelo trace já montado em tempo real no script que eu devo rodar para criar o arquivo TXT do TKPROF. Simples assim.(rsrsrs)

Saída do comando:
tkprof ORCL_ora_10144.trc ORCL_ora_10144.txt explain=system/zse4nji9 sys=yes waits=yes table=sys.plan_table$ sort=fchela

Este comando exatamente como ele está eu copio, colo no prompt e executo logado como oracle no sistema operacional. Ele irá criar um arquivo chamado ORCL_ora_10144.txt

Abaixo segue um exemplo do início de um arquivo de trace após ter sido utilizado o TKPROF

TKPROF: Release 11.2.0.3.0 – Development on Mon Feb 2 16:58:17 2014
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
Trace file: ORCL_ora_10144.trc
Sort options: fchela
********************************************************************************
count    = number of times OCI procedure was executed
cpu      = cpu time in seconds executing
elapsed  = elapsed time in seconds executing
disk     = number of physical reads of buffers from disk
query    = number of buffers gotten for consistent read
current  = number of buffers gotten in current mode (usually for update)
rows     = number of rows processed by the fetch or execute call
********************************************************************************
SQL ID: 3k65pg76br3xc Plan Hash: 3482310901
SELECT SUM(ROUND(NVL(PARC.VLR_PARCELA,0),2))
FROM
LF_CIAP_PARCELA PARC WHERE PARC.REFERENCIA <= :B2 AND PARC.ID_CIAP = :B1
call     count       cpu    elapsed       disk      query    current        rows
——- ——  ——– ———- ———- ———- ———-  ———-
Parse        1      0.00       0.00          0          0          0           0
Execute  13681     17.27      17.20          0          0          0           0
Fetch    13681      6.87      56.20       4765      83174          0       13681
——- ——  ——– ———- ———- ———- ———-  ———-
total    27363     24.14      73.41       4765      83174          0       13681

Este é apenas um exemplo. Nos próximos posts iremos analisar o resultado do trace, isto é, ler e entender. Assim iremos conseguir saber a exata demora de tudo que é feito durante o processo da usuária. A análise do trace é o primeiro passo para detectar lentidões em processos ligados a banco de dados.

Grande abraço! Até amanhã e continue com o propósito de sempre manter o FOCO NA META!!! Sempre!

Sobre raul andrade

DBA e Instrutor Oracle, apaixonado pela minha família e por ensinar.
Esta entrada foi publicada em Talento quando Tá lento. Adicione o link permanente aos seus favoritos.

Deixe uma resposta