Consultor Eletrônico

Este trabalho pode ser facilmente realizado executando o programa SESSION_TRACE_ENABLE, existente no pacote DBMS_MONITOR. Ele recebe os seguintes parâmetros:

- session_id: identificador da sessão. Se não for informado, o trace será ativado para a sua sessão atual;
- serial_num: número serial da sessão, que garante a unicidade na identificação da sua sessão. Se não for informado, serão ativados os traces para todas as sessões que tiverem o mesmo sesion_id.
- waits: se informar o valor verdadeiro, serão registradas no trace informações sobre eventos de espera da sessão. TRUE é o valor padrão, caso não seja informado.
- binds: se informar o valor verdadeiro, serão registradas no trace informações sobre as variáveis de substituição das consultas (bind variables). FALSE é o valor padrão, caso não seja informado.

Para desativar o trace execute o programa SESSION_TRACE_DISABLE deste mesmo pacote, informando os mesmos dois primeiros parâmetros utilizados na ativação. Se não informar nenhum parâmetro será desativado para a sessão corrente.

O usuário que irá ativar o rastreamento deve possuir permissão SYSDBA ou ter privilégio de execução no pacote DBMS_MONITOR.

Dependendo do ambiente a tarefa mais árdua neste trabalho é conseguir identificar a sessão que será rastreada. A visão V$SESSION do dicionário do Oracle provê, além dos campos session_id (sid) e serial_num (serial#), outras colunas que permitem identificar a sessão, como estas:

- username: nome do usuário do banco Oracle. Não ajuda muito quando todas as sessões são conectadas utilizando o mesmo esquema (Ex. produtos Datasul e Logix);
- osuser: nome do usuário do sistema operacional da máquina cliente. Não ajuda muito quando a conexão é realizada através de um servidor de aplicação num modelo de 3 camadas, pois todas as conexões virão das mesmas máquinas;
- machine/terminal: nome da máquina e do terminal, também do sistema operacional que estabeleceu a conexão cliente;
- program: nome do executável que faz a conexão com o banco. No ambiente Datasul será o executável cliente do Progress e no Logix com Totvstec será o executável do totvsappserver.

Como pudemos observar, nos ambientes Datasul e Logix precisaremos recorrer a alguns artifícios para identificar as conexões. No ambiente Datasul, onde a conexão é geralmente client/server sem terceira camada, é mais fácil rastrear pelos campos machine e osuser.

Já no Logix a maneira mais prática é identificar a sessão primeiramente na tabela do produto chamada LOG_DADOS_SESSAO_LOGIX. Estes são os seus campos:

- sid: identificador da conexão com o Oracle, podendo ser utilizado para fazer um join com a visão V$SESSION, através do seu campo audsid;
- dat_execucao: como o nome já aponta é a data de execução do programa (pode ser assimilado como a data de login ou abertura da sessão no banco);
- usuario: login no sistema Logix;
- programa: nome do programa em execução. No Logix cada programa abre uma sessão no banco Oracle;

Com a linha da tabela LOG_DADOS_SESSAO_LOGIX selecionada, faz-se uma consulta na tabela V$SESSION para obter os valores das colunas SID e SERIAL#.

Existem outras maneiras de ativar o trace das sessões, incluindo rastrear todas a sessões do banco de dados e também comandos que podem ser utilizados em versões mais antigas do Oracle. Para esta diversidade de opções busque informação na documentação oficial da Oracle.

Abaixo um exemplo de como ativar o TRACE do Oracle utilizando a package DBMS_MONITOR.

Para habilitar trace na sessão do usuário que vai executar os comandos SQL, pode-se utilizar a package DBMS_MONITOR, porque o seu uso faz parte do método recomendado pela Oracle para gerenciamento de comandos SQL:

a) Comando para listar o SID e SERIAL para auxiliar na ativação do TRACE, sendo necessário saber o owner da tabela.

SQL> SELECT sid, serial#, machine FROM v$session WHERE username = 'TSS';

b) Com base no que foi coletado com o comando acima, altere o comando abaixo e execute para ativação do TRACE.

SQL> EXEC DBMS_MONITOR.SESSION_TRACE_ENABLE(session_id => 12, serial_num => 31093, waits => true, binds => true);

c) Execute o programa e simule a situação que está gerando o problema no ambiente

d) Terminando de executar o programa, pode desabilitar a geração de trace executando o comando abaixo:

SQL> EXEC DBMS_MONITOR.SESSION_TRACE_DISABLE(session_id => 12, serial_num => 31093);

e) O comando abaixo lista o diretório que está sendo gravado o arquivo de trace (.trc)

SQL> show parameter background_dump_dest

f) O comando abaixo lista o arquivo de TRACE gerado na execução do programa (disponível a partir do Oracle 11).

SELECT tracefile FROM v$process WHERE addr = (SELECT paddr FROM v$session WHERE sid = 12 AND serial# = 31093);

g) Sabendo qual o arquivo de trace gerado, abra uma janela de prompt de comando do Sistema Operacional e entre no diretório identificado do passo anterior, exemplo:

tkprof orcl_ora_3803.trc resultado.txt sys=no

O tkprof está sendo executado com 3 parâmetros:
1) nome do arquivo trace
2) nome do arquivo de saída
3) um valor para o parâmetro sys.

Lembrando que somente o nome do arquivo trace e o nome do arquivo de saída são obrigatórios.
O valor "no" fornecido para o parâmetro "sys" para evitar que SQL recursivo seja incluído no arquivo result.txt.

Autor: Eloi Rene Pscheidt