Indo a fundo na investigação.
Ela chegou!!!! Não é assim que a gente pensa quando chega a sexta-feira??? Com certeza!
Embora, um outro fato também é verdadeiro, quando você gosta do que faz todos os dias são como sexta-feira, porém quando o contrário ocorre aí sentimos a síndrome do Fantástico…
Nunca ouviu falar??? Ok vou explicar, é aquela vontade de chorar quando no domingo à noite está “no ar” o Fantástico, e você lembra que no outro dia já é segunda feira. Hehehe
Por isso que MUITAS vezes, mais importante que ganhar bem é sentir-se bem no que está fazendo. Todo trabalho feito com carinho é trabalho bem feito.
Vamos lá, vamos lá então que já filosofamos bastante e a nossa usuária ainda está precisando do relatório dela lembra???
Então recapitulando, nós temos um processo específico, que costumava demorar 3 minutos e agora está demorando mais de uma hora, que é rodado uma vez por mês, mas que precisa ser rodado em breve para conferência e que tem severidade alta pois é relatório para a diretoria.
Nós DBAs temos que acostumar com algo que eu já comentei uma vez: Tudo que acontece no sistema ligado a velocidade de processamento, a princípio já é por “default” culpa do banco de dados.
Sei que quem é DBA agora está concordando comigo, e aqueles que ainda não são, um dia descobrirão isso.
Sendo assim cabe a nós DBAs defender nosso “filho” banco. Não pense que estou ficando louco, o DBA é um pouco “pai” do banco de dados.
Esse processo de defesa eu sempre costumo dizer que deve iniciar testando o processo do usuário. No nosso caso, vamos ligar para a nossa usuária e combinar com ela que deve colocar para rodar para que possamos analisar a sessão dela.
Este analisar a sessão que eu comento sempre se inicia com uma tarefa que chamamos de fazer um trace da sessão.
Trace de uma sessão, nada mais é do que criar um arquivo texto que irá rastrear/registrar, tudo que a sessão da usuária estará fazendo.
Para isso vai uma breve explanação do que é sessão em banco de dados.
Toda vez que algum usuário, ou alguma aplicação deseja buscar dados em um banco de dados, ele deve primeiramente estabelecer com ele uma conexão.
Vou pegar um exemplo do processo de uma conexão específica feita com uma ferramenta nativa do Oracle, ou seja, uma ferramenta de conexão que já vem instalada quando é feita a instalação do mesmo, o SQLPLUS.
Então para exemplificar imaginemos que a nossa usuária tenha o nome de Elisangela (eu poderia dizer que é um nome meramente ilustrativo, mas é homenagem à minha esposa.rsrsrs)gostaria de se conectar ao banco de dados para fazer uma busca de informações.
Lá na máquina dela ela digita algo que chamados de string de conexão:
elisangela/elis2003RFA@orcl
Essa forma de conexão o usuário informou, username/senha@nome_do_banco, esse tipo de conexão é chamada de Easy connect, e iremos falar sobre ela um dia. No momento é apenas para ilustrar o processo.
Então quando usuária coloca este comando, uma solicitação de conexão é feita ao banco de dados. Quando está tudo OK, ou seja, quando usuário, senha, nome do banco estão ok, o banco de dados vai ainda verificar se este usuário pode (tem privilégio) para criar conexão no banco de dados.
Estando tudo OK, é criada uma sessão de servidor, onde para cada sessão é dado um SID (Session Identificator) e um SERIAL# (número de série da sessão).
Estes doi itens serão únicos no banco de dados e através deles que conseguiremos fazer um trace da sessão.
Por isso é necessário que combinemos com a usuária o momento da conexão para que possamos pegar a exata sessão dela para criar o trace.
Segue abaixo um pequeno script que utilizo para identificar o SID e SERIAL# de uma sessão de usuário.
SELECT sid, serial# FROM v$session WHERE username=’ELISANGELA’;
Este script deverá ser rodado antes da usuária conectar para vermos se já existe(m) alguma(s) conexão(ões) da pessoa. O ideal é que não exista nenhuma outra conexão.
Caso ela diga que não tem como abortar outras conexões que existam, anote os SIDs e SERIAIS que já estão rodando e estes serã os que NÃO nos interessarão.
Mande então ela conectar na aplicação para rodar o tal do relatório. Quando ela disse “conectei”, aí sim rode novamente nosso script e pegue o SID e SERIAL# da sessão a qual iremos criar um rastreamento.
Durante o contato com a usuária como já comentei antes, faça ela se sentir bem de estar sendo atendida, aja com cordialidade caso ela tenha dificuldade de entender o que você está falando.
Para alguns usuários falar para ela que vai fazer um trace é mesmo que falar em outra língua… Isso os faz menos especiais??? Claro que não! Somente demonstra que cada pessoa deve conhecer bem da sua área de trabalho.
Portando use termos como: “Preciso fazer uma análise do relatório e preciso ver ele rodando” ou “Preciso ver o que o sistema está fazendo que está demorando tanto e para isso preciso ver ele rodando e acompanhar”, bem, o que você vai dizer nã importa muito,
o importante é deixar nossa usuária na certeza de que está sendo atendida e conseguir o SID e SERIAL.
Quando tivermos com estes dois valores poderemos então fazer um trace/rastreamento do processo. Nossa intenção com isso é em primeiro lugar, ver do tempo que o sistema demora para trazer o resultado das seguintes perguntas:
1- Quanto tempo efetivamente ele está “parado” no banco de dados?
2- Quais as instruções SQLs(queries) estão mais lentas?
3- Onde está tendo lentidão, caso esteja.
Assim teremos descoberto se realmente a voz do povo que disse: A CULPA É DO BANCO!!! Está certa, ou se nosso banco de dados mais uma vez foi injustiçado.
Acredite, nos meus anos de análise de performance sei com certeza que na grande maioria das vezes a culpa não está no banco de dados.
Mas isso provaremos e comentaremos mais adiante.
No próximo post irei comentar como fazer este trace, por quanto tempo fazê-lo, o que fazer com ele depois de pronto.
É isso aí! Um excelente final de semana! Aproveite para descansar, curtir seu bem maior (família) e jamais esqueça:
FOCO NA META!!! Seja ela qual for!
Grande Abraço,
RAULdba
