E aí, beleza! Espero que esse artigo te encontre bem. Hoje a gente vai falar sobre oradebug, essa pequena maravilha do Oracle, e como setar os eventos 10046 e 10053 pra troubleshooting de performance.

Primeiro de tudo, o que é oradebug?

Oradebug é uma ferramenta do sqlplus, destinada só pra pessoal de suporte Oracle. Mas ela pode ser bem útil em um monte de situações. Você pode usar pra setar eventos específicos de troubleshooting, usar pra diagnosticar qual interface seu RAC está usando pras mensagens de interconnect, usar pra executar um hanganalyze (o comando, não eu, beleza? =]), system state dumps, errorstack dumps, e a lista vai longe.

Como eu uso?

Primeiro de tudo, você precisa atachar o oradebug a uma sessão/processo específico.

Usando o ospid:

Pega o os pid pro processo, normalmente com o comando ps, ou pegando a thread em ambiente Windows. Com o ospid (nesse exemplo 1177)

oradebug setospid 1177;

Se você tentar atachar o oradebug a um processo inativo, você vai receber:

SQL> oradebug setospid 13050; ORA-00072: process “13050” is not active

Se tudo correu bem, você vai receber:

SQL> oradebug setospid 16792; Oracle pid: 150, Unix process pid: 16792, image: oracle@BLASERVER12

Usando o SID pra atachar o oradebug:

Primeiro de tudo você precisa descobrir o orapid da sessão, rodando o sql abaixo:

select p.pid orapid from v$process p, v$session s where s.sid = &SID and p.addr = s.paddr /

Exemplo:

SQL> select p.pid orapid from v$process p, v$session s where s.sid = &SID and p.addr = s.paddr / 2 3 4 5 6 Enter value for sid: 651 old 4: where s.sid = &SID new 4: where s.sid = 651

ORAPID ———- 152

SQL> oradebug setorapid 152; Oracle pid: 152, Unix process pid: 5392, image: oracle@BLASERVER12 (TNS V1-V3)

Tá pronto!

Setando o evento 10046

oradebug event 10046 trace name context forever, level 12;

Setando o evento 10053

oradebug event 10053 trace name context forever, level 1;

Por que isso é importante?

Você pode usar o 10046 pra pegar informações específicas de sql, tipo objeto, parsing, elapsed time, wait events, bind variables. É uma alternativa pro dbms_monitor e dbms_system, outro jeito de gerar um trace de sessão, e ele pode ser “tkprofado” também.

Se você quer entender as decisões do optimizer, não tem jeito melhor que usar um trace 10053. Você vai entender os cost estimates, access paths, query block names, peeked binds, parâmetros de optimizer usados durante o parse.

Em outro post eu vou dar detalhe sobre os levels, e por que a gente digita “name context forever”. Esse é um post how-to apenas =]

Falamos!