A Culpa é do DBA
Muitas vezes nos utilizamos do efeito Dunning-Kruger. Ou seja, acreditamos que a solução ou o problema está em uma área que não temos tanto domínio ou não conhecemos, sem mesmo averiguar antes se não seriamos os verdadeiros donos ou fatores para resolução. A velha história: a culpa ou o problema é meu e passo para quem eu quiser.
O banco de dados é uma ciência exata. Contudo, a fórmula que resolve um problema hoje, não o resolverá amanhã. A performance de uma query ou de um código PL/SQL poderá sofrer mudanças em decorrência de vários fatores, mesmo que as configurações de banco ou códigos não sejam alterados. E acredite: 95% das vezes o problema é nosso e apenas 5% é do DBA.
Acredito, ainda, que todo e qualquer trabalho para resolução de uma não conformidade deverá ser realizado unindo os esforços dos especialistas das áreas impactadas diretamente ou indiretamente. Mesmo que o percentual de responsabilidade seja mais de um do que do outro, haja vista que é necessário averiguar historicamente o que foi feito ou modificado de todos os lados para ter gerado um impacto nas aplicações, somado as experiências individuais. Duas cabeças pensam melhor que uma, isto é fato.
Olhando em uma visão de desenvolvedor PL/SQL – já que sou um – existem alguns pontos que devemos no atentar e averiguar antes de culpar o DBA. Tais situações podem ajudar a agir preventivamente – e claro reativamente – para questão de performance de códigos ou SQL no banco.
Conhecer como o Oracle trabalha
Se quiser o Banco de Dados pode apenas armazenar dados que são colocados dentro dele. Contudo, é ideal conhecer com se dar seu funcionamento e a sua estrutura para que, assim, possa explorar todo o poder computacional do ambiente. Com esse conhecimento se pode construir melhores modelagens e implementações, evitando assim o trabalho em cima de problemas, haja vista que na construção vários destes já serão prevenidos.
Atualize-se sobre as novidades de cada versão
A Oracle a cada release traz novas funções, cláusulas e mecanismos para melhoria de performance do PL/SQL e do SQL e é de suma importância estar atento. Utilize a documentação oficial da Oracle (gratuita) para verificar os pontos de melhorias de uma versão para outra ou então os livros da Oracle Press. Estes livros trazem sempre um capítulo de New Features. Desta maneira, é interessante avaliar os códigos de programas e implementar estas novidades de uma maneira proativa.
Boas práticas
É fácil criar um programa extremamente escalonável e com boa performance. Contudo, é ainda mais simples fazer o contrário. Por isto, esteja atento a utilização de boas práticas como Short-Circuit, Bulk Collections, Forall, Sqls bens escritos, dentre outros.
Existe mais de um tipo de índice
O B-Tree é o mais conhecido e comumente utilizado. Contudo, existem outros tipos, como: Bitmap, Bitmap Join, Function-Based Indexes e Oracle Text. Cada tipo atende uma determinada situação, seja por cardinalidade, seletividade, dentre outros. Desta maneira, ao se pensar em criar um índice deverá antes verificar a real necessidade e estruturá-lo segundo o tipo mais correto. Livre-se do mito que o índice resolve tudo. Pelo contrário, muitas vezes caso seja criado fora da boa prática e sem necessidade poderá causar mais problema de performance do que resolver.
Esteja atento as estatísticas
Defendo que esta atividade é mais de responsabilidade da equipe de desenvolvimento do que do DBA. Digo isto, pois quem deve avaliar a periodicidade, bem como se as estatísticas colhidas já não representa uma boa visão para os planos de execução é quem está mais próximo do negócio, tendo conhecimentos das tabelas que sofrem maiores alterações diárias. Assim, o desenvolvimento é capaz de certificar e determinar quantitativamente e qualitativamente quando os números atuais são ou não boas estatísticas.
Conhecer como os Planos de Execução funcionam
Tendo em mente os passos tomados na execução de uma query, empodera a possibilidade de resolução problemas, seja para reescrevê-la, dividi-la, ou absolvê-la da culpa de uma má performance e, o principal, identificar que o Plano de Execução apontado pelo Oracle não é o melhor plano e sugerir, por fim, um melhor caminho de acesso a informação ao banco.
Todos os pontos acima abordados foram tratados de forma genérica, pois o aprofundamento dos temas tornaria este texto sem fim. A ideia aqui é tentar explanar sobre a necessidade de como é importante conhecer os componentes e como eles se relacionam no desenvolvimento em banco de dados e mostrar que o DBA é o menos culpado de tudo.
Segue ainda alguns livros indicados sobre os assuntos abordados: Expert Oracle Database Architecture, Pro Oracle SQL, Expert Oracle SQL: Optimization, Deployment, and Statistics, Oracle PL/SQL Performance Tuning Tips & Techniques e Oracle Database 11g PL/SQL Programming.
