Os 10 erros mais comuns encontrados em Bancos de Dados Oracle
Introdução
No artigo de hoje vou comentar sobre os 10 erros mais comuns encontrados em Bancos de Dados (BDs) Oracle, que impactam negativamente na performance dos BDs e que poderiam ser evitados implementando-se algumas dicas que darei a seguir. Várias dessas dicas (ver Solução(ões) possível(is)) podem ser implementadas sem muito esforço, porém, outras podem requerer uma reengenharia completa da aplicação ou uma análise mais aprofundada sobre o problema para definir um diagnóstico e soluções melhores.
Problemas mais comuns
1- Gerenciamento de conexão ruim:
Muitas aplicações (principalmente aplicações web) conectam e se desconectam rapidamente em cada interação com o BD. O custo de criar uma nova conexão em cada interação com o BD pode ser muito alto, em relação ao tempo de parse e execução de cada instrução SQL que é executada nas interações com o BD.
Solução(ões) possível(is):
a) Criar pool de conexões (Connection Pooling) na aplicação.
b) No Oracle Database 11G já é possível habilitar Connection Pooling no BD, porém, pelo que eu li sobre o assunto, me parece que este recurso ainda não está muito bom no BD, portanto, recomendo ainda, a opção “a)”.
2- Mau uso de cursores e da Shared Pool:
Não usar cursores compartilhados ou variáveis bind pode resultar em muitos hard parses, que degradam a performance das instruções SQL e que podem consumir muito espaço de memória na Shared Pool.
Solução(ões) possível(is):
a) Nas aplicações, use variáveis bind ou chame stored procedures.
b) Habilitar o compartilhamento de cursores na instância de BD também pode contornar o problema, mas CUIDADO, outros podem surgir… por isso, prefira a opção “a)”.
3- SQL ruim:
As instruções SQL estão usando muitos recursos do sistema.
Solução(ões) possível(is):
Otimizar as instruções SQL (SQL Tuning).
4- Parâmetros de inicialização com valores diferentes do padrão:
Muitos parâmetros de inicialização são configurados com valores inapropriados, baseando-se em mau entendimento ou suposições incorretas.
Solução(ões) possível(is):
Conhecer bem os parâmetros de inicialização, a arquitetura do SGBD Oracle e a sua necessidade real, para configurá-los corretamente.
5- I/O ruim:
Em muitos lugares o armazenamento do BD não está bem distribuído nos discos disponíveis ou a largura de banda de I/O não é suficiente para atender a demanda das requisições do BD.
Solução(ões) possível(is):
Conhecer bem os dispositivos de armazenamento (Ex.: Storage) disponíveis, configurar o tipo de armazenamento (Ex.: RAID) mais apropriado e distribuir os arquivos do BD (log files, datafiles, control files etc.) em vários discos, seguindo as recomendações da própria Oracle. Para mais informações, leia I/O Configuration and Design.
6- Configuração de Redo Logs:
Redo logs pequenos ou poucos grupos de redo logs podem gerar muitos checkpoints, que consequentemente, irão gerar uma sobrecarga na Buffer Cache e no sistema de I/O.
Solução(ões) possível(is):
Configurar apropriadamente a quantidade de grupos de redo log e o tamanho dos redo log files. Para mais informações, leia Sizing Redo Log Files.
7- Serialização de blocos de dados:
A serialização de blocos de dados na Buffer Cache ocorre quando há a falta de listas livres, grupos de listas livres, slots de transação (initrans) ou segmentos de rollback. Normalmente isso ocorre quando:
- As aplicações executam pesadas rotinas de carga;
- As aplicações tem muita concorrência e tamanhos de blocos maiores que 8K;
- As aplicações possuem uma grande qtde. de usuários e o BD possui poucos segmentos de rollback.
Solução(ões) possível(is):
a) Configurar tablespaces para usar ASMM;
b) Configurar o gerenciamento automático de UNDO;
c) Não configurar tablespaces com tamanho de bloco maior que 8K para armazenar dados de objetos que sofrem muitas atualizações concorrentes.
8- Full Table Scans longos:
Full Table Scans em operações online interativas ou de alto volume, normalmente consomem muito I/O lógico e físico.
Solução(ões) possível(is):
Criar índices, otimizar SQL Ruim, particionar tabelas etc.
9- Grande quantidade de SQL recursivo (SYS) executados:
Uma grande quantidade de SQL recursivo executado pelo usuário SYS pode indicar atividades muito altas de gerenciamento de espaço de armazenamento, tais como alocação de extents. Essas atividades impactam negativamente no tempo de resposta do usuário.
Solução(ões) possível(is):
Usar tablespaces gerenciados localmente etc.
10- Erros de migração e implantação:
Em muitos casos, uma aplicação usa muitos recursos do sistema porque o schema contendo as tabelas não foi migrado com sucesso, por exemplo, de um ambiente de desenvolvimento para o ambiente de produção. Nestes casos, o que ocorre normalmente é a ausência de índices ou estatísticas incorretas, que influenciam em planos de execução ruins.
Solução(ões) possível(is):
a) Exporte as estatísticas do schema de origem usando a package DBMS_STATS;
b) Atualize as estatísticas de objetos manualmente;
c) Crie os objetos ausentes.
Artigo original:
