Wednesday, May 18, 2005
Statspack - Introdução
Agora que já fizemos o setup, precisamos entender o statspack. Este recurso do Oracle captura uma grande quantidade de informação, compila e apresenta em um relatório com aproximadamente 20 páginas. As principais informações apresentadas neste relatório são:
Nesta introdução, quero chamar atenção sobre o crasso erro na utilização do statspack, o período de tempo do snapshot. Ele não deveria nunca passar de 30 minutos e não menos de 15. Algo entre esses números seria o bastante.
Nesse caso, o "mais é melhor" não funciona. Exemplo: durante o dia de ontem tive que parar para atender 25 vezes o telefone. Isso atrapalhou meu trabalho ou não? Difícil de responder sem uma análise mais a fundo.
O problema com período de tempo extenso é que, as vezes, o ponto que está afetando a performance fica "diluído" no tempo. Pegando o exemplo dos telefonemas. Para definir se o número de chamadas foi o problema que impactou o trabalho, temos que analisar o número 25 vezes contra o tempo - se foi durante o dia, então 25 por 8 horas, totaliza 1 ligação a cada 19 minutos, não está mal. Agora, se o período fosse mais curto, digamos 15 minutos: Owh! 1 ligação a cada 36 segundos, agora sim, podemos afirmar que os telefonemas impactaram seriamente o trabalho, ocasionando o não cumprimento de algum cronograma.
Um outro problema encontrado no uso do statspack é a frequência com que ele é executado. Geralmente, o statspack é utilizado somente quando o sistema está indo mal. Não! Este relatório deveria ser executado todos os dias em seu sistema, para que haja histórico (instrumentação) e quando os usuários reclamarem de performance, é possível comparar os resultados de um report, quando o sistema estava bem, contra o outro, do momento que ele vai mal.
Após esta breve intrução estamos prontos para "brincar" um pouco com o statspack. No próximo artigo, vamos discutir as principais seções do statspack e como identificar issues de performance. Vou preparar alguns códigos (procedures e jobs) e tabelas para os exemplos.
Abraços,
- Informação da Instância
- Tempo do snapshot
- Estatística de uso da buffer cache, log buffer e shared pool
- Overview das estatísticas por segundo e transação
- Taxas de acerto - Famosos hit ratios
- Utilização da shared pool sobre o período medido
- TOP 5 - Lista de eventos em espera (os 5 primeiros) e seus tempos em segundos e percentual
- Lista de todos os eventos que ficaram em espera durante o período do snapshot
- Vários sabores de TOPs para SQLs, ordenados por LIOs, por PIOs, mais executados, mais parceados, e por ai vai.
Nesta introdução, quero chamar atenção sobre o crasso erro na utilização do statspack, o período de tempo do snapshot. Ele não deveria nunca passar de 30 minutos e não menos de 15. Algo entre esses números seria o bastante.
Nesse caso, o "mais é melhor" não funciona. Exemplo: durante o dia de ontem tive que parar para atender 25 vezes o telefone. Isso atrapalhou meu trabalho ou não? Difícil de responder sem uma análise mais a fundo.
O problema com período de tempo extenso é que, as vezes, o ponto que está afetando a performance fica "diluído" no tempo. Pegando o exemplo dos telefonemas. Para definir se o número de chamadas foi o problema que impactou o trabalho, temos que analisar o número 25 vezes contra o tempo - se foi durante o dia, então 25 por 8 horas, totaliza 1 ligação a cada 19 minutos, não está mal. Agora, se o período fosse mais curto, digamos 15 minutos: Owh! 1 ligação a cada 36 segundos, agora sim, podemos afirmar que os telefonemas impactaram seriamente o trabalho, ocasionando o não cumprimento de algum cronograma.
Um outro problema encontrado no uso do statspack é a frequência com que ele é executado. Geralmente, o statspack é utilizado somente quando o sistema está indo mal. Não! Este relatório deveria ser executado todos os dias em seu sistema, para que haja histórico (instrumentação) e quando os usuários reclamarem de performance, é possível comparar os resultados de um report, quando o sistema estava bem, contra o outro, do momento que ele vai mal.
Após esta breve intrução estamos prontos para "brincar" um pouco com o statspack. No próximo artigo, vamos discutir as principais seções do statspack e como identificar issues de performance. Vou preparar alguns códigos (procedures e jobs) e tabelas para os exemplos.
Abraços,
