Descobrindo a Origem do problemaBom dia! Boa tarde! Boa Noite!
Vou comentar hoje sobre um problema que nós DBAs vivenciamos muito (infelizmente).
Infelizmente é muito comum que empresas desenvolvedoras de aplicações diversas, inclusive voltadas para médias e grandes empresas não tenham um DBA de performance focado nos desenvolvimentos. Também ocorre que os testes então são feitos pela mesma equipe que desenvolve e a maioria dos testes é feito como teste unitário, ou seja, testa apenas se o fluxo está de acordo com a regra de negócios, porém se terá uma performance aceitável quando forem executados por diversas sessões ao mesmo tempo, se causarão algum lock ou até mesmo deadlocks, não será verificado.
Sei que você está pensando será que isso acontece??!!! Acredite! Isso acontece e é mais comum do que você imagina.
Estas situações normalmente são testadas apenas no “quente” na base de produção do cliente, onde a “cobaia” irá relatar o problema e muitas vezes pagar pela correção.
Mas como descobrir quando isso ocorre? E o pior, como conseguir detalhar para que se possa pedir providências?
Vamos lá então…
Sabe aquele momento que você analisa um trace, AWR, statspack e descobre que existe uma query muito ruim rodando na base?
Pois é! Neste momento a primeira coisa que nos vem na cabeça é aquele sentimento, aquela vontade exterminar quem está rodando algo tão ruim não é mesmo?
Aí você parte para a vingança… “Vou achar este cara e tirar todos os privilégios dele, colocar num plano de recursos que não vai conseguir fazer mais nada, cortar os paralelos, cortar a cabeça dele se for preciso…”
Hehehe, enfim, você parte para a descoberta de um culpado “físico”, alguém que você possa xingar.
Porém, como disse um sábio alguma vez: a vingança não é a resposta. Então você acaba descobrindo que o culpado não é nenhum usuário e sim alguma procedure da aplicação que está gerando esta query, ou seja, ela é interna de algum procedimento que roda no banco de dados.
E agora??? Você precisa encontrar qual objeto roda esta query, qual procedure, package, trigger, etc, para então repassar ao desenvolvimento da aplicação para correções.
Eu já passei e passo até hoje muito por esta situação, por isso criei um PL/SQL interessante que irá me trazer estes dados.
Segue aí:
DECLARE
CURSOR c IS
SELECT owner,name, text
FROM dba_source where type in (‘PROCEDURE’,’PACKAGE’,’PACKAGE BODY’,’TYPE BODY’,’TRIGGER’,’FUNCTION’,’TYPE’);
BEGIN
FOR r IN c LOOP
IF upper(r.text) LIKE ‘%COLOCAR_TRECHO_QUERY%’ THEN
DBMS_OUTPUT.put_line (r.owner||’.’||r.name);
END IF;
END LOOP;
END;
Nela você irá preencher com um trecho da query entre os sinais de % conforme destacado e executar.
Ele irá varrer a base e te trará o owner e o nome do objeto que tem esta query.
Simples não é mesmo? Assim você pega o nome do objeto e repassa para análise.
Ah! Não esqueça de mencionar os dados encontrados nos relatórios, traces para comprovar o que você está falando a respeito da má performance.
É amigo, este é um problema que você não precisaria ter se as empresas levassem a sério os testes antes de disponibilizar aplicações e releases para os clientes.
Espero que tenha curtido o post de hoje, que continue acompanhando o blog e participando sempre!
Grande abraço! Saúde Força e União sempre para todos nós! O resto… Bem, o resto é resto.
