Capacity Planning (Parte 2)

Capacity Planning (Continuação)

Agora que conhecemos a teoria para a realização de um projeto capacity planning, vamos analisar quais as métricas devem ser coletadas para cada camada que constitui o sistema computacional.
Primeiramente, temos que definir thresholds que indicam níveis de conforto satisfatórios, por exemplo 50 GB de redo diário. Ultrapassando esse nível, os tamanhos dos arquivos têm de ser reajustados para manter o tempo de leitura recomendado pelo Oracle (15 a 30 min).
Depois disso, será necessário colidir as métricas do Oracle com as métricas coletadas pelos outros componentes do sistema computacional. As métricas que devem ser coletadas são:
i) CPU: utilização, run-queue, context switches (voluntárias e involuntárias), interrupções, system calls;
ii) Storage: Número de IOPS/second, Queue Depth, Tamanho de IOPS, Tempo de resposta, throughput;
iii) Filesystem: crescimento e tempo de resposta;
iv) Memória: memória física consumida, swap in/out e Page faults;
v) Rede: Throughput e detalhes do netstat –s e kstat; e
vi) Servidor de aplicação (supondo IIS): time-taken, bytes-sent, bytes-received, status, cs-uri-stem, cs-uri-query, cs(cookie), cs(referrer).
Do monitoramento do servidor de aplicação, podemos retirar as informações plotadas na figura 4:

Figura4

As métricas que devem ser coletadas para uma análise detalhada do banco de dados:

  • Users (transactions, logons, parses);
  • Redo activity;
  • Temp activity;
  • Tablespace e espaço usado pelos objetos;
  • Pga usage;
  • Sga usage;
  • Parallel Operations;
  • I/O Operations; e
  • File Stats e Temp Stats.

Para Wait events:

Analisar os top waits events, events idle e parallel (PX*) waits (se houver), conforme pode ser visto na figura 5:

Figura5

 

A decomposição do tempo de resposta mostra que events idle e parallel não são significativos no dia analisado desta base. Então vamos detalhar rapidamente os principais wait events plotados na figura 5:

  • CPU: tempo gasto de CPU para processamento das operações
  • Db file scattered read: tempo gasto com leituras multiblocks
  • Db file seqüencial read: tempo gasto com leituras single-blocks
  • Buffer busy waits: este evento indica uma contenção (problema de lentidão) e análise deve ser aprofundada para que seja descoberta se esta contenção ocorre, por exemplo, em um bloco de índice ou de dados, ou até no header do bloco e para cada um destes casos há uma solução diferente que são melhor explicada através do metalink: Case Study: Buffer Busy Waits Issue [ID 358303.1].

Após a coleta de todas as métricas citadas acima deve se montar tabelas com a sumarização dos dados para cada servidor e BD monitorados e os thresholds definidos juntamente com a área de negócio.

Darei mais exemplos no próximo post de como fazer a correlação entre negócio e hardware.

 

Abraços

José Eduardo Fiamengui Jr

 

 

 

Sobre oradeep

José Eduardo Fiamengui Júnior Graduação: Tecnologia em Informática pela Universidade Estadual de Campinas (Unicamp) Pós-Graduação: Administração em Banco de Dados Oracle pelo Instituto Brasileiro de Tecnologia Avançada (IBTA) Mba em Gestão Estratégica em TI pela FGV OCE Certified ITIL Certified Empresa Atual: Dba Oracle e Performance Specialist na Ccee Empresa Atual: Instrutor Oracle IBTA
Esta entrada foi publicada em Oracle. ligação permanente.

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s