Tuning no Negócio

Tuning no Negócio

Olá,

Muitas vezes temos notado problemas de tuning de procedures ou de queries dentro de um sistema no Oracle. Na maioria das vezes a solicitação deste “ajuste fino” acaba nas mãos do DBA que tem que ficar correndo atrás de material ou documentação e até de Fóruns (ainda bem que temos o GPO…) para solicitar um apoio e até uma nova visão sobre como melhorar isso ou aquilo. Como já havia dito antes, não sou exatamente um DBA, apenas conheço o Oracle há mais tempo que alguns, mas também fiz meus cursos e estudo por gostar e ter uma certa visão lógica mais apurada. Com isso, na grande maioria das vezes também tenho presenciado problemas de performance causados por três principais razões:

Modelo de Dados inadequado: não vou criticar o modelo de ninguém, apenas temos por necessidade criar ou desenvolver um modelo para atender uma especificação funcional, porém essa visão pode representar apenas uma situação de momento, poucos são os modelos que atendem as expectativas de uma empresa. Afinal para que colocar tratativas Globais de auditoria no TIMESTAMP se a empresa tem apenas uma unidade com 50 funcionários? Por outro lado, alguns modelos não estão preparados para grandes volumes de dados ou de inúmeros acessos simultâneos com diversas atualizações em várias tabelas filhas-mãe-avó-etc. por inúmeros usuários concorrentes. Mas o Modelo de Dados nada mais é que o Resultado de uma Definição de Negócios, que é o próximo item.

Definição de Negócios subestimada: Note que essa definição de negócio é que determina praticamente o Modelo de Dados. Se a Empresa não sabe onde quer chegar, quando deseja (e não quando quer, pois há outros fatores além do querer) chegar e principalmente como investir no resultado, acho muito difícil que essa definição represente algo confiável. Sei que é difícil para as empresas saber isso, mas é necessário. Quem já passou pelo drama de desenvolver algum sistema para Empresas e depois de pronto descobre que precisa ser utilizado para várias empresas o mesmo modelo unificado, sabe bem o que estou falando, ou ainda quem desenvolveu um sistema de fluxo de negócio qualquer e descobre que tem que ter vários níveis de aprovadores que não foi nem mencionado, também sabe o que é isso.

Queries mal-estruturadas: Criam-me que este é o menor dos problemas, isso pode ser resolvido com duas ações principais: Treinamento sobre como o Oracle processa e executa as queries (e isso pode e deve até ser explicado por um DBA, pois fica mais fácil depois de esclarecer alguns locks, waits e enqueues) e princípios de lógica. O ponto está que a lógica da query às vezes é definida pela necessidade do negócio que é dinâmica, ou seja, muda conforme a necessidade de mercado (ou da cabeça do Pseudo-Gerente) e nisso recai os pontos acima… Ora, se a lógica da query muda por causa do Negócio, então A Definição de Negócios pode estar equivocada (não errada, apenas não adequada ao momento) e portanto uma boa parte do Modelo de Dados também deve ter esse problema. Vou colocar um exemplo para esclarecer melhor:

Um modelo de dados de um ERP foi muito bem analisado e desenvolvido para altos volumes, porém em um dos processos havia um gargalo que não foi considerado na época de sua definição, isso somente representaria um problema na seguinte situação: algum processo batch que levasse horas e outros usuários acessando a mesma tabela simultaneamente a esse processo. Como os processos em lote (batch) normalmente podem ser efetuados em horários de menor pico, isso nunca representou uma ameaça. Porém anos depois os processos em lote passaram a ser mais recorrentes (por conta do mercado) e apesar da infra-estrutura ser excelente para o Oracle, os processos em lote quando executados fora do horário de pico levariam alguns minutos, porém nestes horários de pico demorava-se horas e simplesmente travando outros processos on-line.  Mas como resolver isso se os horários de pico estão aumentando por conta do crescimento da empresa? Hoje alguns atendimentos são 24X7 e esses processos estão quase sempre com altos volumes, analisar o Negócio e verificar se é possível executar esse lote em outro momento, ou melhor qual o momento adequado para esse processamento? Essa é a alternativa mais coerente, o balanceamento seria melhor distribuído por tarefas. Ponto, colocamos um agendamento para esse processo batch, se mesmo assim o processo continuar a gerar problemas então temos que analisar as rotinas mesmo até chegarmos as queries problemáticas… mas sempre tentar deixar elas por último pois nem sempre o problema será resolvido com elas, pois se a query já estiver otimizada, o volume ser alto mesmo e tempo ser demorado por conta de limitações físicas – pode ser que o resultado ainda não seja satisfatório, em outras palavras, o Tuning deve começar pelo Negócio e depois para a lógica e somente então para o DBA, mas se nem assim resolver ou se verificar que o Modelo de Dados é inadequado melhor ter uma dessas por perto…

Abraços