Você está na página 1de 356

Otimização e Performance do Banco de Dados Oracle 10g

TOROTIMP

Outubro/2005

Apostila desenvolvida especialmente para Target Informática Ltda. Sua cópia ou reprodução é expressamente proibida.

Outubro/2005

Otimização e Performance do Banco de Dados Oracle 10g

Sumário

1. Visão Geral sobre Tuning

1-1

Objetivos

1-2

Questões sobre Tuning

1-3

Metas de Tuning

1-4

Exemplos de Metas de Tuning Mensuráveis

1-5

Fases de Tuning

1-6

Passos do Tuning

1-7

Desempenho versus Segurança

1-8

Exercícios – 1

1-9

2. Oracle Alert e Arquivos de Trace

2-1

Objetivos

2-2

Informações de Diagnóstico

2-3

Arquivo Alert Log

2-4

Controlando o Arquivo de Alert Log

2-7

Controlando Arquivos de Trace de Processos Background

2-8

Arquivos de Trace de Usuário

2-9

Controlando os Arquivos de Trace de Usuário

2-10

Exercícios – 2

2-12

3. Utilitários e Visões de Performance Dinâmicas

3-1

Objetivos

3-2

Visões, Utilitários e Ferramentas

3-3

Visões Especiais e do Dicionário de Dados

3-4

Visões Dinâmicas de Performance e Solução de Problemas

3-5

Tópicos para Solução de Problemas e Tuning

3-6

Coletando Estatísticas de Sistema

3-8

Coletando Estatísticas de Sessão

3-10

Scripts UTLBSTAT e UTLESTAT

3-12

STATSPACK

3-13

Resultados do Relatório de STATSPACK

3-14

Coletando Estatísticas

3-15

Relatório de Estatísticas

3-17

Estatísticas do Library Cache

3-19

Estatísticas de I/O

3-20

Eventos de Espera Oracle

3-21

Visão V$EVENT_NAME

3-22

Visões de Estatísticas de Eventos

3-23

Visão V$SYSTEM_EVENT

3-24

Visão V$SESSION_EVENT

3-25

Visão V$SESSION_WAIT

3-26

Ferramentas Desenvolvidas pelo DBA

3-28

Oracle Diagnostics Pack e Oracle Tuning Pack

3-29

Performance Manager

3-31

Categorias de Tuning

3-32

Exercícios – 3

3-33

Otimização e Performance do Banco de Dados Oracle 10g

4. Efetuando o Tuning

da Shared Pool

4-1

Objetivos

4-2

Shared Global Area

4-3

Shared Pool

4-4

Library Cache

4-5

Efetuando o Tuning do Library Cache

4-6

Terminologia

4-8

Ferramentas de Diagnóstico para Tuning do Library Cache

4-9

Cursores estão sendo Compartilhados ?

4-11

Diretrizes: Library Cache Reloads

4-12

Invalidações

4-13

Dimensionando o Library Cache

4-14

Alocação de Espaço Global

4-15

Grandes Requisitos de Memória

4-17

Efetuando o Tuning do Espaço Reservado da Shared Pool

4-19

Fixando Objetos Grandes

4-21

Blocos PL/SQL Anônimos

4-22

Outros Parâmetros que Afetam o Library Cache

4-23

Data Dictionary

Cache, Terminologia e Tuning

4-24

Ferramentas de Diagnóstico para Tuning do Data Dictionary Cache

4-25

Efetuando o Tuning do Data Dictionary Cache

4-26

Diretrizes: Dictionary Cache Misses

4-27

UGA e Shared Server

4-28

Dimensionando a User Global Area

4-29

Large Pool

4-30

Exercícios – 4

4-32

5. Efetuando o Tuning do Database Buffer Cache

5-1

Objetivos

5-2

Características do Buffer Cache

5-3

Parâmetros de Dimensionamento do Buffer Cache no Oracle 10g

5-5

Dimensionamento Dinâmico da SGA

5-6

Redimensionando a SGA: Exemplos

5-8

Prevendo Alterações no Tamanho da SGA

5-9

Gerenciando o Database Buffer Cache

5-10

Metas e Técnicas de Tuning

5-13

Utilitários de Diagnóstico

5-15

Medindo o Cache Hit Ratio

5-16

Diretrizes para Utilização do Cache Hit Ratio

5-17

Utilizando Múltiplos Buffer Pools

5-19

Definindo Múltiplos Buffer Pools

5-20

Habilitando Múltiplos Buffer Pools

5-21

Diretrizes do Buffer Pool KEEP

5-22

Calculando o Hit Ratio para Múltiplos Pools

5-23

Identificando Segmentos Candidatos para cada Pool

5-24

Visões do Dicionário com Buffer Pools

5-25

Outros Indicadores de Performance

5-26

Efetuando o Cache de Tabelas

5-28

Free Lists

5-29

Diagnosticando Contenção na Free List

5-30

Otimização e Performance do Banco de Dados Oracle 10g

Resolvendo Contenção de Free List

Gerenciamento Automático de Espaço de Segmentos (Automatic Segment

5-32

Space Management)

 

5-33

Exercícios – 5

5-34

6. Efetuando o Tuning do Redo Log Buffer

6-1

Objetivos

6-2

Redo Log Buffer

6-3

Dimensionando o Redo Log Buffer

6-4

Efetuando o Tuning do Redo Log Buffer

6-5

Utilitários de Diagnóstico para Tuning do Redo Log Buffer

6-6

Diretrizes para Tuning do Redo Log Buffer

6-8

Reduzindo Operações de Redo

6-11

Gerenciamento Automático de Memória Compartilhada

6-12

Exercícios – 6

6-13

7. Configuração do Banco de Dados e Detalhes de I/O

7-1

Objetivos

7-2

Estatísticas de I/O para Diferentes Tipos de Arquivo Oracle

7-3

Utilização de Tablespace

7-4

Gerenciando Tablespaces

7-5

Tablespaces com tamanhos de Blocos Diferentes

7-6

Distribuindo Arquivos Através de Dispositivos

7-7

Striping de Arquivos Oracle

7-8

Efetuando Tuning de Operações de Full Table Scan

7-9

Utilitários de Diagnóstico para Verificar Estatísticas de I/O

7-11

Estatísticas de I/O

7-12

Grupos e Membros de Redo Log

7-13

Configuração de Archive Log File

7-15

Checkpoints

7-17

Diretrizes para Tuning de Checkpoint

7-18

Múltiplos I/O Slaves

7-20

Parâmetros de Inicialização

7-21

Múltiplos Processos DBWn

7-22

Exercícios – 7

7-23

8. Utilizando Blocos Oracle Eficientemente

8-1

Objetivos

8-2

Hierarquia de Armazenamento do Banco de Dados

8-3

Alocando uma Extensão

8-4

Evitando a Alocação Dinâmica

8-5

Evitando as Desvantagens da Alocação Dinâmica

8-6

Prós e Contras de Extensões Grandes

8-7

Tamanho de Bloco do Banco de Dados

8-9

Tamanho

de Bloco

Oracle (DB_BLOCK_SIZE)

8-10

Prós e Contras de Tamanho de Bloco Pequeno

8-11

Prós e Contras de Tamanho de Bloco Grande

8-12

PCTFREE e PCTUSED

8-13

Diretrizes de PCTFREE e PCTUSED

8-15

Migração (Migration) e Encadeamento (Chaining)

8-16

Detectando o Encadeamento e Migração

8-17

Otimização e Performance do Banco de Dados Oracle 10g

 

Selecionando Linhas Migradas e Encadeadas

8-18

High Water Mark

8-19

Estatísticas de Tabelas

8-20

Package DBMS_SPACE

8-21

Reorganização de Índices

8-22

Monitorando Índices

8-23

Exercícios – 8

8-25

9.

Otimizando Operações de Sort

9-1

Objetivos

9-2

Operações que Necessitam de Sort

9-3

Processo de Ordenação

9-5

Área de Sort e Parâmetros

9-6

Outros Parâmetros para Área de Sort

9-9

Processo de Sort e Espaço Temporário

9-10

Segmento de Espaço Temporário

9-11

Efetuando o Tuning de Ordenações

9-12

Evitando Ordenações

9-13

Utilitários de Diagnóstico

9-15

Diagnósticos e Diretrizes

9-17

Monitorando Tablespaces Temporárias

9-18

Configurando Tablespaces Temporárias

9-19

Exercícios – 9

9-21

10.Latches

10-1

 

Objetivos

10-2

Latches: Visão Geral

10-3

Procedimento de Requisição e Espera por Latches

10-5

Tipos de Requisições por Latches

10-6

Diagnosticando Problemas de Contenção por Latches

10-7

Categorias de Latches

10-9

11.Tuning de Segmentos de Undo

11-1

Objetivos

11-2

Automatic Undo Management (AUM)

11-3

Undo Tablespace

11-4

Alteração de Tablespace de Undo

11-5

Utilização de Segmentos de Undo

11-6

Obtendo Informações sobre Segmentos de Undo

11-7

Estatísticas dos Segmentos de Undo

11-8

Atividade Atual nos Segmentos de Undo

11-10

Monitorando o Gerenciamento Automático de Undo

11-11

Diretrizes: Utilizando Menos Undo

11-12

Problemas com Segmentos de Undo

11-13

Erro de Leitura Consistente

11-14

Exercícios – 11

11-15

12.Tuning de SQL

12-1

Objetivos

12-2

Visão Geral

12-3

Modos de Otimização

12-4

Otimização e Performance do Banco de Dados Oracle 10g

Configurando o Modo de Otimização

12-5

Ferramentas de Diagnóstico

12-6

Explain Plan

12-7

Exemplo de Plano de Execução

12-8

Diagnosticando a Performance de Comandos SQL

12-9

Parâmetros de Inicialização Importantes

12-10

Ligando e Desligando o Trace

12-11

Formatando o Arquivo de Trace

12-12

Estatísticas de Trace (TKPROF)

12-13

Examinando a Performance de Comandos

12-14

Autotrace

12-15

Comandos SQL Ineficientes

12-16

Packages, Procedures e Triggers

12-17

Performance de Módulo

12-18

Registrando um Módulo

12-19

Rastreando um Módulo

12-20

Obtendo Informações do Dicionário

12-21

Exercícios – 12

12-22

13.Considerações de Tuning para Diferentes Aplicações

13-1

Objetivos

13-2

Visão Geral

13-3

Processamento de Transações Online

13-4

Sistemas de Suporte a Decisão (DSS)

13-5

Aplicações com Múltiplos Propósitos

13-6

Escolhendo a Estrutura Física Mais Adequada

13-7

Métodos de Acesso aos Dados

13-8

Índices B-Tree

13-9

Índices Comprimidos

13-12

Índices Bitmap

13-13

Criando e Mantendo Índices Bitmap

13-14

Comparando Índices B*Tree e Bitmap

13-15

Índices de Chave Reversa

13-16

Criando Índices de Chave Reversa

13-17

Tabelas Index-Organized

13-18

Tabelas Index-Organized Comparadas com Tabelas Normais

13-20

Criando Tabelas Index-Organized

13-21

Índices Baseados em Funções

13-22

Visões do Dicionário

13-23

Clusters

13-24

Particionamento

13-25

Exemplo de Particionamento por Intervalo

13-26

Exemplo de Particionamento por Lista

13-27

Acessos às Partições

13-28

Histogramas

13-29

Requisitos para OLTP

13-31

Detalhes sobre Aplicações OLTP

13-32

Requisitos para DSS

13-33

Detalhes sobre Aplicações DSS

13-34

Sistemas Híbridos

13-35

Otimização e Performance do Banco de Dados Oracle 10g

14.Tuning do Sistema Operacional

14-1

Objetivos

14-2

Introdução

14-3

Configurações Multi-CPU

14-4

Paging e Swapping

14-5

Tuning de Memória

14-6

Tuning de I/O

14-7

Diretrizes para Tuning de CPU

14-8

Processos e Threads

14-9

Diretrizes

14-10

Apêndice - Resolução dos Exercícios

1

Soluções Exercícios 1

2

Soluções Exercícios 2

3

Soluções Exercícios 3

4

Soluções Exercícios 4

7

Soluções Exercícios 5

9

Soluções Exercícios 6

11

Soluções Exercícios 7

12

Soluções Exercícios 8

14

Soluções Exercícios 9

16

Soluções Exercícios 11

18

Soluções Exercícios 12

20

Otimização e Performance do Banco de Dados Oracle 10g

1.1. VisãoVisão GeralGeral sobresobre TuningTuning

Visão Geral sobre Tuning

Objetivos

Listar as diferentes responsabilidades associadas com o processo de tuning.

Definir os passos associados com o processo de tuning.

Identificar diferentes metas de tuning.

Visão Geral sobre Tuning

Questões sobre Tuning

Quem Realiza o Tuning?

Todos os envolvidos com o sistema Oracle 10g, analistas de sistema, designers, desenvolvedores e administradores de banco de dados (DBAs), devem pensar sobre performance e tuning ao executarem seu trabalho.

Se problemas surgirem, normalmente o DBA é quem realiza a primeira tentativa para resolvê-los.

Porque Realizar o Tuning?

Sem dúvida, a melhor prática de tuning é ter cuidado no design dos sistemas e aplicações e a maioria dos ganhos de performance é percebida através do tuning da aplicação.

É menos provável que você tenha problemas de performance se:

O hardware pode satisfazer demandas de usuário.

Seu banco de dados Oracle 10g foi cuidadosamente desenhado.

Seus

desenvolvedores

de

aplicação

escrevem

programas

eficientes.

SQL

Se decisões erradas forem feitas cedo, ou se os usuários esperarem muito mais do sistema do que anteriormente, você pode ter que considerar seriamente a melhoria de performance. Quanto mais tempo você demorar para iniciar o processo de tuning, maior será o custo de tempo e recursos.

Como Efetuar o Tuning?

Você deve começar o tuning com uma idéia clara do que você está tentando alcançar. Tente quantificar isto o mais precisamente possível, em condições reais. Por exemplo:

Processar 10,000 pedidos por dia.

Produzir 250,000 lançamentos de faturamento durante a noite no final do mês.

Neste curso, descrevemos freqüentemente os objetivos de tuning do Oracle 10g, mas em última instância estes devem beneficiar os usuários. Não há nenhum ponto em efetuar uma pequena melhoria no uso do database buffer cache se todos os usuários estão acessando os dados através de uma rede lenta em PCs antigos. Neste caso, seus esforços de tuning não serão notados.

Tuning é um processo repetitivo. Não é uma atividade que você efetua uma vez e então esquece.

Visão Geral sobre Tuning

Metas de Tuning

Suas metas primárias ao efetuar tuning em um servidor Oracle 10g são para garantir que:

Comandos SQL acessem o menor número possível de blocos Oracle.

Se um bloco for necessário, então que esteja no cache em memória.

Usuários compartilhem o mesmo código.

Quando o código for necessário, que esteja no cache em memória.

Onde leituras e escritas forem inevitáveis, que sejam efetuadas o mais rápido possível.

Usuários nunca esperem por recursos presos por outros usuários.

Backups e outras administrações internas possam ser efetuadas o mais rápido possível.

Visão Geral sobre Tuning

Exemplos de Metas de Tuning Mensuráveis

Tempo de resposta.

Disponibilidade do banco de dados.

Percentuais de utilização do banco de dados.

Utilização de memória.

Quando estiver efetuando o tuning de um ambiente de banco de dados Oracle 10g o DBA deve estabelecer metas de tuning mensuráveis. Sem isto, será difícil determinar quando o tuning terá atingido um nível satisfatório.

Tempo de resposta é a quantidade de tempo que demora para um usuário receber dados a partir de uma requisição, como por exemplo, o resultado de uma consulta, ou o tempo que leva para atualizar uma tabela ou gerar um relatório.

Disponibilidade do banco de dados é também uma boa medida para metas de tuning. A disponibilidade do banco de dados pode sofrer impactos devido a operações de backup e recovery ou no shutdown e startup da instância para alteração de parâmetros.

Percentuais de utilização (hit percentage) do banco de dados fornecem bons fundamentos para determinar se a performance está aumentando ou diminuindo com o passar do tempo.

A utilização de memória é também uma medida válida, uma vez que operações excessivas de paginação e swapping podem impactar na performance do banco de dados e do sistema operacional. A utilização de memória pode também impactar nos percentuais de utilização do banco de dados.

Visão Geral sobre Tuning

Fases de Tuning

O tuning pode ser dividido em quatro fases:

Design da aplicação e programação:

Sempre que possível, o tuning deveria começar nessa fase. Com um bom design, muitos problemas não ocorrem. Por exemplo, a normalização excessiva das tabelas pode gerar um número grande de joins. Portanto, algumas desnormalizações deveriam ser feitas.

Configuração do banco de dados:

É importante monitorar pontos críticos, mesmo tendo discos rápidos. Você deveria planejar a configuração de dados de forma a acelerar o tempo de recovery e o acesso aos dados.

Adição de nova aplicação:

Ao adicionar uma nova aplicação ao sistema, a carga de trabalho muda. Qualquer mudança na carga de trabalho deveria ser acompanhada de tuning.

Tuning contínuo:

Essa é a metodologia recomendada para bancos de dados em produção. Consiste em procurar por gargalos e eliminá-los. Use ferramentas para identificá-los. Examinando os relatórios gerados você pode formar hipóteses sobre o que está causando o gargalo. A partir da hipótese, você pode desenvolver uma solução e implementá-la. Execute um teste de stress no banco para verificar se o problema foi resolvido.

Visão Geral sobre Tuning

Passos do Tuning

A ordem recomendada para implementação de tuning é a seguinte:

1. Design (se não for tarde demais).

2. Aplicação.

3. Memória.

4. I/O.

5. Contenção.

6. Sistema operacional.

Repita o processo se suas metas não forem atingidas.

A razão para esta estrutura é que melhorias feitas cada vez mais cedo na seqüência podem evitar que se deva lidar com outros problemas mais tarde.

Por exemplo, se suas aplicações estiverem utilizando muitos full table scans, isto pode aparecer como I/O excessivo. Entretanto, não há nenhum ponto em redimensionar o buffer cache, ou redistribuir arquivos nos discos, se você pode reescrever as consultas de forma que acessem somente quatro blocos ao invés de quatro mil.

Os dois primeiros passos são tipicamente de responsabilidade dos arquitetos do sistema e desenvolvedores da aplicação. Entretanto, o DBA pode também ser envolvido no tuning da aplicação.

Visão Geral sobre Tuning

Desempenho versus Segurança

Fatores que afetam o desempenho:

Múltiplos control files

Múltiplos membros nos grupos de redo log

Checkpoints freqüentes

Backups de datafiles

Arquivamento de redo log files

Número de usuários e transações concorrentes

Há sempre uma troca feita por desempenho. De forma a aumentar o desempenho do sistema, algum outro aspecto será afetado de forma inversa. Freqüentemente o tempo de recovery é afetado. Quanto mais seguro o DBA faz o banco, mais lento este fica.

A decisão deve ser feita levando em consideração quão seguro o banco deve ser e que nível de desempenho é necessário: quantos usuários concorrentes devem acessar o banco, quantas transações por segundo devem ser feitas, etc.

Visão Geral sobre Tuning

Exercícios – 1

1. Siga as instruções do instrutor para a criação do banco de dados.

2. Crie uma instância do Enterprise Manager para o banco de dados.

Visão Geral sobre Tuning

Espaço para anotações

Otimização e Performance do Banco de Dados Oracle 10g

2.2. OracleOracle AlertAlert ee ArquivosArquivos dede TraceTrace

Oracle Alert e Arquivos de Trace

Objetivos

Identificar a localização e a utilidade do arquivo de alert log.

Identificar a localização e a utilidade dos arquivos de trace de processos background e de usuário.

Oracle Alert e Arquivos de Trace

Informações de Diagnóstico

Arquivos de Trace:

Arquivo de alert log.

Arquivos de trace de processos background.

Arquivos de trace de usuário.

Arquivo Alert Log

Se um erro ocorre enquanto sua instância Oracle estiver executando, as mensagens são escritas para o arquivo alert log. Durante o startup do banco de dados, se o arquivo alert log não existir, o servidor Oracle o criará.

cronológico de

O arquivo alert log

de um banco de dados

é

um

log

mensagens e erros. O servidor Oracle utiliza o arquivo alert log como uma alternativa para exibir tais informações.

Arquivos de Trace de Processos Background

Se um erro for detectado por um processo background, a informação sofre um dump para um arquivo de trace.

Arquivos de Trace de Usuário

Arquivos de trace podem também ser gerados por processos servidores quando requisitado pelo usuário para exibir o consumo de recursos durante o processamento de comandos.

Oracle Alert e Arquivos de Trace

Arquivo Alert Log

É importante que o administrador do banco de dados verifique o arquivo alert log periodicamente para detectar problemas antes que se tornem sérios.

As seguintes informações são registradas no arquivo de alert log:

Erros internos (ORA-00600) e erros de corrupção de bloco (ORA-

01578).

Operações que afetem estruturas e parâmetros do banco de dados, e comandos como CREATE DATABASE, STARTUP, SHUTDOWN, ARCHIVE LOG e RECOVER.

Os valores de todos os parâmetros de inicialização não default no momento do startup da instância.

Oracle Alert e Arquivos de Trace

Starting up ORACLE RDBMS Version: 10.1.0.2.0. System parameters with non-default values:

processes

= 250

sga_max_size

= 88080384 = 71303168 = 4194304 = /oracle/oradata/tuning/control01.ctl,

shared_pool_size

java_pool_size

control_files

/oracle/oradata/tuning/control02.ctl

db_block_size

= 8192

db_cache_size

= 8388608

compatible

= 10.1.0.2.0

db_file_multiblock_read_count= 16

db_recovery_file_dest

= /oracle/flash_recovery_area

db_recovery_file_dest_size= 2147483648

undo_management

= AUTO

undo_tablespace

= UNDOTBS1

remote_login_passwordfile= EXCLUSIVE

db_domain

= = tuning = tuning = (PROTOCOL=TCP) (SERVICE=tuningXDB) = 10 = /oracle/admin/tuning/bdump = /oracle/admin/tuning/udump = /oracle/admin/tuning/cdump = 65536 = tuning = 300

instance_name

service_names

dispatchers

job_queue_processes

background_dump_dest

user_dump_dest

core_dump_dest

sort_area_size

db_name

open_cursors

PMON started with pid=2, OS id=20278

MMAN started with pid=3, OS id=20280 DBW0 started with pid=4, OS id=20282 LGWR started with pid=5, OS id=20284 CKPT started with pid=6, OS id=20286 SMON started with pid=7, OS id=20288 RECO started with pid=8, OS id=20290 CJQ0 started with pid=9, OS id=20292 Tue Jan 4 10:26:14 2005 starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES) (PROTOCOL=TCP))' starting up 1 shared server(s) Tue Jan 4 10:26:14 2005

ALTER DATABASE

MOUNT

Tue Jan 4 10:26:14 2005 Controlfile identified with block size 16384 Tue Jan 4 10:26:19 2005

Setting recovery target incarnation to 1 Tue Jan 4 10:26:19 2005

Successful mount of redo thread 1, with mount id 272594822 Tue Jan 4 10:26:19 2005 Database mounted in Exclusive Mode.

Completed: ALTER DATABASE Tue Jan 4 10:26:19 2005 ALTER DATABASE OPEN …

MOUNT

Figura 2-1 : Exemplo de arquivo alert_<SID>.log

Oracle Alert e Arquivos de Trace

Tue Jan 4 10:15:53 2005

Thread 1 advanced to log sequence 76

create tablespace DATA

Current log# 1 seq# 76 mem# 0: /oracle/oradata/tuning/redo01a.log

datafile '/oracle/oradata/tuning/data01.dbf' size 300M reuse

Thread 1 cannot allocate new log, sequence 76

Tue Jan 4 10:50:19 2005

Checkpoint not complete

alter tablespace user_data begin backup

EXTENT MANAGEMENT LOCAL online

Tue Jan 4 10:16:03 2005

Tue Jan 4 10:50:19 2005

Completed: ORA-1123 signalled create tablespace during: alter SYSTEM tablespace datafile user_data begin backup

'/oracle/oradata/tuning/system01.dbf'

Backups de controlfile e online tablespace.

Checkpoints não completados devido ao switch muito rápido dos redo log files.

Criação de tablespaces.

Uma vez que este arquivo cresce e acaba ocupando espaço em disco, copie e remova-o freqüentemente, ou diminua seu tamanho periodicamente.

Oracle Alert e Arquivos de Trace

Controlando o Arquivo de Alert Log

Alert e Arquivos de Trace Controlando o Arquivo de Alert Log Figura 2-2: Configurando o destino

Figura 2-2: Configurando o destino do arquivo alert log

O seguinte parâmetro do init<SID>.ora controla a localização do arquivo alert log:

BACKGROUND_DUMP_DEST

BACKGROUND_DUMP_DEST

O nome do arquivo é alert_<SID>.log.

Oracle Alert e Arquivos de Trace

BACKGROUND_DUMP_DEST

BACKGROUND_DUMP_DEST

Controlando Arquivos de Trace de Processos Background

Controlando Arquivos de Trace de Processos Background Figura 2-3: Configurando o destino dos arquivos de trace

Figura 2-3: Configurando o destino dos arquivos de trace

O seguinte parâmetro do init<SID>.ora controla a localização dos arquivos de trace de processos background:

No UNIX, o nome do arquivo é <SID>_<processname>_<PID>.trc.

No Windows, o nome do arquivo é <SID><processname>.trc.

Exemplo parcial de um arquivo de trace de processo background no Linux

(tuning_smon_20288.trc):

Oracle Alert e Arquivos de Trace

ORACLE_HOME = /oracle/product/10.1.0/db_1

System name:

Linux

Node name:

dbserver10g.targettrust.com

Release: 2.4.21-4.EL

Version:

#1 Fri Oct 3 17:52:56 EDT 2003

Machine: i686 Instance name: tuning Redo thread mounted by this instance: 1 Oracle process number: 7 Unix process pid: 20288, image: oracle@dbserver10g.targettrust.com (SMON) *** SERVICE NAME:() 2005-01-04 10:26:19.492 *** SESSION ID:(275.1) 2005-01-04 10:26:19.492

Oracle Alert e Arquivos de Trace

Arquivos de Trace de Usuário

SQL> ALTER SESSION SET sql_trace=TRUE;

SQL> ALTER SESSION SET sql_trace=TRUE;

SQL> ALTER SESSION SET sql_trace=TRUE;

Trace de processo servidor é habilitado ou desabilitado em nível de sessão ou instância pelo:

Comando ALTER SESSION.

Procedure SET_SQL_TRACE_IN_SESSION.

Parâmetro de inicialização SQL_TRACE.

Um arquivo de trace de usuário contém estatísticas dos comandos SQL de uma sessão.

Um arquivo de trace de usuário é útil para tuning de SQL.

O Oracle cria um arquivo de trace de usuário por processo servidor.

Arquivos de trace de usuário podem também ser gerados por um processo servidor quando requisitado por um usuário ou DBA.

Trace em Nível de Instância

Este registro de trace é habilitado ou desabilitado pelo parâmetro de inicialização SQL_TRACE. O valor default é FALSE.

SQL> EXECUTE dbms_system.set_sql_trace_in_session(8,12,TRUE);

SQL> EXECUTE dbms_system.set_sql_trace_in_session(8,12,TRUE);

SQL> EXECUTE dbms_system.set_sql_trace_in_session(8,12,TRUE);

Trace em Nível de Sessão

O seguinte comando habilita a escrita para um arquivo de trace para uma sessão particular:

Onde: 8 e 12 representam o SID e SERIAL# do usuário conectado, respectivamente.

A package DBMS_SYSTEM é criada no Servidor Oracle pelo script localizado no diretório $ORACLE_HOME/rdbms/admin/dbmsutil.sql. O script é automaticamente executado quando catproc.sql for executado.

O seguinte comando habilita a escrita para um arquivo de trace para a sessão do usuário conectado:

Oracle Alert e Arquivos de Trace

SQL> alter session set sql_trace=true;

Sessão alterada.

SQL> select id, nome from aluno.tclientes where id = 130;

ID NOME ---------- ----------------------------------- 130 Ramiro Antunes

Controlando os Arquivos de Trace de Usuário

Antunes  Controlando os Arquivos de Trace de Usuário Figura 2-4: Configurando o destino dos arquivos

Figura 2-4: Configurando o destino dos arquivos de trace de usuário

Os seguintes parâmetros de inicialização controlam a localização e o tamanho dos arquivos de trace de usuário, onde:

USER_DUMP_DEST define onde os arquivos de trace devem ser criados quando requisitados pelos usuários ou DBA.

MAX_DUMP_FILE_SIZE especificado em blocos do sistema operacional, limita o tamanho dos arquivos de trace de usuário.

O nome do arquivo é ora_<PID>.trc.

Exemplos:

Habilitando trace em uma sessão:

Oracle Alert e Arquivos de Trace

PARSING IN CURSOR #1 len=51 dep=0 uid=0 oct=3 lid=0 tim=1078949592214907 hv=3493566330 ad='520dba60' select id,

PARSING IN CURSOR #1 len=51 dep=0 uid=0 oct=3 lid=0 tim=1078949592214907 hv=3493566330 ad='520dba60' select id, nome from aluno.tclientes where id = 130 END OF STMT PARSE

#1:c=10000,e=4381,p=0,cr=2,cu=0,mis=1,r=0,dep=0,og=1,tim=1078949592214900

EXEC #1:c=0,e=108,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,tim=1078949592215125 FETCH #1:c=0,e=89,p=0,cr=2,cu=0,mis=0,r=1,dep=0,og=1,tim=1078949592215294 FETCH #1:c=0,e=1,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1078949592217840

FETCH #1:c=0,e=1,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=1078949592217840

Visão

(tuning_ora_24484.trc):

parcial

do

arquivo

de

trace

de

usuário

resultante

Nota: MAX_DUMP_FILE_SIZE e USER_DUMP_DEST são parâmetros de inicialização dinâmicos.

Oracle Alert e Arquivos de Trace

Exercícios – 2

A meta destes exercícios é familiarizar você com a configuração da máquina, e focar os utilitários de diagnóstico, como os arquivos de trace e as visões de eventos de espera.

1. Conecte-se como sysdba.

2. Consulte os parâmetros para localizar o arquivo de alert log e os arquivos de trace de usuário respectivamente.

3. Examine o seu arquivo alert.log.

4. Conecte-se com o SQL*Plus e execute um comando que crie um arquivo de trace de usuário. Consulte a visão DBA_TABLES do dicionário de dados e quaisquer outras consultas que deseje. Finalize o trace.

5. Examine o arquivo de trace resultante, sem se preocupar com seu conteúdo, pois isto será discutido em um capítulo posterior.

Oracle Alert e Arquivos de Trace

Espaço para anotações

Oracle Alert e Arquivos de Trace

Otimização e Performance do Banco de Dados Oracle 10g

3.3. UtilitáriosUtilitários ee VisõesVisões dede PerformancePerformance DinâmicasDinâmicas

Utilitários e Visões de Performance Dinâmicas

Objetivos

Coletar estatísticas através:

De visões dinâmicas de performance e solução de problemas.

Do relatório gerado por STATSPACK.

Eventos de espera Oracle.

Utilitários e Visões de Performance Dinâmicas

Visões, Utilitários e Ferramentas

Visões Dinâmicas e do Dicionário

O servidor Oracle exibe todas as estatísticas de sistema na visão V$SYSSTAT, e utiliza várias outras visões para informações sobre performance e para solução de problemas. Você pode consultar estas visões para encontrar totais cumulativos desde o startup da instância, mas isto é freqüentemente de pouca ajuda; se sua instância raramente sofre um shutdown, as estatísticas podem referir-se a um longo período e possuir pouco significado.

O Oracle exibe estatísticas sobre o armazenamento de dados nas visões DBA_xxx que podem ajudá-lo na solução de problemas de storage dos segmentos (tabelas, clusters, índices e partições).

Scripts UTLBSTAT e UTLESTAT

Você deve recolher informações de performance sobre um período definido, provavelmente o momento de maior utilização do dia ou então no final do mês, e produzir um relatório.

Você pode efetuar isto com os scripts utlbstat.sql e utlestat.sql.

Consultores

experientes

normalmente

iniciam

um

projeto

de

tuning

utilizando este utilitário para capturar dados.

Utilitário STATSPACK

Similar em essência a utlbstat e utlestat, serve para coletar estatísticas de períodos de tempo e armazená-las no banco de dados. Isso permite que sejam comparadas estatísticas de diferentes intervalos de tempo, através de várias fotografias (snapshots) tiradas do banco. Também permite gerar um relatório de quaisquer duas fotografias.

Eventos de Espera Oracle

Se você estiver solucionando problemas, você necessita saber quando um processo esperou por qualquer tipo de recurso. Uma lista de eventos de espera está presente no servidor Oracle.

Algumas visões do dicionário exibem os eventos para aquelas sessões que tiveram que esperar.

Aplicações do Oracle Diagnostics and Tuning Packs

Você pode também utilizar as ferramentas gráficas da Oracle fornecidas com o Oracle Diagnostics and Tuning Packs, um conjunto de aplicações windows-based dirigidas a várias áreas de gerenciamento de performance Oracle, como monitoramente gráfico, análises e tuning automatizado de bancos de dados Oracle.

Utilitários e Visões de Performance Dinâmicas

Visões Especiais e do Dicionário de Dados

Quando você necessita visualizar o armazenamento de dados em detalhes, você deve utilizar o comando ANALYZE, que coleta estatísticas e preenche colunas de visões DBA_xxx e especiais.

O comando ANALYZE preenche colunas nas visões que abrangem:

Armazenamento de dados em tabelas dentro de extensões e blocos:

DBA_TABLES

DBA_TAB_COLUMNS

Armazenamento de dados em clusters dentro de extensões e blocos:

DBA_CLUSTERS

Armazenamento de dados em índices dentro de extensões e blocos, e utilização de índices:

DBA_INDEXES

INDEX_STATS

Distribuição de dados em colunas não indexadas e indexadas:

DBA_TAB_HISTOGRAMS

INDEX_HISTOGRAM

Também podemos usar a package DBMS_STATS, descrita em detalhes no capítulo "Utilizando Blocos Oracle Eficientemente".

Utilitários e Visões de Performance Dinâmicas

Visões Dinâmicas de Performance e Solução de Problemas

Visões V$

Baseadas nas tabelas X$, que são estruturas de memória que armazenam informações sobre a instância e portanto estão disponíveis quando a instância estiver no modo NOMOUNT ou MOUNT.

São listadas na visão V$FIXED_TABLE.

As visões V$ (sinônimos para as visões V_$) pertencem ao usuário SYS.

Tabelas X$

Normalmente não são consultadas diretamente; nem todas as informações são necessariamente úteis, e os nomes de colunas tendem a ser abreviados e obscuros.

As tabelas X$ são dinâmicas, e seu conteúdo está constantemente sendo modificado.

As visões V$, e as tabelas X$ que estão por trás delas, são preenchidas na inicialização da instância e limpas no shutdown.

Armazenam informações de tempo se você configurar o parâmetro TIMED_STATISTICS do init<SID>.ora para TRUE ou executar o comando SQL:

SQL> ALTER SYSTEM SET timed_statistics=TRUE;

SQL> ALTER SYSTEM SET timed_statistics=TRUE;

SQL> ALTER SYSTEM SET timed_statistics=TRUE;

Utilitários e Visões de Performance Dinâmicas

Tópicos para Solução de Problemas e Tuning

Dinâmicas Tópicos para Solução de Problemas e Tuning Figura 3-1: Tópicos para solução de problemas e

Figura 3-1: Tópicos para solução de problemas e tuning

Estatísticas de Sistema

Visões pertinentes a instância/banco de dados:

V$PX_PROCESS_SYSSTAT: estatísticas de sistema de parallel query.

V$PROCESS: informações sobre os processos atualmente ativos.

V$WAITSTAT: estatísticas de contenções.

V$SYSTEM_EVENT: total de esperas para eventos específicos.

Visões pertinentes a memória:

V$BUFFER_POOL_STATISTICS: alocação de buffer pools na instância (criada pelo script $ORACLE_HOME/rdbms/admin/catperf.sql).

V$DB_OBJECT_CACHE: objetos do banco de dados que estão em cache no library cache.

V$LIBRARYCACHE: estatísticas de performance e atividade do library cache.

V$ROWCACHE: atividade de hits e misses do data dictionary.

V$SYSSTAT: estatísticas básicas da instância.

Visões pertinentes a performance de disco:

V$FILESTAT: estatísticas de leitura/escrita em data files.

V$TEMPSTAT: informações sobre estatísticas de leitura/escrita em data files de tablespaces temporárias.

Utilitários e Visões de Performance Dinâmicas

Visões pertinentes a contenção:

V$LATCH: estatísticas para cada tipo de latch.

V$ROLLSTAT: estatísticas para todos os segmentos de undo online.

V$WAITSTAT: estatísticas de contenção de bloco (o parâmetro TIMED_STATISTICS do init<SID>.ora deve estar configurado para TRUE).

Estatísticas de Sessão

V$LOCK: locks atualmente mantidos pelo servidor.

V$OPEN_CURSOR: cursores atualmente abertos e compilados (parsed) para cada sessão.

V$SORT_USAGE: tamanho de segmentos temporários e sessões que os criaram; identificação dos processos que estão efetuando ordenações em disco.

V$SESSTAT: estatísticas da sessão do usuário.

V$SESSION_EVENT: informações sobre as esperas por um evento para uma sessão.

V$SESSION_WAIT: recursos ou eventos pelos quais as sessões ativas estão aguardando.

V$PX_SESSTAT: informações sobre as sessões utilizando execução em paralelo.

Utilitários e Visões de Performance Dinâmicas

Coletando Estatísticas de Sistema

de Performance Dinâmicas Coletando Estatísticas de Sistema Figura 3-2: Coletando estatísticas de sistema Estatísticas

Figura 3-2: Coletando estatísticas de sistema

Estatísticas Genéricas de Sistema

Todos os tipos de estatísticas de sistema estão catalogados na visão V$STATNAME: cerca de 290 estatísticas estão disponíveis.

O servidor Oracle exibe todas as estatísticas de sistema calculadas na visão V$SYSSTAT. Você pode consultar esta visão para encontrar totais cumulativos desde o startup da instância.

Exemplo:

Utilitários e Visões de Performance Dinâmicas

SQL> SELECT * FROM v$sgastat; SQL> SELECT name, class, value FROM v$sysstat; POOL NAME NAME

SQL> SELECT * FROM v$sgastat;

SQL> SELECT name, class, value FROM v$sysstat;

POOL

NAME

NAME

CLASS

VALUE

BYTES

--------------------- ------- ------------

------------ -------------------------- ----------

db block gets

fixed_sga

8

7687

777556

consistent gets

buffer_cache

8

17547

8388608

physical reads

log_buffer

8

763

262144

session uga memory

shared pool free memory

1

1312236

4192704

session pga memory

shared pool pl/sql source

1

57634176

19576

sorts (memory)

shared pool sessions

64

497

1284644

sorts (disk)

shared pool sql area

64

0

13103560

sorts (rows)

64

605

shared pool sessions 64 497 1284644 sorts (disk) shared pool sql area 64 0 13103560 sorts
shared pool sessions 64 497 1284644 sorts (disk) shared pool sql area 64 0 13103560 sorts
shared pool sessions 64 497 1284644 sorts (disk) shared pool sql area 64 0 13103560 sorts

São classificadas por tópicos de tuning:

Class 1 refere-se a atividade geral da instância.

Class 2 refere-se a atividade do redo log buffer.

Class 4 refere-se a lock.

Class 8 refere-se a atividade do database buffer cache.

Class 16 refere-se a atividade do sistema operacional.

Class 32 refere-se a paralelização.

Class 64 refere-se aos acessos de tabelas.

Class 128 refere-se a propósitos de debug.

Estatísticas Globais da SGA

O servidor Oracle exibe todas as estatísticas de memória calculadas na visão V$SGASTAT. Você pode consultar esta visão para encontrar totais cumulativos da utilização detalhada da SGA desde o startup da instância.

Exemplo:

Estatísticas de Eventos de Espera

visão

V$EVENT_NAME: cerca de 286 estatísticas estão disponíveis.

Estatísticas acumuladas para todas as sessões são armazenadas em V$SYSTEM_EVENT: esta exibe os totais de esperas para um evento específico desde o startup da instância.

Se você estiver solucionando um problema, você necessita saber quando um processo esperou por algum recurso.

Todos

os

tipos

de

eventos

de

espera

estão

catalogados

na

Utilitários e Visões de Performance Dinâmicas

Coletando Estatísticas de Sessão

de Performance Dinâmicas Coletando Estatísticas de Sessão Figura 3-3: Coletando estatísticas de sessão Estatísticas

Figura 3-3: Coletando estatísticas de sessão

Estatísticas Genéricas de Sessão

Dados de sessão são cumulativos desde o momento da conexão. Você pode exibir informações atuais da sessão para cada usuário conectado. Outra visão, V$MYSTAT, exibe as estatísticas da sessão corrente.

Exemplo: determine o tipo de conexão que os usuários possuem.

SQL> SELECT sid, username, type, server

2 FROM v$session; SID USERNAME

TYPE

SERVER

---------- ------------------------------ ---------- ---------

250 DBSNMP

USER

DEDICATED

251 DBSNMP

USER

DEDICATED

252 SYSMAN

USER

DEDICATED

253 SYSMAN

USER

DEDICATED

254 SYS

USER

DEDICATED

255 ALUNO

USER

DEDICATED

Utilitários e Visões de Performance Dinâmicas

   

SQL> SELECT sid, event

 

2 FROM v$session_wait

3 WHERE wait_time = 0;

SID EVENT ---------- -----------------------------------------------

   

250 queue messages

 
   

251 SQL*Net message from client

 

SQL> SELECT username, name, value

252

SQL*Net message from client

2 FROM v$statname n, v$session s, v$sesstat t

253

SQL*Net message from client

SQL*Net message from client

SQL*Net message from client

SQL*Net message from client

3 WHERE s.sid = t.sid

254

5 AND s.type = 'USER'

256

4 AND n.statistic# = t.statistic#

255

6 AND s.username is not null

257

wait for unread message on broadcast channel

7 AND n.name = 'session pga memory'

8 AND t.value > 1000000;

USERNAME

NAME

VALUE

------------------------------ ------------------------------ ----------

DBSNMP

session pga memory session pga memory session pga memory session pga memory

1022540

1350220

1153612

1219148

 

SYSMAN

SYSMAN

SYSMAN

SYSMAN

session pga memory 1284684

O servidor Oracle exibe todas as estatísticas de sessão calculadas na visão V$SESSTAT. Você pode consultar esta visão para encontrar os totais cumulativos de sessão desde o startup da instância.

Exemplo: determine as sessões que consomem mais de 1000000 bytes de memória para a pga.

Estatísticas de Eventos de Espera de Sessão

A visão V$SESSION_EVENT exibe por sessão, os totais de esperas para um evento específico desde o startup da instância.

A visão V$SESSION_WAIT lista os recursos ou eventos pelos quais as sessões ativas estão aguardando.

Se você estiver solucionando um problema, você necessita saber quando um processo esperou por algum recurso. A estrutura da V$SESSION_WAIT torna fácil a verificação em tempo real se qualquer sessão está aguardando, e se estiver, o porquê da espera.

Você pode então investigar mais adiante para visualizar se tais esperas ocorrem com freqüência e se estão correlacionadas com outros fenômenos, como o uso de módulos específicos.

Utilitários e Visões de Performance Dinâmicas

Scripts UTLBSTAT e UTLESTAT

Coletam informações de performance sobre um período definido.

Produzem um relatório formatado.

Utilize os scripts utlbstat.sql e utlestat.sql.

Execute os scripts a partir do SQL*Plus conectado como SYSDBA.

Configure TIMED_STATISTICS para TRUE.

As visões dinâmicas exibem totais cumulativos desde o startup da instância, mas isto é freqüentemente de pouca ajuda; se sua instância raramente sofre shutdown, as estatísticas podem cobrir um longo período e possuírem pouco significado.

Você deve coletar informações de performance sobre um período definido, provavelmente seu período de maior utilização do dia ou final do mês, e produzir um relatório.

Você pode efetuar isto com os scripts utlbstat.sql e utlestat.sql, armazenados no diretório $ORACLE_HOME/rdbms/admin no UNIX e %ORACLE_HOME%\rdbms\admin no Windows.

O script utlestat também gera um relatório (em arquivo) no diretório corrente. Ele contém as estatísticas do período apurado, feitas através das diferenças entre as estatísticas do início e do final do período.

Nota: STATSPACK provê estatísticas mais claras

Utilitários e Visões de Performance Dinâmicas

STATSPACK

A package STATSPACK pode ser instalada a partir do script spcreate.sql,

presente no diretório $ORACLE_HOME/rdbms/admin/, e consome inicialmente cerca de 80Mb de espaço na tablespace default do usuário perfstat. Porém o espaço necessário pode aumentar a medida que a package for utilizada.

O script cria o usuário Perfstat, as tabelas do statspack, suas constraints

e a package STATSPACK. Durante a instalação é requisitado o nome das tablespaces default e temporária desse usuário.

Uso da package STATSPACK

Usa-se a ferramenta STATSPACK tirando-se ao menos duas fotografias (snapshots) do banco de dados em momentos diferentes e comparando-as. Conecte-se com o usuário Perfstat, e execute a procedure STATSPACK.snap. Isso armazenará nas tabelas de STATSPACK os valores estatísticos de desempenho.

Tire outra fotografia do banco a cada dia, semana, mês ou ano, para comparar os períodos desejados. O melhor método é automatizar a coleta de estatísticas para que seja feita regularmente.

O script spauto.sql utiliza a package DBMS_JOB para isso. O script agenda a coleta de snapshots a cada hora, mas isso pode ser alterado.

Relatório de STATSPACK

Para examinar as mudanças nas estatísticas entre dois momentos, execute o script spreport.sql conectado com o usuário Perfstat. Será mostrada uma lista de períodos de coleta e pedido os períodos inicial e final. O relatório com as diferenças entre estes períodos será calculado e gravado em um arquivo com o nome indicado pelo usuário.

Utilitários e Visões de Performance Dinâmicas

Resultados do Relatório de STATSPACK

Primeira página do relatório

A primeira página resume o relatório. Os itens dessa página incluem a

maioria das informações que um DBA necessita para otimizar o desempenho do sistema. Cada uma dessas áreas será vista em detalhes no curso.

Cache Sizes

O tamanho atual do buffer cache, shared pool e log buffer mostrados em

Kb. Também mostra o tamanho primário de bloco (DB_BLOCK_SIZE).

Load Profile

Valores dados por segundo e por transação. São mostrados tamanho de redo, leituras e escritas físicas feitas durante o período analisado.

Instance Efficiency Percentages

Os itens aqui mostrados são os mais comumente usados para tuning de performance. O objetivo é ter todas as percentagens em 100%, ou tão próximo quanto possível. Compare esses valores com os valores normais do banco de dados.

Top Five Wait Events

A lista completa de eventos de espera aparece mais adiante no relatório,

e serão tratadas depois no curso. Essa lista mostra os eventos de maior contenção.

O resto do documento

O relatório feito por STATSPACK é melhor do que aquele feito por UTLBSTAT/ UTLESTAT, pois resume as informações mais relevantes para o DBA (aquelas nas quais o DBA deve se concentrar primeiro)

O resto do documento mostra:

Lista completa de eventos de espera, colocados em ordem de importância (os mais problemáticos aparecem primeiro).

Informações sobre os comandos SQL presentes atualmente na Shared Pool. Várias listas de comandos aparecem aqui, ordenadas por número de execuções, compilações (parse calls), buffers lidos e número de leituras. Listagens nessas ordens facilitam a identificação dos comandos mais "caros" ao sistema, e aqueles que devem ser analisados primeiro.

Estatísticas de segmentos de Undo.

Estatísticas da SGA. Duas listas: um resumo e uma lista detalhada por área da memória.

Valores iniciais dos parâmetros do init<SID>.ora. Como existem parâmetros dinâmicos no banco, não há garantias de que esses sejam os valores usados atualmente.

Utilitários e Visões de Performance Dinâmicas

SQL> SQL> create @$ORACLE_HOME/rdbms/admin/utlbstat.sql table stats$begin_stats as select * from

2

v$sysstat where 1=0;

SQL> create table stats$end_stats as select * from

2

stats$begin_stats;

Coletando Estatísticas

* from 2 stats$begin_stats; Coletando Estatísticas Figura 3-4: Coletando estatísticas Inicie a Coleta de

Figura 3-4: Coletando estatísticas

Inicie a Coleta de Estatísticas

O script cria as tabelas BEGIN e END e obtém uma imagem dos dados das visões de performance dinâmica (V$xxx) para coletar as estatísticas iniciais armazenando-as nas tabelas BEGIN.

Stats tablename

Baseada em

stats$begin_latch

v$latch

stats$begin_roll

v$rollstat

stats$begin_lib

v$librarycache

stats$begin_dc

v$rowcache

stats$begin_event

v$system_event

stats$file_view

v$filestats, ts$, v$datafile, file$

stats$begin_file

stats$file_view

stats$begin_waitstat

v$waitstat

Utilitários e Visões de Performance Dinâmicas

SQL> @$ORACLE_HOME/rdbms/admin/utlestat.sql

SQL>SQL>createinserttableintostats$statsstats$end_latchas selectselecte.value-b.value* from v$latch;

 

2 change, n.name

3 from v$statname n, stats$begin_stats b, stats$end_stats e

4 where n.statistic# = b.statistic#

5 and

n.statistic# = b.statistic#;

 

Encerre a Coleta de Estatísticas

O script obtém uma nova imagem dos dados das visões de performance dinâmica (V$xxx) para coletar as estatísticas finais armazenando-as nas tabelas END.

Stats tablename

Baseada em

stats$end_stats

v$sysstat

stats$end_lib

v$librarycache

stats$end_event

v$system_event

stats$end_waitstat

v$waitstat

stats$end_roll

v$rollstat

stats$end_file

stats$file_view

stats$end_dc

v$rowcache

O script cria as tabelas DIFFERENCE onde armazena os valores da

estatísticas iniciais a partir das

subtração

estatísticas finais.

dos

resultados

das

O script remove todas as visões e tabelas temporárias.

O script gera um relatório selecionando os dados a partir das tabelas DIFFERENCE.

Nota: o script conecta-se como SYSDBA e cria tabelas na tablespace default do usuário SYS, ou seja, SYSTEM. Antes de executar o script, crie uma nova tablespace para este propósito, e modifique a tablespace default do usuário SYS para esta nova tablespace. Ao finalizar a execução dos 2 scripts, modifique a tablespace default do usuário SYS de volta para SYSTEM.

Utilitários e Visões de Performance Dinâmicas

Statistic SQL> spool report.txt SQL> select --------------------------- --------- --------- ---------

Statistic

SQL> spool report.txt

SQL> select

--------------------------- --------- --------- ---------

--------------------------- --------- --------- ---------

Total Per Trans Per Logon

Total Per Trans Per Logon

Statistic

from stats$lib;

consistent gets

DBWR checkpoint buffers wri

219

559715

9.95

1168.51 25441.59

.46

DBWR checkpoint write reque db block gets 9949 159 20.77 .33 452.23 7.23 physical reads
DBWR checkpoint write reque
db block gets
9949
159
20.77
.33
452.23
7.23
physical reads
419280
875.32 19058.18
DBWR checkpoint write reque db block gets 9949 159 20.77 .33 452.23 7.23 physical reads 419280
DBWR checkpoint write reque db block gets 9949 159 20.77 .33 452.23 7.23 physical reads 419280
DBWR checkpoint write reque db block gets 9949 159 20.77 .33 452.23 7.23 physical reads 419280
DBWR checkpoint write reque db block gets 9949 159 20.77 .33 452.23 7.23 physical reads 419280

Relatório de Estatísticas

Report.txt

O relatório gerado pelo script utlestat.sql contém uma seqüência de comandos SELECT sobre as tabelas DIFFERENCE.

Estatísticas do Library Cache

O library cache contém as áreas compartilhadas de SQL e PL/SQL. Efetuar tuning desta área significa reduzir os misses nos passos de parse ou execute do processamento de comandos SQL ou PL/SQL, sempre que se descobrir que misses do library cache estão afetando a performance do Oracle.

Estatísticas de Sistema

Esta seção do relatório fornece para cada estatística de sistema, um número total de operações, o número total de operações por commit de usuário e por logon. Isto ajuda você a efetuar o tuning de diversas áreas.

Exemplo 1: DBWR Checkpoints

DBWR Checkpoints indicam o número de mensagens de checkpoints que foram enviadas para o DBWR. O aumento de I/O durante um checkpoint pode resultar na perda de performance.

Reduza o número e/ou freqüência do checkpoint aumentando o parâmetro do init.ora LOG_CHECKPOINT_INTERVAL e LOG_CHECKPOINT_TIMEOUT. Entretanto, fique atento que checkpoints infreqüentes aumentam o tempo de recovery do banco de dados.

Exemplo 2: Consistent Gets, DB Blocks Gets, Physical Reads

Consistent Gets é o número de blocos acessados do buffer cache para consultas sem a cláusula FOR UPDATE.

DB Block Gets é o número de blocos acessados do buffer cache para comandos INSERT, UPDATE e SELECT FOR UPDATE.

A soma destes representa o número de leituras lógicas.

Physical Reads é o número de requisições por um bloco que causou I/O físico.

Utilitários e Visões de Performance Dinâmicas

Você calcula o hit ratio para detectar se o tamanho do database buffer cache é suficientemente grande ou se freqüentemente não consegue manter os blocos lidos em memória.

Estatísticas de Eventos de Espera

Cada evento de espera de sistema é uma troca de contexto que custa tempo de CPU. Observando o Total Time, você freqüentemente pode determinar qual é o “gargalo” pelo qual os processos estão tendo de aguardar.

Estatísticas de Latch

O Oracle utiliza latches para proteger o acesso a estruturas internas, como o library cache para cursores compartilhados, ou a lista LRU (least- recently-used) para buffer de dados do buffer cache.

O tuning da área de latch consiste em reduzir a contenção para alocação de latches.

Estatísticas de Espera por Buffer Busy

Esta pequena seção indica, se o evento de espera “buffer busy wait” for alto, quais classes de blocos estão tendo alto nível de contenção: bloco de dado, header de segmento ou header de undo.

Estatísticas do Dictionary Cache

Cada comando SQL ou PL/SQL implica em acesso para os objetos do dicionário, e portanto ao cache do dicionário. Misses no cache do dicionário causam um aumento de I/O e uma correspondente perda de performance.

Efetuar o tuning desta área significa que você reduziu os misses do dictionary cache.

Esta seção exibe os gets e os misses para cada tipo de item que está no cache.

Estatísticas de I/O por Datafile/Tablespace

Esta seção exibe como o I/O de arquivo foi dividido através dos discos, contando o número de leituras/escritas físicas, leituras/escritas físicas de blocos e a quantidade de tempo despendido para estas operações por cada datafile e tablespace.

Período de Medição

Esta seção exibe o momento em que o script utlbstat iniciou a coleta das estatísticas begin e quando o utlestat iniciou a coleta das estatísticas end.

Utilitários e Visões de Performance Dinâmicas

SQL> Rem Select Library cache statistics. The pin hit rate should be high. SQL> select namespace library,

 

2 gets,

3 round(decode(gethits,0,1,gethits)/decode(gets,0,1,gets),3)

 

4 gethitratio,

 

5 pins,

6 round(decode(pinhits,0,1,pinhits)/decode(pins,0,1,pins),3)

 

7 pinhitratio,

 

8 reloads, invalidations

9 from stats$lib;

 

LIBRARY

GETS GETHITRATI

PINS PINHITRATI

RELOADS INVALIDATI

------------ ---------- ---------- ---------- ---------- ---------- ----------

SQL AREA

604

.998

4351

.998

5

0

TABLE/PROCED

36

.972

329

.994

0

0

BODY

10

1

184

1

0

0

TRIGGER

0

1

731

1

0

0

INDEX

0

1

0

1

0

0

CLUSTER

4

1

4

1

0

0

OBJECT

0

1

0

1

0

0

PIPE

0

1

0

1

0

0

JAVA SOURCE

0

1

0

1

0

0

JAVA RESOURC

0

1

0

1

0

0

JAVA DATA

0

1

0

1

0

0

11 rows selected.

Estatísticas do Library Cache

Este é um exemplo da primeira seção do report.txt.

Utilitários e Visões de Performance Dinâmicas

SQL> Rem I/O should be spread evenly accross drives. A big difference between SQL> Rem phys_reads and phys_blks_rd implies table scans are going on. SQL> select table_space, file_name,

2 phys_reads reads, phys_blks_rd blks_read, phys_rd_time read_time,

3 phys_writes writes, phys_blks_wr blks_wrt, phys_wrt_tim write_time,

4 megabytes_size megabytes,

 

5 round(decode(phys_blks_rd,0,0,phys_rd_time/phys_blks_rd),2) avg_rt,

6 round(decode(phys_reads,0,0,phys_blks_rd/phys_reads),2) "blocks/rd"

7 from stats$files order by table_space, file_name;

 

TABLE_SPACE

FILE_NAME

READS BLKS_READ READ_TIME AVG_RT blocks/rd

WRITES

BLKS_WRT WRITE_TIME MEGABYTES

--------------- --------------------------------------- ---------- ---------- ----- ----- ---------- ---------- ---------- ---------- ---------- ----------

DEFAULTTBS1

/oracle/oradata/tuning/default01.dbf

0

0

0

0

0

0

210

0

0

INDX

/oracle/oradata/tuning/indx01.dbf

0

0

0

0

0

0

26

0

0

SYSAUX

/oracle/oradata/tuning/sysaux01.dbf

18

18

1

6

13

0

210

.06

1

SYSTEM

/oracle/oradata/tuning/system01.dbf

99

183

0

28

28

2

315

0

1.85

UNDOTBS1

/oracle/oradata/tuning/undo01.dbf

1

1

0

29

63

1

210

0

1

USERS

/oracle/oradata/tuning/users01.dbf

0

0

0

0

0

0

26

0

0

6 rows selected.

 

Estatísticas de I/O

Este é um exemplo da última seção do report.txt.

Utilitários e Visões de Performance Dinâmicas

Eventos de Espera Oracle

A visão V$EVENT_NAME lista uma coleção de eventos de espera que fornecem informações sobre as sessões que tiveram que aguardar para serem processadas:

EVENT#

NAME

PARAMETER1

PARAMETER2

PARAMETER3

Existem mais de 290 eventos de espera no servidor Oracle. Estes eventos são listados na visão V$EVENT_NAME.

Free Buffer Wait

Latch Free

Buffer Busy Wait

Db File Sequential Read

Db File Scattered Read

Db FileParallel Write

Undo Segment Tx Slot

Undo Segment Extension

Free Buffer Wait

Utilitários e Visões de Performance Dinâmicas

SQL> SELECT name, parameter1, parameter2, parameter3

 

2

FROM v$event_name;

NAME

PARAMETER1 PARAMETER2 PARAMETER3

------------------------------- ---------- ---------- ---------- PL/SQL lock timer duration alter system set mts_dispatcher waited

buffer busy waits library cache pin log buffer space log file switch (checkpoint incomplete) transaction

file#

block#

id

handle addr pin address 0*mode+name

undo seg#

wrap#

count

808 linhas selecionadas.

 

Visão V$EVENT_NAME

Parâmetros que Descrevem um Evento de Espera

Exemplo 1: o evento de espera Buffer Busy Wait aguarda até que um buffer torne-se disponível. Este evento ocorre quando um buffer é lido no buffer cache por outra sessão (e a sessão está aguardando que a leitura se complete), ou está no buffer cache, mas em um modo incompatível (ou seja, alguma outra sessão está modificando o buffer).

Este evento é complementado com três parametros:

FILE# e BLOCK#: estes parâmetros identificam o número do bloco no data file que está identificado pelo número de arquivo para o bloco pelo qual o servidor Oracle necessita aguardar.

ID: o evento Buffer Busy Wait é chamado de diferentes lugares na sessão. Cada local no kernel aponta para uma diferente razão. ID refere-se ao local na sessão que causou este evento.

Exemplo 2: o evento Log File Switch (Checkpoint Incomplete) aguarda por um log switch porque a sessão não pode fazer um wrap para o próximo log. O wrapping não pode ser efetuado porque o checkpoint para aquele log não foi completado. Este evento não possui parâmetros.

Utilitários e Visões de Performance Dinâmicas

Visões de Estatísticas de Eventos

V$SYSTEM_EVENT: total de esperas por um evento, para todas as sessões juntas.

V$SESSION_EVENT: esperas por um evento para cada sessão que teve de aguardar.

V$SESSION_WAIT: esperas por um evento para as sessões atualmente ativas que estão aguardando.

Os resultados de estatísticas das sessões que tiveram de aguardar ou estão atualmente aguardando por um recurso podem ser visualizados utilizando–se as visões V$SESSION_EVENT, V$SESSION_WAIT.

Estatísticas acumuladas para todas as sessões podem ser visualizadas utilizando a visão V$SYSTEM_EVENT.

Utilitários e Visões de Performance Dinâmicas

SQL> SELECT event, total_waits, total_timeouts, ----------------- ------ -------- ------ ---------- 2 time_waited,

SQL> SELECT event, total_waits, total_timeouts,

----------------- ------ -------- ------ ----------

2 time_waited, average_wait

3 FROM v$system_event;

total_timeouts, ----------------- ------ -------- ------ ---------- 2 time_waited, average_wait 3 FROM v$system_event;

Visão V$SYSTEM_EVENT

latch free

EVENT

pmon timer

process startup

5

932

1

535 254430 272.993562

TIME_ AVERAGE_

8 2.66666667

WAIT

5

5

TOTAL_ TOTAL_

3

WAITS TIMEOUTS WAITED

buffer busy waits

12

0

5

5

50 linhas selecionadas.

A visão V$SYSTEM_EVENT mostra o total de esperas para um evento em particular desde o startup da instância.

Se você estiver solucionando um problema, você necessita saber quando um processo teve de esperar por qualquer recurso. Portanto, é útil consultar esta visão cada vez que a performance do sistema diminui.

A visão V$SYSTEM_EVENT contém as seguintes colunas:

EVENT: nome do evento de espera.

TOTAL_WAITS: número total de esperas para o evento.

TOTAL_TIMEOUTS: número total de timeouts para o evento.

TIME_WAITED: quantidade total de tempo aguardado para este evento, em centésimos de segundo.

AVERAGE_WAIT: a quantidade média de tempo aguardado para este evento, em centésimos de segundo.

Utilitários e Visões de Performance Dinâmicas

Visão V$SESSION_EVENT

SQL> SELECT sid, event, total_waits,average_wait

 

2

FROM v$session_event where sid=10;

SID EVENT

TOTAL_WAITS AVERAGE_WAIT

---- ------------------------------ ----------- -------------

10

buffer busy waits

12

5

10

db file sequential read

129

0

10

file open

1

0

10

SQL*Net message to client

77

0

10

SQL*Net more data to client

2

0

10

SQL*Net message from client

76

0

A visão V$SESSION_EVENT mostra a mesma informação da visão V$SYSTEM_EVENT, mas por sessão. Esta inclui as colunas listadas na página anterior, com uma coluna extra, SID, para identificar a sessão. Você pode efetuar um join da coluna SID com a V$SESSION.SID para encontrar detalhes do usuário.

Utilitários e Visões de Performance Dinâmicas

SQL> SELECT sid, seq#, event, wait_time, state

2

FROM v$session_wait;

SID

SEQ# EVENT

WAIT STATE

TIME ---- ------ --------------------------- ----- -------

 

1 1284 pmon timer

0 WAITING

2 1697 rdbms ipc message

0 WAITING

3 183 rdbms ipc message

0 WAITING

4 4688 rdbms ipc message

0 WAITING

5 114 smon timer

0 WAITING

6 14 SQL*Net message from client

-1 WAITED

 

SHORT

TIME

Visão V$SESSION_WAIT

Esta visão lista os recursos ou eventos para os quais as sessões ativas estão aguardando.

Colunas:

SID: identificador da sessão.

SEQ#: número de seqüência identificando a espera.

EVENT: recurso ou evento aguardado.

P1TEXT: descrição do primeiro parâmetro adicional, que corresponde ao PARAMETER1 descrito para a visão V$EVENT_NAME.

P1: valor do primeiro parâmetro adicional.

P1RAW: valor em hexadecimal do primeiro parâmetro adicional.

P2TEXT: descrição do segundo parâmetro adicional, que corresponde ao PARAMETER2 descrito para a visão V$EVENT_NAME.

P2: valor do segundo parâmetro adicional.

P2RAW: valor em hexadecimal do segundo parâmetro adicional.

P3TEXT: descrição do terceiro parâmetro adicional, que corresponde ao PARAMETER3 descrito para a visão V$EVENT_NAME.

P3: valor do terceiro parâmetro adicional.

P3RAW: valor em hexadecimal do terceiro parâmetro adicional.

WAIT_TIME:

Valor

Descrição

>0

Último tempo de espera da sessão

=0

A sessão está aguardando

=-1

O valor foi inferior a 1/100 de um segundo

=-2

O sistema não pode fornecer informação de tempo

SECONDS_IN_WAIT: número de segundos que o evento aguardou.