oracle

 

Nesta nova série de posts relacionados a performance em bancos de dados Oracle, irei começar a falar sobre um assunto que muito me interessa, e que muito deveria interessar a todos os DBAs.

 

1 – Introdução

Antes de mais nada, para você, o que seria performance tuning? Para mim é o ato de realizar tarefas pro e reativamente, com a finalidade de evitar e resolver problemas relacionados a performance do banco de dados como um todo ou a algo bem específico, como uma carga em lote ou uma simples query.

Para aplicar os conceitos de performance tuning em determinado ambiente, o DBA antes de mais nada deve saber identificar se realmente há um problema de performance. Eu, particularmente não vou atrás de um ou outro usuário que reclamar que o cadastro de produtos esta lento. Muito depende do dia de trabalho (há ambientes que possuem demandas acima do normal em dias específicos, que são ambientes sazonais) da frequência com que se executa determinada ação (há usuários que podem reclamar de lentidão ao usar uma funcionalidade pela primeira vez) e até mesmo do humor do usuário que, por exemplo, na noite anterior, descobriu que a filha de 16 anos está grávida de um jovem de 14 anos.

Todos os fatores acima servem como base para saber se o ambiente está realmente lento, de uma forma constante, ou experimentando picos de lentidão, o que é comum na maioria dos ambientes.

Para realmente saber se o ambiente está lento, verificar diretamente no sistema operacional e no banco de dados. No sistema operacional, executar comandos como top, iostat, vmstat para saber se o servidor não está “no talo”. Caso o servidor esteja com espaço nos seus recursos de hardware, partir para uma análise mais específica, no banco de dados. Gerar e verificar, caso haja licença para isso, um relatório AWR para começar a ter uma direção em termos de onde o problema está.

Já vi casos de que apenas uma query estava “derrubando” o ambiente inteiro, isso porque a query realizava um crossjoin entre 2 tabelas, uma com 500.000 e outra com 200.000 registros. Esse tipo problema grotesco, infelizmente, ocorre com certa frequência, e cabe ao DBA detectar, solucionar e principalmente, previnir que tal problema volte a ocorrer.

 

2 – Compulsuve Tuning Disorder (CTD)

Isso é um “mal” que pode atingir a qualquer DBA. Basicamente esse mal se caracteriza pelo vicio em tentar otimizar tudo que existe no banco, desde aquela consulta em uma tabela de 10 linhas que retorna apenas uma linha, até a velocidade com que o café é produzido e disponibilizado em seu setor.

Mas alguns de vocês podem falar: “Ah, mas tudo que é bom, pode ficar melhor”. Mas no escopo de performance em bancos de dados, isso não está inteiramente correto. Eu tenho a seguinte filosofia em relação a performance em bancos: Não mexer no que esta funcionando bem, EM TERMOS DE PERFORMANCE. Não confundir com a administração diária do banco.

Se você é daqueles que vive pensando em melhorar TUDO do ambiente em termos de performance, mesmo percebendo que os usuários estão com um lindo sorriso no rosto, o que é coisa muito rara no nosso meio, você provavelmente sofre desse mal.

 

3) Tópicos a serem abordados

Nesta série de posts eu irei abordar otimizações nas seguintes areas, todas voltadas para o Oracle:

3.1) Tuning de memória da instância Oracle

3.2) Tuning de rede

3.3) Tuning de storage

3.4) Tuning de SQLs

3.5) Tuning de índices

3.6) Detectando possíveis problemas a nível de S.O

 

É isso ai pessoal, até a próxima postagem.

 

Keep Querying.