Oracle Otimizao e Performance em Portugues Excelente Apostila Curso Completo de Oracle Otimizao e Performance em Portugues

Otimizao e Performance do Banco de
Dados Oracle 10g
TOROTIMP
Outubro/2005
Apostila desenvolvida especialmente para Target Informtica Ltda.

Sua cpia ou reproduo expressamente proibida.
Outubro/2005
Otimizao e Performance do Banco de Dados Oracle 10g
Sumrio
1. Viso Geral sobre Tuning..........................................................1-1
Objetivos.....................................................................................................1-2
Questes sobre Tuning................................................................................1-3
Metas de Tuning..........................................................................................1-4
Exemplos de Metas de Tuning Mensurveis................................................1-5
Fases de Tuning..........................................................................................1-6
Passos do Tuning.........................................................................................1-7
Desempenho versus Segurana.................................................................1-8
Exerccios 1..............................................................................................1-9
2. Oracle Alert e Arquivos de Trace...............................................2-1

Objetivos.....................................................................................................2-2
Informaes de Diagnstico.......................................................................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 Usurio.....................................................................2-9
Controlando os Arquivos de Trace de Usurio...........................................2-10
Exerccios 2............................................................................................2-12
3. Utilitrios e Vises de Performance Dinmicas...........................3-1

Objetivos.....................................................................................................3-2
Vises, Utilitrios e Ferramentas................................................................3-3
Vises Especiais e do Dicionrio de Dados.................................................3-4
Vises Dinmicas de Performance e Soluo de Problemas.......................3-5
Tpicos para Soluo de Problemas e Tuning..............................................3-6
Coletando Estatsticas de Sistema..............................................................3-8
Coletando Estatsticas de Sesso.............................................................3-10
Scripts UTLBSTAT e UTLESTAT...................................................................3-12
STATSPACK................................................................................................3-13
Resultados do Relatrio de STATSPACK.....................................................3-14
Coletando Estatsticas..............................................................................3-15
Relatrio de Estatsticas...........................................................................3-17
Estatsticas do Library Cache....................................................................3-19
Estatsticas de I/O.....................................................................................3-20
Eventos de Espera Oracle.........................................................................3-21
Viso V$EVENT_NAME...............................................................................3-22
Vises de Estatsticas de Eventos.............................................................3-23
Viso V$SYSTEM_EVENT...........................................................................3-24
Viso V$SESSION_EVENT..........................................................................3-25
Viso 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
Exerccios 3............................................................................................3-33
TargetTrust Treinamento e Consultoria I

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 Diagnstico para Tuning do Library Cache........................4-9
Cursores esto sendo Compartilhados ?...................................................4-11
Diretrizes: Library Cache Reloads.............................................................4-12
Invalidaes..............................................................................................4-13
Dimensionando o Library Cache...............................................................4-14
Alocao de Espao Global.......................................................................4-15
Grandes Requisitos de Memria...............................................................4-17
Efetuando o Tuning do Espao Reservado da Shared Pool........................4-19
Fixando Objetos Grandes..........................................................................4-21
Blocos PL/SQL Annimos...........................................................................4-22
Outros Parmetros que Afetam o Library Cache.......................................4-23
Data Dictionary Cache, Terminologia e Tuning.........................................4-24
Ferramentas de Diagnstico 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
Exerccios 4............................................................................................4-32
5. Efetuando o Tuning do Database Buffer Cache...........................5-1

Objetivos.....................................................................................................5-2
Caractersticas do Buffer Cache..................................................................5-3
Parmetros de Dimensionamento do Buffer Cache no Oracle 10g.............5-5
Dimensionamento Dinmico da SGA..........................................................5-6
Redimensionando a SGA: Exemplos...........................................................5-8
Prevendo Alteraes no Tamanho da SGA..................................................5-9
Gerenciando o Database Buffer Cache.....................................................5-10
Metas e Tcnicas de Tuning......................................................................5-13
Utilitrios de Diagnstico..........................................................................5-15
Medindo o Cache Hit Ratio........................................................................5-16
Diretrizes para Utilizao do Cache Hit Ratio...........................................5-17
Utilizando Mltiplos Buffer Pools...............................................................5-19
Definindo Mltiplos Buffer Pools...............................................................5-20
Habilitando Mltiplos Buffer Pools............................................................5-21
Diretrizes do Buffer Pool KEEP..................................................................5-22
Calculando o Hit Ratio para Mltiplos Pools..............................................5-23
Identificando Segmentos Candidatos para cada Pool...............................5-24
Vises do Dicionrio com Buffer Pools......................................................5-25
Outros Indicadores de Performance..........................................................5-26
Efetuando o Cache de Tabelas..................................................................5-28
Free Lists...................................................................................................5-29
Diagnosticando Conteno na Free List....................................................5-30
TargetTrust Treinamento e Consultoria II

Resolvendo Conteno de Free List..........................................................5-32

Gerenciamento Automtico de Espao de Segmentos (Automatic Segment
Space Management).................................................................................5-33
Exerccios 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
Utilitrios de Diagnstico para Tuning do Redo Log Buffer.........................6-6
Diretrizes para Tuning do Redo Log Buffer..................................................6-8
Reduzindo Operaes de Redo.................................................................6-11
Gerenciamento Automtico de Memria Compartilhada..........................6-12
Exerccios 6............................................................................................6-13
7. Configurao do Banco de Dados e Detalhes de I/O....................7-1

Objetivos.....................................................................................................7-2
Estatsticas de I/O para Diferentes Tipos de Arquivo Oracle.......................7-3
Utilizao de Tablespace.............................................................................7-4
Gerenciando Tablespaces...........................................................................7-5
Tablespaces com tamanhos de Blocos Diferentes......................................7-6
Distribuindo Arquivos Atravs de Dispositivos............................................7-7
Striping de Arquivos Oracle........................................................................7-8
Efetuando Tuning de Operaes de Full Table Scan....................................7-9
Utilitrios de Diagnstico para Verificar Estatsticas de I/O......................7-11
Estatsticas de I/O.....................................................................................7-12
Grupos e Membros de Redo Log...............................................................7-13
Configurao de Archive Log File..............................................................7-15
Checkpoints..............................................................................................7-17
Diretrizes para Tuning de Checkpoint.......................................................7-18
Mltiplos I/O Slaves...................................................................................7-20
Parmetros de Inicializao......................................................................7-21
Mltiplos Processos DBWn........................................................................7-22
Exerccios 7............................................................................................7-23
8. Utilizando Blocos Oracle Eficientemente....................................8-1

Objetivos.....................................................................................................8-2
Hierarquia de Armazenamento do Banco de Dados...................................8-3
Alocando uma Extenso.............................................................................8-4
Evitando a Alocao Dinmica....................................................................8-5
Evitando as Desvantagens da Alocao Dinmica.....................................8-6
Prs e Contras de Extenses Grandes........................................................8-7
Tamanho de Bloco do Banco de Dados.......................................................8-9
Tamanho de Bloco Oracle (DB_BLOCK_SIZE)............................................8-10
Prs e Contras de Tamanho de Bloco Pequeno.........................................8-11
Prs e Contras de Tamanho de Bloco Grande...........................................8-12
PCTFREE e PCTUSED.................................................................................8-13
Diretrizes de PCTFREE e PCTUSED............................................................8-15
Migrao (Migration) e Encadeamento (Chaining)....................................8-16
Detectando o Encadeamento e Migrao.................................................8-17
TargetTrust Treinamento e Consultoria III
Selecionando Linhas Migradas e Encadeadas...........................................8-18

High Water Mark.......................................................................................8-19
Estatsticas de Tabelas..............................................................................8-20
Package DBMS_SPACE..............................................................................8-21
Reorganizao de ndices.........................................................................8-22
Monitorando ndices.................................................................................8-23
Exerccios 8............................................................................................8-25
9. Otimizando Operaes de Sort..................................................9-1

Objetivos.....................................................................................................9-2
Operaes que Necessitam de Sort............................................................9-3
Processo de Ordenao..............................................................................9-5
rea de Sort e Parmetros..........................................................................9-6
Outros Parmetros para rea de Sort.........................................................9-9
Processo de Sort e Espao Temporrio.....................................................9-10
Segmento de Espao Temporrio.............................................................9-11
Efetuando o Tuning de Ordenaes..........................................................9-12
Evitando Ordenaes................................................................................9-13
Utilitrios de Diagnstico..........................................................................9-15
Diagnsticos e Diretrizes..........................................................................9-17
Monitorando Tablespaces Temporrias.....................................................9-18
Configurando Tablespaces Temporrias....................................................9-19
Exerccios 9............................................................................................9-21
10.Latches.................................................................................10-1
Objetivos...................................................................................................10-2
Latches: Viso Geral.................................................................................10-3
Procedimento de Requisio e Espera por Latches..................................10-5
Tipos de Requisies por Latches.............................................................10-6
Diagnosticando Problemas de Conteno 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
Alterao de Tablespace de Undo.............................................................11-5
Utilizao de Segmentos de Undo............................................................11-6
Obtendo Informaes sobre Segmentos de Undo.....................................11-7
Estatsticas dos Segmentos de Undo........................................................11-8
Atividade Atual nos Segmentos de Undo................................................11-10
Monitorando o Gerenciamento Automtico de Undo..............................11-11
Diretrizes: Utilizando Menos Undo..........................................................11-12
Problemas com Segmentos de Undo......................................................11-13
Erro de Leitura Consistente....................................................................11-14
Exerccios 11........................................................................................11-15
12.Tuning de SQL........................................................................12-1
Objetivos...................................................................................................12-2
Viso Geral...............................................................................................12-3
Modos de Otimizao...............................................................................12-4
TargetTrust Treinamento e Consultoria IV
Configurando o Modo de Otimizao........................................................12-5

Ferramentas de Diagnstico.....................................................................12-6
Explain Plan..............................................................................................12-7
Exemplo de Plano de Execuo................................................................12-8
Diagnosticando a Performance de Comandos SQL...................................12-9
Parmetros de Inicializao Importantes................................................12-10
Ligando e Desligando o Trace.................................................................12-11
Formatando o Arquivo de Trace..............................................................12-12
Estatsticas 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 Mdulo..........................................................................12-18
Registrando um Mdulo..........................................................................12-19
Rastreando um Mdulo...........................................................................12-20
Obtendo Informaes do Dicionrio.......................................................12-21
Exerccios 12........................................................................................12-22
13.Consideraes de Tuning para Diferentes Aplicaes................13-1

Objetivos...................................................................................................13-2
Viso Geral...............................................................................................13-3
Processamento de Transaes Online.......................................................13-4
Sistemas de Suporte a Deciso (DSS)......................................................13-5
Aplicaes com Mltiplos Propsitos........................................................13-6
Escolhendo a Estrutura Fsica Mais Adequada..........................................13-7
Mtodos 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 Funes................................................................13-22
Vises do Dicionrio...............................................................................13-23
Clusters...................................................................................................13-24
Particionamento......................................................................................13-25
Exemplo de Particionamento por Intervalo.............................................13-26
Exemplo de Particionamento por Lista...................................................13-27
Acessos s Parties...............................................................................13-28
Histogramas...........................................................................................13-29
Requisitos para OLTP..............................................................................13-31
Detalhes sobre Aplicaes OLTP.............................................................13-32
Requisitos para DSS................................................................................13-33
Detalhes sobre Aplicaes DSS..............................................................13-34
Sistemas Hbridos...................................................................................13-35
TargetTrust Treinamento e Consultoria V

14.Tuning do Sistema Operacional...............................................14-1

Objetivos...................................................................................................14-2
Introduo................................................................................................14-3
Configuraes Multi-CPU...........................................................................14-4
Paging e Swapping...................................................................................14-5
Tuning de Memria...................................................................................14-6
Tuning de I/O.............................................................................................14-7
Diretrizes para Tuning de CPU..................................................................14-8
Processos e Threads.................................................................................14-9
Diretrizes................................................................................................14-10
Apndice - Resoluo dos Exerccios.................................................1

Solues Exerccios 1.....................................................................................2
Solues Exerccios 6...................................................................................11
Solues Exerccios 11.................................................................................18
Solues Exerccios 12.................................................................................20
TargetTrust Treinamento e Consultoria VI

1. Viso Geral sobre Tuning
TargetTrust Treinamento e Consultoria 1

Viso 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.

Questes 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 dvida, a melhor prtica de tuning ter cuidado no design dos
sistemas e aplicaes e a maioria dos ganhos de performance percebida
atravs do tuning da aplicao.
menos provvel que voc tenha problemas de performance se:
O hardware pode satisfazer demandas de usurio.
Seu banco de dados Oracle 10g foi cuidadosamente desenhado.
Seus desenvolvedores de aplicao escrevem programas SQL
eficientes.
Se decises erradas forem feitas cedo, ou se os usurios 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 comear o tuning com uma idia clara do que voc est
tentando alcanar. Tente quantificar isto o mais precisamente possvel, em
condies reais. Por exemplo:
Processar 10,000 pedidos por dia.
Produzir 250,000 lanamentos de faturamento durante a noite no
final do ms.
Neste curso, descrevemos freqentemente os objetivos de tuning do
Oracle 10g, mas em ltima instncia estes devem beneficiar os usurios. No
h nenhum ponto em efetuar uma pequena melhoria no uso do database
buffer cache se todos os usurios esto acessando os dados atravs de uma
rede lenta em PCs antigos. Neste caso, seus esforos de tuning no sero
notados.
Tuning um processo repetitivo. No uma atividade que voc efetua
uma vez e ento esquece.

Metas de Tuning
Suas metas primrias ao efetuar tuning em um servidor Oracle 10g so
para garantir que:
Comandos SQL acessem o menor nmero possvel de blocos Oracle.
Se um bloco for necessrio, ento que esteja no cache em memria.
Usurios compartilhem o mesmo cdigo.
Quando o cdigo for necessrio, que esteja no cache em memria.
Onde leituras e escritas forem inevitveis, que sejam efetuadas o
mais rpido possvel.
Usurios nunca esperem por recursos presos por outros usurios.
Backups e outras administraes internas possam ser efetuadas o
mais rpido possvel.

Exemplos de Metas de Tuning Mensurveis

Tempo de resposta.
Disponibilidade do banco de dados.
Percentuais de utilizao do banco de dados.
Utilizao de memria.
Quando estiver efetuando o tuning de um ambiente de banco de dados
Oracle 10g o DBA deve estabelecer metas de tuning mensurveis. Sem isto,
ser difcil determinar quando o tuning ter atingido um nvel satisfatrio.
Tempo de resposta a quantidade de tempo que demora para um usurio
receber dados a partir de uma requisio, como por exemplo, o resultado de
uma consulta, ou o tempo que leva para atualizar uma tabela ou gerar um
relatrio.
Disponibilidade do banco de dados tambm uma boa medida para
metas de tuning. A disponibilidade do banco de dados pode sofrer impactos
devido a operaes de backup e recovery ou no shutdown e startup da
instncia para alterao de parmetros.
Percentuais de utilizao (hit percentage) do banco de dados fornecem
bons fundamentos para determinar se a performance est aumentando ou
diminuindo com o passar do tempo.
A utilizao de memria tambm uma medida vlida, uma vez que
operaes excessivas de paginao e swapping podem impactar na
performance do banco de dados e do sistema operacional. A utilizao de
memria pode tambm impactar nos percentuais de utilizao do banco de
dados.

Fases de Tuning
O tuning pode ser dividido em quatro fases:

Design da aplicao e programao:
Sempre que possvel, o tuning deveria comear nessa fase. Com um bom
design, muitos problemas no ocorrem. Por exemplo, a normalizao excessiva
das tabelas pode gerar um nmero grande de joins. Portanto, algumas
desnormalizaes deveriam ser feitas.
Configurao do banco de dados:
importante monitorar pontos crticos, mesmo tendo discos rpidos. Voc
deveria planejar a configurao de dados de forma a acelerar o tempo de
recovery e o acesso aos dados.
Adio de nova aplicao:
Ao adicionar uma nova aplicao ao sistema, a carga de trabalho muda.
Qualquer mudana na carga de trabalho deveria ser acompanhada de tuning.
Tuning contnuo:
Essa a metodologia recomendada para bancos de dados em produo.
Consiste em procurar por gargalos e elimin-los. Use ferramentas para
identific-los. Examinando os relatrios gerados voc pode formar hipteses
sobre o que est causando o gargalo. A partir da hiptese, voc pode
desenvolver uma soluo e implement-la. Execute um teste de stress no
banco para verificar se o problema foi resolvido.

Passos do Tuning
A ordem recomendada para implementao de tuning a seguinte:
1. Design (se no for tarde demais).
2. Aplicao.
3. Memria.
4. I/O.
5. Conteno.
6. Sistema operacional.
Repita o processo se suas metas no forem atingidas.
A razo para esta estrutura que melhorias feitas cada vez mais cedo na
seqncia podem evitar que se deva lidar com outros problemas mais tarde.
Por exemplo, se suas aplicaes estiverem utilizando muitos full table
scans, isto pode aparecer como I/O excessivo. Entretanto, no 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 invs de quatro mil.
Os dois primeiros passos so tipicamente de responsabilidade dos
arquitetos do sistema e desenvolvedores da aplicao. Entretanto, o DBA pode
tambm ser envolvido no tuning da aplicao.

Desempenho versus Segurana
Fatores que afetam o desempenho:

Mltiplos control files
Mltiplos membros nos grupos de redo log
Checkpoints freqentes
Backups de datafiles
Arquivamento de redo log files
Nmero de usurios e transaes concorrentes
H sempre uma troca feita por desempenho. De forma a aumentar o

desempenho do sistema, algum outro aspecto ser afetado de forma inversa.
Freqentemente o tempo de recovery afetado. Quanto mais seguro o DBA faz
o banco, mais lento este fica.
A deciso deve ser feita levando em considerao quo seguro o banco
deve ser e que nvel de desempenho necessrio: quantos usurios
concorrentes devem acessar o banco, quantas transaes por segundo devem
ser feitas, etc.

Exerccios 1
1. Siga as instrues do instrutor para a criao do banco de dados.
2. Crie uma instncia do Enterprise Manager para o banco de dados.

Espao para anotaes

2. Oracle Alert e Arquivos de

Trace

Oracle Alert e Arquivos de Trace
Objetivos
Identificar a localizao e a utilidade do arquivo de alert log.
Identificar a localizao e a utilidade dos arquivos de trace de
processos background e de usurio.

Informaes de Diagnstico
Arquivos de Trace:
Arquivo de alert log.
Arquivos de trace de processos background.
Arquivos de trace de usurio.
Arquivo Alert Log

Se um erro ocorre enquanto sua instncia Oracle estiver executando, as
mensagens so escritas para o arquivo alert log. Durante o startup do banco
de dados, se o arquivo alert log no existir, o servidor Oracle o criar.
O arquivo alert log de um banco de dados um log cronolgico de
mensagens e erros. O servidor Oracle utiliza o arquivo alert log como uma
alternativa para exibir tais informaes.
Arquivos de Trace de Processos Background

Se um erro for detectado por um processo background, a informao sofre
um dump para um arquivo de trace.
Arquivos de Trace de Usurio

Arquivos de trace podem tambm ser gerados por processos servidores
quando requisitado pelo usurio para exibir o consumo de recursos durante o
processamento de comandos.

Arquivo Alert Log

importante que o administrador do banco de dados verifique o arquivo
alert log periodicamente para detectar problemas antes que se tornem srios.
As seguintes informaes so registradas no arquivo de alert log:
Erros internos (ORA-00600) e erros de corrupo de bloco (ORA-
01578).
Operaes que afetem estruturas e parmetros do banco de dados,
e comandos como CREATE DATABASE, STARTUP, SHUTDOWN,
ARCHIVE LOG e RECOVER.
Os valores de todos os parmetros de inicializao no default no
momento do startup da instncia.

Starting up ORACLE RDBMS Version: 10.1.0.2.0.

System parameters with non-default values:
processes = 250
sga_max_size = 88080384
shared_pool_size = 71303168
java_pool_size = 4194304
control_files = /oracle/oradata/tuning/control01.ctl,
/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 =
instance_name = tuning
service_names = tuning
dispatchers = (PROTOCOL=TCP) (SERVICE=tuningXDB)
job_queue_processes = 10
background_dump_dest = /oracle/admin/tuning/bdump
user_dump_dest = /oracle/admin/tuning/udump
core_dump_dest = /oracle/admin/tuning/cdump
sort_area_size = 65536
db_name = tuning
open_cursors = 300
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 MOUNT
Tue Jan 4 10:26:19 2005
ALTER DATABASE OPEN
Figura 2-1 : Exemplo de arquivo alert_<SID>.log

Tue Jan1 4
Thread 10:15:53
advanced to2005
log sequence 76
create
Currenttablespace DATA76 mem# 0: /oracle/oradata/tuning/redo01a.log
log# 1 seq#
datafile
Thread 4'/oracle/oradata/tuning/data01.dbf'
Tue Jan1 cannot 2005 new log, sequence 76 size 300M reuse
allocate
10:50:19
EXTENT
Checkpoint
alter MANAGEMENT LOCAL online
not complete
tablespace user_data begin backup
Tue
Tue Jan
Jan 44 10:16:03
10:50:19 2005
2005
ORA-1123 signalled
Completed: create tablespace SYSTEM
during: alter datafile user_data begin backup
tablespace
'/oracle/oradata/tuning/system01.dbf'
...
Backups de controlfile e online tablespace.

Checkpoints no completados devido ao switch muito rpido dos
redo log files.
Criao de tablespaces.
Uma vez que este arquivo cresce e acaba ocupando espao em disco,
copie e remova-o freqentemente, ou diminua seu tamanho periodicamente.

Controlando o Arquivo de Alert Log
Figura 2-2: Configurando o destino do arquivo alert log
O seguinte parmetro do init<SID>.ora controla a localizao do arquivo

alert log:
BACKGROUND_DUMP_DEST
O nome do arquivo alert_<SID>.log.

BACKGROUND_DUMP_DEST
Controlando Arquivos de Trace de Processos

Background
Figura 2-3: Configurando o destino dos arquivos de trace
O seguinte parmetro do init<SID>.ora controla a localizao 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_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

Arquivos de Trace de Usurio

SQL> ALTER SESSION SET sql_trace=TRUE;
Trace de processo servidor habilitado ou desabilitado em nvel de

sesso ou instncia pelo:
Comando ALTER SESSION.
Procedure SET_SQL_TRACE_IN_SESSION.
Parmetro de inicializao SQL_TRACE.
Um arquivo de trace de usurio contm estatsticas dos comandos

SQL de uma sesso.
Um arquivo de trace de usurio til para tuning de SQL.
O Oracle cria um arquivo de trace de usurio por processo servidor.
Arquivos de trace de usurio podem tambm ser gerados por um processo
servidor quando requisitado por um usurio ou DBA.
Trace em Nvel de Instncia

Este registro de trace habilitado ou desabilitado pelo parmetro de
inicializao SQL_TRACE. O valor default FALSE.
SQL> EXECUTE dbms_system.set_sql_trace_in_session(8,12,TRUE);
Trace em Nvel de Sesso

O seguinte comando habilita a escrita para um arquivo de trace para uma
sesso particular:
Onde: 8 e 12 representam o SID e SERIAL# do usurio conectado,

respectivamente.
A package DBMS_SYSTEM criada no Servidor Oracle pelo script
localizado no diretrio $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
sesso do usurio conectado:

SQL> alter session set sql_trace=true;
Sesso alterada.
SQL> select id, nome from aluno.tclientes where id = 130;
ID NOME
---------- -----------------------------------
130 Ramiro Antunes
Controlando os Arquivos de Trace de Usurio
Figura 2-4: Configurando o destino dos arquivos de trace de usurio
Os seguintes parmetros de inicializao controlam a localizao e o

tamanho dos arquivos de trace de usurio, onde:
USER_DUMP_DEST define onde os arquivos de trace devem
ser criados quando requisitados pelos
usurios ou DBA.
MAX_DUMP_FILE_SIZE especificado em blocos do sistema
operacional, limita o tamanho dos arquivos
de trace de usurio.
O nome do arquivo ora_<PID>.trc.
Exemplos:
Habilitando trace em uma sesso:


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
Viso parcial do arquivo de trace de usurio resultante

(tuning_ora_24484.trc):
Nota: MAX_DUMP_FILE_SIZE e USER_DUMP_DEST so parmetros de
inicializao dinmicos.

Exerccios 2
A meta destes exerccios familiarizar voc com a configurao da
mquina, e focar os utilitrios de diagnstico, como os arquivos de trace e as
vises de eventos de espera.
1. Conecte-se como sysdba.

2. Consulte os parmetros para localizar o arquivo de alert log e os
arquivos de trace de usurio 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 usurio. Consulte a viso DBA_TABLES do dicionrio de dados
e quaisquer outras consultas que deseje. Finalize o trace.
5. Examine o arquivo de trace resultante, sem se preocupar com seu
contedo, pois isto ser discutido em um captulo posterior.

Espao para anotaes


3. Utilitrios e Vises de
Performance Dinmicas

Utilitrios e Vises de Performance Dinmicas
Objetivos
Coletar estatsticas atravs:
De vises dinmicas de performance e soluo de problemas.
Do relatrio gerado por STATSPACK.
Eventos de espera Oracle.

Vises, Utilitrios e Ferramentas
Vises Dinmicas e do Dicionrio

O servidor Oracle exibe todas as estatsticas de sistema na viso
V$SYSSTAT, e utiliza vrias outras vises para informaes sobre performance
e para soluo de problemas. Voc pode consultar estas vises para encontrar
totais cumulativos desde o startup da instncia, mas isto freqentemente de
pouca ajuda; se sua instncia raramente sofre um shutdown, as estatsticas
podem referir-se a um longo perodo e possuir pouco significado.
O Oracle exibe estatsticas sobre o armazenamento de dados nas vises
DBA_xxx que podem ajud-lo na soluo de problemas de storage dos
segmentos (tabelas, clusters, ndices e parties).
Scripts UTLBSTAT e UTLESTAT

Voc deve recolher informaes de performance sobre um perodo
definido, provavelmente o momento de maior utilizao do dia ou ento no
final do ms, e produzir um relatrio.
Voc pode efetuar isto com os scripts utlbstat.sql e utlestat.sql.
Consultores experientes normalmente iniciam um projeto de tuning
utilizando este utilitrio para capturar dados.
Utilitrio STATSPACK
Similar em essncia a utlbstat e utlestat, serve para coletar estatsticas de
perodos de tempo e armazen-las no banco de dados. Isso permite que sejam
comparadas estatsticas de diferentes intervalos de tempo, atravs de vrias
fotografias (snapshots) tiradas do banco. Tambm permite gerar um relatrio
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 vises do dicionrio exibem os eventos para aquelas sesses que
tiveram que esperar.
Aplicaes do Oracle Diagnostics and Tuning Packs

Voc pode tambm utilizar as ferramentas grficas da Oracle fornecidas
com o Oracle Diagnostics and Tuning Packs, um conjunto de aplicaes
windows-based dirigidas a vrias reas de gerenciamento de performance
Oracle, como monitoramente grfico, anlises e tuning automatizado de
bancos de dados Oracle.

Vises Especiais e do Dicionrio de Dados

Quando voc necessita visualizar o armazenamento de dados em
detalhes, voc deve utilizar o comando ANALYZE, que coleta estatsticas e
preenche colunas de vises DBA_xxx e especiais.
O comando ANALYZE preenche colunas nas vises que abrangem:
Armazenamento de dados em tabelas dentro de extenses e blocos:
DBA_TABLES
DBA_TAB_COLUMNS
Armazenamento de dados em clusters dentro de extenses e blocos:
DBA_CLUSTERS
Armazenamento de dados em ndices dentro de extenses e blocos,
e utilizao de ndices:
DBA_INDEXES
INDEX_STATS
Distribuio de dados em colunas no indexadas e indexadas:
DBA_TAB_HISTOGRAMS
INDEX_HISTOGRAM
Tambm podemos usar a package DBMS_STATS, descrita em detalhes no

captulo "Utilizando Blocos Oracle Eficientemente".

Vises Dinmicas de Performance e Soluo de

Problemas
Vises V$
Baseadas nas tabelas X$, que so estruturas de memria que
armazenam informaes sobre a instncia e portanto esto
disponveis quando a instncia estiver no modo NOMOUNT ou
MOUNT.
So listadas na viso V$FIXED_TABLE.
As vises V$ (sinnimos para as vises V_$) pertencem ao usurio
SYS.
Tabelas X$
Normalmente no so consultadas diretamente; nem todas as
informaes so necessariamente teis, e os nomes de colunas
tendem a ser abreviados e obscuros.
As tabelas X$ so dinmicas, e seu contedo est constantemente
sendo modificado.
As vises V$, e as tabelas X$ que esto por trs delas, so
preenchidas na inicializao da instncia e limpas no shutdown.
Armazenam informaes de tempo se voc configurar o parmetro
TIMED_STATISTICS do init<SID>.ora para TRUE ou executar o
comando SQL:
SQL> ALTER SYSTEM SET timed_statistics=TRUE;

Tpicos para Soluo de Problemas e Tuning
Figura 3-1: Tpicos para soluo de problemas e tuning
Estatsticas de Sistema
Vises pertinentes a instncia/banco de dados:
V$PX_PROCESS_SYSSTAT: estatsticas de sistema de parallel query.
V$PROCESS: informaes sobre os processos atualmente ativos.
V$WAITSTAT: estatsticas de contenes.
V$SYSTEM_EVENT: total de esperas para eventos especficos.
Vises pertinentes a memria:
V$BUFFER_POOL_STATISTICS: alocao de buffer pools na instncia
(criada pelo script $ORACLE_HOME/rdbms/admin/catperf.sql).
V$DB_OBJECT_CACHE: objetos do banco de dados que esto em
cache no library cache.
V$LIBRARYCACHE: estatsticas de performance e atividade do library
cache.
V$ROWCACHE: atividade de hits e misses do data dictionary.
V$SYSSTAT: estatsticas bsicas da instncia.
Vises pertinentes a performance de disco:
V$FILESTAT: estatsticas de leitura/escrita em data files.
V$TEMPSTAT: informaes sobre estatsticas de leitura/escrita em
data files de tablespaces temporrias.
Vises pertinentes a conteno:

V$LATCH: estatsticas para cada tipo de latch.
V$ROLLSTAT: estatsticas para todos os segmentos de undo online.
V$WAITSTAT: estatsticas de conteno de bloco (o parmetro
TIMED_STATISTICS do init<SID>.ora deve estar configurado para
TRUE).
Estatsticas de Sesso
V$LOCK: locks atualmente mantidos pelo servidor.
V$OPEN_CURSOR: cursores atualmente abertos e compilados
(parsed) para cada sesso.
V$SORT_USAGE: tamanho de segmentos temporrios e sesses que
os criaram; identificao dos processos que esto efetuando
ordenaes em disco.
V$SESSTAT: estatsticas da sesso do usurio.
V$SESSION_EVENT: informaes sobre as esperas por um evento
para uma sesso.
V$SESSION_WAIT: recursos ou eventos pelos quais as sesses ativas
esto aguardando.
V$PX_SESSTAT: informaes sobre as sesses utilizando execuo
em paralelo.

Coletando Estatsticas de Sistema
Figura 3-2: Coletando estatsticas de sistema
Estatsticas Genricas de Sistema

Todos os tipos de estatsticas de sistema esto catalogados na viso
V$STATNAME: cerca de 290 estatsticas esto disponveis.
O servidor Oracle exibe todas as estatsticas de sistema calculadas na
viso V$SYSSTAT. Voc pode consultar esta viso para encontrar totais
cumulativos desde o startup da instncia.
Exemplo:

SQL> SELECT *
name,
FROMclass,
v$sgastat;
value FROM v$sysstat;
POOL
NAME NAME CLASS VALUE BYTES
---------------------
------------ --------------------------
------- ----------------------
db block getsfixed_sga 8 7687 777556
consistent gets
buffer_cache 8 17547 8388608
physical reads
log_buffer 8 763 262144
sessionpool
shared uga memory
free memory 1 1312236 4192704
sessionpool
shared pga memory
pl/sql source 1 57634176 19576
sorts (memory)
shared pool sessions 64 497 1284644
sorts (disk)
shared pool sql area 64 013103560
sorts (rows) 64 605
So classificadas por tpicos de tuning:

Class 1 refere-se a atividade geral da instncia.
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 paralelizao.
Class 64 refere-se aos acessos de tabelas.
Class 128 refere-se a propsitos de debug.
Estatsticas Globais da SGA

O servidor Oracle exibe todas as estatsticas de memria calculadas na
viso V$SGASTAT. Voc pode consultar esta viso para encontrar totais
cumulativos da utilizao detalhada da SGA desde o startup da instncia.
Exemplo:
Estatsticas de Eventos de Espera

Todos os tipos de eventos de espera esto catalogados na viso
V$EVENT_NAME: cerca de 286 estatsticas esto disponveis.
Estatsticas acumuladas para todas as sesses so armazenadas em
V$SYSTEM_EVENT: esta exibe os totais de esperas para um evento especfico
desde o startup da instncia.
Se voc estiver solucionando um problema, voc necessita saber quando
um processo esperou por algum recurso.

Coletando Estatsticas de Sesso
Figura 3-3: Coletando estatsticas de sesso
Estatsticas Genricas de Sesso
Dados de sesso so cumulativos desde o momento da conexo. Voc

pode exibir informaes atuais da sesso para cada usurio conectado. Outra
viso, V$MYSTAT, exibe as estatsticas da sesso corrente.
Exemplo: determine o tipo de conexo que os usurios 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

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, message
252 SQL*Net value from client
2 FROM v$statname
253 SQL*Net messages,from
n, v$session v$sesstat
client t
3 WHERE s.sid254
= t.sid
SQL*Net message from client
4 AND n.statistic# = t.statistic#
255 SQL*Net message from client
5 AND s.type 256
= 'USER'
SQL*Net message from client
6 AND s.username is not
257 wait fornull
unread message on broadcast channel
7 AND n.name = 'session pga memory'
8 AND t.value > 1000000;
USERNAME NAME VALUE

------------------------------ ------------------------------ ----------
DBSNMP session pga memory 1022540
SYSMAN session pga memory 1350220
O servidor Oracle exibe todas as estatsticas de sesso calculadas na

viso V$SESSTAT. Voc pode consultar esta viso para encontrar os totais
cumulativos de sesso desde o startup da instncia.
Exemplo: determine as sesses que consomem mais de 1000000 bytes
de memria para a pga.
Estatsticas de Eventos de Espera de Sesso

A viso V$SESSION_EVENT exibe por sesso, os totais de esperas para um
evento especfico desde o startup da instncia.
A viso V$SESSION_WAIT lista os recursos ou eventos pelos quais as
sesses ativas esto aguardando.
um processo esperou por algum recurso. A estrutura da V$SESSION_WAIT torna
fcil a verificao em tempo real se qualquer sesso est aguardando, e se
estiver, o porqu da espera.
Voc pode ento investigar mais adiante para visualizar se tais esperas
ocorrem com freqncia e se esto correlacionadas com outros fenmenos,
como o uso de mdulos especficos.

Scripts UTLBSTAT e UTLESTAT

Coletam informaes de performance sobre um perodo definido.
Produzem um relatrio 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 vises dinmicas exibem totais cumulativos desde o startup da
instncia, mas isto freqentemente de pouca ajuda; se sua instncia
raramente sofre shutdown, as estatsticas podem cobrir um longo perodo e
possurem pouco significado.
Voc deve coletar informaes de performance sobre um perodo definido,
provavelmente seu perodo de maior utilizao do dia ou final do ms, e
produzir um relatrio.
Voc pode efetuar isto com os scripts utlbstat.sql e utlestat.sql,
armazenados no diretrio $ORACLE_HOME/rdbms/admin no UNIX e
%ORACLE_HOME%\rdbms\admin no Windows.
O script utlestat tambm gera um relatrio (em arquivo) no diretrio
corrente. Ele contm as estatsticas do perodo apurado, feitas atravs das
diferenas entre as estatsticas do incio e do final do perodo.
Nota: STATSPACK prov estatsticas mais claras

STATSPACK
A package STATSPACK pode ser instalada a partir do script spcreate.sql,
presente no diretrio $ORACLE_HOME/rdbms/admin/, e consome inicialmente
cerca de 80Mb de espao na tablespace default do usurio perfstat. Porm o
espao necessrio pode aumentar a medida que a package for utilizada.
O script cria o usurio Perfstat, as tabelas do statspack, suas constraints
e a package STATSPACK. Durante a instalao requisitado o nome das
tablespaces default e temporria desse usurio.
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 usurio Perfstat, e execute a procedure STATSPACK.snap.
Isso armazenar nas tabelas de STATSPACK os valores estatsticos de
desempenho.
Tire outra fotografia do banco a cada dia, semana, ms ou ano, para
comparar os perodos desejados. O melhor mtodo automatizar a coleta de
estatsticas 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.
Relatrio de STATSPACK
Para examinar as mudanas nas estatsticas entre dois momentos,
execute o script spreport.sql conectado com o usurio Perfstat. Ser mostrada
uma lista de perodos de coleta e pedido os perodos inicial e final. O relatrio
com as diferenas entre estes perodos ser calculado e gravado em um
arquivo com o nome indicado pelo usurio.

Resultados do Relatrio de STATSPACK
Primeira pgina do relatrio

A primeira pgina resume o relatrio. Os itens dessa pgina incluem a
maioria das informaes 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. Tambm mostra o tamanho primrio de bloco (DB_BLOCK_SIZE).
Load Profile
Valores dados por segundo e por transao. So mostrados tamanho de
redo, leituras e escritas fsicas feitas durante o perodo analisado.
Instance Efficiency Percentages
Os itens aqui mostrados so os mais comumente usados para tuning de
performance. O objetivo ter todas as percentagens em 100%, ou to prximo
quanto possvel. 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 relatrio,
e sero tratadas depois no curso. Essa lista mostra os eventos de maior
conteno.
O resto do documento
O relatrio feito por STATSPACK melhor do que aquele feito por
UTLBSTAT/ UTLESTAT, pois resume as informaes 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
importncia (os mais problemticos aparecem primeiro).
Informaes sobre os comandos SQL presentes atualmente
na Shared Pool. Vrias listas de comandos aparecem aqui,
ordenadas por nmero de execues, compilaes (parse calls),
buffers lidos e nmero de leituras. Listagens nessas ordens facilitam
a identificao dos comandos mais "caros" ao sistema, e aqueles
que devem ser analisados primeiro.
Estatsticas de segmentos de Undo.
Estatsticas da SGA. Duas listas: um resumo e uma lista detalhada
por rea da memria.
Valores iniciais dos parmetros do init<SID>.ora. Como
existem parmetros dinmicos no banco, no h garantias de que
esses sejam os valores usados atualmente.

SQL>
SQL> create table stats$begin_stats as select * from
@$ORACLE_HOME/rdbms/admin/utlbstat.sql
2 v$sysstat where 1=0;
SQL> create table stats$end_stats as select * from
2 stats$begin_stats;
Coletando Estatsticas
Figura 3-4: Coletando estatsticas
Inicie a Coleta de Estatsticas

O script cria as tabelas BEGIN e END e obtm uma imagem dos dados das
vises de performance dinmica (V$xxx) para coletar as estatsticas 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

SQL>SQL>
create
@$ORACLE_HOME/rdbms/admin/utlestat.sql
insert
table
into
stats$stats
stats$end_latch
as select
select
e.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 Estatsticas

O script obtm uma nova imagem dos dados das vises de
performance dinmica (V$xxx) para coletar as estatsticas 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
subtrao dos resultados das estatsticas iniciais a partir das
estatsticas finais.
O script remove todas as vises e tabelas temporrias.
O script gera um relatrio selecionando os dados a partir das tabelas
DIFFERENCE.
Nota: o script conecta-se como SYSDBA e cria tabelas na tablespace
default do usurio SYS, ou seja, SYSTEM. Antes de executar o script, crie uma
nova tablespace para este propsito, e modifique a tablespace default do
usurio SYS para esta nova tablespace. Ao finalizar a execuo dos 2 scripts,
modifique a tablespace default do usurio SYS de volta para SYSTEM.

SQL> spool report.txt

Statistic Total Per Trans Per Logon
SQL> select ... from stats$lib;
--------------------------- --------- --------- ---------
DBWR checkpoint
consistent gets buffers wri 559715
219 1168.51
.46 25441.59
9.95
DBWR
db block
checkpoint
gets write reque 9949
159 20.77
.33 452.23
7.23
physical reads 419280 875.32 19058.18
Relatrio de Estatsticas
Report.txt
O relatrio gerado pelo script utlestat.sql contm uma seqncia de
comandos SELECT sobre as tabelas DIFFERENCE.
Estatsticas do Library Cache

O library cache contm 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 esto afetando a performance do Oracle.
Estatsticas de Sistema
Esta seo do relatrio fornece para cada estatstica de sistema, um
nmero total de operaes, o nmero total de operaes por commit de
usurio e por logon. Isto ajuda voc a efetuar o tuning de diversas reas.
Exemplo 1: DBWR Checkpoints
DBWR Checkpoints indicam o nmero 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 nmero e/ou freqncia do checkpoint aumentando o parmetro
do init.ora LOG_CHECKPOINT_INTERVAL e LOG_CHECKPOINT_TIMEOUT.
Entretanto, fique atento que checkpoints infreqentes aumentam o tempo de
recovery do banco de dados.
Exemplo 2: Consistent Gets, DB Blocks Gets, Physical Reads
Consistent Gets o nmero de blocos acessados do buffer cache para

consultas sem a clusula FOR UPDATE.
DB Block Gets o nmero de blocos acessados do buffer cache para
comandos INSERT, UPDATE e SELECT FOR UPDATE.
A soma destes representa o nmero de leituras lgicas.
Physical Reads o nmero de requisies por um bloco que causou I/O
fsico.

Voc calcula o hit ratio para detectar se o tamanho do database buffer

cache suficientemente grande ou se freqentemente no consegue manter
os blocos lidos em memria.
Estatsticas de Eventos de Espera

Cada evento de espera de sistema uma troca de contexto que custa
tempo de CPU. Observando o Total Time, voc freqentemente pode
determinar qual o gargalo pelo qual os processos esto tendo de aguardar.
Estatsticas 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 conteno para alocao
de latches.
Estatsticas de Espera por Buffer Busy

Esta pequena seo indica, se o evento de espera buffer busy wait for
alto, quais classes de blocos esto tendo alto nvel de conteno: bloco de
dado, header de segmento ou header de undo.
Estatsticas do Dictionary Cache

Cada comando SQL ou PL/SQL implica em acesso para os objetos do
dicionrio, e portanto ao cache do dicionrio. Misses no cache do dicionrio
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 seo exibe os gets e os misses para cada tipo de item que est no
cache.
Estatsticas de I/O por Datafile/Tablespace

Esta seo exibe como o I/O de arquivo foi dividido atravs dos discos,
contando o nmero de leituras/escritas fsicas, leituras/escritas fsicas de
blocos e a quantidade de tempo despendido para estas operaes por cada
datafile e tablespace.
Perodo de Medio
Esta seo exibe o momento em que o script utlbstat iniciou a coleta das
estatsticas begin e quando o utlestat iniciou a coleta das estatsticas end.

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.
Estatsticas do Library Cache

Este um exemplo da primeira seo do report.txt.

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

WRITES BLKS_WRT WRITE_TIME MEGABYTES AVG_RT blocks/rd
--------------- --------------------------------------- ---------- ---------- -----
----- ---------- ---------- ---------- ---------- ---------- ----------
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.
Estatsticas de I/O
Este um exemplo da ltima seo do report.txt.

Eventos de Espera Oracle

A viso V$EVENT_NAME lista uma coleo de eventos de espera que
fornecem informaes sobre as sesses que tiveram que aguardar para serem
processadas:
EVENT#
NAME
PARAMETER1
PARAMETER2
PARAMETER3
Existem mais de 290 eventos de espera no servidor Oracle. Estes eventos
so listados na viso 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

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 file# block# id
library cache pin handle addr pin address 0*mode+name
log buffer space
log file switch
(checkpoint incomplete)
transaction undo seg# wrap# count
...
808 linhas selecionadas.
Viso V$EVENT_NAME
Parmetros que Descrevem um Evento de Espera

Exemplo 1: o evento de espera Buffer Busy Wait aguarda at que um
buffer torne-se disponvel. Este evento ocorre quando um buffer lido no
buffer cache por outra sesso (e a sesso est aguardando que a leitura se
complete), ou est no buffer cache, mas em um modo incompatvel (ou seja,
alguma outra sesso est modificando o buffer).
Este evento complementado com trs parametros:
FILE# e BLOCK#: estes parmetros identificam o nmero do bloco no
data file que est identificado pelo nmero de arquivo para o bloco
pelo qual o servidor Oracle necessita aguardar.
ID: o evento Buffer Busy Wait chamado de diferentes lugares na
sesso. Cada local no kernel aponta para uma diferente razo. ID
refere-se ao local na sesso que causou este evento.
Exemplo 2: o evento Log File Switch (Checkpoint Incomplete) aguarda
por um log switch porque a sesso no pode fazer um wrap para o prximo
log. O wrapping no pode ser efetuado porque o checkpoint para aquele log
no foi completado. Este evento no possui parmetros.

Vises de Estatsticas de Eventos

V$SYSTEM_EVENT: total de esperas por um evento, para todas as
sesses juntas.
V$SESSION_EVENT: esperas por um evento para cada sesso que
teve de aguardar.
V$SESSION_WAIT: esperas por um evento para as sesses
atualmente ativas que esto aguardando.
Os resultados de estatsticas das sesses que tiveram de aguardar ou
esto atualmente aguardando por um recurso podem ser visualizados
utilizandose as vises V$SESSION_EVENT, V$SESSION_WAIT.
Estatsticas acumuladas para todas as sesses podem ser visualizadas
utilizando a viso V$SYSTEM_EVENT.

-----------------
SQL> SELECT event,------
total_waits,
--------
total_timeouts,
------ ----------
2 time_waited, average_wait
3 FROM v$system_event;
Viso V$SYSTEM_EVENT
latch free 5 5 5 1
EVENTtimer
pmon TOTAL_
932 TOTAL_535 254430
TIME_ 272.993562
AVERAGE_
process startup WAITS3 TIMEOUTS WAITED
8 2.66666667
WAIT
buffer busy waits 12 0 5 5
...
A viso V$SYSTEM_EVENT mostra o total de esperas para um evento em

particular desde o startup da instncia.
um processo teve de esperar por qualquer recurso. Portanto, til consultar
esta viso cada vez que a performance do sistema diminui.
A viso V$SYSTEM_EVENT contm as seguintes colunas:
EVENT: nome do evento de espera.
TOTAL_WAITS: nmero total de esperas para o evento.
TOTAL_TIMEOUTS: nmero total de timeouts para o evento.
TIME_WAITED: quantidade total de tempo aguardado para este
evento, em centsimos de segundo.
AVERAGE_WAIT: a quantidade mdia de tempo aguardado para este
evento, em centsimos de segundo.

Viso 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 viso V$SESSION_EVENT mostra a mesma informao da viso

V$SYSTEM_EVENT, mas por sesso. Esta inclui as colunas listadas na pgina
anterior, com uma coluna extra, SID, para identificar a sesso. Voc pode
efetuar um join da coluna SID com a V$SESSION.SID para encontrar detalhes
do usurio.

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
5 114 smon timer 0 WAITING
6 14 SQL*Net message from client -1 WAITED
SHORT
TIME
Viso V$SESSION_WAIT
Esta viso lista os recursos ou eventos para os quais as sesses ativas

esto aguardando.
Colunas:
SID: identificador da sesso.
SEQ#: nmero de seqncia identificando a espera.
EVENT: recurso ou evento aguardado.
P1TEXT: descrio do primeiro parmetro adicional, que corresponde
ao PARAMETER1 descrito para a viso V$EVENT_NAME.
P1: valor do primeiro parmetro adicional.
P1RAW: valor em hexadecimal do primeiro parmetro adicional.
P2TEXT: descrio do segundo parmetro adicional, que corresponde
P2: valor do segundo parmetro adicional.
P2RAW: valor em hexadecimal do segundo parmetro adicional.
P3TEXT: descrio do terceiro parmetro adicional, que corresponde
P3: valor do terceiro parmetro adicional.
P3RAW: valor em hexadecimal do terceiro parmetro adicional.
WAIT_TIME:
Valor Descrio
>0 ltimo tempo de espera da sesso
=0 A sesso est aguardando
=-1 O valor foi inferior a 1/100 de um segundo
=-2 O sistema no pode fornecer informao
de tempo
SECONDS_IN_WAIT: nmero de segundos que o evento aguardou.

STATE: WAITING, WAITED UNKNOW TIME, WAITED SHORT TIME

(menos que um centsimo de segundo), WAITED KNOW TIME (o valor
armazenado na coluna WAIT_TIME).
Parmetro de Inicializao TIMED_STATISTICS
Configure o parmetro TIMED_STATISTICS para TRUE para recuperar
valores na coluna WAIT_TIME. Este um parmetro de inicializao dinmico.

Ferramentas Desenvolvidas pelo DBA

Desenvolva seus prprios scripts.
Utilize as packages fornecidas para tuning.
Programe verificaes de performance peridicas.
Os utilitrios e ferramentas Oracle podem no fornecer todas as
estatsticas que voc necessita. Portanto, voc pode criar seus prprios scripts
para:
Verificar o espao livre restante em cada datafile.
Determinar se as tabelas possuem espao suficiente para permitir
sua extenso.
Descrever as estruturas dos schemas para exibir as tabelas e ndices
associados.

Oracle Diagnostics Pack e Oracle Tuning Pack

Alm do conjunto padro de aplicaes do OEM, o Diagnostics Pack e o
Tuning Pack fornecem um conjunto opcional de aplicaes grficas integradas
para monitoramento e tuning que atendem a vrias reas de gerencimento de
performance, como monitoramento grfico, anlises e tuning automatizado de
bancos de dados Oracle, fornecendo informaes grficas de performance em
tempo real.
Diagnostics Pack
o Lock Monitor
o Performance Manager
o Performance Overview
o Top Sessions
o Top SQL
o Trace Data Viewer
Tuning Pack
o Oracle Expert
o Outline Management
o SQL Analyze
Tablespace Map
o Change Management Pack
Change Manager
Performance Manager
Fornece a possibilidade de monitorar a performance do banco de dados
em tempo real. Fornece dzias de grficos pr-definidos para exibio de uma
grande variedade de estatsticas de performance do banco de dados relativas
a usurios, processamento, tablespaces, redo logs, buffers, caches e I/O.
Top Sessions
Monitora como as sesses conectadas utilizam os recursos do banco de
dados/instncia em tempo real. Voc pode obter uma viso geral da atividade
das sesses, exibindo as n top sessions ordernadas por uma estatstica de sua
escolha.
Permite o monitoramento de locks, que so mecanismos que previnem a
interao destrutiva entre usurios acessando os mesmos recursos.
Oracle Trace Data Viewer

Esta aplicao permite a voc visualizar o resultado formatado do trace e
tomar as decises apropriadas de tuning ou configurao.

Tablespace Map
Permite o monitoramento e o gerenciamento do armazenamento do banco
de dados. Voc pode obter uma viso geral das informaes de utilizao da
tablespace e utilizar a caracterstica de coalescing para unir blocos livres
adjacentes.
SQL Analyze
Permite o tuning de aplicaes SQL.
Oracle Expert
Permite otimizar a performance do seu ambiente de banco de dados. O
Oracle Expert auxiliar voc com a configurao inicial do banco de dados e
com a coleta e avaliao de caractersticas de performance de bancos de
dados existentes. Esta ferramenta fornece recomendaes de tuning que voc
pode implementar imediatamente.

Performance Manager
Caractersticas
A aplicao Performance Manager captura, calcula e apresenta dados de
performance em uma viso grfica em tempo real que permite a voc
monitorar valores para:
Utilizar efetivamente a memria.
Minimizar o I/O de disco.
Prevenir a conteno de recursos.
Os dados exibidos em modo de tempo real podem ser gravados para
posterior consulta.
Voc pode definir novos grficos e exibir janelas contendo grficos de
vrias categorias.
Sete categorias diferentes de grficos pr-definidos esto disponveis para
exibio atravs do menu Display.
Predefined Charts
Sete categorias diferentes de grficos esto disponveis, cada uma com
um conjunto de grficos especficos sobre uma rea de performance.
Contention
Estes grficos incluem Circuit, Dispatcher, Free List Hit %, Latch, Lock,
Queue, Redo Allocation Hit %, Rollback NoWait Hit % e Shared Server.
Database/Instance
Estes grficos incluem Process, Session, System Statistics, Table Access,
Tablespace, Tablespace Free Space, # Users Active, # Users Logged On, #
Users Waiting, # Users Waiting for Locks e # Users Running.
I/O
Estes grficos incluem File I/O Rate, File I/O Rate Details, Network I/O Rate
e System I/O Rate.
Load
Estes grficos incluem Buffers Gets Rate, Network Bytes Rate, Redo
Statistics Rate, Sort Rows Rate, Table Scan Rows Rate e Throughput Rate.
Memory
Estes grficos incluem Buffer Cache Hit %, Data Dictionary Cache Hit %,
Library Cache
Hit %, Library Cache Details, SQL Area, Memory Allocated, Memory Sort Hit %,
Parse Ratio e Read Consistency Hit %.
Categorias de Tuning
Tuning de Aplicao
Tuning de SQL
O Oracle Expert efetua o tuning de comandos SQL e efetua a fixao
(pinning) de SQL.
Mtodos de acesso
O Oracle Expert determina quais ndices so necessrios e gera os
comandos SQL para criar, modificar e remover ndices, como apropriado.
Tuning de Parmetros da Instncia

Efetua por exemplo, um balanceamento de recursos entre I/Os de leitura e
I/Os de escrita. Os parmetros de instncia sobre os quais voc pode efetuar
tuning so os seguintes:
Parmetros da SGA (system global area), que impactam no tamanho
total da rea global de sistema para a instncia.
Parmetros de I/O, os quais impactam sobre o processamento ou
distribuio do I/O para a instncia.
Parmetros de sort, que influenciam como o servidor Oracle efetua
operaes de ordenao em nome do usurio.
Parmetros de parallel query, que so especficos para o
comportamento de parallel query da instncia.
Parmetros de parallel server, que so especficos para o
comportamento das instncias de parallel server.
Tuning da Estrutura do Banco de Dados

Dimensionamento
O Oracle Expert gera recomendaes sobre o dimensionamento de
estruturas, como a escolha correta dos parmetros de storage para um
segmento. O Oracle Expert efetua recomendaes para o armazenamento de
segmentos, o que define a alocao inicial do segmento e a taxa de
crescimento.
Disposio
O Oracle Expert efetua recomendaes sobre a disposio das estruturas,
como o particionamento de segmentos e a distribuio dos arquivos do banco
de dados.

Exerccios 3
Leia todos os exerccios antes de comear.
O objetivo desta sesso de exerccios familiarizar voc com as diferentes
formas de recuperar informaes de estatsticas.
Acompanhe o instrutor na tarefa de criar o usurio PERFSTAT e a package
STATSPACK, executando o script spcreate.sql
1. Antes de criar um snapshot, verifique se o parmetro necessrio do
init.ora foi configurado para TRUE.
2. Crie um snapshot, conectado como PERFSTAT. Anote o nmero desse
snapshot.
3. Inicie as 3 sesses seguintes com o usurio ALUNO:
A primeira sesso deve executar o script lab03_1.sql, que cria e efetua
a carga de dados para tabelas do ALUNO. Aguarde at que o script
tenha sido finalizado.
Ento a segunda sesso deve executar o script lab03_2.sql.
Ao mesmo tempo, a terceira sesso deve executar o script lab03_3.sql.
No aguarde at que os 2 ltimos scripts tenham finalizado a carga de
dados e efetue o exerccio 4.
4. Consulte a viso dinmica apropriada para visualizar:
A performance do library cache.
Entre as estatsticas de sistema, aquelas relativas a atividade de
ordenao.
As sesses que esto consumindo mais de 10.000 bytes de memria
PGA.
As estatsticas de segmentos de undo.
As estatsticas de I/O de arquivo.
5. Crie outro snapshot, conectado como PERFSTAT. Execute o script
spreport.sql de forma que o relatrio resultante seja armazenado como
alunoN_report.txt, no seu diretrio UDUMP.
6. Examine o arquivo alunoN_report.tx resultante e compare com os valores
que voc consultou anteriormente.
7. Mostre a lista com os nomes dos eventos de espera.
8. Existem sesses atualmente aguardando por recursos?

Espao para anotaes

4. Efetuando o Tuning da
Shared Pool

Efetuando o Tuning da Shared Pool
Objetivos
Efetuar o tuning do library cache e do data dictionary cache.
Medir o shared pool hit ratio.
Dimensionar a shared pool apropriadamente.
Fixar objetos na shared pool.
Efetuar o tuning do espao reservado da shared pool.
Descrever as consideraes de memria UGA e de sesso.
Configurar a large pool.

Shared Global Area
Figura 4-1: Componentes da shared global area
Contedo da Shared Pool

A shared pool possui duas estruturas principais e mais uma terceira:
O library cache, que armazena os SQL e PL/SQL compartilhados.
O data dictionary cache, que mantm informaes sobre objetos do
dicionrio.
A user global area (UGA), que mantm informaes sobre conexes
Shared Server.
Efetuando o Tuning da Shared Global Area

Um cache miss no data dictionary cache ou library cache possui um custo
maior do que um miss no database buffer cache. Efetuar o tuning da shared
pool uma prioridade.
Quando voc efetua o tuning da shared pool, provvel que voc esteja
preocupado principalmente com o library cache, uma vez que o algoritmo do
Oracle tende a manter dados do dicionrio de dados mais tempo em memria
do que dados do library cache. Portanto, efetuando-se o tuning do library
cache para um cache hit ratio aceitvel garante que o hit ratio do data
dictionary cache tambm seja aceitvel.
Se a shared pool for muito pequena, o servidor tem que dedicar recursos
para gerenciar o espao disponvel limitado. Isto consome recursos de CPU e
causa conteno.
Se a shared pool for muito grande, o gerenciamento da fragmentao da
memria tambm pode causar conteno.
Shared Pool
Figura 4-2: Componentes da shared pool
Tamanho da Shared Pool

Voc configura o tamanho da shared pool com o parmetro
SHARED_POOL_SIZE do init<SID>.ora, que possui um valor default de 8Mb.
Library Cache
O library cache contm as reas compartilhadas de SQL e PL/SQL: a
representao completa de blocos PL/SQL ou comandos SQL.
Blocos PL/SQL incluem:
Procedures.
Funes.
Packages.
Triggers.
Blocos PL/SQL annimos.
Data Dictionary Cache

O data dictionary cache armazena as definies dos objetos do dicionrio
em memria.
User Global Area

A UGA contm informaes de sesso para Shared Servers. Ela alocada
no Shared Pool quando usa-se Shared Servers e a UGA no configurada.

Library Cache
Figura 4-3: Viso da library cache
Utilizado para armazenar comandos SQL e blocos PL/SQL para serem

compartilhados pelos usurios.
Gerenciados por um algoritmo LRU.
Utilizado para evitar o reparse de comandos.
Armazenamento de SQL e PL/SQL

O servidor Oracle utiliza o library cache para armazenar comandos SQL e
blocos PL/SQL. Um algoritmo de LRU utilizado para gerenciar o cache.
Se um usurio executar um comando que j est no cache, o servidor
Oracle pode utilizar a verso que est no cache sem ter que efetuar o reparse
do comando.
Para saber se um comando j est no cache, o servidor Oracle:
1. Reduz o comando para um valor numrico do texto ASCII.
2. Utiliza uma funo de hash deste nmero.

Efetuando o Tuning do Library Cache
1 Meta
Reduza os misses mantendo a operao de parse em um nvel mnimo:
Garanta que os usurios possam compartilhar os comandos.
Evite que comandos sejam removidos da memria alocando espao
suficiente.
Evite invalidaes que induzem ao reparse.
2 Meta
Evite a fragmentao:
Reservando espao para grandes necessidades de memria.
Fixando em memria os objetos grandes freqentemente requeridos.
Eliminando grandes blocos PL/SQL annimos.
Reduzindo o consumo de memria UGA de conexes Shared Server.
Primeira Meta de Tuning

Reduza os misses mantendo a operao de parse a um nvel mnimo:
Se uma aplicao fizer uma chamada de parse para um comando
SQL e a representao do parse do comando no existir na shared
SQL area no library cache, o servidor Oracle efetua o parse do
comando e aloca uma shared SQL area.
Garanta que comandos SQL possam compartilhar uma shared SQL area
sempre que possvel utilizando:
Cdigo genrico tanto quanto for possvel.
Variveis bind ao invs de constantes.
Se uma aplicao fizer uma chamada de execute para um comando
SQL e a shared SQL area contendo a representao do parse do
comando tiver sido desalocada do library cache para fazer lugar para
outro comando, o servidor Oracle implicitamente efetua o reparse do
comando, aloca uma nova shared SQL area e o executa. Reduza
library cache misses em chamadas de execuo alocando mais
memria para o library cache.
Se um objeto de schema for referenciado em um comando SQL e
este objeto for modificado posteriormente de qualquer forma, a
shared SQL area torna-se invlida.
Segunda Meta de Tuning

Evite a fragmentao:

Garantindo espao contnuo suficiente para grandes necessidades de

memria atravs da alocao de espao reservado na shared pool
area.
Fixando objetos grandes freqentemente requisitados como reas de
SQL e PL/SQL em memria, ao invs de deix-los sair da memria
com o mecanismo normal de LRU.
Utilizando pequenas funes em packages PL/SQL ao invs de
grandes blocos annimos.
Medindo a memria de sesso utilizada por processos servidor
compartilhados em conexes Shared Server.

Terminologia
Cada linha da viso V$LIBRARYCACHE contm estatsticas para um tipo de
item mantido na library cache. O item descrito por cada linha identificado
pelo valor da coluna NAMESPACE. Linhas da tabela com os seguintes valores
de NAMESPACE refletem a atividade da library cache para comandos SQL e
blocos PL/SQL:
SQL AREA, TABLE/PROCEDURE, BODY, TRIGGER.
Linhas com outros valores de NAMESPACE refletem a atividade da library
cache para as definies de objeto que o Oracle utiliza para manuteno de
dependncias:
INDEX, CLUSTER, OBJECT, PIPE
Palavras-chave relacionadas com NAMESPACES so:
GETS (parse): o nmero total de requisies por informao sobre o
item correspondente.
PINS (execues): o nmero de execues de comandos SQL ou
procedures.
RELOADS (parse): se uma chamada de execute para um comando
SQL for feita e a shared SQL area contendo a representao do parse
do comando foi desalocada da library cache para fazer lugar para
outro comando ou porque os objetos que o comando referencia o
invalidaram, o servidor Oracle implicitamente recarrega o comando e
portanto efetua o reparse do mesmo. O nmero de reloads contado
para cada um dos NAMESPACE.
INALIDATIONS (parse): quando um objeto modificado, possvel
que haja um novo e melhor plano de execuo para todos os
comandos que utilizam o objeto. Por isso o servidor Oracle marca
todos os atuais planos de execuo para esse objeto como invlidos.

Ferramentas de Diagnstico para Tuning do

Library Cache
Figura 4-4: Ferramentas de diagnstico para tuning do library cache
Descrio das Vises

V$SGASTAT: tamanhos de todas as estruturas da SGA.
SQL> SELECT *
2 FROM v$sgastat;
POOL NAME BYTES

------------ -------------------------- ----------
fixed_sga 777556
buffer_cache 8388608
log_buffer 262144
shared pool parameters 38116
shared pool pl/sql source 19732
shared pool table definiti 1388
shared pool trigger defini 2104
shared pool trigger inform 496
shared pool trigger source 1700
shared pool type object de 371180
java pool free memory 4194304
...

Uma vez que a shared pool atua como um cache, nada ser removido
at que toda a memria livre seja utilizada. Memria livre mais corretamente
vista como "espao perdido" (wasted space). Um valor alto de memria livre
mais um sintoma de fragmentao.
V$SQLAREA: estatsticas completas sobre todos os cursores
compartilhados, e os primeiros 1000 caracteres do comando SQL.
V$SQL: lista as estatsticas de Shared SQL Areas e contm uma linha
para cada filho do texto SQL original. similar a V$SQLAREA, porm
sem a clusula GROUP BY que torna essa lenta ao consultar.
V$SQLTEXT: texto SQL completo, em mltiplas linhas.
V$DB_OBJECT_CACHE: objetos do banco de dados que esto no
cache, incluindo packages; tambm objetos como tabelas e
sinnimos, onde estes so referenciados em comandos SQL.
V$LIBRARYCACHE: estatsticas sobre o gerenciamento do library
cache.

SQL> SELECT namespace,

gethitratio
sql_text, users_executing,
gethitratio
2 FROM v$librarycache
executions, loads
v$librarycache;
3 FROM
WHEREv$sqlarea;
namespace = 'SQL AREA';
NAMESPACE GETHITRATIO

SQL> select
---------------
* from
-----------
v$sqltext
SQL
2 AREA
WHERE sql_text
,873228474
like
TABLE/PROCEDURE
3 'SELECT * FROM,666161616
aluno.tclientes where id =%';
BODY ,959731544
TRIGGER ,835164835
INDEX ,091836735
CLUSTER ,945355191
OBJECT 1
PIPE 1
JAVA SOURCE 1
JAVA RESOURCE 1
JAVA DATA 1
Cursores esto sendo Compartilhados ?

Verifique o GETHITRATIO na V$LIBRARYCACHE:
Encontre quais os comandos que os usurios esto executando:
Viso V$LIBRARYCACHE: o GETHITRATIO determina o percentual de

chamadas de parse que encontraram um cursor para compartilhar
(GETHITS/GETS) em ambientes OLTP. Esta taxa deve ser superior a 90%. Caso
contrrio, existe espao para provavelmente melhorar a eficincia do cdigo
de sua aplicao.
Experimente:
Melhorar o cdigo de aplicao. Isso pode no ser possvel se voc
no tiver acesso aos cdigos fontes.
Aumente o tamanho da Shared Pool.

Diretrizes: Library Cache Reloads
Figura 4-5: Diretrizes para library cache reloads
Reloads devem:
Ser preferencialmente 0.
Nunca maiores do que 1% do nmero de PINS.
SQL> SELECT sum(pins) "Executions", sum(reloads)"Cache Misses",
2 sum(reloads)/sum(pins)
3 FROM v$librarycache;
Executions Cache Misses SUM(RELOADS)/SUM(PINS)

---------- ------------ ----------------------
219566 970 ,004417806
Como Obter a Proporo entre Reloads e Pins

Viso V$LIBRARYCACHE: a viso exibe se comandos para os quais j
havia sido efetuado o parse foram removidos do cache. O nmero de
RELOADS no deve ser maior do que 1% do nmero de PINS.
REPORT.TXT: esta seo indica a mesma proporo para o perodo de
execuo de utlbstat e utlestat.

LIBRARY PINS PINHITRATIO RELOADS

----------- -------- ----------- -------
BODY 105 1 0
SQL AREA 12822 .982 95
TABLE/PROCED 3714 .969 81
TRIGGER 917 .997 3
Diretrizes
Se a proporo entre reloads e pins for maior que 1%, existem duas
razes possveis:
reas de parse compartilhadas foram removidas da memria (aged
out), embora sejam requeridas por sucessivas reexecues, devido a
falta de espao.
reas de parse foram invalidadas.
Para evitar reloads freqentes, aumente o parmetro SHARED_POOL_SIZE
do init<SID>.ora.

SQL> SELECT namespace, pins, reloads, invalidations

NAMESPACE PINS RELOADS INVALIDATIONS

--------------- ---------- ---------- -------------
SQL AREA 154694 520 345
SQL> ANALYZE table aluno.tclientes compute statistics;
Tabela analisada.
SQL> SELECT *
2 FROM aluno.tclientes;
SQL> SELECT namespace, pins, reloads, invalidations

NAMESPACE PINS RELOADS INVALIDATIONS

--------------- ---------- ---------- -------------
SQL AREA 155012 528 346
Invalidaes
Quando Invalidaes Ocorrem

Se um objeto de schema for referenciado em um comando SQL e este
objeto for posteriormente modificado de qualquer forma, a shared SQL area
torna-se invlida (marcada como invlida) e o comando deve sofrer reparse a
prxima vez que for executado, e portanto, um reload deve ocorrer.
Exemplo: uma tabela, seqncia, sinnimo ou viso recriado, alterado
ou removido, ou uma procedure ou especificao de package recompilada,
ento todas as shared SQL areas dependentes so invalidadas.

Dimensionando o Library Cache

Defina o espao global necessrio para armazenar objetos
(packages, vises e assim por diante).
Defina a quantidade de memria utilizada por comandos SQL usuais.
Reserve espao para grandes necessidades de memria para evitar
misses e fragmentao.
Mantenha objetos freqentemente utilizados em memria.
Converta grandes blocos PL/SQL annimos em pequenos blocos
annimos chamando funes de packages.

SQL> SELECT 250

sum(sharable_mem)
sum(250
* value
* users_opening)
bytes_per_user
SQL>2SELECT
FROM sum(sharable_mem)
v$db_object_cache;
v$sqlarea
v$sqlarea;
v$sesstatwhere
s, v$statname
executions
n > 5;
2 3FROM v$db_object_cache
WHERE executions > =
s.statistic# 5;n.statistic#
3 4WHERE
AND type = 'PACKAGE'
SUM(SHARABLE_MEM)
n.name = 'opened cursors current'
4 5ORAND type = 'PACKAGE
-----------------
s.sid = 15; BODY'
5 OR type = 'FUNCTION'
22038042
7551398
6 OR type = 'PROCEDURE';

Alocao de Espao Global

Stored objects como packages e vises:
Comandos SQL:
Testando suas Aplicaes

Para uma aplicao existente, voc pode configurar um teste e utilizar as
vises dinmicas para descobrir a quantidade de memria utilizada. Inicie
configurando o SHARED_POOL_SIZE para um valor bastante grande (s custas
de outras estruturas se necessrio), e ento execute a aplicao.
Clculo da Memria Compartilhada Utilizada

Para stored objects como packages e vises, utilize a seguinte
consulta.
Para comandos SQL, voc necessita consultar a viso V$SQLAREA
aps a aplicao ter executado durante algum tempo. Para
comandos freqentemente disparados, voc pode utilizar a seguinte
consulta para estimar a quantidade de memria utilizada, embora
isto no inclua SQL dinmico:
Voc deve tambm permitir cerca de 250 bytes na shared pool por
usurio por cursor aberto. Isto pode ser testado durante momentos de
alta utilizao da aplicao com a seguinte consulta:
Em um ambiente de teste, voc pode medir isto selecionando o nmero
de cursores abertos para um usurio de teste, multiplicando o valor resultante
pelo nmero total de usurios.
Sua aplicao deve possuir um library cache ideal do tamanho da soma

dos nmeros acima, mais uma pequena compensao para SQL dinmico.

Grandes Requisitos de Memria
Figura 4-6: Grandes requisitos de memria
Satisfaa grandes requisies de memria contnua.

Reserve memria no fragmentada dentro da shared pool.
Porque Reservar Espao na Shared Pool ?

O DBA pode reservar memria dentro da shared pool para satisfazer
grandes alocaes durante operaes como compilao PL/SQL e compilao
de trigger. Pequenos objetos no fragmentaro a lista reservada, ajudando a
garantir que a lista reservada possua grandes pedaos de memria contnua.
Quando a memria alocada a partir lista reservada liberada, esta retorna
para a lista reservada.
Parmetros de Inicializao
O tamanho da lista reservada, bem como o tamanho mnimo dos objetos
que podem ser alocados a partir da lista reservada, so controlados por dois
parmetros de inicializao:
SHARED_POOL_RESERVED_SIZE: controla a quantidade de
SHARED_POOL_SIZE reservada para grandes alocaes (configure o
valor inicial para 10% do SHARED_POOL_SIZE). Se
SHARED_POOL_RESERVED_SIZE for maior que metade de
SHARED_POOL_SIZE, o servidor Oracle sinaliza um erro.

SQL> desc V$SHARED_POOL_RESERVED

Nome Nulo? Tipo
----------------------------------------- -------- -----------
FREE_SPACE NUMBER
AVG_FREE_SIZE NUMBER
FREE_COUNT NUMBER
MAX_FREE_SIZE NUMBER
USED_SPACE NUMBER
AVG_USED_SIZE NUMBER
USED_COUNT NUMBER
MAX_USED_SIZE NUMBER
REQUESTS NUMBER
REQUEST_MISSES NUMBER
LAST_MISS_SIZE NUMBER
MAX_MISS_SIZE NUMBER
REQUEST_FAILURES NUMBER
LAST_FAILURE_SIZE NUMBER
ABORTED_REQUEST_THRESHOLD NUMBER
ABORTED_REQUESTS NUMBER
LAST_ABORTED_SIZE NUMBER
Viso V$SHARED_POOL_RESERVED
Esta viso ajuda no tuning da reserved pool e do espao dentro da shared
pool. As colunas da viso somente so vlidas se o parmetro
SHARED_POOL_RESERVERD_SIZE estiver configurado para um valor vlido.
Onde:
FREE_SPACE o total de espao livre na lista reservada.
AVG_FREE_SIZE o tamanho mdio da memria livre na lista
reservada.
MAX_FREE_SIZE o tamanho da maior parte de memria livre na
lista reservada.
REQUEST_MISSES o nmero de vezes que a lista fornecida no
possua um pedao de memria para satisfazer a
requisio, e procedeu o flushing (limpeza) dos
objetos a partir da lista LRU.
As seguintes colunas da viso contm valores que so vlidos mesmo se o
parmetro no estiver configurado:
REQUEST_FAILURES
LAST_FAILURE_SIZE
ABORTED_REQUEST_THRESHOLD
ABORTED_REQUESTS
LAST_ABORTED_SIZE
Onde:
REQUEST_FAILURES o nmero de vezes em que no foi
encontrada memria para satisfazer uma
requisio.

LAST_FAILURE_SIZE o tamanho da ltima requisio que falhou.

Efetuando o Tuning do Espao Reservado da

Shared Pool
Diagnsticos com a Viso

V$SHARED_POOL_RESERVED
Estatsticas a partir da viso V$SHARED_POOL_RESERVED podem ajudar
voc a efetuar o tuning de parmetros. Em um sistema com ampla memria
livre para aumentar a SGA, a meta possuir REQUEST_MISSES = 0, no ter
nenhum REQUEST_FAILURES, ou pelo menos evitar que este valor aumente.
Diagnsticos com a Procedure

ABORTED_REQUEST_THRESHOLD
A procedure ABORTED_REQUEST_THRESHOLD, da package
DBMS_SHARED_POOL, permite limitar a quantidade da shared pool a ser limpa
(flush) antes de reportar o erro ORA-04031, para limitar a extenso de um
flush que pode ocorrer devido a um grande objeto.
Diretrizes quando SHARED_POOL_RESERVED_SIZE

muito pequeno
O reserverd pool muito pequeno quando o valor para
REQUEST_FAILURES maior que zero e estiver aumentando. Para resolver isto,
voc pode aumentar o valor para SHARED_POOL_RESERVED_SIZE e
SHARED_POOL_SIZE de acordo. As configuraes que voc selecionar para
estes depende das regras da SGA de seu sistema. Esta opo aumenta a
quantidade de memria disponvel na lista reservada sem possuir um efeito
sobre os usurios que no alocam memria a partir da lista reservada. Como
segunda opo, reduza o nmero de alocaes permitidas para usuar memria
a partir da lista reservada; entretanto, aumente a shared pool normal, a qual
pode afetar outros usurios no sistema.
Diretrizes de quando o
SHARED_POOL_RESERVED_SIZE muito Grande
Muita memria pode ter sido alocada para a lista reservada se:
REQUEST_MISS = 0 ou no aumentando.
FREE_SPACE => 50% do mnimo do SHARED_POOL_RESERVED_SIZE.
Neste caso, diminua o valor de SHARED_POOL_RESERVED_SIZE.

Diretrizes de quando o SHARED_POOL_SIZE muito

Pequeno
A fixed table V$SHARED_POOL_RESERVED pode tambm indicar quando o
valor para SHARED_POOL_SIZE muito pequeno. Isto pode ser o caso quando
REQUEST_FAILURES for maior que 0 e estiver aumentando. Se voc tiver
habilitado a lista reservada, diminua o valor para
SHARED_POOL_RESERVED_SIZE. Se voc no tiver habilitado a lista reservada,
voc pode aumentar o SHARED_POOL_SIZE.

SQL> SELECT * from v$db_object_cache

2 WHERE sharable_mem > 10000
3 AND (type = 'PACKAGE' or type = 'PACKAGE BODY'
4 OR type = 'FUNCTION' or type = 'PROCEDURE')
5 AND kept = 'NO';
Fixando Objetos Grandes

Encontre aqueles objetos PL/SQL que no esto fixados no library
cache:
Fixe (pin) packages grandes no library cache:
Porque e Quando Manter Objetos na Memria

A carga de objetos grandes a fonte primria de fragmentao. O tempo
de resposta do usurio afetado devido ao grande nmero de pequenos
SQL> EXECUTE dbms_shared_pool.keep('package_name');

objetos a serem removidos da shared pool para dar lugar para o objeto. Para
evitar estas situaes, mantenha estes objetos grandes ou freqentemente
requisitados na shared pool para garantir que nunca sejam removidos da
shared pool.
Quais objetos devem ser mantidos:
Objetos procedurais grandes freqentemente requisitados como as
packages STANDARD e DIUTIL, e aqueles para os quais a memria
compartilhada excede um threshold definido.
Triggers compiladas que so muito executadas em tabelas utilizadas
freqentemente.
Seqncias, uma vez que nmeros seqnciais so perdidos quando a
seqncia removida da shared pool.
Quando fix-los: no momento do startup o ideal, uma vez que evita
futuras fragmentaes.
A limpeza da shared pool utilizando o comando ALTER SYSTEM FLUSH
SHARED_POOL no elimina os objetos fixados.
Como Fixar os Objetos

Utilize a package DBMS_SHARED_POOL com a procedure KEEP.
Para criar a package, execute o script dbmspool.sql. O script prvtpool.plb
executado automaticamente no final do anterior. Estes scripts no so
executados pelo catproc.sql.
Utilize a procedure UNKEEP para remover objetos fixados (pinned) da
shared pool.

SQL> SQL> DECLARE

SQL>SELECT
EXECUTESELECT
address,sql_text
x hash_value
/* number;
KEEP_ME
from
*/v$sqlarea
x number;
dbms_shared_pool.keep('address,hash_value');
2 FROM2 v$sqlarea
WHERE x
BEGIN command_type
:= 5; = 47
3 WHERE3 command_type
AND length(sql_text)
END; = 47 > 500;
4 AND sql_text like '% KEEP_ME %';

ADDRESS HASH_VALUE
-------- ----------
51926340 2009431512
Blocos PL/SQL Annimos

Encontre os blocos PL/SQL annimos para convert-los em pequenos
blocos PL/SQL annimos que disparam funes de packages.
Duas Solues para Eliminar Grandes Blocos PL/SQL

Annimos
Encontre-os e os converta para pequenos blocos PL/SQL annimos
que disparam funes de packages.
Se um bloco PL/SQL annimo no puder ser convertido em uma
package, pode ser identificado na V$SQLAREA e marcado como
KEPT.
Voc pode ento manter estes blocos em memria, utilizando a
procedure apropriada.
Torna-se:
Execute a procedure KEEP sobre o bloco PL/SQL annimo identificado pelo

address e hash_value recuperado a partir do comando anterior.

Outros Parmetros que Afetam o Library

Cache
OPEN_CURSORS: define o nmero de cursores referenciando as
private SQL areas alocadas para o processo do usurio (uma rea de
SQL privada continua existindo at o cursor estar fechado e ainda
permanece existindo aps a concluso do comando).
Para obter vantagens de memria adicional disponvel para shared SQL
areas, voc pode necessitar aumentar o nmero de cursores permitidos
para uma sesso. Desenvolvedores de aplicao devem fechar cursores
abertos no necessrios para conservar memria do sistema. O valor
default 50.
CURSOR_SPACE_FOR_TIME: um parmetro boleano cujo default
FALSE (se voc configur-lo para TRUE, voc escolhe utilizar espao
para ganhar tempo; shared SQL areas no so desalocadas at que o
cursor referenciando-as seja fechado. Portanto, garanta que exista
memria livre disponvel e nenhum cache misses. No modifique
este parmetro a menos que o valor de RELOADS na
V$LIBRARYCACHE esteja consistentemente 0. Se sua aplicao
utilizar Forms, ou qualquer SQL dinmico, deixe esta configurao
em FALSE).
SESSION_CACHED_CURSORS: este parmetro ajuda em situaes
onde um usurio repetidamente efetua o parse dos mesmos
comandos. Isto ocorre em aplicaes Forms quando usurios
freqentemente alternam entre forms; todos os comandos SQL
abertos para um form sero fechados quando voc alternar para o
outro. O parmetro faz com os cursores fechados sofram cache
dentro da sesso. Portanto, qualquer chamada subseqente para
efetuar o parse do comando evita a fase de parse.
Para verificar se sua configurao est eficiente, compare as
estatsticas de sesso session cursor cache hits e parse count na
V$SESSTAT para uma sesso de usurio tpica. Se poucos parses
resultam em hits, voc pode aumentar o nmero. Lembre-se que isto
pode aumentar a demanda global de memria.
O default 0, o que significa que no ser efetuado o cache de cursores
na sesso.
CURSOR_SHARING: o valor default desse parmetro permite que
comandos compartilhem os cursores apenas se eles forem idnticos
de todas as formas. Ele pode ser mudado para permitir que
comandos similares compartilhem cursores, se eles tiverem o
mesmo result set. Isso permite que comandos que sejam idnticos,
exceto por um valor literal, compartilhem o cursor, evitando assim
parse desnecessrio. Note que variveis bind compartilham cursores
independentemente desse parmetro.

Data Dictionary Cache, Terminologia e Tuning
Viso V$ROWCACHE
Trs colunas importantes:
PARAMETER: nome do Data Dictionary Cache que est sendo
reportado.
GETS: exibe o nmero total de requisies por informaes no item
correspondente (por exemplo, na linha que contm estatsticas para
descries de arquivo, esta coluna possui o nmero total de
requisies por dados de descrio de arquivo).
GETMISSES: exibe o nmero de requisies de dados resultantes em
cache misses.
Meta
Misses no cache do dicionrio de dados so esperados em alguns casos.
Aps o startup da instncia, o cache do dicionrio de dados no contm dados,
de forma que provvel que qualquer comando SQL disparado resulte em
cache misses. A medida que os dados forem lidos para o cache, a
probabilidade de cache misses deve diminuir. Eventualmente, o banco de
dados deve atingir uma situao estvel (steady state) na qual os dados do
dicionrio mais freqentemente utilizados estejam em cache. Neste ponto,
muitos poucos cache misses devem ocorrer. Para efetuar o tuning do cache,
examine sua atividade somente aps sua aplicao ter sido executada por
algum tempo.

Ferramentas de Diagnstico para Tuning do

Data Dictionary Cache
Figura 4-7: Ferramentas de diagnstico para tuning do data dictionary cache
Monitorando o Cache do Dicionrio

Utilize a viso V$ROWCACHE. As colunas de maior interesse esto
descritas na tabela abaixo:
Coluna Descrio
PARAMETER Categorias de itens de dados do
dicionrio
GETS Requisies por informaes nesta
categoria
GETMISSES Requisies que resultaram em cache
misses
Dimensionamento
Voc pode dimensionar o cache do dicionrio somente de forma indireta
com o parmetro SHARED_POOL_SIZE. O algoritmo para alocao do espao da
shared pool fornece preferncia para o cache do dicionrio.

SQL> SELECT parameter, gets, getmisses

2 FROM v$rowcache;
PARAMETER GETS GETMISSES

-------------------------------- ---------- ----------
dc_objects 8144 1338
dc_constraints 72 33
...
Efetuando o Tuning do Data Dictionary Cache

Mantenha a proporo entre a soma de GETMISSES e a soma de
GETS abaixo de 15%.
A proporo entre a soma de todos os GETMISSES e a soma de todos os
GETS deve ser menor que 15% durante a execuo normal. Se for maior,
considere o aumento de SHARED_POOL_SIZE.
Voc no deve esperar alcanar um valor zero para GETMISSES, porque no
primeiro momento aps o startup em que um servidor necessitar da definio
de um objeto, este deve ser carregado para o cache.

NAME GET_REQS GET_MISS

---------------------------------------- -------- ---------
dc_objeccts 143434 171
dc_constraints 140432 127
Diretrizes: Dictionary Cache Misses

Resultado do report.txt:
Se o resultado do report.txt indicar um proporo alta entre
GET_MISS/GET_REQ para um nmero de itens, isto indica que o
SHARED_POOL_SIZE deve ser aumentado.

UGA e Shared Server
Figura 4-8: UGA e shared server
User Global Area

Se voc utilizar o Shared Servered server, as informaes de user session
e cursor state so armazenadas na shared pool ao invs da memria privada
do usurio. reas de sort e reas privadas de SQL esto includas nas
informaes de sesso. Isto assim porque servidores compartilhados (shared
servers) trabalham comando a comando, de forma que qualquer servidor pode
necessitar acesso para qualquer informao de usurio. Esta parte da shared
pool chamada de User Global Area (UGA).
O total de memria necessrio para o servidores compartilhados no
maior do que se voc utilizar servidores dedicados. Voc pode necessitar
aumentar o SHARED_POOL_SIZE, mas sua memria privada de usurio
menor.
Se estiver usando Shared Servers, ento configure a Large Pool. Dessa
forma a UGA ser armazenada nela, e no na Shared Pool.

SQL> SELECT sum(value) || 'bytes' "Total max

session
memory"
memory"
2 FROM v$sesstat, v$statname
v$mystat, v$statname
3 WHERE name = 'session uga memory
memory'max'
4 AND v$sesstat.statistic#
v$mystat.statistic# ==v$statname.statistic#;
v$statname.statistic#;
Dimensionando a User Global Area

Espao utilizado de UGA pela sua conexo de teste:
Espao utilizado de UGA por todos os usurios Shared Server:
Espao mximo de UGA utilizado por todos os usurios Shared
Server:
Para todas as conexes Shared Server, voc necessita calcular a
quantidade de espao necessrio para todos os usurios shared server
colocarem sua memria de sesso na shared pool.

Large Pool
Figura 4-9: Large pool
Pode ser configurada como uma rea de memria separada na SGA,

utilizada como memria com:
Processos server de I/O: DBWR_IO_SLAVES
Operaes de backup e restore
Memria de sesso para Servidores Compartilhados
til nestas situaes para evitar overhead de performance causado
pelo desmembramento do shared SQL cache.
Dimensionada pelo parmetro LARGE_POOL_SIZE.
Existncia do Large Pool

A large pool deve ser explicitamente configurada quando necessrio. A
memria da large pool no obtida a partir da shared pool, mas diretamente
da SGA, desta forma adicionando-se a quantidade de memria compartilhada
que o servidor Oracle necessita para o startup da instncia.
Vantagens
A large pool utilizada para fornecer grandes alocaes de memrias
para a memria de sesso para:
Processos server de I/O.
Operaes de backup e restore
A memria para as operaes de backup e restore do Oracle server e
para os processos server de I/O alocada em buffers de algumas
centenas de kilobytes. A large pool est melhor habilitada para
satisfazer estas requisies do que a shared pool.
Shared Server: alocando memria de sesso a partir da large pool
para o servidores compartilhados, o servidor Oracle pode utilizar a
shared pool primariamente para cache de shared SQL e evitar o
overhead de performance causado pelo desmembramento do shared
SQL cache.

Parallel execution: quando o parmetro

PARALLEL_AUTOMATIC_TUNING estiver configurado para TRUE, o
servidor Oracle aloca buffers de execuo em paralelo a partir da
large pool. Quando este parmetro estiver configurado para FALSE, o
Oracle aloca buffers de execuo em paralelo a partir da shared
pool. O servidor Oracle automaticamente calcula o valor do
parmetro LARGE_POOL_SIZE se o valor do parmetro
PARALLEL_AUTOMATIC_TUNING for TRUE. Para manualmente
configurar um valor para LARGE_POOL_SIZE, consulte a viso
V$SGASTAT e aumente ou diminua o valor para LARGE_POOL_SIZE
dependendo de suas necessidades.

Exerccios 4
O objetivo desta seo de exerccios utilizar as ferramentas de diagnstico

disponveis para monitorar e efetuar o tuning da shared pool.
3. Verifique o tamanho da shared pool.
4. Para simular atividade de usurio sobre o banco de dados, conecte-se
como ALUNO e execute o script lab04_1.sql e em paralelo lab04_2.sql.
5. Efetue a medida do hit ratio para o library cache.
6. Efetue a medida do hit ratio para o data dictionary cache.
7. Crie um novo snapshot, conectado como PERFSTAT, e crie um novo
relatrio comparando este com o seu ltimo snapshot do exerccio
anterior.
8. Utilize o resultado do relatrio para obter ambos os hit ratios.
9. Que solues voc iria aplicar se qualquer dos hit ratios estivesse ruim ?
10. Determine que packages, procedures e triggers esto fixadas na
shared pool.
11. Fixe uma das packages fornecidas pelo Oracle que necessite ser
mantida em memria. Por exemplo a package DBMS_OUTPUT.
12. Determine a quantidade de memria de sesso utilizada na shared
pool para sua sesso.

Espao para anotaes


5. Efetuando o Tuning do
Database Buffer Cache

Efetuando o Tuning do Database Buffer Cache
Objetivos
Descrever como o buffer cache gerenciado.
Calcular o buffer cache hit ratio.
Examinar o impacto de adicionar ou remover buffers.
Criar mltiplos buffer pools.
Dimensionar mltiplos pools.
Monitorar a utilizao do buffer cache.
Efetuar o uso apropriado do cache de tabelas.
Diagnosticar a conteno de LRU latch.
Evitar a conteno da free list.

Caractersticas do Buffer Cache
Figura 5-1: Caractersticas do buffer cache
O buffer cache armazena cpias dos blocos de dados dos datafiles. Uma
vez que o buffer cache parte da SGA, estes blocos podem ser compartilhados
por todos os usurios. O buffer cache possui as seguintes caractersticas:
No Oracle 10g, os buffer caches podem ser configurados com os
seguintes parmetros:
DB_CACHE_SIZE: define o tamanho do buffer default em bytes.
DB_KEEP_CACHE_SIZE: define o tamanho keep buffer pool em bytes.
DB_RECYCLE_CACHE_SIZE: define o tamanho do recycle buffer pool
em bytes.
Com essas configuraes os buffer pools em Oracle 10g podem ser
redimensionados dinamicamente.
O processo servidor efetua a leitura dos dados a partir dos datafiles
para o buffer cache. Para aumentar a performance, o processo
servidor algumas vezes efetua a leitura de mltiplos blocos em uma
nica leitura.
O processo DBWn escreve os dados a partir do buffer cache para os
data files. Para aumentar a performance, o DBWn escreve mltiplos
blocos em uma nica escrita.
Cada buffer no cache armazena um nico bloco do banco de dados.
Em um determinado momento, o buffer cache pode armazenar
mltiplas cpias de um nico bloco do banco de dados. Somente
uma cpia corrente do bloco existe, mas processos servidor podem
necessitar construir cpias de leitura consistente, utilizando
informaes de undo, para satisfazer consultas.
Os blocos no buffer cache so gerenciados utilizando duas listas:

A lista dos blocos menos recentemente utilizados (least recently used

LRU) utilizada para manter os blocos mais recentemente
acessados em memria. Os blocos na lista so organizados a partir
dos most recently used (MRU) para os least recently used.
A checkpoint queue aponta para os blocos do buffer cache que foram
modificados mas ainda no escritos para disco.
Blocos no buffer cache podem estar em um de quatro estados:
Free buffers so blocos que possuem a mesma imagem no disco e em
memria. Estes blocos esto disponveis para reutilizao.
Dirty blocks so blocos com uma imagem diferente na memria que a
imagem no disco. Estes blocos devem ser escritos para disco antes
que possam ser reutilizados.
Pinned buffers so blocos de memria que esto atualmente sendo
acessados.
Clean significa que o buffer est nesse momento livre e um
candidato para ser sobreescrito com outro bloco se seu contedo no
for acessado novamente. O contedo do buffer est em sincronia com
o disco ou foi usado para manter ou gerar um snapshot antigo do
dado (CR Block).
Processos servidor utilizam os blocos no buffer cache, mas o processo
DBWn que torna blocos do cache disponveis atravs da escrita dos blocos
modificados de volta para os datafiles.
A lista Least Recently Used monitora a utilizao dos buffers. Eles so

listados de acordo com o nmero de vezes que so usados. Assim, os buffers
mais usados sero encontrados na ponta dos mais recentemente utilizados
(MRU) e os menos utilizados na ponta oposta (LRU). Blocos carregados do
disco so colocados em buffers da ponta LRU, e estes so movidos para o
centro da lista, de onde iro para uma ponta ou outra, de acordo com sua
utilizao.
Se o parmetro DB_BLOCK_CHECKSUM for igual a TRUE, cada bloco

escrito ter um checksum number, e a escrita ser confirmada. Isso adiciona
algum overhead escrita, e a deixar mais lenta.

Parmetros de Dimensionamento do Buffer

Cache no Oracle 10g
Divises do Database Buffer Cache

O Database Buffer Cache pode ser subdividido em diferentes pools, de
acordo com as caractersticas dos blocos de dados carregados, tambm em
pools com tamanho de bloco diferentes.
Parmetros
O tamanho de bloco definido pelo parmetro DB_BLOCK_SIZE logo na
criao do banco referido como o tamanho de bloco primrio, e usado para
definir o tamanho de bloco da tablespace SYSTEM. Outras tablespaces podem
ter tamanhos de blocos diferentes.
Para cada tamanho de bloco podem haver trs buffer pools, Keep, Recycle
e Default. Eles so dimensionados respectivamente pelos parmetros
DB_KEEP_CACHE_SIZE, DB_RECYCLE_CACHE_SIZE e DB_CACHE_SIZE, todos em
unidades de memria (bytes, K ou M).
O pool default o nico obrigatrio, mas os trs pools so independentes.
Ou seja, os demais no retiram suas reas de memria do pool default. A
utilidade e funcionamento dos diferentes pools sero vistas mais adiante nesse
captulo.

Dimensionamento Dinmico da SGA

A partir do Oracle 9i possvel redimensionar os componentes da SGA
sem a necessidade de ser feito shutdown da instncia. Para fazermos isso
basta que sejam alterados os parmetros que definem o Shared Pool ou o
Database Buffer Cache com o comando ALTER SYSTEM.
Parmetro SGA_MAX_SIZE
A soma da memria alocada para os componentes da SGA no pode
ultrapassar o tamanho definido pelo parmetro SGA_MAX_SIZE aps o startup.
O tamanho definido por esse parmetro a quantidade de memria realmente
alocada no startup da instncia, mesmo que a soma dos componentes no
atinja esse valor.
A instncia deveria ser configurada para iniciar utilizando menos memria
do que o definido por SGA_MAX_SIZE, para deixar uma "folga" para futuros
ajustes no espao alocado pelos componentes.
Grnulo
A alocao de memria da SGA sempre feita em grnulos, reas
contguas de memria virtual, inclusive para os redimensionamentos. Os
valores de alocao so, portanto arredondados para um mltiplo do tamanho
do grnulo.
O tamanho definido em SGA_MAX_SIZE determina o tamanho do grnulo
da seguinte forma:
Grnulo = 4Mb se SGA_MAX_SIZE for menor ou igual a 128Mb.
Grnulo = 16Mb se SGA_MAX_SIZE for maior que 128Mb.
O tamanho mnimo da SGA de trs grnulos: 1 para a rea fixa
(incluindo o redo log buffer); 1 para o database buffer cache, e um para o
shared pool.
Monitoramento
Utilize a viso V$BUFFER_POOL para monitorar o tamanho dos buffer
caches. As colunas so:
Coluna Descrio
ID Nmero do buffer pool.
NAME Nome do buffer pool.
BLOCK_SIZE Tamanho do bloco para esse buffer.
RESIZE_STATE Estado atual da operao de resize (STATIC, ALLOCATING,
ACTIVATING ou SHRINKING).

CURRENT_SIZE Tamanho atual do subcache em megabytes.

BUFFERS Nmero atual de buffers.
TARGET_SIZE Novo tamanho em bytes, se um redimensionamento estiver
em andamento. Se RESIZE_STATE for STATIC, ento mostra o
tamanho atual.
TARGET_BUFFERS Novo tamanho em buffers, se um redimensionamento estiver
em andamento. Se RESIZE_STATE for STATIC, ento mostra o
tamanho atual.
PREV_SIZE Tamanho anterior do pool.
PREV_BUFFERS Nmero anterior de buffers do pool.

SQL> show parameter db_cache_size;
NAME TYPE VALUE

------------------------------------ ----------- --------
db_cache_size big integer 8M
SQL> alter system set db_cache_size=16M;
Sistema alterado.
SQL> show parameter db_cache_size;
NAME TYPE VALUE

----------------------------------- ----------- -------
db_cache_size big integer 16M
Redimensionando a SGA: Exemplos

O redimensionamento feito com o comando ALTER SYSTEM, e s
funcionar se houverem grnulos suficientes para satisfazer o aumento.
Diminuir o tamanho de um componente possvel, porm apenas se os
grnulos a serem liberados no houverem sido utilizados pelo componente.
Exemplo:

Prevendo Alteraes no Tamanho da SGA

possvel coletar estatsticas para prever o comportamento da instncia
com diferentes configuraes de tamanho da SGA. Faz-se isso atravs do
parmetro DB_CACHE_ADVICE. O parmetro dinmico e pode ter os valores:
OFF: estatsticas desligadas e memria para elas no alocada.
READY: estatsticas desligadas, mas a memria para o recurso
permanece alocada.
ON: estatsticas ligadas, e memria e CPU alocados para a coleta
dessas estatsticas. Algum overhead de CPU pode resultar do uso
desse recurso. Se esse parmetro for alterado de OFF para ON
depois do startup, pode ocorrer o erro ORA-04031 (inability to
allocate from the shared pool). O valor READY previne esse erro, pois
a memria j estar alocada.
Consultando estatsticas
Para consultar as informaes fornecidas pelo recurso do Advisory,
verifique a viso V$DB_CACHE_ADVICE:
Coluna Descrio
ID Nmero do buffer pool (de 1 a 8).
BLOCK_SIZE Tamanho do bloco em bytes para os buffers desse
pool. Valores possveis so: tamanho padro e
potncias de 2 (2048, 4096, 8192, 16384 ou 32768).
ADVICE_STATUS Estado do advisory
SIZE_FOR_ESTIMATE Tamanho do cache sendo previsto (em megabytes).
BUFFER_POOL_ESTIMATE Tamanho do cache sendo previsto (em buffers).
ESTD_PHYSICAL_READ_FACTOR Fator de leitura para esse tamanho de cache. a taxa
entre o nmero de leituras fsicas estimadas e o
nmero de leituras no cache atual. Se no houverem
leituras no cache atual, ento vale NULL.
ESTD_PHYSICAL_READS Nmero estimado de leituras fsicas para esse
tamanho de cache.

Gerenciando o Database Buffer Cache
O Processo Servidor e o Database Buffer Cache
Figura 5-2: Processo servidor e o database buffer cache
Quando um processo servidor necessita de um bloco, segue estes passos

para efetuar a leitura do bloco:
Primeiro, o servidor pesquisa o bloco no buffer cache utilizando uma
funo de hash (passo 1). Se bloco for encontrado, movido para
em direo ao final MRU na lista LRU. Isto uma leitura lgica, uma
vez que nenhum I/O ocorreu.
Se o bloco no for encontrado no buffer cache, o processo servidor
efetuar a leitura do bloco a partir do datafile. Primeiro, o servidor
pesquisa na lista LRU por um free block (passo 2).
Enquanto estiver pesquisando a lista LRU, o servidor pode mover dirty
blocks para a checkpoint queue (ou dirty list, passo 3).
Se a checkpoint queue exceder seu tamanho limite, o servidor sinaliza
para o DBWR remover (flush) dirty blocks do data buffer cache (passo
4).
Se o servidor no encontrar um bloco livre dentro de um limite de
pesquisa, sinaliza para o DBWR efetuar o flush (passo 4).
Aps um free block ser encontrado, o servidor efetua a leitura do
bloco a partir do datafile para o free block no database buffer cache
(passo 5). O servidor move o bloco a partir do final da LRU para o
centro da lista LRU.
Finalmente, se o bloco no estiver consistente, o servidor reconstri

uma verso anterior do bloco a partir do bloco corrente e dos
segmentos de undo.
O Processo DBWR e o Database Buffer Cache
Figura 5-3: Processo DBWR e o database buffer cache
O DBWn gerencia o buffer cache atravs da escrita dos dirty blocks para
os data files para garantir que existam free blocks para os servidores. O DBWR
responde a diferentes eventos em uma instncia Oracle:
O Checkpoint queue excedeu seu tamanho de limite.
Um processo servidor descobriu que a checkpoint queue atingiu seu
tamanho mximo, de forma que ele sinaliza ao DBWn para efetuar o
flush (passo 4). O DBWn escreve os blocos do checkpoint queue (passo
6 e 7).
O limite de pesquisa foi excedido.
Um processo servidor que no encontrou um free block na lista LRU
dentro do threshold de pesquisa sinaliza para o DBWn efetuar o flush
dos dirtu blocks (passo 4). O DBWn escreve os dirty blocks diretamente
da lista LRU (passo 8 e 7).
Timeout de 3 segundos.
A cada trs segundos o DBWn acorda para verificar a checkpoint
queue por blocos a serem escritos. O DBWn move dirty blocks da lista
LRU para a checkpoint queue (passo 9) de forma que possua blocos
suficientes para um full write buffer. Ento, o DBWn escreve os blocos
da checkpoint queue a partir do buffer cache para os datafiles (passo 6
e 7). Se no existir atividade de atualizao por perodos extensos de
tempo, o DBWn pode eventualmente escrever todos os dirty blocks

durante os timeouts de 3 segundos.
LGWR sinaliza um checkpoint.
Quando o LGWR sinalizar que um checkpoint ocorreu (passo 10), o
DBWn copia os dirty blocks a partir da LRU para a checkpoint queue
(passo 9) e escreve todos os blocos do checkpoint queue (passos 6 e 7).
Alter tablespace offline temporary ou alter tablespace begin backup.
Quando uma tablespace alterada para offline temporary ou seu
backup online iniciado, o DBWn copia os dirty blocks para esta
tablespace a partir da LRU para o checkpoint queue (passo 9) e escreve
os blocos da checkpoint queue (passo 6 e 7).
Drop object.
Quando um objeto removido, o DBWn primeiro efetua o flush dos dirty
blocks do objeto para disco (passos 8 e 7).
Clean shutdown
O banco de dados sofre um shutdown utilizando a opo Normal,
Immediate ou Transactional.

Metas e Tcnicas de Tuning

Metas de tuning:
Servidores encontrem os dados em memria.
Para OLTP 90% de hit ratio.
Tcnicas de tuning:
Aumentar o tamanho do buffer cache.
Utilizar mltiplos buffer pools.
Efetuar o cache de tabelas.
Evitar (bypass) o buffer cache em leituras de sort e parallel.
Metas de Tuning
Devido ao I/O fsico demorar um tempo significativo e aumentar a
demanda de CPU, a performance do Oracle pode ser melhorada quando os
servidores encontrarem a maioria dos blocos que necessitam em memria. A
estatstica que mede a performance do database buffer cache o cache hit
ratio. Esta estatstica a proporo do nmero de blocos encontrados em
memria para o nmero de blocos acessados. Quando o database buffer cache
muito pequeno, o sistema mais lento porque efetua muito mais I/Os.
Medidas de Diagnstico
Para monitorar o uso do buffer cache, verifique:
Eventos de espera nas vises V$SYSTEM_EVENT,
V$SESSIONS_EVENT e V$SESSION_WAIT.
V$SYSSTAT, STATSPSCK ou UTLBSTAT e UTLESTAT para verificar o
cache hit ratio.
Viso V$DB_CACHE_ADVICE.
Tcnicas de Tuning
O DBA monitora o buffer cache calculando o cache hit ratio a partir das
estatsticas coletadas pelo Oracle e analisando os eventos de espera.
Para aumentar o cache hit ratio, o DBA pode:

Aumentar o tamanho do buffer cache.
Utilizar mltiplos buffer pools para separar blocos por caractersticas
de acesso.
Efetua o cache de tabelas em memria.
Analizar os comandos SQL para garantir que estejam otimizados, de
forma a acessarem o menor nmero de blocos possvel.
Primeiro, o DBA determina a modificao no hit ratio quando buffers forem
adicionados ou removidos. Como regra geral, aumente o tamanho do buffer
quando:
O cache hit ratio for menor que 90%.
Existir memria adequada para outros processos, de forma que o

aumento no cause paginao de memria.
O aumento anterior do buffer cache foi efetivo. Aumentar o tamanho
do database buffer cache nem sempre aumenta a performance, uma
vez que caractersticas da aplicao podem evitar futuros
melhoramentos do hit ratio. Por exemplo, em grandes
datawarehouse ou sistemas de apoio deciso, os quais
rotineiramente utilizam muitos scans de grandes tabelas, a maioria
dos dados sofre leitura a partir do disco. Para estes sistemas, o
tuning do buffer cache menos importante e o tuning do I/O vital.
Se as caractersticas de acesso aos dados esto causando um cache hit
ratio baixo, o DBA pode ser capaz de aumentar a proporo definindo mltiplos
pools ou efetuando o cache de tabelas.
Observaes Tcnicas
Voc necessita considerar o impacto do cache do sistema operacional. Por
exemplo, o servidor Oracle pode exibir uma alta taxa de I/O fsico que no
aparece em nvel de sistema operacional. Isto pode significar que blocos
Oracle, removidos do buffer cache, esto mantidos no cache do sistema
operacional e podem ser acessados muito rapidamente. Entretanto, como
regra geral, melhor evitar o cache do sistema operacional.
Mais memria pode ser necessria, porque existe a duplicao dos
blocos Oracle na memria: uma no cache do sistema operacional e
uma no database buffer cache.
Os blocos Oracle mantidos no cache do sistema operacional utilizam
memria que pode ser utilizada por blocos no Oracle.
Existe um overhead de CPU da cpia dos blocos a partir do cache do
sistema operacional para o database buffer cache.

SQL> SELECT name, value

2 FROM v$sysstat
physical_reads,
3 WHERE db_block_gets,
name in ('session logical reads',
4 consistent_gets
'physical reads',
5 FROM v$buffer_pool_statistics;
'physical reads direct',
6 'physical reads direct (lob)');

Utilitrios de Diagnstico
Figura 5-4: Utilitrios de diagnstico
Descrio das Vises

As vises V$SYSSTAT e V$SESSTAT contm estatsticas utilizadas
para calcular o cache hit ratio:
V$BUFFER_POOL: descreve mltiplos buffer pools.
V$BUFFER_POOL_STATISTICS: descreve informaes de pools
individuais.
V$BH: descreve os blocos mantidos no buffer cache.

Statistic
SQL> SELECT 1 - (phy.value - Total
lob.value - Per
dir.value)Per
/
2 ses.value "CACHETrans
HIT RATIO"Logon Second
--------------------------
3 FROM v$sysstat ses, -------
v$sysstat---------
lob, ---------
physical
4 reads 15,238
v$sysstat phy, v$sysstat dir13.0 15,238.0
physical
5 WHERE reads
ses.name
direct = 'session863
logical reads'
0.7 863.0
Physical
6 AND reads direct(lob)
dir.name = 'physical 0 0
reads direct' 0
session
7 ANDlogical
lob.name
reads = 'physical
119,376reads 101.8
direct119,376.0
(lob)'
8 AND lob.name = 'physical reads';
CACHE HIT RATIO

---------------
.908160337
Medindo o Cache Hit Ratio

A partir da V$SYSSTAT:
A partir de STATSPACK:
O Oracle coleta estatsticas sobre o acesso aos dados e as armazena na
viso de performance dinmica V$SYSSTAT. Voc mede o cache hit ratio
utilizando quatro estatsticas de sistema:
physical reads: nmero de blocos que sofreram leitura a partir do
disco.
physical reads direct: nmero de leituras diretas do disco (no
necessitam de cache)
physical reads direct (lob): nmero de leituras diretas de LOBs.
session logical reads: nmero de requisies de leituras lgicas.
Calcule o hit ratio para o buffer cache com a seguinte frmula:
Hit Ratio = 1 (physical reads physical reads direct - physical reads
direct (lob) ) /
session logical reads
'session logical reads' fornece o nmero total de requisies por dados.
Este valor inclui requisies satisfeitas pelo acesso aos buffers em memria e
requisies que causaram um I/O fsico. Voc pode multiplicar o hit ratio por
100 para converter para um percentual.
Uma vez que estas estatsticas so coletadas somente a partir do
momento de startup da instncia, consulte-as durante cargas de trabalho
normal, mas no imediatamente aps o startup, porque como o buffer cache
est vazio quando a instncia inicia, existem mais leituras fsicas logo aps o
startup.

Diretrizes para Utilizao do Cache Hit Ratio

Picos de utilizao no hit ratio devido aos mtodos de acesso aos dados:
Full table scans.
Design dos dados ou aplicao.
Grandes tabelas com acesso randmico.
Distribuio desigual de cache hits.
Diretrizes para o aumento do tamanho do cache:
Cache hit ratio menor que 0.9.
No esto ocorrendo page faults inadequados.
O aumento anterior foi efetivo.
Aumentando o Cache Hit Ratio atravs da Reduo

de Buffer Cache Misses
1. Se o seu ratio for baixo, ou menor que 60% ou 70%, ento voc pode
querer aumentar o nmero de buffers no cache para melhorar a
performance.
2. Para tornar o buffer cache maior, aumente o valor do parmetro de
inicializao DB_CACHE_SIZE.
3. O DBA coleta novas estatsticas que estimam o ganho de performance
que resultou do aumento do tamanho do buffer cache. Com estas
estatsticas, voc pode estimar quantos buffers adicionar para o seu cache
se necessrio.
Removendo Buffers Desnecessrios quando o Cache

Hit Ratio estiver Alto
1. Se o seu ratio estiver alto, seu cache provavelmente grande o
suficiente para armazenar seus dados mais freqentemente acessados.
Neste caso, voc pode ser capaz de reduzir o tamanho do cache e
ainda manter uma boa performance.
2. Para tornar o buffer cache menor, reduzir o valor do parmetro de
inicializao DB_CACHE_SIZE. O valor mnimo para este parmetro 4.
3. O DBA coleta novas estatsticas para calcular a performance do buffer
cache baseada em um tamanho menor de cache. Um exame destas
estatsticas pode auxiliar a determinar quanto menor pode-se tentar
tornar o buffer cache sem adversamente afetar a performance.
Avaliando o Cache Hit Ratio

No continue aumentando DB_CACHE_SIZE mesmo quando o ltimo
aumento no efetuou diferena significativa no cache hit ratio. Isto
pode ser devido a forma que voc est acessando seus dados, ou
podem existir outras operaes que nem mesmo utilizem o buffer
pool. Por exemplo, o Oracle evita o buffer cache para ordenao e
parallel reads.

Alm disso, ao visualizar o cache hit ratio, tenha em mente que

blocos encontrados durante um full table scan no so colocados no
topo da lista LRU; portanto, scans repetitivos no fazem com que os
blocos fiquem no cache.
A soluo fica a nvel de design ou implementao, uma vez que
scan repetitivo sobre a mesma tabela grande raramente a soluo
mais eficiente para o problema. Pode ser melhor executar todo o
processamento em um nico passo ou adicionar ndices apropriados
para a tabela.
Em grandes bancos de dados executando uma aplicao OLTP, em
qualquer unidade de tempo determinada, a maioria das linhas so
acessadas uma ou zero vezes. Portanto, existe pouco ganho em
manter a linha (ou o bloco que a contm) em memria por um longo
perodo.
Finalmente, a relao entre cache hit ratio e o nmero de buffers
est longe de uma distribuio suave. Quando estiver efetuando o
tuning do buffer pool, evite a utilizao de buffers adicionais que
contribuem pouco ou nada para o cache hit ratio.
Aumentando o DB_CACHE_SIZE
Como regra geral, aumente DB_CACHE_SIZE sobre as seguintes
condies:
O cache hit ratio menor que 90%.
Existe memria adequada para outros processos, medida pela
quantidade de page faults.
O aumento anterior de DB_CACHE_SIZE foi efetivo.

Utilizando Mltiplos Buffer Pools
Figura 5-5: Utilizando mltiplos buffer pools
O DBA pode ser capaz de aumentar a performance do database buffer

cache criando mltiplos buffer pools. Os objetos so associados com um buffer
pool dependendo de como os objetos so acessados. O Oracle possui trs
buffer pools:
KEEP: utilizado para manter objetos em memria que provavelmente
sero reutilizados. Mantendo-se estes objetos em memria reduz-se
operaes de I/O.
RECYCLE: utilizado para eliminar blocos da memria que possuem
pouca chance de serem reutilizados. Removendo estes blocos da
memria rapidamente, o espao que seria utilizado por estes buffers
pode ser alocado para outros objetos.
DEFAULT: este pool sempre existe. equivalente a um buffer cache
em uma instncia sem pools dos tipos keep ou recycle.

DB_CACHE_SIZE
DB_RECYCLE_CACHE_SIZE
DB_KEEP_CACHE_SIZE
Definindo Mltiplos Buffer Pools

Latches so automaticamente alocados pelo Oracle.
Esses parmetros so dinmicos
Trs buffer pools podem ser definidos: default, recycle e keep. O fato de
blocos (buffers) serem alocados para o pool Keep no significa que tais blocos
sero mantidos em memria por mais tempo. Esse tempo depende da carga
de trabalho posta sobre esse pool. O procedimento deve ser de limitar o
nmero de tabelas que utilizam esse pool para maximizar o tempo de
permanncia dos blocos em memria.
Para uma tabela usar um pool especfico, defina na clusula STORAGE o
parmetro BUFFER_POOL, no comando CREATE TABLE ou ALTER TABLE (ver a
seguir).

CREATE INDEX{aluno.tdescontos_idx
BUFFER_POOL ... }
KEEP | RECYCLE | DEFAULT
STORAGE (BUFFER_POOL KEEP);
ALTER TABLE aluno.tdescontos

STORAGE (BUFFER_POOL RECYCLE);
ALTER INDEX aluno.tdescontos_idx

REBUILD
STORAGE (BUFFER_POOL KEEP);
Habilitando Mltiplos Buffer Pools
Clusula BUFFER_POOL
A clusula BUFFER_POOL utilizada para definir o buffer pool default para
um objeto. parte da clusula de STORAGE e vlida para os comandos CREATE
e ALTER de tabelas, clusteres e ndices. Os blocos de um objeto sem uma
configurao explcita de buffer pool vo para o buffer pool DEFAULT.
A sintaxe :
Quando o buffer pool default de um objeto alterado utilizando o

comando ALTER, todos os buffer que atualmente contm blocos do segmento
alterado permanecem no buffer pool onde estavam antes do comando ALTER.
Novos blocos lidos e quaisquer blocos que sejam removidos e recarregados
iro para o novo buffer pool.
Buffer pools so atribudos para um segmento, de forma que os objetos
com mltiplos segmentos podem possuir blocos em mltiplos buffer pools. Por
exemplo, uma tabela
index-organized pode possuir diferentes buffer pools definidos para o
segmento de ndice e de overflow.

SQL> ANALYZE table aluno.tcontratos estimate statistics;
Tabela analisada.
SQL>
SQL> SELECT table_name, blocks
2 FROM dba_tables
3 WHERE owner = 'ALUNO'
4 AND table_name = 'TCONTRATOS';
TABLE_NAME BLOCKS
------------------------------ ----------
TCONTRATOS 1
Diretrizes do Buffer Pool KEEP

Meta de tuning: manter blocos em memria.
Tamanho: manter todos ou quase todos os blocos.
Utilitrio: ANALYZE ... ESTIMATE STATISTICS
Meta de Tuning
A meta do buffer pool keep manter objetos em memria, evitando desta
forma operaes de I/O. O tamanho do buffer pool keep calculado pela soma
dos tamanhos de todos os objetos dedicados a este pool.
Dimensionamento
Utilize o comando ANALYZE...ESTIMATE STATISTICS para obter o tamanho
de cada objeto. A high water mark sempre exata, mesmo se voc utilizar
estatsticas estimadas. Some a coluna BLOCKS a partir de DBA_TABLES,
DBA_INDEXES e DBA_CLUSTERS para obter o total de blocos necessrios.
Dependendo das caractersticas de acesso aos dados e da quantidade de
memria disponvel, voc pode no querer manter todos os blocos destes
objetos no buffer pool. Freqentemente voc pode reduzir o tamanho do buffer
pool keep e ainda manter um hit ratio alto. Estes blocos podem ser alocados
para outros buffer pools.
O DBA deve monitorar os objetos no pool KEEP que aumentem de
tamanho. Um objeto pode no mais caber no buffer pool keep, de forma que
voc comea a perder blocos do cache.

SQL> SELECT name,

2 1 - (physical_reads / (db_block_gets +
3 consistent_gets)) "HIT RATIO"
4 FROM v$buffer_pool_statistics
5 WHERE db_block_gets + consistent_gets > 0;
NAME HIT RATIO

-------------------- ----------
DEFAULT ,979758302
KEEP .983520845
RECYCLE .503866235
Calculando o Hit Ratio para Mltiplos Pools
Coluna Descrio
SET_MSIZE Tamanho mximo permitido.
CNUM_REPL Nmero atual de buffers em reposio.
CNUM_WRITE Nmero atual de buffers na lista de escrita.
CNUM_SET Nmero total atual de buffers para esse pool.
BUF_GOT Nmero de buffers reservados para esse pool.
SUM_WRITE Nmero de buffers escritos pelo DBWn nesse pool.
SUM_SCAN Nmero de buffers pesquisados pelo DBWn nesse pool.
FREE_BUFFER_WAIT Esperas por blocos livres nesse pool.

Identificando Segmentos Candidatos para cada

Pool
Keep Pool:
Blocos repetidamente acessados.
Tamanho do segmento < 10% do tamanho do buffer pool default.
Recycle Pool:
Blocos no so reutilizados fora da transao.
Tamanho do segmento > 2 vezes o tamanho do buffer pool default.
Lembre que cada objeto mantido em memria implica em uma troca.
Embora seja benfico manter blocos freqentemente acessados, reter blocos
pouco freqentemente utilizados resulta em menos espao disponvel para
outros blocos mais ativos.

SQL> SELECT id, name, block_size, buffers

2 FROM v$buffer_pool
3 WHERE id <> 0;
ID NAME BLOCK_SIZE BUFFERS

---------- -------------------- ---------- ----------
1 KEEP 8192 14000
2 RECYCLE 8192 2000
3 DEFAULT 8192 1002
Vises do Dicionrio com Buffer Pools
Vises do Dicionrio de Dados

Estas vises do dicionrio possuem uma coluna BUFFER POOL que indica o
buffer pool default para um determinado objeto:
USER_, DBA_SEGMENTS
USER_, ALL_, DBA_CLUSTERS
USER_, ALL_, DBA_INDEXES
USER_, ALL_, DBA_TABLES
USER_, ALL_, DBA_OBJECT_TABLES
USER_, ALL_, DBA_ALL_TABLES
A viso V$BUFFER_POOL descreve os buffer pools alocados. As colunas
desta viso exibem:
O tamanho de cada buffer, em bytes.
O nmero de buffers.

SQL> SELECT event,

name, value
total_waits
2 FROM v$system_event
v$sysstat
3 WHERE event
name =in
'free buffer inspected';
4 ('free buffer waits', 'buffer busy waits');
NAME VALUE
----------------------------------------
EVENT TOTAL_WAITS ----------
free buffer inspected-----------
-------------------- 17197
buffer busy waits 16

free buffer waits 337
Outros Indicadores de Performance

V$SYSSTAT:
V$SYSTEM_EVENT:
O buffer cache hit ratio sem dvida a medida mais til da performance
do buffer cache. Entretanto, existem alguns outros indicadores.
Estatsticas de Espera
Voc deve considerar o aumento do tamanho do buffer cache se o valor
estiver alto ou aumentando para a estatstica de sistema free buffer inspected.
Esta estatstica o nmero de buffers verificados para encontrar um buffer
livre. Buffers so pulados porque so do tipo dirty ou pinned.
Eventos de Espera
Voc pode descobrir se houve esperas por buffers a partir de
V$SYSTEM_EVENT ou V$SESSION_WAIT. No existem esperas se um evento
no ocorre. Trs eventos principais devem ser acompanhados:
Buffer Busy Waits: indica que mltiplos processos tentaram acessar
um mesmo buffer concorrentemente. Consulte a viso V$WAITSTAT
para verificar as estatsticas de espera de cada classe de buffer.
Classes que normalmente apresentam esperas so:
blocos de dados (data blocks): conteno em blocos de tabelas e
ndices (mas no nos cabealhos)
Verifique comandos SQL que utilizem ndices no seletivos.
Verifique a existncia de ndices right-hand (aqueles onde muitos
processos inserem no mesmo ponto do ndice).
Considere o uso de gerenciamento de espao automtico, ou o
aumento de free-lists, para evitar que mltiplos processos
insiram no mesmo bloco ao mesmo tempo.
A viso V$SESSION_WAIT informa o nmero de bloco e arquivo
(colunas P*) que esto causando conteno. Com isso pode-se
saber a quais objetos eles pertencem.
Cabealhos de Undo: mostra a conteno em cabealhos de
segmentos de undo.

Blocos de Undo: mostra a conteno em blocos dos segmentos de

undo.
Free Buffers Inspected: medida de quantos buffers da lista LRU so

inspecionados por um processo que procura por um buffer livre antes
de acionar o DBWn para gravar e liberar novos buffers.
Free Buffer Waits: indica que um processo acionou o DBWn para
liberar buffers, aps no encontrar buffers livres. Procure maneiras
de acelerar as escritas feitas pelo DBWn. Isso tambm indica que o
buffer cache est muito pequeno. Examine os hit ratios para
determinar se um aumento necessrio.

Efetuando o Cache de Tabelas

Habilite o cache durante full table scans:
Criando a tabela com a clusula CACHE.
Alterando a tabela com a clusula CACHE.
Utillizando o hint CACHE em uma consulta.
Utilize o pool Keep
Quando o servidor recupera blocos utilizando um full table scan, os blocos
vo para o final da lista LRU. Os blocos sero utilizados na prxima vez que um
bloco livre for necessrio, de forma que no ficaro disponveis para outros
processos. Voc pode decidir efetuar o cache de tabelas inteiras no final da
lista MRU.
Voc pode alterar este comportamento tomando uma das medidas citadas
acima.
Se voc utilizar um destes mtodos o servidor Oracle coloca os blocos da
tabela mais perto do final MRU da lista LRU. Utilize a clusula CACHE quando
voc criar pequenas tabelas lookup utilizadas por muitos usurios. Voc pode
sobrecarregar o buffer cache se voc possuir muitas tabelas em cache.

Free Lists
A free list para um objeto mantm uma lista de blocos que esto
disponveis para inseres.
O nmero de free lists para um objeto pode ser configurado
dinamicamente.
Sistemas de uma nica CPU no se beneficiam muito de mltiplas
free lists.
A meta de tuning garantir que um objeto possua suficiente free
lists para minimizar conteno.
O uso de Automatic Free Space Management elimina a necessidade
de free lists e diminui a conteno.
Utilizando Free Lists

Quando uma operao de insero sobre um objeto ocorrer, a free list
utilizada para determinar quais blocos esto disponveis para inseres. Muitos
processos servidores podem concorrer pela mesma free list se muitos inserts
estiverem ocorrendo. Isto resulta em conteno na free list de forma que
processos servidores tero que aguardar.
Sistemas com uma nica CPU no recebem grande benefcio a partir de
mltiplas free lists, porque a CPU gerencia um processo de cada vez. Mesmo
em um sistema com uma nica CPU, adicionar free lists pode garantir que o
processador seja utilizado mais eficientemente.
A meta de tuning geral para free lists garantir que exista um nmero
suficiente para minimizar conteno sobre muitos processos server.

Diagnosticando Conteno na Free List
Figura 5-6: Diagnosticando conteno na free list
Vises de Performance Dinmica

As vises de performance dinmica, V$SESSION_WAIT, V$WAITSTAT e
V$SYSTEM_EVENT, so utilizadas para diagnosticar problemas de conteno de
free list.
A viso DBA_SEGMENTS do dicionrio de dados utilizada para identificar
os objetos que necessitam ser modificados para aumentar o nmero de free
lists.
No existem parmetros de inicializao a configurar para minimizar a
conteno de free list. A palavra chave FREELISTS utilizada em nvel de
segmento.
Critrios de Diagnstico
Voc pode consultar as vises V$WAITSTAT e V$SYSTEM_EVENT para
determinar se existe conteno de free list. Se nmeros altos forem
retornados, voc deve identificar o objeto ou objetos.
Consulte a viso V$WAITSTAT:

SQL> SELECT event,

class, total_waits
count, time
v$waitstat
3 WHERE class
event = 'buffer
'segmentbusy
header';
waits';
Consulte a viso V$SYSTEM_EVENT:

Para reduzir esperas de buffer busy sobre:
Blocos de dados: modifique os parmetros de storage PCTFREE e/ou
PCTUSED; verifique a existncia de ndices right-hand (ndices que
so inseridos no mesmo ponto por muitos processos); aumente o
parmetro de storage INITRANS; reduza o nmero de linhas por
bloco.
Header de segmento: utilize free lists ou aumente o nmero de free
lists; utilize free lists groups (mesmo em um ambiente com uma
nica instncia, isto pode fazer diferena).
Blocos de free list: adicione mais free lists.

Resolvendo Conteno de Free List

Para resolver conteno de free list, voc deve identificar o objeto cuja
free list est em conteno.
Para identificar o objeto

Determine o FILE, BLOCK e ID para o qual a conteno na free list
est ocorrendo consultando a viso V$SESSION_WAIT.
Identifique o segmento e determine o nmero de free lists que
existem atualmente para este segmento consultando a viso
SQL> SELECT s.segment_name, s.segment_type, s.freelists, w.wait_time,

2 w.seconds_in_wait, w.state
3 FROM dba_segments s, v$session_wait w
4 WHERE w.event = 'buffer busy waits'
5 AND w.p1 = s.header_file
6 AND w.p2 = s.header_block;

DBA_SEGMENTS:
Altere o objeto.
Para aumentar o nmero de free lists para o objeto, voc deve alterar o
objeto utilizando um valor maior para a palavra chave FREELISTS.
Mova o objeto para uma tablespace que utilize Automatic Segment
Space management.

SQL> CREATE
SQL> CREATE TABLESPACE
TABLE aluno.nova_tabela
aluno_data
22 DATAFILE
(ID NUMBER(10))
'/oracle/oradata/tuning/aluno_data01.dbf' SIZE 1M
33 EXTENT
TABLESPACE aluno_data;
MANAGEMENT LOCAL
4 SEGMENT SPACE MANAGEMENT AUTO;
Gerenciamento Automtico de Espao de

Segmentos (Automatic Segment Space
Management)
Especifique o gerenciamento automtico de espao na criao da
tablespace.
Crie os segmentos a terem seu espao gerenciado automaticamente
dentro dessas tablespaces.
Recursos do gerenciamento automtico de espao:

Gerencia automaticamente o espao livre dentro de segmentos do
banco.
Rastreia espao livre e usado dentro do segmento atravs de
bitmaps, ao invs de free lists.
Prov melhor uso do espao, principalmente para objetos com
grande variao no tamanho do registro.

Exerccios 5
O objetivo desta seo de exerccios utilizar os utilitrios de diagnstico
disponveis para monitorar e efetuar o tuning do database buffer cache.
1. A partir do SQL*Plus, conecte-se como PERFSTAT e crie um snapshot.
como ALUNO e execute o script lab05_1.sql.
3. Conecte-se como SYSTEM e efetue a medida do hit ratio para o database
buffer cache.
4. Quando o script tiver finalizado, a partir do SQL*Plus, conecte-se como
PERFSTAT e crie outro snapshot.
5. Utilize o resultado do relatrio para obter o cache hit ratio.
6. Dimensione o buffer pool keep para armazenar as tabelas ALUNO.S_EMP
e ALUNO.S_DEPT.
7. Habilite as tabelas ALUNO.S_EMP e ALUNO.S_DEPT para efetuar o cache
no pool keep.

Espao para anotaes


6. Efetuando o Tuning do
Redo Log Buffer

Efetuando o Tuning do Redo Log Buffer
Objetivos
Determinar se processos esto aguardando por espao no redo log
buffer.
Dimensionar o redo log buffer apropriadamente.
Reduzir operaes de redo.

Redo Log Buffer
Figura 6-1: Redo log buffer
Contedo do Redo Log Buffer

Processos do servidor Oracle copiam entradas de redo a partir do espao
de memria de usurio para o redo log buffer para cada comando DML ou DDL.
As entradas de redo contm as informaes necessrias para reconstruir
ou desfazer modificaes efetuadas para o banco de dados por operaes DML
ou DDL. So utilizadas para recuperao do banco de dados. Ocupam espao
contnuo e seqencial no buffer.
Entradas de Redo e LGWR

O processo LGWR escreve o redo log buffer para o online redo log file
ativo (ou membros do grupo ativo) no disco. Escreve todas as entradas de redo
copiadas para o buffer desde a ltima escrita.
O redo log buffer um buffer circular. Desta forma, processos servidores
podem copiar novas entradas sobre as entradas no redo log buffer que foram
escritas para disco. O LGWR normalmente escreve rpido o bastante para
garantir que espao esteja sempre disponvel no buffer para novas entradas.

SQL> SELECT 'V$PARAMETER' "Table name", name,

to_number(value,'9999999') "Value"
2 FROM v$parameter
3 WHERE name = 'log_buffer'
4 UNION
5 SELECT 'V$SGASTAT' "Table name", name, bytes
6 FROM v$sgastat
7 WHERE name = 'log_buffer';
Table name NAME Value

----------- --------------- ----------
V$PARAMETER log_buffer 262144
V$SGASTAT log_buffer 262144
Dimensionando o Redo Log Buffer

Parmetro LOG_BUFFER.
Valor default: 512Kb ou (128Kb * CPU_COUNT), o que for maior.
Tamanho
Valores maiores reduzem I/O para o log file, particularmente se
transaes forem longas ou numerosas, pois quanto menor for o
redo log buffer, mais rpido ser preenchido um tero de sua
capacidade (o que causa uma escrita de LGWR).
Comandos COMMIT freqentes iro limpar o buffer, levando desta forma a
um tamanho menor para o buffer.
Exemplo:

Figura 6-2: Efetuando tuning do redo log buffer
Diagnosticando Problemas
Em mquinas com processadores rpidos e discos relativamente lentos,
os processadores podem preencher o resto do redo log buffer enquanto o
processo LGWR move uma poro do buffer para disco. Por esta razo, um
buffer maior diminui a probabilidade de novas entradas colidirem com a parte
do buffer que ainda est sendo escrita.
Processos servidores podem requisitar espao do redo log buffer para
escrever novas entradas e no encontrar nenhuma. Eles tero que aguardar
que o LGWR descarregue o buffer para disco.
Meta de Tuning
Efetuar o tuning do redo log buffer significa garantir que exista espao
suficiente para que requisies por espao de log de processos servidor sejam
satisfeitas. Entretanto, muito espao para o buffer pode reduzir a quantidade
de memria que pode ser alocada para outras reas.

SQL> SELECT sid, event, seconds_in_wait, state

2 FROM v$session_wait
3 WHERE event = 'log buffer space%';
SID EVENT SECONS_IN_WAIT STATE
---- ------------------- -------------- -------
15 log buffer space 110 WAITING
Utilitrios de Diagnstico para Tuning do Redo

Log Buffer
Figura 6-3: Utilitrios de diagnstico para tuning do redo log buffer
Vises Dinmicas
A viso V$SESSION_WAIT indica atravs do evento Log Buffer Space
se existem quaisquer esperas por espao no log buffer porque a
sesso est escrevendo dados para o log buffer mais rapidamente
que o LGWR pode escrev-los.
SECONDS_IN_WAIT para o evento Log Buffer Space

O valor de SECONDS_IN_WAIT do evento Log Buffer Space indica o tempo
gasto aguardando por espao no redo log buffer porque o log switch no
ocorre. Isto um indicativo que os buffers esto sendo preenchidos mais
rapidamente do que o LGWR os est escrevendo e pode tambm indicar
conteno de I/O em disco sobre os redo log files.
Redo Buffer Allocation Retries

A estatstica Redo Buffer Allocation Retries na viso V$SYSSTAT reflete o
nmero de vezes que um processo usurio aguardou por espao no redo log
buffer para copiar novas entradas sobre as entradas que foram escritas para
disco. O LGWR normalmente escreve rpido o suficiente para garantir que

SQL>
SQL>SELECT
SELECTname,
name,value
value
2 2 FROM
FROMv$sysstat
v$sysstat
3 3 WHERE
WHEREname
name= ='redo
'redobuffer
log space
allocation
requests';
retries';
espao esteja sempre disponvel no buffer para novas entradas, mesmo

quando o acesso para o redo log crtico.
Nota: a viso V$SYSSTAT exibe outra estatstica, Redo Log Space Requests:
Esta estatstica indica que o log file ativo est cheio e o servidor Oracle
aguardando por alocao de espao em disco para entradas de redo. Espao
criado efetuando um log switch.

SQL> SELECT name,

sid, event,
value seconds_in_wait, state
2 FROM v$sysstat
v$session_wait
3 WHERE event
name in= 'log buffer space';
4 ('redo buffer allocation retries',
5 'redo entries');
Diretrizes para Tuning do Redo Log Buffer

No devem existir esperas por Log Buffer Space:
O valor para Redo Buffer Allocation Retries deve estar perto de 0; o
nmero deve ser menor que 1% de Redo Entries.
Redo Buffer Allocation Retries Statistic Ratio

O valor de Redo Buffer Allocation Retries deve estar perto de 0. O nmero
de Redo Buffer Allocation Retries no deve ser maior que 1% das Redo Entries.
Se este valor estiver aumentando consistentemente, processos tiveram que
aguardar por espao no buffer. A espera pode ser causada devido ao log buffer
ser muito pequeno, pelo checkpoint, ou pelo log switch.
Aumente o tamanho do redo log buffer, se necessrio, modificando o
valor do parmetro de inicializao LOG_BUFFER.
Alternativamente, melhore o processo de checkpointing ou archiving.
O redo log buffer normalmente pequeno comparado com a Shared
Global Area (SGA). Um modesto aumento pode melhorar significativamente a
performance.
SECONDS_IN_WAIT
O tempo de espera (SECONDS_IN_WAIT) tambm deve ser zero.
Considere:
Aumentar o tamanho do log buffer se este estiver pequeno.
Mover os log files para discos mais rpidos como striped disks.

SQL> SELECT event,total_waits,time_waited,average_wait

3 WHERE event like 'log file switch completion%';
Diretrizes para Tuning do Redo Log Buffer

(continuao)
Figura 6-4: Diretrizes para tuning do redo log buffer
Aumente o valor de LOG_BUFFER at a proporo (ratio) ficar estvel.

O tamanho de LOG_BUFFER deve ser um mltiplo do tamanho de bloco do
sistema operacional.
Investigaes Futuras
Investigue as razes porque o LGWR est lento em liberar buffers:
Existe conteno de I/O de disco nos redo log files. Verifique se os
redo log files esto armazenados em dispositivos rpidos e
separados.
Na viso V$SYSTEM_EVENT, o evento Log File Switch Completion
identifica eventos de espera devido a log switches.
Aumente o tamanho dos redo log files e/ou adicione novos grupos.
O DBWn no havia completado o checkpoint do arquivo quando o
LGWR necessitou do arquivo novamente. O LGWR teve que esperar.
Verifique no arquivo alert.log a existncia da mensagem
CHECKPOINT NOT COMPLETE.

SQL> SELECT event,total_waits,time_waited,average_wait

3 WHERE event like 'log file switch (arch%';
(check%';
Verifique na viso V$SYSTEM_EVENT o nmero de ocorrncias do

evento log file switch (checkpoint incomplete) que identifica as
esperas de log file switch devido a checkpoints incompletos.
Verifique o tamanho e o nmero de grupos de redo log.
O archiver no pode escrever para os archived redo log files ou no
pode realizar a operao de archive rpido o bastante. Portanto, o
LGWR foi impedido de escrever.
Confirme que o dispositivo de archive no est cheio.
Adicione grupos de redo log.
Verifique na viso V$SYSTEM_EVENT o nmero de ocorrncias do
evento log file switch (archiving needed) que identifica as esperas
de log file switch devido a falhas de archive.
Regule a velocidade do arquivamento.
O processo LGWR inicia um novo processo ARCn sempre que o
nmero atual de processos ARCn for insuficiente para tratar a carga.
Se voc antecipar uma carga crtica para o archiving, como durante
bulk loading de dados, voc pode especificar mltiplos processos
archiver com o parmetro de inicializao
LOG_ARCHIVE_MAX_PROCESSES.

Reduzindo Operaes de Redo
Modo NOLOGGING
A opo NOLOGGING:
Aplica-se a tabelas, parties, tablespaces e ndices.
No registra modificaes para os dados no redo log buffer (algum
log mnimo ainda efetuado, para operaes como alocao de
extenses).
No especificado como um atributo a nvel de comando INSERT,
mas ao invs disso especificado na utilizao do comando ALTER
ou CREATE para a tabela, partio, ndice ou tablespace.
O modo configurado antes da carga e reconfigurado para LOGGING
quando a carga completada (se uma falha de mdia ocorrer antes
de um backup ser efetuado, ento todas as tabelas, parties e
ndices que foram modificados podem ficar corruptos).
Comandos SQL que podem Utilizar o Modo

NOLOGGING
Embora voc possa configurar o atributo NOLOGGING para uma tabela,
partio, ndice ou tablespace, o modo NOLOGGING no se aplica para cada
operao sobre o objeto para o qual o atributo est configurado.
CREATE TABLE ... AS SELECT.
CREATE INDEX.
ALTER INDEX ... REBUILD.
Os seguintes comandos jamais sero afetados pelo atributo NOLOGGING:
UPDATE, DELETE, INSERT e vrios comandos DDL no listados acima.

Gerenciamento Automtico de Memria

Compartilhada
Nas verses anteriores, o administrador do banco de dados era obrigado a
especificar o tamanho para todos os diferentes componentes da SGA, incluindo
os parmetros SHARED_POOL_SIZE, DB_CACHE_SIZE, JAVA_POOL_SIZE e
LARGE_POOL_SIZE.
O banco de dados Oracle 10g inclui a funcionalidade Automatic Shared
Memory Management que simplifica significativamente o gerenciamento da
memria SGA. No 10g, o DBA pode apenas especificar o total de memria
disponvel para a SGA de uma instncia utilizando o parmetro de inicializao
SGA_TARGET. Com isto, o Oracle ir gerenciar automaticamente a distribuio
deste pedao de memria entre os componentes da SGA, garantindo sempre a
maior e mais efetiva utilizao da memria.
Informar um tamanho para o parmetro SGA_TARGET reflete no
gerenciamento de tamanho de memria dos seguintes componentes:
Fixed SGA
Log Buffer
Shared Pool
Java Pool
Buffer Cache
Buffer Cache com tamanho de blocos diferentes
Streams Pool
Se o parmetro SGA_TARGET estiver configurado com um valor maior ao
SGA_MAX_SIZE, ento o SGA_MAX_SIZE ser redirecionado automaticamente
para comportar o SGA_TARGET. O SGA_TARGET pode ser modificado
dinamicamente.

Exerccios 6
1. Conecte-se como SYSTEM e efetue a medida do ratio para as requisies
de espao para o redo log buffer.
2. Que solues poderiam ser aplicadas se o ratio estivesse ruim?
3. Acompanhe o instrutor na modificao do tamanho do parmetro
apropriado.

Espao para anotaes

7. Configurao do Banco de
Dados e Detalhes de I/O

Configurao do Banco de Dados e Detalhes de I/O
Objetivos
Diagnosticar o uso inapropriado de tablespaces SYSTEM, TEMP, DATA
e INDEX.
Detectar problemas de I/O.
Garantir que arquivos sejam distribudos para minimizar conteno
de I/O.
Utilizar striping onde apropriado.
Efetuar o tuning de checkpoints.
Efetuar o tuning de I/O de processos DBWn.

Estatsticas de I/O para Diferentes Tipos de

Arquivo Oracle
Oracle File I/O
Processo Databas Log Archive Control
e
CKPT read/writ read/writ
e e
DBWn write
LGWR write read/writ
e
ARCn read write read/writ
e
SERVER read/writ read write read/writ
e e
Diretrizes de Performance
Voc pode melhorar a performance do banco de dados configurando os
discos.
Existem regras bsicas de performance:
Manter I/O de disco em um nvel mnimo.
Distribuir sua carga de disco atravs de dispositivos e controladoras.
Usar tablespaces temporrias quando apropriado.
A tabela acima exibe os componentes bsicos de disco e o throughput de
I/O de processos background.
Os processos servidores executaro as tarefas de leitura em redo logs,

escrita em archived logs e leitura e escrita em control files apenas em
determinadas operaes de backup e recovery. Assim, podemos apresentar
uma tabela diferente, apenas com as operaes mais comuns:
Oracle File I/O
Processo Databas Log Archive Control
e
CKPT write write
DBWn write
LGWR write
ARCn read write read/writ
e
SERVER read

Utilizao de Tablespace
Reserve a tablespace SYSTEM para objetos do dicionrio de dados.
Separe tabelas e ndices em tablespaces diferentes.
Crie tablespaces separadas para undo.
Armazene colunas LOB em tablespaces separadas.
Crie uma ou mais tablespaces temporrias. Crie grupos de
tablespaces temporrias.
Utilize Tablespaces Gerenciadas Localmente em sistemas OLTP.
Diretrizes
Cada banco de dados deve possuir tablespaces especficas para:
Objetos do dicionrio de dados.
Segmentos de undo.
Segmentos temporrios.
Tabelas.
ndices.
LOBs.
A maioria dos bancos de dados de produo possuem muito mais
tablespaces do que isto, mas o princpio separar dados de diferentes tipos e
com diferentes utilizaes para propsitos de administrao interna e backup.
A tablespace SYSTEM contm somente objetos do dicionrio de dados
criados pelo SYS. Nenhum outro usurio deve possuir permisso para criar
objetos nela.
Lembre-se que stored objects como packages e triggers de banco de
dados formam parte do dicionrio de dados.
Segmentos de undo devem utilizar tablespaces exclusivas (segmentos de
undo obrigatoriamente ficam em tablespaces de undo).
Quando voc cria usurios, voc aloca uma tablespace temporria para
quaisquer ordenaes em disco que sejam necessrias, ou para tabelas
temporrias. Estas reas de sort devem estar separadas de outros objetos do
banco de dados. Se o usurio no possuir uma tablespace temporria, as reas
de sort utilizam a tablespace SYSTEM.
Tabelas e ndices devem ser separados em tablespaces diferentes, uma
vez que ndices e tabelas freqentemente recebem inseres e leituras
simultaneamente.
Para aplicaes tipo OLTP com grande carga de trabalho, tablespaces
gerenciadas pelo dicionrio de dados causam problemas de conteno, porque
o dicionrio de dados deve ser acessado para operaes de gerenciamento de
espao, como alocao de extenses. Em tablespaces gerenciadas localmente
(Locally Managed Tablespaces), no h acesso ao dicionrio de dados nessas
operaes, e por isso menos conteno.

Gerenciando Tablespaces
Dois novos parmetros foram introduzidos no Oracle 9i que tem por
funcionalidade automatizar o armazenamento e gerenciamento de
tablespaces.
- Tablespaces Gerenciadas Localmente (Locally Managed Tablespaces

LMT) implementada pela adio da clusula EXTENT MANAGEMENT
LOCAL na definio da tablespace. LMT tablespaces automatizam o
gerenciamento de extenses e remove a capacidade de se especificar o
parmetro de armazenamento NEXT.
- Gerenciamento Automtico de Espao (Automatic Space Management

ASM) implementada pela adio da clusula SEGMENT SPACE
MANAGEMENT AUTO na definio da tablespace. ASM tablespaces
automatizam o gerenciamento da freelist e remove a capacidade de
especificar os parmetros PCTFREE, PCTUSED, FREELISTS e FREELISTS
GROUPS.
Exemplo de criao de uma tablespace com os novos parmetros.
CREATE TABLESPACE aluno_asm

DATAFILE '/oracle/oradata/tuning/aluno_asm01.dbf' SIZE 50M
EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT AUTO;

Tablespaces com tamanhos de Blocos

Diferentes
A partir da verso 9i, o Oracle comeou a suportar tamanhos de blocos
diferentes no mesmo banco de dados.
A palavra-chave BLOCKSIZE foi adicionada ao comando CREATE
TABLESPACE. Os valores vlidos so os seguintes:
- 2k
- 4k
- 8k
- 16k
- 32k (depende do sistema operacional)
CREATE TABLESPACE TBS01 ... BLOCKSIZE 16K;
CREATE TABLESPACE TBS02 ... BLOCKSIZE 8192;
CREATE TABLESPACE TBS03 ... BLOCKSIZE 2K;
O campo BLOCK_SIZE foi adicionado a viso DBA_TABLESPACES.

O parmetro DB_BLOCK_SIZE ainda necessrio no arquivo init.ora
durante a criao do banco. Este valor o tamanho default para novas
tablespaces assim como o tamando para a tablespace system, a tablespace de
undo e todas as tablespaces temporrias.
Como nas verses anteriores o parmetro DB_BLOCK_SIZE no pode ser
modificado sem recriar o banco novamente.
Todas as parties de objetos particionados devem estar em tablespaces
com tamanhos de blocos iguais.
ndices podem estar em tablespaces com tamanho de bloco diferente do
que a tabela correspondente.
Novos parmetros foram criados para suportar essa nova caracterstica:
- DB_2K_CACHE_SIZE Buffer Pool para objetos com tamanho de bloco

2k.
4k.
8k.


16k.
32k.

Distribuindo Arquivos Atravs de Dispositivos

Separe arquivos de dados e redo log files.
Divida dados de tabela.
Reduza I/O de disco no relacionado com o Oracle.
Diretrizes
Em geral para reduzir a atividade em um disco sobrecarregado,
mova um ou mais dos seus arquivos muito acessados para um disco
menos ativo.
Redo log files so escritos seqencialmente pelo processo LGWR.
Coloque os redo log files em um disco com nenhuma outra atividade
ou com pouca incidncia de leituras e escritas. O processo
background LGWR pode escrever muito mais rpido se no houver
atividade concorrente.
Se os usurios acessarem uma tabela grande concorrentemente, a
diviso (striping) atravs de data files e discos pode ajudar a reduzir a
conteno.
Tente eliminar o I/O no relacionado com Oracle nos discos que
contenham arquivos do banco de dados. Isto til tambm na
otimizao de acesso para redo log files e permite a voc monitorar
toda a atividade de data file nestes discos com a viso de
performance dinmica V$FILESTAT.
Conhecendo os tipos de operaes que predominam em sua aplicao e a
velocidade com a qual seu sistema pode processar os I/Os correspondentes,
voc pode escolher o layout de disco que ir maximizar a performance.

ALTER TABLE tablename

ALLOCATE EXTENT (DATAFILE 'filename' size 10M);
Striping de Arquivos Oracle

Striping de sistema operacional:
Utilize software de striping do sistema operacional ou RAID.
Decida o tamanho correto do stripe.
Striping manual:
Utilize o comando CREATE TABLE ou ALTER TABLE com a clusula
ALLOCATE.
Striping de Sistema Operacional

Seu sistema operacional pode permitir o striping, e o que parece ser um
nico arquivo contnuo est atualmente dividido entre dispositivos. Por
exemplo, voc pode utilizar o software de striping do sistema operacional,
como um gerenciador de volume lgico.
Escolha o tamanho correto do stripe dependendo do tamanho de bloco do
Oracle e do parmetro de inicializao DB_FILE_MULTIBLOCK_READ_COUNT.
A variedade mais comum de striped file system em UNIX RAID
(abreviao para Redundant Array of Inexpensive Disks). Diferentes nveis de
RAID striping possuem nveis variantes de verificao nativa de segurana.
Striping Manual
Voc pode criar tablespaces de forma que sejam compostas de mltiplos
arquivos, cada um em um disco separado. Voc ento cria tabelas e ndices de
forma que sejam divididos atravs destes mltiplos arquivos.
Voc pode efetuar o stripe:
Criando objetos com MINEXTENTS > 1, onde cada extenso
ligeiramente menor que os striped data files.
Alocando extenses para um arquivo explicitamente.
Utilizando Striping
Se seu sistema operacional oferecer striping, voc normalmente deve
obter vantagens dele. Voc necessita pensar sobre o tamanho do stripe, o qual
deve normalmente ser um mltiplo do valor que voc configurou para
DB_FILE_MULTIBLOCK_READ_COUNT.
Mantenha em mente que o striping manual uma tarefa de trabalho
intensivo. O Oracle preenche as extenses que voc criou uma aps a outra.
Em um determinado momento, uma extenso provavelmente estar muito
ativa e as outras estaro menos ativas. Se voc estiver utilizando parallel

query e efetuando muitos full table scans, ento o striping manual pode valer a
pena.

SQL> SELECT name, value

2 FROM v$sysstat
3 WHERE name like '%table scans%';
NAME VALUE
------------------------------ ----------
table scans (short tables) 9697
table scans (long tables) 48
table scans (rowid ranges) 0
table scans (cache partitions) 0
table scans (direct read) 0
Efetuando Tuning de Operaes de Full Table

Scan
Investigue a necessidade de full table scans.
Especifique o parmetro de inicializao
DB_FILE_MULTIBLOCK_READ_COUNT:
Para determinar o nmero de blocos do banco de dados que o
servidor l a cada vez.
Para influenciar o plano de execuo do otimizador baseado em custo.
Monitore full table scans de longa durao com a viso
V$SESSION_LONGOPS.
Investigando Full Table Scans

Se existir uma alta atividade em um disco, freqentemente existe uma
consulta que est causando o problema para a qual o tuning ainda no foi
efetuado. A meta dos testes de performance aumentar a eficcia com que os
dados so acessados.
A seguinte consulta fornece uma viso geral de como os vrios full table
scans esto sendo executados:
Os valores para table scans (long tables) e table scans (short tables)
esto relacionados com full table scans.
Se o nmero de table scans (long tables) for alto, ento um grande
percentual de tabelas foram acessadas sem ndice em lookups. Sua aplicao
pode necessitar de tuning ou ndices devem ser adicionados. Garanta que os
ndices apropriados estejam disponveis.
Tuning Full Table Scans

O parmetro de inicializao DB_FILE_MULTIBLOCK_READ_COUNT
determina o nmero mximo de blocos do banco de dados lidos em uma
operao de I/O durante full table scans.
A configurao deste parmetro pode reduzir o nmero de chamadas de
I/O necessrias para um full table scan, aumentando a performance.

I/O uma funo do sistema operacional e portanto existem limites

especficos do sistema operacional relacionados com a configurao deste
parmetro. A capacidade do Oracle para efetuar a leitura de mltiplos blocos
limitada pelo sistema operacional no nmero de bytes que podem ser lidos em
uma nica chamada de I/O.
A configurao do parmetro DB_FILE_MULTIBLOCK_READ_COUNT dita
quantas chamadas de I/O sero necessrias para completar um table scan. Por
exemplo, se DB_FILE_MULTIBLOCK_READ_COUNT estiver configurado para 16, e
o tamanho de bloco Oracle for igual a 4K, ento um scan seqncial de uma
tabela de 64K pode ser lido em um passo. Isto aumenta a velocidade do table
scan e a performance global da consulta.
A meta de configurao do parmetro DB_FILE_MULTIBLOCK_READ_COUNT
para que table scans sejam executados em poucos e grandes I/Os. Isto
feito pela avaliao do nmero de blocos necessrios para completar cada
table scan com o passar do tempo, ento ajustando o parmetro de forma que
a maioria dos scans possa ser efetuado em um I/O.
O nmero total de I/Os atualmente necessrios para efetuar um full table
scan depende de outros fatores, como o tamanho da tabela e se parallel query
est sendo utilizado.
O otimizador baseado em custo utiliza todos estes fatores, incluindo o
parmetro DB_FILE_MULTIBLOCK_READ_COUNT para determinar o custo de full
table scans. O otimizador baseado em custo favorece full table scans quando o
custo for menor que index scans.
Monitorando Operaes de Full Table Scan

Alguns mecanismos esto disponveis para os usurios e DBAs
monitorarem o progresso de full table scans e para obter uma idia do tempo
estimado para completar a tarefa. Para fornecer este mecanismo, o servidor
Oracle mantm estatsticas rastreando o progresso destas operaes e torna-
as disponvel para os usurios atravs da viso de performance dinmica
V$SESSION_LONGOPS.
Nota: a package DBMS_APPLICATION_INFO contm uma procedure
chamada SET_SESSION_LONGOPS para preencher a viso a partir de uma
aplicao.

SQL> SELECT sid, serial#, opname,

2 TO_CHAR(start_time,'HH24:MI:SS') AS START_TIME,
3 (sofar/totalwork)*100 PERCENT_COMPLETE
4 FROM v$session_longops;
SID SERIAL# OPNAME START PERCENT_COMPLETE

--- ------- ------------ -------- ----------------
8 219 TABLE SCAN 13:00:09 48.98098

Utilitrios de Diagnstico para Verificar

Estatsticas de I/O
Figura 7-1: Utilitrios de diagnstico para verificar estatsticas de I/O
Monitorando a Utilizao de Arquivos

Para monitorar quais arquivos esto envolvidos na maioria dos I/Os em um
banco de dados, voc pode consultar o seguinte:
Viso V$FILESTAT.
Viso V$TEMPFILE.
Estatsticas de arquivo de STATSPACK.
Utilizando a Viso de Performance Dinmica

V$FILESTAT
Voc pode consultar V$FILESTAT para encontrar o nmero de I/Os por
arquivo em disco. Some todos os I/Os sobre os data files por disco para
encontrar os datas files com probabilidade de causar um gargalo no disco.
A viso V$FILESTAT contm as seguintes colunas:
Coluna Descrio
FILE# Nmero do arquivo (efetue um join para
FILE# da V$DATAFILE para obter o
nome)
PHYRDS Nmero de leituras fsicas efetuadas
PHYWRTS Nmero de escritas fsicas efetuadas
PHYBLKRD Nmero de blocos fsicos lidos
PHYBLKWRT Nmero de blocos fsicos escritos
READTIM Tempo gasto efetuando leituras
WRITETIM Tempo gasto efetuando escritas

SQL> SELECT phyrds, phywrts, d.name

2 FROM v$datafile d, v$filestat f
3 WHERE d.file# = f.file# order by d.name;
PHYRDS PHYWRTS NAME

---------- ---------- ----------------------------------------
1 10 /oracle/oradata/tuning/aluno_data01.dbf
32 20 /oracle/oradata/tuning/default01.dbf
21 9 /oracle/oradata/tuning/indx01.dbf
2907 2415 /oracle/oradata/tuning/sysaux01.dbf
6700 742 /oracle/oradata/tuning/system01.dbf
105 1025 /oracle/oradata/tuning/undo01.dbf
21 9 /oracle/oradata/tuning/users01.dbf
Nota: as duas ltimas colunas contm 0 a menos que o parmetro

TIMED_STATISTICS esteja configurado para TRUE. Utilize a seguinte consulta
para monitorar estes valores:
Estatsticas de I/O
SQL> SELECT d.tablespace_name TABLESPACE,
2 d.file_name,
3 f.phyrds,
4 f.phyblkrd,
5 f.readtim,
6 f.phywrts,
7 f.phyblkwrt,
8 f.writetim
9 FROM v$filestat f, dba_data_files d
10 WHERE f.file# = d.file_id
11 ORDER BY tablespace_name, file_name;
TABLESPACE FILE_NAME PHYRDS PHYBLKRD READTIM PHYWRTS PHYBLKWRT WRITETIM

------------ -------------------------------------- ------ -------- ------- ------- --------- -------
ALUNO_DATA /oracle/oradata/tuning/aluno_data01.dbf 1 1 0 10 13 1
DEFAULTTBS1 /oracle/oradata/tuning/default01.dbf 33 33 0 20 31 1
INDX /oracle/oradata/tuning/indx01.dbf 22 22 0 9 9 0
SYSAUX /oracle/oradata/tuning/sysaux01.dbf 2907 3467 160 2416 3865 205
SYSTEM /oracle/oradata/tuning/system01.dbf 6764 15769 53 744 924 29
UNDOTBS1 /oracle/oradata/tuning/undo01.dbf 108 108 0 1028 2380 58
USERS /oracle/oradata/tuning/users01.dbf 22 22 0 9 9 1
Para fazer uma boa avaliao de quais resultados so bons e quais so

ruins, voc deve ter conhecimento de quais tipos de objetos esto
armazenados em quais tablespaces.
Voc deve investigar quantos full table scan esto sendo efetuados nas
tabelas da aplicao devido a perda de ndices e ao uso ineficiente do
otimizador baseado em custo.

Grupos e Membros de Redo Log
Figura 7-2: Grupos e membros de redo log
Configurao de Online Redo Log File

Dimensione redo log files para minimizar conteno.
Tenha grupos suficientes para evitar espera.
Armazene redo log files em dispositivos rpidos e isolados.
Consulte as vises de performance dinmica V$LOGFILE, V$LOG e
V$LOG_HISTORY.
Online redo log files so organizados em grupos.
Um grupo deve possuir um ou mais membros. Todos os membros de um
grupo possuem contedo idntico.
Voc deve possuir dois ou mais membros em cada grupo por segurana, a
menos que voc esteja efetuando mirroring de todos os arquivos em nvel de
hardware.
Redo log files do mesmo grupo devem estar em dispositivos separados e
rpidos, uma vez que o LGWR escreve neles quase continuamente.
Dimensione corretamente redo log files para minimizar conteno e
freqentes log switches. Voc pode utilizar as estatsticas redo size de
STATSPACK. Como diretriz, um redo log deveria manter ao menos 20 minutos
de dados de redo.

Monitorando Informaes de Redo Log File

Voc pode consultar as vises de performance dinmica V$LOGFILE e
V$LOG para obter informaes sobre o nome, localizao, tamanho e status
dos online redo log files.
Quaisquer esperas (waits) por log file parallel write na
V$SYSTEM_EVENT indicam um possvel problema de I/O com os log files.
O Oracle no fornece um meio de monitorar I/Os de disco de redo, de
forma que voc deve utilizar comandos de monitoramento de disco do sistema
operacional.

ALTER SYSTEM ARCHIVE LOG ALL

TO <log_archive_dest>
Configurao de Archive Log File

Permita ao LGWR escrever para um disco diferente do qual um
processo ARCn est efetuando a leitura.
Compartilhe o trabalho de arquivamento:
Modifique a velocidade de arquivamento:
LOG_ARCHIVE_MAX_PROCESSES
LOG_ARCHIVE_DEST_n
(LOG_ARCHIVE_DUPLEX_DEST, LOG_ARCHIVE_MIN_SUCCEED_DEST)
Aumente o nmero de processos Archive.
Utilitrios de Diagnstico
Figura 7-3: Utilitrios de diagnstico
Se voc estiver arquivando, ainda mais importante possuir mais que

dois grupos de redo log. Quando um grupo estiver preenchido o processo
DBWR deve efetuar o checkpoint normalmente, e um arquivo deve ser
arquivado. Voc deve garantir tempo para ambas as operaes antes que o
processo LGWR necessite sobrescrever um arquivo de novo.
Regulando a Velocidade de Arquivamento

Ocasionalmente, em bancos de dados muito ocupados, um nico
processo ARC0 no consegue manter o ritmo com o volume de
informaes escritas para os redo logs. O Oracle 10g permite ao
administrador do banco de dados definir mltiplos processos archive
utilizando o parmetro LOG_ARCHIVE_MAX_PROCESSES.
O processo LGWR inicia um novo processo ARCn sempre que o
nmero atual de processos ARCn for insuficiente para administrar a
carga de trabalho. Se voc antecipar uma grande carga de
arquivamento, voc pode manualmente iniciar processos server para
compartilhar o trabalho executando o comando:

SQL> SELECT *
ALTER SYSTEM ARCHIVE LOG ALL TO 'dir_name';
2 FROM v$archive_processes;
PROCESS STATUS LOG_SEQUENCE STAT
------- ------- ------------ ----
0 ACTIVE 122 BUSY
1 ACTIVE 0 IDLE
2 STOPPED 0 IDLE
Monitore a viso V$ARCHIVE_PROCESSES para disparar processos

archiver extra sempre que mais de dois archives necessitarem
arquivamento.
Nota:
O nmero de I/O slaves utilizado pelo processo ARC0 para arquivar
redo log files automaticamente configurado para 4 quando o
parmetro de inicializao DBWR_IO_SLAVES estiver configurado
para um valor maior que 0.
Obtendo Informaes sobre Archived Log Files e

suas Localizaes
Voc pode consultar a viso de performance dinmica V$ARCHIVED_LOG
para exibir informaes dos archived log a partir do control file incluindo
nomes dos archive log. Um registro de archive log inserido aps o online redo
log ser corretamente arquivado ou limpo (a coluna name nula se o log foi
limpo).
A viso de performance dinmica V$ARCHIVE_DEST descreve, para a
instncia corrente, todos os destinos de archive log, seus valores correntes,
modo e status.

Checkpoints
Checkpoints Incrementais causam:
Atualizao dos headers de control files por parte do CKPT.
Atualizao dos headers de control files e data files por parte do CKPT,
para checkpoints causados por log switches.
Checkpoints Completos causam:
Atualizao dos headers de control files e data files por parte do
CKPT.
DBWn grava todos os buffers presentes no Checkpoint Queue.
Checkpoints freqentes:
Reduzem o tempo de recovery da instncia.
Diminuem a performance de execuo.
O processo background LGWR escreve para os redo log groups de forma
circular, um aps o outro. Quando um grupo estiver preenchido, o Oracle deve
efetuar um log switch e conseqentemente um checkpoint. Isto significa que:
O DBWn escreve todos os dirty blocks cobertos pelo log que est
sofrendo checkpoint para os data files.
O CKPT atualiza os headers dos data files e control files.
Checkpoints normalmente permitem que outros trabalhos continuem ao
mesmo tempo, embora o checkpoint completo gere muitas escritas em disco.
Se o processo DBWR no houver terminado o checkpoint de um arquivo e o
LGWR necessitar o arquivo novamente, o LGWR ter que aguardar.
Checkpoints freqentes significam pouco tempo para o recovery da
instncia mas mais escritas pelo DBWR (para os data files) e pelo CKPT (para
os headers de data files). Sua escolha depende de sua prioridade relativa ao
tempo de recovery e performance de execuo.

Diretrizes para Tuning de Checkpoint

Dimensione os online redo log files para diminuir o nmero de
checkpoints.
Adicione grupos de online redo log para aumentar o tempo antes do
LGWR sobrescrever informaes.
Regule checkpoints com os parmetros de inicializao:
FAST_START_IO_TARGET
LOG_CHECKPOINT_INTERVAL
LOG_CHECKPOINT_TIMEOUT
FAST_START_MTTR_TARGET
Monitorando a Freqncia de Checkpoints

O tamanho do Ckeckpoint Queue determinante para o tempo de
recuperao de uma instncia aps uma falha. Para acelerar o processo de
recovery, uma fila menor seria necessria. Entretanto, com uma fila pequena,
mais escritas seriam efetuadas pelo DBWn, pois este descarrega os dirty
blocks presentes no checkpoint queue sempre que este atinge um
determinado nmero de blocos. Um balano deve ser encontrado entre essas
duas circunstncias.
Voc pode verificar os momentos de log switches no arquivo alert.log.
Alm disso, verifique o arquivo por mensagens de erro dizendo
Checkpoint not complete; unable to allocate file. Estas mensagens significam
que o LGWR teve que esperar que um chekpoint terminasse.
Se as estatsticas de sistema background chekpoints started e
background checkpoints completed possurem valores que diferem por mais
de 1, os checkpoints no esto sendo completados entre log switches. Voc
necessita aumentar os log files.
Voc pode configurar o parmetro LOG_CHECKPOINTS_TO_ALERT de forma
que o incio e o fim de checkpoints sejam registrados no arquivo alert.log.
A estatstica DBWn checkpoint write requests no report.txt indica o
nmero de vezes que checkpoints foram enviados para o DBWn. Um nmero
alto de checkpoints por transao indicam que muitos checkpoints esto
ocorrendo.
Regulando Checkpoints
O DBWn deve sempre efetuar um checkpoint no final de cada grupo de
redo log. Voc pode tambm configurar checkpoints com os parmetros de
inicializao.
Se performance eficiente for sua prioridade, escolha um tamanho de redo
log file de forma que checkpoints ocorram com freqncia suficiente para no
causar uma queda notvel na resposta mas no mais freqentes do que isso.

Em muitos sites esta freqncia de aproximadamente 30 minutos, mas

seu banco de dados pode possuir freqncias de checkpoints de qualquer tipo
entre dois segundos e oito horas, dependendo das necessidades de negcio.
Voc pode tentar experimentar diferentes freqncias de checkpoint.
Sistemas OLTP pode sofrer conteno de disco durante checkpoints se a SGA
estiver muito grande e checkpoints forem infreqentes. Neste caso,
checkpoints mais freqentes envolvem poucos dirty blocks.

Mltiplos I/O Slaves

Fornece requisies de I/O assncrono no bloqueadoras em sistemas
com processador simples.
Aplicam-se aos processos DBWn, LGWR, ARCn e backup.
Normalmente no so recomendados se I/O assncrono estiver
disponvel.
Seguem a conveno de nomenclatura ora_iNnn_SID.
No recomendado em sistemas com mltiplos processadores. Utilize
DB_WRITER_PROCESSES.
Para compartilhar operaes de I/O, voc pode utilizar mltiplos I/O
slaves.
Se o comportamento de I/O assncrono no estiver nativamente
disponvel, voc pode simular com a aplicao de processos de I/O slave. I/O
slaves so processos especializados cuja nica funo efetuar I/O.
No Oracle 10g, a interface de I/O de arquivo foi refeita para fornecer
chamadas de I/O nonblocking para seus clientes.
Muitas plataformas que suportam I/O assncrono para dispositivos de disco
podem funcionar desta forma para dispositivos de fita. Mesmo neste caso, I/O
slaves podem ser utilizados para efetuar I/O nonblocking para dispositivos de
fita.
Alm disso sob cargas pesadas, o processo DBWR pode necessitar
processos adicionais para efetuar parte do I/O.
Mecanismo de I/O Slave

I/O slaves podem ser aplicados pelos processos DBWn e utilizados por
processos LGWR, ARC0 e de backup.
I/O Slaves para o DBWn so alocados imediatamente aps o banco de
dados ser aberto quando a primeira requisio de I/O for efetuada. Por
exemplo, se o parmetro DBWR_IO_SLAVES=4, os seguintes I/O slaves sero
iniciados para o DBWR: ora_i101_SID, ora_i102_SID, ora_i103_SID e
ora_i104_SID.
Outros I/O slaves (para LGWR, ARC0 e processos de backup) so
dinamicamente alocados quando necessrio.
Ou seja, o processo emitindo I/Os procura por um I/O slave livre. Se no
existirem slaves livres, ento o emissor do I/O iniciar um. Se o nmero
permitido de slaves j tiver sido iniciado, ento o emissor aguarda e tenta de
novo encontrar um slave livre.
O DBW0 continua a efetuar todo o trabalho relacionado com o processo
DBW0, por exemplo unindo dirty buffers em um batch. Futuramente, o
processo DBW0 inicia o I/O. O DBW0 I/O slave simplesmente efetua o I/O no
lugar do DBW0. Ou seja, a escrita do batch paralelizada entre I/O slaves.

Isto benfico em ambiente de escrita intensiva uma vez que o tempo de

CPU associado com a emisso de I/Os pode ser dividido entre I/O slaves.

Aplique I/O slaves para processos DBWn, LGWR, ARCn e de backup
com:
DBWR_IO_SLAVES
BACKUP_TAPE_IO_SLAVES
Ligue ou desligue o I/O assncrono com:
DISK_ASYNCH_IO
TAPE_ASYNCH_IO
Os parmetros de inicializao DBWR_IO_SLAVES,
BACKUP_TAPE_IO_SLAVES controlam a aplicao de I/O slaves.
Voc pode ligar ou desligar o uso de I/O assncrono com os parmetros
DISK_ASYNCH_IO e TAPE_ASYNCH_IO. Pode ser necessrio desligar a facilidade
de I/O assncrono fornecida pelo sistema operacional. Por exemplo, se cdigo
de I/O assncrono da plataforma possuir bugs ou no for eficiente, I/O
assncrono pode ser desabilitado por tipo de dispositivo.
Normalmente o parmetro deve ser deixado com o valor default, ou seja,
TRUE.

Mltiplos Processos DBWn

Aplique mltiplos processos DBWn com DB_WRITER_PROCESSES.
til para sistemas SMP com um nmero grande de CPUs.
No pode ser utilizado concorrentemente com mltiplos I/O slaves.
Mltiplos processos DBWn podem ser especificados pelo parmetro
DB_WRITER_PROCESSES. At 20 processos (DBW0 at DBW9 e DBWa at
DBWj) podem ser utilizados. Em contraste com mltiplos I/O slaves, os quais
somente paralelizam a escrita do batch entre os DBWn I/O slaves, voc pode
paralelizar a leitura bem como a escrita de buffers com a caracterstica de
mltiplos DBWn.
Assim, do ponto de vista de throughput, n processos DBWn devem obter
melhor resultado do que o processamento de 1 processo DBWn com o mesmo
nmero de n I/O slaves.

Exerccios 7
1. Verifique o seu banco de dados e veja se existem deficincias relativas a
configurao do mesmo. Considere o seguinte:
a. Quantas tablespaces voc possui ? Quais tablespace voc
adicionaria e com que estrutura de diretrio?
b. Existem objetos que no so do dicionrio de dados na tablespace
SYSTEM?
2. Descubra se checkpoints freqentes esto ocorrendo. Este tempo o
ideal? Se no for, qual seria?
como ALUNO e execute o script lab07_1.sql. Monitore as estatsticas de
I/O.

Espao para anotaes

8. Utilizando Blocos Oracle

Eficientemente

Utilizando Blocos Oracle Eficientemente
Objetivos
Determinar um tamanho de bloco apropriado.
Otimizar a utilizao de espao dentro de blocos.
Detectar e resolver migrao de linhas.
Monitorar e efetuar o tuning de ndices.

Hierarquia de Armazenamento do Banco de

Dados
Figura 8-1: Hierarquia de armazenamento do banco de dados
Gerenciamento de Espao
O gerenciamento eficiente de espao no banco de dados importante
para sua performance. Este captulo explica como gerenciar extenses e
blocos no banco de dados.
Blocos
No Oracle, o bloco a menor unidade de I/O de data file e a menor
unidade de espao que pode ser alocada. Um bloco Oracle consiste de um ou
mais blocos contnuos do sistema operacional.
Extenses
Uma extenso uma unidade lgica de alocao de espao de
armazenamento do banco de dados composta de um nmero de blocos de
dados contnuos. Uma ou mais extenses por sua vez formam um segmento.
Quando o espao existente em um segmento est completamente utilizado, o
Oracle aloca uma nova extenso para o segmento.
Segmentos
Um segmento um conjunto de extenses que contm todos os dados
para uma estrutura lgica de armazenamento especfica dentro de uma
tablespace. Por exemplo, para cada tabela, o Oracle aloca uma ou mais

extenses para formar segmentos de dados para a tabela. Para ndices, o

Oracle aloca uma ou mais extenses para formar o segmento de ndice.

Alocando uma Extenso
Figura 8-2: Alocando uma extenso
Quando operaes do banco de dados causarem o crescimento dos dados

e excederem o espao alocado, o Oracle estende o segmento. A extenso
dinmica, estendendo o segmento durante a execuo de um comando INSERT
ou UPDATE, reduz a performance, uma vez que o servidor executa vrios
comandos SQL recursivos para encontrar espao livre e adicionar a extenso
para o dicionrio de dados. Este processo, chamado extenso dinmica, reduz
a performance. Voc pode evitar a extenso dinmica:
Criando tablespaces gerenciadas localmente, e no pelo dicionrio
de dados.
Dimensionando segmentos apropriadamente.
Monitorando e pr-alocando extenses.

SQL> SELECT owner, table_name, blocks, empty_blocks

SQL> ALTER TABLE aluno.tdescontos allocate extent;
2 FROM dba_tables
3 WHERE empty_blocks / (blocks+empty_blocks) > .1;

OWNER TABLE_NAME BLOCKS EMPTY_BLOCKS
------- --------------- ------ -------------
ALUNO TDESCONTOS 1450 50
ALUNO TCONTRATOS 460 40
Evitando a Alocao Dinmica

Para exibir segmentos com menos de 10% de blocos livres:
Para evitar a alocao dinmica:
Dimensione o segmento apropriadamente:
Determinando o tamanho mximo do objeto.
Escolhendo os parmetros de storage que aloquem extenses
suficientemente grandes para acomodar todos os dados quando voc
criar o objeto.
Quando estiver determinando o tamanho do segmento, o DBA deve
permitir o crescimento dos dados. Por exemplo, alocar espao suficiente
para os dados atuais e para quaisquer dados que sero inseridos para o
segmento no prximo ano.
Monitore o banco de dados para encontrar segmentos que esto
perto de estender-se dinamicamente e ento utilize o comando
ALTER TABLE/INDEX/CLUSTER para estend-los.

SQL> CREATE TABLESPACE aluno_data_2

2 DATAFILE '/oracle/oradata/tuning/aluno_data02.dbf'
3 SIZE 100M
4 EXTENT MANAGEMENT LOCAL
5 UNIFORM SIZE 2M;
Evitando as Desvantagens da Alocao

Dinmica
Crie uma tablespace gerenciada localmente:
Crie tablespaces gerenciadas localmente para os objetos que se estendem

continuamente.
Uma tablespace gerenciada localmente gerencia suas prprias extenses
e mantm um bitmap em cada data file para manter o rastreamento do status
de free ou used dos blocos naquele data file. Cada bit no bitmap corresponde a
um bloco ou grupo de blocos. Quando uma extenso alocada ou liberada
para reutilizao, o servidor Oracle modifica os valores do bitmap para mostrar
o novo status dos blocos. Estas modificaes no geram informao de undo
porque no atualizam tabelas no dicionrio de dados.

Prs e Contras de Extenses Grandes

Prs:
Menor probabilidade de extenso dinmica.
Pequeno benefcio de performance.
Pode superar limitaes do sistema operacional em tamanho de
arquivo.
Uma nica leitura sobre o mapa de extenses.

Contras:
Espao livre pode no estar disponvel.
Espao no utilizado.
Para facilitar o gerenciamento de espao, o DBA cria objetos com
tamanhos apropriados de segmentos e extenses. Como regra geral,
extenses grandes so preferidas ao invs de pequenas extenses.
Vantagens de Extenses Grandes

Extenses grandes evitam alocao dinmica de extenses, uma vez
que estes segmentos possuem uma probabilidade menor de
necessitarem estender-se.
Extenses grandes podem fornecer um pequeno benefcio de
performance porque o Oracle pode efetuar a leitura delas a partir do
disco com poucas leituras multibloco do que seriam necessrias para
efetuar a leitura de muitas extenses pequenas. Para evitar leituras
multibloco parciais, configure o tamanho da extenso para um
mltiplo de 5*DB_FILE_MULTIBLOCK_READ_COUNT. Multiplique por
cinco, porque o Oracle tenta alocar blocos em limites de cinco
blocos. Atravs da correspondncia dos tamanhos de extenses com
os tamanhos de I/O e alocao de espao, o custo de performance
de possuir muitas extenses em um segmento pode ser minimizado.
Entretanto, para uma tabela que nunca possui uma operao de full
table scan, no faz diferena em termos de performance de consulta
se a tabela possui uma ou mltiplas extenses.
Para tabelas muito grandes, as limitaes do sistema operacional
para tamanho de arquivo podem forar o DBA a alocar o objeto com
mltiplas extenses.
A performance de pesquisas utilizando um ndice no afetada se o
ndice possuir uma ou mltiplas extenses.
Mapas de extenses listam todas as extenses para um certo
segmento. Para MAXEXTENTS UNLIMITED, estes mapas esto em
mltiplos blocos. Para melhor performance, voc deve ser capaz de
efetuar a leitura do mapa de extenses com um nico I/O. A
performance degradada se mltiplos I/Os forem necessrios para
um full table scan obter o mapa de extenses. Alm disso, um
nmero grande de extenses pode degradar a performance do
dicionrio de dados, uma vez que cada extenso utiliza espao no
dictionary cache.
Desvantagens de Extenses Grandes

Uma vez que extenses grandes necessitam mais blocos contnuos,
o Oracle pode ter dificuldades em encontrar espao contguo
suficiente para armazen-las.
Uma vez que o DBA dimensiona o segmento para permitir o
crescimento, parte do espao alocado para o segmento pode no ser
utilizada inicialmente.
Para determinar quando alocar poucas extenses grandes ou muitas
extenses pequenas, considere os benefcios e desvantagens de cada situao
levando em conta seus planos para crescimento e uso das tabelas.

Tamanho de Bloco do Banco de Dados
Figura 8-3: Tamando do bloco do banco de dados
Uma das metas do tuning do banco de dados minimizar o nmero de

blocos visitados. O desenvolvedor contribui para esta meta efetuando o tuning
da aplicao e comandos SQL. O DBA reduz as visitas de blocos:
Utilizando um tamanho de bloco grande.
Mantendo linhas o mais prximas possvel em blocos.
Prevenindo a migrao de linhas.
Infelizmente, para o DBA, as duas ltimas metas conflitam: quanto mais
dados forem mantidos em um bloco, maior ser a probabilidade de migrao.

Tamanho de Bloco Oracle (DB_BLOCK_SIZE)

O tamanho de bloco possui as seguintes caractersticas:
Quando o banco de dados criado, seu tamanho de bloco
configurado para o valor do parmetro DB_BLOCK_SIZE.
Unidade mnima de I/O para leituras de datafile.
O tamanho de bloco default na maioria das plataformas Oracle 2K
ou 4K.
Alguns sistemas operacionais agora permitem tamanhos de bloco de
at 64K.
O tamanho no pode ser modificado sem a recriao ou duplicao
do banco de dados. Isto torna difcil testes de aplicao com
tamanhos de bloco diferentes.
Deve ser mltiplo do tamanho de bloco do sistema operacional.
Se o seu sistema operacional efetua a leitura do prximo bloco
durante leituras seqnciais, e sua aplicao efetua muitos full table
scans, ento o tamanho do I/O do sistema operacional deve ser igual
ou maior que o tamanho do bloco do banco de dados.
O tamanho de bloco escolhido afeta a performance. Como regra geral:
Acesso aleatrio para um objeto grande, como em um ambiente
OLTP, favorece blocos pequenos.
Acesso seqencial para grandes quantidades de dados, em um
ambiente DSS, prefira blocos grandes.

Prs e Contras de Tamanho de Bloco Pequeno
Vantagens
Blocos pequenos reduzem a conteno de bloco, uma vez que
existem poucas linhas por bloco.
Blocos pequenos so excelentes para linhas pequenas.
Blocos pequenos so ideais para acesso aleatrio, uma vez que
pouco provvel que um bloco seja reutilizado aps ter sido lido em
memria, um tamanho de bloco pequeno torna mais eficiente o uso
do buffer cache. Isto especialmente importante quando os recursos
de memria forem escassos, porque o tamanho do database buffer
cache limitado.
Desvantagens
Blocos pequenos possuem um overhead relativamente grande.
Voc pode acabar armazenando somente um nmero pequeno de
linhas por bloco, dependendo do tamanho da linha. Isto pode causar
I/Os adicionais.
Blocos pequenos podem causar a leitura de mais blocos de ndices.

Prs e Contras de Tamanho de Bloco Grande

Prs:
Menos overhead.
Ideal para acesso seqncial.
Ideal para linhas muito grandes.
Melhor performance de leitura de ndices.

Contras:
Aumenta a conteno de bloco.
Utiliza mais espao no buffer cache.
Vantagens
Existe relativamente menos overhead e desta forma mais espao
para armazenar dados teis.
Blocos grandes so ideais para leituras seqnciais.
Blocos grandes so ideais para linhas muito grandes.
Blocos grandes melhoram a performance de leitura de ndices.
Blocos grandes podem armazenar mais entradas de ndice em cada
bloco, o que reduz o nmero de nveis (levels) em grandes ndices.
Poucos nveis de ndice significam poucos I/Os ao atravessar os
ramos (branches) de ndices.
Desvantagens
Um tamanho de bloco grande no o ideal para blocos de ndices
utilizados em um ambiente do tipo OLTP, porque aumentam a
conteno de bloco nos blocos folha (leaf) do ndice.
Espao no buffer cache ser desperdiado se voc estiver efetuando
acessos randmicos para pequenas linhas e possuir um tamanho de
bloco grande. Por exemplo, com um tamanho de bloco de 8K e um
tamanho de linha de 50 bytes, voc estaria desperdiando 7,950
bytes no buffer cache ao efetuar acesso randmico.
Se voc redimensionar blocos do banco de dados e no existir memria
adicional, voc pode necessitar reconfigurar o parmetro DB_CACHE_SIZE. Isto
afetar o percentual de cache hits.

PCTFREE e PCTUSED
Figura 8-4: PCTFREE e PCTUSED
Dois parmetros de gerenciamento de espao, PCTFREE e PCTUSED,

permitem a voc controlar o uso do espao livre dentro de todos os blocos de
dado de um segmento. Voc especifica estes parmetros na criao ou
alterao de uma tabela ou cluster. Voc tambm pode especificar o
parmetro de storage PCTFREE na criao ou alterao de um ndice.
Parmetro PCTFREE
O parmetro PCTFREE configura o percentual mnimo de um bloco de
dados a ser reservado como espao livre (free space) para possveis
atualizaes para linhas que j existam naquele bloco.
Parmetro PCTUSED
O parmetro PCTUSED configura o percentual mnimo de um bloco que
pode ser utilizado para o row data mais um overhead antes que novas linhas
sejam adicionadas para o bloco.
Como PCTFREE e PCTUSED Trabalham em Conjunto

Por exemplo, voc executa um comando CREATE TABLE com PCTFREE 20
de forma que o Oracle reserva 20% de cada bloco de dados no segmento de
dados desta tabela para atualizaes para as linhas existentes em cada bloco.
O espao utilizado no bloco pode crescer (1) at que o row data e overhead
atinjam um total de 80% do tamanho total do bloco. Ento o bloco removido
da free list para prevenir inseres adicionais (2).
Aps voc executar um comando DELETE ou UPDATE, o Oracle processa o
comando e verifica se o espao utilizado no bloco agora menor do que
PCTUSED. Se for, o bloco vai para o incio da free list. Quando a transao
sofrer commit, o espao livre no bloco torna-se disponvel para outras
transaes (3).
Aps um bloco de dados ser preenchido para o limite do PCTFREE
novamente (4), o Oracle considera o bloco indisponvel para a insero de
novas linhas at o percentual deste bloco cair abaixo do parmetro PCTUSED.
DML e PCTFREE e PCTUSED

Dois tipos de comandos podem aumentar o espao livre de um ou mais
blocos de dados: comandos DELETE e comandos UPDATE que atualizem
valores existentes para valores que utilizem menos espao.
Espao liberado em um bloco pode no ser contnuo. Por exemplo, uma
linha do meio do bloco removida. O Oracle efetua o coalesce do espao livre
de um bloco de dados somente quando:
Um comando INSERT ou UPDATE tenta utilizar um bloco que contm
espao livre suficiente para conter um novo pedao da linha.
O espao livre est fragmentado de forma que um pedao de linha
no pode ser inserido em uma seo contnua do bloco.
O Oracle efetua esta compresso somente em tais situaes, porque caso
contrrio a performance de um sistema de banco de dados iria diminuir devido
a contnua compresso do espao livre em blocos de dados.

Diretrizes de PCTFREE e PCTUSED

PCTFREE
Default: 10.
Zero se no houver atividade de UPDATE.
PCTFREE = 100 * upd / (avg row length).
PCTUSED
Default: 40.
Configure se linhas forem removidas.
PCTUSED = 100 PCTFREE 100 * rows * (avg row length) / blocksize.
Para configurar PCTFREE e PCTUSED utilize as frmulas acima, onde:
upd a quantidade mdia adicionada por updates, em
bytes. Determinado atravs da subtrao do tamanho
mdio da linha do tamanho corrente da linha.
avg row length o tamanho mdio das linhas. Obtenha atravs
da coluna AVG_ROW_LEN da tabela DBA_TABLES, aps
rodar o comando ANALYZE.
rows o nmero de linhas a serem removidas antes que a
manuteno da free list ocorra.
A frmula para o PCTUSED permite inseres para a tabela quando existir

espao suficiente no bloco para atualizaes de linha e para mais uma linha.
PCTUSED relevante somente em tabelas que sofrem delees, mas em
muitas tabelas voc pode ser capaz de agrupar mais linhas nos blocos
configurando PCTUSED para um valor maior que o default (40%).
Para tabelas com muitas inseres, modificando o PCTUSED pode-se
melhorar a performance de armazenamento de blocos. Blocos que so
densamente populados podem causar conteno na free list, mas poucos
blocos so necessrios, tabelas so menores e operaes de leitura so mais
rpidas.
Se voc modificar PCTFREE e PCTUSED para tabelas existentes, no
existir impacto imediato nos blocos. Entretanto, a atividade DML futura
utilizar as novas regras para as tabelas.

Migrao (Migration) e Encadeamento

(Chaining)
Figura 8-5: Migrao e encadeamento
Em duas circunstncias, os dados para uma linha de uma tabela podem

ser muito grandes para permanecerem em um nico bloco de dados.
No primeiro caso, chamado chaining, a linha muito grande para ser
colocada at mesmo em um bloco de dados vazio. Neste caso, o Oracle
armaze

Idioma

Oracle Otimizao e Performance em Portugues Excelente Apostila Curso Completo de Oracle Otimizao e Performance em Portugues

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Oracle Otimizao e Performance em Portugues Excelente Apostila Curso Completo de Oracle Otimizao e Performance em Portugues

Enviado por

Direitos autorais:

Formatos disponíveis

Otimizao e Performance do Banco de

Dados Oracle 10g

Apostila desenvolvida especialmente para Target Informtica Ltda.

2. Oracle Alert e Arquivos de Trace...............................................2-1

3. Utilitrios e Vises de Performance Dinmicas...........................3-1

TargetTrust Treinamento e Consultoria I

4. Efetuando o Tuning da Shared Pool...........................................4-1

5. Efetuando o Tuning do Database Buffer Cache...........................5-1

TargetTrust Treinamento e Consultoria II

Resolvendo Conteno de Free List..........................................................5-32

6. Efetuando o Tuning do Redo Log Buffer.....................................6-1

7. Configurao do Banco de Dados e Detalhes de I/O....................7-1

8. Utilizando Blocos Oracle Eficientemente....................................8-1

Selecionando Linhas Migradas e Encadeadas...........................................8-18

9. Otimizando Operaes de Sort..................................................9-1

11.Tuning de Segmentos de Undo................................................11-1

Configurando o Modo de Otimizao........................................................12-5

13.Consideraes de Tuning para Diferentes Aplicaes................13-1

TargetTrust Treinamento e Consultoria V

14.Tuning do Sistema Operacional...............................................14-1

Apndice - Resoluo dos Exerccios.................................................1

TargetTrust Treinamento e Consultoria VI

1. Viso Geral sobre Tuning

TargetTrust Treinamento e Consultoria 1

TargetTrust Treinamento e Consultoria 2

Questes sobre Tuning

Quem Realiza o Tuning?

Porque Realizar o Tuning?

Como Efetuar o Tuning?

TargetTrust Treinamento e Consultoria 3

TargetTrust Treinamento e Consultoria 4

Exemplos de Metas de Tuning Mensurveis

TargetTrust Treinamento e Consultoria 5

O tuning pode ser dividido em quatro fases:

TargetTrust Treinamento e Consultoria 6

TargetTrust Treinamento e Consultoria 7

Desempenho versus Segurana

Fatores que afetam o desempenho:

H sempre uma troca feita por desempenho. De forma a aumentar o

TargetTrust Treinamento e Consultoria 8

1. Siga as instrues do instrutor para a criao do banco de dados.

2. Crie uma instncia do Enterprise Manager para o banco de dados.

TargetTrust Treinamento e Consultoria 9

Espao para anotaes

TargetTrust Treinamento e Consultoria 10

2. Oracle Alert e Arquivos de

TargetTrust Treinamento e Consultoria 1

TargetTrust Treinamento e Consultoria 2

Arquivo Alert Log

Arquivos de Trace de Processos Background

Arquivos de Trace de Usurio

TargetTrust Treinamento e Consultoria 3

Arquivo Alert Log

TargetTrust Treinamento e Consultoria 4

Starting up ORACLE RDBMS Version: 10.1.0.2.0.

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

TargetTrust Treinamento e Consultoria 5

Backups de controlfile e online tablespace.

TargetTrust Treinamento e Consultoria 6

Controlando o Arquivo de Alert Log

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

O seguinte parmetro do init<SID>.ora controla a localizao do arquivo