Tuning Banco Dados Oracle 10g

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
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
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
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
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
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
VI
1. Viso Geral sobre Tuning
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.
2.
3.
4.
5.
6.
Design (se no for tarde demais).

Aplicao.
Memria.
I/O.
Conteno.
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
10
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 (ORA01578).

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

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:
11

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

(tuning_ora_24484.trc):
de
trace
de
usurio
resultante
Nota: MAX_DUMP_FILE_SIZE e USER_DUMP_DEST so parmetros de

inicializao dinmicos.
12
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.
13
Espao para anotaes
14
15
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
Class
Class
Class
Class
Class
Class
Class
1 refere-se a atividade geral da instncia.

2 refere-se a atividade do redo log buffer.
4 refere-se a lock.
8 refere-se a atividade do database buffer cache.
16 refere-se a atividade do sistema operacional.
32 refere-se a paralelizao.
64 refere-se aos acessos de tabelas.
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
---------- -----------------------------250 DBSNMP
251 DBSNMP
252 SYSMAN
253 SYSMAN
254 SYS
255 ALUNO
TYPE
---------USER
USER
USER
USER
USER
USER
SERVER
--------DEDICATED
DEDICATED
DEDICATED
DEDICATED
DEDICATED
DEDICATED
10

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
value from client
252 SQL*Net
2 FROM v$statname
n,
v$session
v$sesstat
253 SQL*Net messages,from
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'
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
-----------------------------DBSNMP
SYSMAN
SYSMAN
SYSMAN
SYSMAN
NAME
VALUE
------------------------------ ---------session pga memory
1022540
session pga memory
1350220
session pga memory
1153612
session pga memory
1219148
session pga memory
1284684
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.
11
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
12
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.
13
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.
14

SQL>
SQL>
2
SQL>
2
create
table stats$begin_stats as select * from
@$ORACLE_HOME/rdbms/admin/utlbstat.sql
v$sysstat where 1=0;
create table stats$end_stats as select * from
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
stats$begin_latch
stats$begin_roll
stats$begin_lib
stats$begin_dc
stats$begin_event
stats$file_view
stats$begin_file
stats$begin_waitstat
Baseada em
v$latch
v$rollstat
v$librarycache
v$rowcache
v$system_event
v$filestats, ts$, v$datafile,
file$
stats$file_view
v$waitstat
15

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
stats$end_stats
stats$end_lib
stats$end_event
stats$end_waitstat
stats$end_roll
stats$end_file
stats$end_dc
Baseada em
v$sysstat
v$librarycache
v$system_event
v$waitstat
v$rollstat
stats$file_view
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.
16

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.
17
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 (leastrecently-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.
18
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.
19

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.
20
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
21

SQL> SELECT name, parameter1, parameter2, parameter3
2 FROM v$event_name;
NAME
------------------------------PL/SQL lock timer
alter system set mts_dispatcher
buffer busy waits
library cache pin
log buffer space
log file switch
(checkpoint incomplete)
transaction
...
808 linhas selecionadas.
PARAMETER1
---------duration
waited
file#
handle addr
PARAMETER2
----------
undo seg#
wrap#
PARAMETER3
----------
block#
id
pin address 0*mode+name
count
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.
22
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.
23

----------------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
WAITS
3 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.
24
Viso V$SESSION_EVENT
SQL> SELECT sid, event, total_waits,average_wait
2 FROM v$session_event where sid=10;
SID
---10
10
10
10
10
10
EVENT
TOTAL_WAITS AVERAGE_WAIT
------------------------------ ----------- ------------buffer busy waits
12
5
db file sequential read
129
0
file open
1
0
SQL*Net message to client
77
0
SQL*Net more data to client
2
0
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.
25

SQL> SELECT sid, seq#, event, wait_time, state
2 FROM v$session_wait;
SID
---1
2
3
4
5
6
SEQ#
EVENT
WAIT
TIME
------ --------------------------- ----1284 pmon timer
0
1697 rdbms ipc message
0
0
0
114 smon timer
0
14 SQL*Net message from client
-1
STATE
------WAITING
WAITING
WAITING
WAITING
WAITING
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
>0
=0
=-1
=-2
Descrio
ltimo tempo de espera da sesso
A sesso est aguardando
O valor foi inferior a 1/100 de um segundo
O sistema no pode fornecer informao
de tempo
SECONDS_IN_WAIT: nmero de segundos que o evento aguardou.
26
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.
27
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.
28
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.
29
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.
30
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 %.
31
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.
32
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?
33
Espao para anotaes
34
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.
10

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.
11
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.
12

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

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.
14
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.
15

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
= 'PACKAGE'
SUM(SHARABLE_MEM)
4WHERE
AND type
n.name
= 'opened cursors current'
4
= 'PACKAGE
BODY'
----------------5ORAND
s.sid
= 15;
type
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.
16
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.
17

SQL> desc V$SHARED_POOL_RESERVED
Nome
Nulo?
----------------------------------------- -------FREE_SPACE
AVG_FREE_SIZE
FREE_COUNT
MAX_FREE_SIZE
USED_SPACE
AVG_USED_SIZE
USED_COUNT
MAX_USED_SIZE
REQUESTS
REQUEST_MISSES
LAST_MISS_SIZE
MAX_MISS_SIZE
REQUEST_FAILURES
LAST_FAILURE_SIZE
ABORTED_REQUEST_THRESHOLD
ABORTED_REQUESTS
LAST_ABORTED_SIZE
Tipo
----------NUMBER
NUMBER
NUMBER
NUMBER
NUMBER
NUMBER
NUMBER
NUMBER
NUMBER
NUMBER
NUMBER
NUMBER
NUMBER
NUMBER
NUMBER
NUMBER
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_REQUESTS
LAST_ABORTED_SIZE
Onde:
REQUEST_FAILURES
o nmero de vezes em que no foi

encontrada memria para satisfazer uma
requisio.
18
LAST_FAILURE_SIZE
o tamanho da ltima requisio que falhou.
19
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

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.
20
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.
21

SQL>
2
3
4
5
SELECT * from v$db_object_cache

WHERE sharable_mem > 10000
AND (type = 'PACKAGE' or type = 'PACKAGE BODY'
OR
type = 'FUNCTION' or type = 'PROCEDURE')
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.
22

SQL> DECLARE
SELECT
sql_text
x hash_value
/*
number;
KEEP_ME
from
*/v$sqlarea
x number;
SQL>
SQL>SELECT
EXECUTE
address,
dbms_shared_pool.keep('address,hash_value');
WHERE x
BEGIN
command_type
:= 5;
= 47
2 FROM2 v$sqlarea
3 command_type
AND length(sql_text)
END;
> 500;
3 WHERE
= 47
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.
23
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.
24
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.
25
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
PARAMETER
GETS
GETMISSES
Descrio
Categorias de itens de dados do
dicionrio
Requisies por informaes nesta
categoria
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.
26

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

NAME
---------------------------------------dc_objeccts
dc_constraints
GET_REQS GET_MISS
-------- --------143434
171
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.
28
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.
29

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

session
memory"
memory"
FROM v$sesstat,
v$statname
v$mystat, v$statname
WHERE name = 'session uga memory
memory'max'
AND v$sesstat.statistic#
v$statname.statistic#;
v$mystat.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.
30
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.
31
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.
32
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.
33
Espao para anotaes
34
35
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
ID
NAME
BLOCK_SIZE
RESIZE_STATE
Descrio
Nmero do buffer pool.
Nome do buffer pool.
Tamanho do bloco para esse buffer.
Estado atual da operao de resize (STATIC, ALLOCATING,
ACTIVATING ou SHRINKING).
CURRENT_SIZE
BUFFERS
TARGET_SIZE
TARGET_BUFFERS
PREV_SIZE
PREV_BUFFERS
Tamanho atual do subcache em megabytes.

Nmero atual de buffers.
Novo tamanho em bytes, se um redimensionamento estiver
em andamento. Se RESIZE_STATE for STATIC, ento mostra o
tamanho atual.
Novo tamanho em buffers, se um redimensionamento estiver
em andamento. Se RESIZE_STATE for STATIC, ento mostra o
tamanho atual.
Tamanho anterior do pool.
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
ID
NAME
BLOCK_SIZE
Descrio
Nmero do buffer pool (de 1 a 8).
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.
10
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
11
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.
12
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%.
13
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.
14

SQL>
2
3
4
5
6
SELECT name, value

FROM
v$sysstat
physical_reads,
WHERE db_block_gets,
name in ('session logical reads',
consistent_gets
'physical reads',
FROM
v$buffer_pool_statistics;
'physical reads direct',
'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:
individuais.
V$BH: descreve os blocos mantidos no buffer cache.
descreve
informaes
de
pools
15

Statistic
SQL> SELECT 1 - (phy.value - Total
lob.value - Per
dir.value)Per
/
Logon
Second
2
ses.value "CACHETrans
HIT RATIO"
-------------------------3 FROM
v$sysstat ses, ------v$sysstat
--------lob,
--------physical
reads
15,238
4
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
direct(lob)
0
0
6 AND reads
dir.name
= 'physical 0
reads direct'
session
7 ANDlogical
lob.name
reads = 'physical
119,376
reads 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.
16
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.
17
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
condies:
regra
geral,
aumente
DB_CACHE_SIZE
sobre
as
seguintes
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.
18
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.
19

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).
20

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

SQL> ANALYZE table aluno.tcontratos estimate statistics;
Tabela analisada.
SQL>
SQL>
2
3
4
SELECT
FROM
WHERE
AND
table_name, blocks
dba_tables
owner = 'ALUNO'
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.
22

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
-------------------DEFAULT
KEEP
RECYCLE
HIT RATIO
---------,979758302
.983520845
.503866235
Calculando o Hit Ratio para Mltiplos Pools

Coluna
NAME
SET_MSIZE
CNUM_REPL
CNUM_WRITE
CNUM_SET
BUF_GOT
SUM_WRITE
SUM_SCAN
FREE_BUFFER_WAIT
Descrio
Tamanho mximo permitido.
Nmero atual de buffers em reposio.
Nmero atual de buffers na lista de escrita.
Nmero total atual de buffers para esse pool.
Nmero de buffers reservados para esse pool.
Nmero de buffers escritos pelo DBWn nesse pool.
Nmero de buffers pesquisados pelo DBWn nesse pool.
Esperas por blocos livres nesse pool.
23
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.
24
SQL> SELECT id, name, block_size, buffers

2 FROM v$buffer_pool
3 WHERE id <> 0;
ID
---------1
2
3
NAME
-------------------KEEP
RECYCLE
DEFAULT
BLOCK_SIZE
---------8192
8192
8192
BUFFERS
---------14000
2000
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_,
USER_,
USER_,
USER_,
USER_,
USER_,
DBA_SEGMENTS
ALL_, DBA_CLUSTERS
ALL_, DBA_INDEXES
ALL_, DBA_TABLES
ALL_, DBA_OBJECT_TABLES
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.
25

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.
26
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.
27
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.
28
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.
29
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:
30

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.
31
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
SQL>
2
3
4
5
6
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
SELECT s.segment_name, s.segment_type, s.freelists, w.wait_time,
w.seconds_in_wait, w.state
FROM dba_segments s, v$session_wait w
WHERE w.event = 'buffer busy waits'
AND w.p1
= s.header_file
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.
32

SQL> CREATE
CREATE TABLESPACE
TABLE aluno.nova_tabela
SQL>
aluno_data
(ID
NUMBER(10))
22 DATAFILE
'/oracle/oradata/tuning/aluno_data01.dbf' SIZE 1M
TABLESPACE
aluno_data;
33 EXTENT
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.
33
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.
34
Espao para anotaes
35
36
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
----------V$PARAMETER
V$SGASTAT
NAME
Value
--------------- ---------log_buffer
262144
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>
2
3
SID
---15
SELECT sid, event, seconds_in_wait, state

FROM v$session_wait
WHERE event = 'log buffer space%';
EVENT
SECONS_IN_WAIT STATE
------------------- -------------- ------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
Considere:
de
espera
(SECONDS_IN_WAIT)
tambm deve
ser
zero.
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.
10
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.
11
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
gerenciamento de tamanho de memria dos seguintes componentes:
no
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.
12
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.
13
Espao para anotaes
14
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
Processo
CKPT
DBWn
LGWR
read/writ
e
Control
read/writ
e
write
ARCn
SERVER
Oracle File I/O

Log
Archive
Databas
e
read/writ
e
write
read
write
read
write
read/writ
e
read/writ
e
read/writ
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:
Processo
CKPT
DBWn
LGWR
ARCn
SERVER
Databas
e
write
write
Oracle File I/O

Log
Archive
Control
write
write
read
write
read/writ
e
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
TABLESPACE. Os valores vlidos so os seguintes:
-
2k
4k
8k
16k
32k (depende do sistema operacional)
ao
comando
CREATE
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.
10

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.
11
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 tornaas 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.
12
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
13
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
FILE#
PHYRDS
PHYWRTS
PHYBLKRD
PHYBLKWRT
READTIM
WRITETIM
Descrio
Nmero do arquivo (efetue um join para
FILE# da V$DATAFILE para obter o
nome)
Nmero de leituras fsicas efetuadas
Nmero de escritas fsicas efetuadas
Nmero de blocos fsicos lidos
Nmero de blocos fsicos escritos
Tempo gasto efetuando leituras
Tempo gasto efetuando escritas
14

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>
2
3
4
5
6
7
8
9
10
11
SELECT d.tablespace_name TABLESPACE,

d.file_name,
f.phyrds,
f.phyblkrd,
f.readtim,
f.phywrts,
f.phyblkwrt,
f.writetim
FROM
v$filestat f, dba_data_files d
WHERE f.file# = d.file_id
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
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.
15
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.
16
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
V$SYSTEM_EVENT indicam um possvel problema de I/O com os log files.
na
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.
17

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.
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:
18

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.
19
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.
20
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.
21
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.
22
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.
23
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.
24
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.
25
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.
26
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

adicionaria e com que estrutura de diretrio?
tablespace
voc
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.
27
Espao para anotaes
28
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
------ALUNO
ALUNO
TABLE_NAME
BLOCKS EMPTY_BLOCKS
--------------- ------ ------------TDESCONTOS
1450
50
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>
2
3
4
5
CREATE TABLESPACE aluno_data_2

DATAFILE '/oracle/oradata/tuning/aluno_data02.dbf'
SIZE 100M
EXTENT MANAGEMENT LOCAL
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.
10
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.
11
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.
12
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.
13
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.
14
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.
15
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.
16
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
armazena os dados para a linha em uma cadeia de um ou mais blocos
de dados. O encadeamento pode ocorrer quando a linha inserida ou
atualizada. Row chaining normalmente ocorre com grandes tabelas,
como as linhas que contm um LOB. Row chaining nestes casos
inevitvel.
Entretanto, no segundo caso, chamado migration, um comando UPDATE
aumenta a quantidade de dados em uma linha de forma que a linha no
consegue mais se ajustar ao seu bloco de dados. O Oracle tenta
encontrar outro bloco com espao livre suficiente para armazenar a
linha inteira. Se tal bloco estiver disponvel, o Oracle move a linha
inteira para o novo bloco. O Oracle mantm o row piece original de uma
linha migrada para apontar para o novo bloco contendo a linha atual; o
ROWID de uma linha migrada no modificado. ndices no so
atualizados, de forma que apontam para a localizao original da linha.
Migrao e encadeamento afetam a performance de forma negativa:
Comandos INSERT ou UPDATE que causam a migrao e

encadeamento executam com menor performance, uma vez que
efetuam processamento adicional.
Consultas que utilizem um ndice para selecionar linhas migradas ou
encadeadas devem efetuar I/O adicional.
A migrao causada devido ao PCTFREE estar muito baixo; no existe

espao suficiente no bloco para atualizaes. Para evitar a migrao, todas as
17

Statistic
SQL>
ANALYZE TABLE aluno.tcursos
Total Per
COMPUTE
transaction
STATISTICS;
------------------------- ----- --------------Tabelafetch
table
analisada.
continued row
495
.02
SQL> SELECT num_rows, chain_cnt
2 FROM dba_tables
3 WHERE table_name = 'TCURSOS';
NUM_ROWS CHAIN_CNT
---------- ---------65
25
tabelas que so atualizadas devem possuir seu PCTFREE configurado de forma

que exista espao suficiente dentro dos blocos para atualizaes.
Detectando o Encadeamento e Migrao
Detecte migrao e encadeamento utilizando o comando ANALYZE:

Detecte a migrao e encadeamento a partir do report.txt:
Voc pode detectar a existncia de linhas migradas e encadeadas em uma

tabela ou cluster utilizando o comando ANALYZE com a opo COMPUTE
STATISTICS. Este comando conta o nmero de linhas migradas e encadeadas e
coloca esta informao na coluna CHAIN_CNT da DBA_TABLES.
A coluna NUM_ROWS fornece o nmero de linhas armazenadas na tabela
ou cluster analisado. Calcule a proporo de linhas migradas e encadeadas em
relao ao nmero de linhas para decidir se voc necessita eliminar linhas
migradas.
Estatstica Table Fetch Continued Row

Voc pode tambm detectar linhas migradas ou encadeadas verificando a
estatstica Table Fetch Continued Row na viso V$SYSSTAT ou no report.txt.
Diretrizes
Aumente o PCTFREE para evitar linhas migradas. Se voc deixar mais
espao livre disponvel no bloco para atualizaes, a linha ter espao para
crescer. Voc pode tambm reorganizar (recriar) tabelas e ndices com uma
alta taxa de deleo.
18

create
SQL>
analyze
table CHAINED_ROWS
table aluno.tcursos
(
list chained rows;
Table
owner_name
analyzed.
varchar2(30),
table_name
varchar2(30),
SQL>
cluster_name
select owner_name,
varchar2(30),
table_name, head_rowid
2partition_name
from chained_rows
varchar2(30),
3head_rowid
where table_namerowid,
= 'TCURSOS';
analyze_timestamp date);
OWNER_NAME TABLE_NAME HEAD_ROWID
---------- ---------- -----------------ALUNO
TCURSOS
AAAA1uAAHAAAAA1AAA
ALUNO
TCURSOS
AAAA1uAAHAAAAA1AAB
Selecionando Linhas Migradas e Encadeadas
Detecte o efeito de chaining e migration utilizando o comando

ANALYZE:
Voc pode identificar linhas migradas e encadeadas em uma tabela ou

cluster utilizando o comando ANALYZE com a opo LIST CHAINED ROWS. Este
comando coleta informaes sobre cada linha migrada ou encadeada e coloca
estas informaes em uma tabela especificada. Para criar a tabela que
armazena as linhas encadeadas, execute o script utlchain.sql:
Se voc criar esta tabela manualmente, sua tabela deve possuir os
mesmos nomes de colunas, tipos de dados e tamanhos da tabela
CHAINED_ROWS.
19
ALTER TABLE <table_name> DEALLOCATE UNUSED ...
High Water Mark
Figura 8-6: High water mark
Gravada no bloco de header do segmento.

Configurada para o incio do segmento na criao.
Restaurada para o incio pelo comando TRUNCATE.
Nunca restaurada por comandos DELETE.
Espao acima da high water mark pode ser recuperado a nvel de tabela
utilizando o comando:
Em um full table scan, o Oracle efetua a leitura em todos os blocos abaixo
da high water mark. Blocos vazios acima da high water podem desperdiar
espao, mas no devem degradar a performance, entretanto, blocos vazios
abaixo da high water mark podem degradar a performance.
20
SQL> ANALYZE table aluno.tcursos compute statistics;

Tabela analisada.
SQL>
2
3
4
5
SELECT num_rows, blocks, empty_blocks as empty,

avg_space, chain_cnt, avg_row_len
FROM
dba_tables
WHERE owner = 'ALUNO'
AND
table_name = 'TCURSOS';
NUM_ROWS
BLOCKS
EMPTY AVG_SPACE CHAIN_CNT AVG_ROW_LEN
---------- ---------- ---------- ---------- ---------- ----------65
1
6
3234
0
73
Estatsticas de Tabelas
Consulte as estatsticas de tabela aps executar o comando analyze:
Voc pode analisar as caractersticas de armazenamento de tabelas,

ndices e clusters para coletar estatsticas, que so ento armazenadas no
dicionrio de dados. Voc pode utilizar estas estatsticas para determinar se
uma tabela ou ndice possui espao no utilizado.
Consulte
estatsticas.
viso
DBA_TABLES
Colunas
NUM_ROWS
BLOCKS
EMPTY_BLOCKS
AVG_SPACE
AVG_ROW_LEN
CHAIN_CNT
AVG_SPACE_FREELIST_BLOC
KS
NUM_FREELIST_BLOCKS
para
visualizar
os
resultados
das
Descrio
Nmero de linhas da tabela
Nmero de blocos abaixo da high water mark da
tabela
Nmero de blocos acima da high water mark da
tabela
Mdia de espao livre nos blocos abaixo da high
water mark
Tamanho mdio das linhas, incluindo o row overhead
Nmero de linhas migradas ou encadeadas na tabela
A mdia de espao livre em todos os blocos de uma
freelist.
Nmero de blocos em uma freelist.
EMPTY_BLOCKS representa os blocos que ainda no foram utilizados, e

no os blocos que estavam preenchidos e agora esto livres.
21

free_blocks(
declare
unused_space(
owner
segmento_owner
segment_owner
varchar2(30);
IN
INvarchar2,
varchar2,
name
segment_name
varchar2(30);
IN varchar2,
seg_type varchar2(30);
segment_type
IN varchar2,
tblock
total_blocks
freelist_group_id
number;
OUT number,
IN number,
...free_blks
total_bytes
OUT
OUT
number,
number,
begin
unused_blocks
scan_limit
IN number
OUT number,
DEFAULT NULL)
dbms_space.unused_space
unused_bytes
OUT number,
last_used_extent_file_id
('&owner','&table_name','TABLE',
OUT number,tblock,
last_used_extent_block_id
tbyte, ublock, ubyte, OUT
lue_fid,
number,
lue_bid,
last_used_block
lublock);
OUT number);
dbms_output.put_line
(...
end;
/
Package DBMS_SPACE
Voc pode tambm utilizar esta package fornecida com o banco para
obter informaes sobre a utilizao de espao em segmentos, que contm
duas procedures:
UNUSED_SPACE retorna informaes sobre o espao no utilizado em

um objeto (tabela, ndice ou cluster). Sua especificao :
FREE_BLOCKS retorna informaes sobre blocos livres em um objeto

(table, index ou cluster). Sua especificao :
Estas procedures so criadas e documentadas atravs do script

dbmsutil.sql que executado pelo catproc.sql. Ao executar esta package, voc
deve fornecer um valor para o FREE_LIST_GROUP_ID. Utilize o valor 1, a menos
que esteja utilizando Real Application Cluster.
22
Reorganizao de ndices
Figura 8-7: Reorganizao de ndices
ndices sobre tabelas volteis podem tambm apresentar um problema de

performance. Em blocos de dados, o Oracle substitui linhas deletadas com as
inseridas; entretanto, em blocos de ndice, o Oracle ordena as entradas
seqencialmente. Valores devem entrar no bloco correto, junto com outras
entradas do mesmo intervalo.
Muitas aplicaes inserem na ordem ascendente do ndice e removem
valores antigos. Mas mesmo se um bloco contm somente uma entrada, ele
deve ser mantido. Neste caso, voc pode necessitar reconstruir seus ndices
regularmente.
Se voc remover todas as entradas de um bloco de ndice, o Oracle coloca
o bloco novamente na free list.
23

SQL> ANALYZE INDEX index_name
acct_no_idxVALIDATE
VALIDATESTRUCTURE;
STRUCTURE
Index analyzed.
SQL> SELECT (DEL_LF_ROWS_LEN/LF_ROWS_LEN) * 100
2
AS index_usage
3 FROM
index_stats;
INDEX_USAGE
----------24
SQL> ALTER INDEX acct_no_idx REBUILD;
Index altered.
Monitorando ndices
Voc pode monitorar o espao utilizado por ndices utilizando o comando:
Ento, consulte a viso INDEX_STATS:
Coluna
LF_ROWS
LF_ROWS_LEN
DEL_LF_ROWS
DEL_LF_ROWS_LEN
Descrio
Nmero de valores atualmente no ndice
Soma em bytes do tamanho de todos os
valores
Nmero de valores deletados do ndice
Tamanho de todos os valores deletados
Nota: a viso INDEX_STATS contm o ltimo ndice analisado. A viso

especfica por sesso. Se voc conectar outra sesso sobre o mesmo usurio, a
viso ser populada com o ndice que for analisado pela sesso que est
consultando a viso.
Reconstruindo ndices
Voc pode decidir reconstruir ndices se entradas deletadas
representarem 20% ou mais das entradas atuais, embora isto ainda dependa
da sua aplicao e prioridades. Voc pode utilizar a consulta acima para
encontrar a proporo. Utilize o comando ALTER INDEX REBUILD para
reorganizar ou compactar um ndice existente ou para modificar suas
caractersticas de storage. O comando REBUILD utiliza o ndice existente como
base para novos ndices. Todos os comandos de armazenamento de ndice so
suportados, como STORAGE (para alocao de extenses), TABLESPACE (para
mover o ndice para uma nova tablespace), e INITRANS (para modificar o
nmero inicial de entradas). Quando estiver construindo um ndice, voc pode
tambm utilizar as seguintes palavras chaves para reduzir o tempo da
operao:
PARALLEL ou NOPARALLEL (NOPARALLEL o default).

RECOVERABLE ou UNRECOVERABLE (RECOVERABLE o default).
UNRECOVERABLE mais rpido porque no escreve entradas de redo
log quando o ndice criado ou reconstrudo.
24
Esta clusula no configura um atributo permanente do objeto, mas

efetiva somente quando o ndice criado; desta forma, no aparece
no dicionrio de dados.
Este atributo no pode ser atualizado.
Este atributo pode somente ser utilizado quando o objeto criado ou
reconstrudo.
Este atributo implica em NOLOGGING por default, o que significa que
inserts adicionais sofrero log.
O ndice no recuperado se necessitar ser recriado durante uma
operao de recovery.
LOGGING e NOLOGGING
NOLOGGING mais rpido porque no escreve quaisquer entradas de
redo durante a vida do ndice at que NOLOGGING seja modificado
para LOGGING.
Este atributo permanente e desta forma aparece no dicionrio de
dados.
Este
atributo
pode
ser
atualizado
(ALTER
INDEX
NOLOGGING/LOGGING) a qualquer momento.
UNRECOVERABLE e LOGGING no so compatveis.
Nota: a opo UNRECOVERABLE pode ser utilizada em verses anteriores
do Oracle 10g, mas ser eventualmente substituda pela opo NOLOGGING.
Para duplicar a semntica da clusula UNRECOVERABLE, crie um objeto com a
opo NOLOGGING e ento utilize o comando ALTER, especificando LOGGING.
Para duplicar a semntica da clusula RECOVERABLE, crie um objeto com a
opo LOGGING.
Utilizando ALTER INDEX REBUILD normalmente mais rpido que remover
e recriar um ndice porque utiliza uma feature de fast full scan. Desta forma
lendo todos os blocos do ndice, utilizando I/O multibloco, ento descartando
os blocos ramo.
25
Exerccios 8
O objetivo destes exerccios utilizar as ferramentas de diagnstico
disponveis para monitorar e efetuar o tuning da utilizao de espao de bloco.
1. Conecte-se como SYSTEM e encontre o PCTFREE, CHAIN_CNT e high
water mark para a tabela S_ORD do usurio ALUNO. Crie o procedimento
encontra_hw_mark no schema do usurio SYSTEM a partir do script
procedure_hw_mark.sql.
2. Execute o script lab08_1.sql para atualizar linhas em ALUNO.S_ORD.
3. Encontre o CHAIN_CNT e a high water mark para a tabela S_ORD do
usurio ALUNO.
4. Elimine quaisquer linhas migradas.
usurio ALUNO.
6. Transfira as linhas migradas da tabela S_ORD para uma nova tabela
chamada S_ORD_TEMP, a partir da tabela CHAINED_ROWS.
26
Espao para anotaes
27
9. Otimizando Operaes de
Sort
Otimizando Operaes de Sort
Objetivos
Identificar as operaes SQL que necessitam de ordenaes.
Garantir que ordenaes sejam efetuadas em memria quando

possvel.
Reduzir o nmero de I/Os necessrios para sort runs.
Alocar espao temporrio apropriadamente.

SQL> SELECT nome, total
2 FROM tcontratos, tclientes
3 WHERE tcontratos.tclientes_id = tclientes.id;
Operaes que Necessitam de Sort
Criao de ndice.
Operao de parallel insert envolvendo manuteno de ndice.
Uso das clusulas ORDER BY ou GROUP BY.
Seleo de valores com DISTINCT.
Uso dos operadores UNION, INTERSECT ou MINUS.
Joins do tipo Sort-Merge.
Execuo do comando ANALYZE.
Criao de ndice
O processo servidor (ou processos, se o ndice estiver sendo criado em
paralelo) tem que ordenar os valores indexados antes de construir a B-Tree.
Clusulas ORDER BY e GROUP BY

O processo servidor deve ordenar os valores especificados pelas clusulas
ORDER BY ou GROUP BY.
Valores Recuperados com DISTINCT

Para a palavra-chave DISTINCT, a ordenao para eliminar duplicidades.
Operao UNION, INTERSECT e MINUS

Servidores necessitam ordenar as tabelas que esto sendo trabalhadas
para eliminar duplicidades.
Nota: o operador UNION ALL no elimina duplicidades, e portanto no
requer ordenao.
Joins do Tipo Sort-Merge

Joins do tipo sort-merge so efetuados para consultas que envolvem o join
de duas tabelas sobre colunas que no possuem ndices, como por exemplo,
uma consulta como a seguinte:
Se no houverem ndices disponveis, uma requisio de equijoin
necessita:
1. Efetuar full table scans das tabelas TCONTRATOS e TCLIENTES.
2. Ordenar cada linha de origem separadamente.
3. Efetuar o merge das origens ordenadas, combinando cada linha de
uma origem com cada linha correspondente da outra origem.

SELECT
name, value
SQL>SQL>
EXECUTE
DBMS_STATS.gather_table_stats('ALUNO',
'TCONTRATOS');
FROM v$sysstat
PL/SQL2 Procedure
sucessfully completed.
3 WHERE name = 'sorts (rows)';
NAME
VALUE
---------------------------------------- ---------sorts (rows)
280150
290350
Antes da operao de sort:

Depois da operao de sort:
Execuo de DBMS_STATS
A package DBMS_STATS til para a coleta de estatsticas sobre tabelas,
ndices e clusteres, para ajudar o otimizador baseado em custo (CBO) a definir
os melhores planos de execuo. Ela ordena os dados para fornecer
informaes sumarizadas.
Execuo de ANALYZE
O comando ANALYZE til para coletar estatsticas sobre tabelas, ndices
e clusters para ajudar o analisador baseado em custo a definir os melhores
planos de execuo, e efetua a ordenao dos dados para fornecer
informaes sumarizadas.
Processo de Ordenao
Figura 9-1: Processo de ordenao
O servidor Oracle ordena em memria se o trabalho puder ser realizado

dentro de uma rea menor do que o valor (em bytes) do parmetro
SORT_AREA_SIZE.
Se a ordenao necessitar de mais espao do que este valor:
1. Os dados so divididos em pedaos menores, chamados sort runs;
cada pedao ordenado individualmente.
2. O processo servidor escreve os pedaos para segmentos temporrios
no disco; estes segmentos armazenam dados de sort runs
intermedirios enquanto o servidor trabalha em outro sort run.
3. Os pedaos ordenados sofrem ento um merge para produzir o
resultado final. Se SORT_AREA_SIZE no for grande o suficiente para
efetuar o merge de todos os sort runs em uma nica vez, subconjuntos
dos sort runs sofre o merge em um nmero de passadas de merge.
rea de Sort e Parmetros
Figura 9-2: rea de sort e parmetros
rea de Sort
O espao de sort:
parte da PGA quando se estiver conectado com um servidor

dedicado.
parte da shared pool quando se estiver conectado com Shared
Server.
Nota: uma aplicao efetuando grandes ordenaes no deve utilizar

Shared Server.
Parmetros
SORT_AREA_SIZE
A rea de sort dimensionada com o parmetro do init<SID>.ora

SORT_AREA_SIZE.
Pode ser configurada dinamicamente utilizando o comando ALTER
SESSION ou ALTER SYSTEM DEFERRED.
O valor default dependente de sistema operacional.
O default normalmente est adequado para a maioria das operaes
OLTP. Ajuste este parmetro para aplicaes DSS, batch jobs ou
grandes operaes.
SORT_AREA_RETAINED_SIZE
Quando a ordenao completada, e a rea de sort ainda contm

linhas ordenadas a serem retornadas (fetched), a rea de sort pode
encolher
para
o
tamanho
especificado
pelo
parmetro
SORT_AREA_RETAINED_SIZED.
A memria liberada novamente para a UGA para uso pelo mesmo
processo servidor Oracle, e no para o sistema operacional, aps a
ltima linha ser retornada a partir do espao de sort.
Requisitos de Memria
Single Server Process
Um plano de execuo pode conter mltiplos sorts.
Por exemplo, um join do tipo sort-merge de duas tabelas pode ser seguido
por um sort para uma clusula ORDER BY.
Se um nico servidor estiver trabalhando em um sort, enquanto efetua
um ORDER BY sort, utiliza:
Uma vez a rea de SORT_AREA_SIZE, em bytes, para o sort ativo.

Duas vezes o tamanho especificado por SORT_AREA_RETAINED_SIZE,
para os join sorts.
Parallel Query Process

Se voc paralelizar o comando, cada servidor da consulta necessita de
uma quantidade de memria de SORT_AREA_SIZE.
Com Parallel Query, dois conjuntos de servidores podem estar trabalhando
ao mesmo tempo, de forma que voc deve:
Calcular SORT_AREA_SIZE * 2 * Grau de Paralelismo.

Se necessrio, adicione SORT_AREA_RETAINED_SIZE * Grau de
Paralelismo * Nmero de Sorts sobre 2.
Se voc pode ainda dispor de memria, o valor ideal para

SORT_AREA_SIZE e SORT_AREA_RETAINED_SIZE para Parallel Query um
megabyte. Em testes, valores maiores do que isto no tiveram melhoria de
performance significativa.
Tamanhos
Normalmente, SORT_AREA_SIZE e SORT_AREA_RETAINED_SIZE devem ser
configurados para o mesmo valor, a menos que:
Voc esteja com muito pouca memria.

Voc esteja utilizando servidor multi-threaded.
Parmetros de inicializao para ndices BITMAP

CREATE_BITMAP_AREA_SIZE
Parmetro esttico que representa a quantidade de memria alocada para
a criao de ndices BITMAP. O valor default de 8M. Um valor maior pode
acelerar a criao de ndices. Entretanto um valor menor pode ser configurado
se a cardinalidade do ndice for muito pequena.
BITMAP_MERGE_AREA_SIZE
Parmetro esttico que representa a quantidade de memria usada para
unir bitmaps recuperados a partir de range scans do ndice. O valor default
de 1M. Um valor maior pode melhorar a performance, pois os bitmaps
precisam ser ordenados antes de serem unidos em um nico bitmap.
Outros Parmetros para rea de Sort
Parmetros para gerenciamento automtico de rea de sort:

PGA_AGGREGATE_TARGET (entre 10M e 4000M)
WORKAREA_SIZE_POLICY (AUTO ou MANUAL)
Substituem os parmetros *_AREA_SIZE.
PGA_AGGREGATE_TARGET define rea total de agregao esperada para

todos os processos servidores anexados instncia. Para configurar esse
parmetro, examine a rea total de memria do servidor disponvel para a
instncia Oracle e diminua desse valor a SGA. O restante deve ser o valor
configurado para PGA_AGGREGATE_TARGET.
WORKAREA_SIZE_POLICY define o tipo de gerenciamento para as reas de
sort do sistema. Valores possveis so:
AUTO: permitido apenas se PGA_AGGREGATE_TARGET estiver
configurado.
MANUAL: define gerenciamento manual, feito a partir dos parmetros
vistos anteriormente (*_AREA_SIZE).

SQL> CREATE TEMPORARY TABLESPACE temp
TEMPFILE '/oracle/oradata/tuning/temp01.ora' SIZE 50M
TABLESPACE GROUP temp_groupA;
Processo de Sort e Espao Temporrio
Figura 9-3: Processo de sort e espao temporrio
Vantagens da Utilizao de Tablespaces Temporrias

Designando tablespaces temporrias exclusivamente para sorts
efetivamente elimina a serializao de operaes de gerenciamento de espao
envolvidas na alocao e desalocao de espao de sort.
Criao de Tablespaces Temporrias

Tablespaces temporrias so criadas com o seguinte comando:
Uma tablespace criada ou alterada desta forma:
No pode conter quaisquer objetos permanentes.

exclusivamente destinada para ordenaes.
Contm um nico segmento de sort por instncia para ambientes
Real Application Cluster.
Tablespaces temporrias tm que ter arquivos temporary. A vantagem
desses arquivos que eles no precisam fazer parte da estratgia de backup,
o que economiza tempo para este processo.
Todo usurio tem uma tablespace temporria definida, que por default a
SYSTEM. Na tablespace definida ser alocado espao para ordenao e criao
10
de tabelas temporrias do usurio, no momento que ele realizar tais

operaes.
Segmento de Espao Temporrio

Ou Segmento de Sort...
Criado no momento da primeira operao de sort que utilizou a

tablespace.
Removido quando o banco de dados fechado.
Cresce a medida que solicitaes forem efetuadas.
Composto de extenses, cada qual podendo ser utilizada por
diferentes operaes de sort.
Descrito em uma estrutura da SGA chamada de Sort Extent Pool
(SEP) (quando um processo necessita espao de ordenao, procura
por free extents no SEP).
11
Efetuando o Tuning de Ordenaes
Evite operaes de sort sempre que possvel.

Reduza o swapping e paging garantindo que a ordenao seja
efetuada em memria quando possvel.
Reduza as chamadas de alocao de espao:
Aloque espao temporrio apropriadamente.
Diagnosticando Problemas
Algumas vezes, voc pode ser capaz de evitar sorts se os dados

processados j foram previamente ordenados.
Quando sorts no so muito grandes, uma rea de sort muito
pequena resulta em overheads de performance devido ao swapping
para disco; garanta que operaes de sort ocorram em memria.
O uso de grandes pedaos de memria para ordenao pode resultar
em paging e swapping, e reduzir a performance global do sistema.
A alocao e liberao de segmentos temporrios ocorrem
freqentemente em tablespaces permanentes.
Metas de Tuning
Evitar operaes de sort que no sejam necessrias.

Otimizar a memria de sort e o overhead de disco.
Eliminar chamadas de alocao de espao para alocar e liberar
segmentos temporrios.
12

SQL> SELECT nome, total
2 FROM tclientes, tcontratos
3 WHERE tclientes.id=tcontratos.tclientes_id;
Evitando Ordenaes
Evite operaes de sort sempre que possvel:
Utilize a clusula NOSORT para criar ndices.

Utilize UNION ALL ao invs de UNION.
Utilize acesso indexado para joins.
Crie ndices em colunas referenciadas na clusula ORDER BY.
Selecione as colunas para anlises.
Utilize ESTIMATE ao invs de COMPUTE para grandes objetos.
SQL> CREATE INDEX tclientes_nome on

2 tclientes(nome) NOSORT;
tclientes(nome) NOSORT
*
ERRO na linha 2:
ORA-01409: NOSORT option may not be used; rows are not in ascending order
Clusula NOSORT
Utilize a clusula NOSORT para criar ndices para dados pr-ordenados em
uma mquina com uma nica CPU. Esta clusula somente vlida para os
dados inseridos em uma tabela:
Em uma mquina com mltiplas CPUs, provvel que seja mais rpido
carregar dados em paralelo, mesmo se estes no forem carregados em ordem.
Ento voc pode utilizar a criao em paralelo de ndices para aumentar a
velocidade de ordenao.
UNION ALL
Utilize UNION ALL ao invs de UNION, esta clusula no elimina
duplicidades, de forma que no necessita efetuar ordenao.
Joins Nested-Loops
Utilize acesso indexado para requisies de equijoin:
O otimizador prefere um join nested-loop ao invs de um join sort-merge.
Um
join
nested-loop no necessita quaisquer sorts, necessitando apenas:
1. Efetuar um full table scan da tabela TCLIENTES.
13
2. Utilizar o valor de ID para cada linha retornada para efetuar um unique

scan no ndice PK_ID.
3. Utilizar o ROWID retornado a partir do index scan para localizar a linha
correspondente na tabela TCONTRATOS.
4. Combinar cada linha retornada a partir de TCLIENTES com a linha
correspondente retornada a partir de TCONTRATOS.
ndices e ORDER BY
Crie ndices em colunas que so freqentemente referenciadas em
clusulas ORDER BY. Dessa forma, o servidor utilizar o ndice ao invs de uma
operao de sort, pois o ndice j est ordenado. Entretanto, o ndice deve ser
criado de forma a combinar com a clusula ORDER BY (em termos de nomes e
ordem das colunas).
ANALYZE FOR COLUMNS

Reduza a quantidade de estatsticas coletadas somente para as colunas
de interesse. Por exemplo aquelas envolvidas em condies de joins:
ANALYZE ... FOR COLUMNS ou ANALYZE ... FOR ALL INDEXED COLUMNS.
Nota: o comando ANALYZE ... SIZE n cria histogramas para as colunas
envolvidas. Combinando esta clusula com a clusula FOR ALL INDEXED
COLUMNS gerar histogramas no necessrios para constraints de primary key
e unique.
ANALYZE ESTIMATE
A clusula COMPUTE mais precisa para o otimizador. Entretanto,
demanda uma grande quantidade de espao de sort. A clusula ESTIMATE
indicada para grandes tabelas e clusters.
14

SQL> SELECT *
2 FROM v$sysstat
3 WHERE name like '%sorts%';
STATISTIC#
---------161
162
163
NAME
CLASS
VALUE
--------------------- ------- -------sorts (memory)
64
154
sorts (disk)
64
4
sorts (rows)
64
571768
Vises Dinmicas e o relatrio de STATSPACK
A viso V$SYSSTAT exibe o nmero de ordenaes em memria

("sorts (memory)), nmero de ordenaes em disco (sorts (disk))
e nmero de linhas ordenadas (sorts (rows).
sorts (disk): nmero de ordenaes necessitando I/O para segmentos
temporrios.
sorts (memory): nmero de ordenaes completamente efetuadas em
memria.
sorts (rows): total de linhas ordenadas no perodo monitorado.
O resultado do relatrio de STATSPACK apresenta as mesmas

informaes. Alm disso, estas informaes cobrem o perodo entre
os snapshots.
15
Statistic
Total Per Transact Per Logon Per Second
-------------- ------ ------------ --------- ---------sorts (disk)
4
.02
.41
.01
sorts (memory)
154
.27
5.77
.12
sorts (rows)
571768
39.62
862.59
18.19
A viso V$SORT_SEGMENT e V$SORT_USAGE exibem informaes

sobre os segmentos temporrios utilizados e sobre os usurios que
esto utilizando estes segmentos.
16

SQL>
2
3
4
5
SELECT disk.value "Disk", mem.value "Mem",

(disk.value/mem.value)*100 "Ratio"
FROM
v$sysstat mem, v$sysstat disk
WHERE mem.name = 'sorts (memory)'
AND
disk.name = 'sorts (disk)';
Disk
Mem
Ratio
---------- ---------- ---------36
893342 ,004029812
Diagnsticos e Diretrizes
Ratio
A proporo entre sorts (disk) e sorts (memory) deve ser menor que 5%,
para um sistema OLTP.
Diretrizes
Se a proporo indicar um nmero alto de sorts sendo efetuados em
disco, aumente o tamanho de SORT_AREA_SIZE ou PGA_AGGREGATE_TARGET.
Isto aumenta o tamanho de cada sort run e diminui o nmero total de runs e
merges.
Performance em Grandes reas de Sort

O aumento do tamanho da rea de sort faz com que cada processo
servidor que efetue ordenao aloque mais memria. Isto pode afetar a
alocao de memria do sistema operacional e induzir a paging e swapping.
Se voc aumentar o tamanho da rea de ordenao, considere diminuir a
rea de memria retida (SORT_AREA_RETAINED_SIZE) do sort area, ou o
tamanho para o qual o Oracle reduz a sort area se diagnosticado que seus
dados no sero acessados em seguida. Um SORT_AREA_RETAINED_SIZE
menor reduz a utilizao de memria mas causa I/O adicional para escrever e
ler dados para e a partir de segmentos temporrios no disco.
17

SQL> SELECT tablespace_name, current_users, total_extents,
2
used_extents, extent_hits, max_used_blocks,
3
max_sort_blocks
4 FROM
v$sort_segment;
TABLESPACE_NAME
MAX_USED_BLOCKS
----------------------------TEMPTBS1
512
CURRENT_USERS TOTAL_EXTENTS USED_EXTENTS EXTENT_HITS

MAX_SORT_BLOCKS
------------- ------------- ------------ ------------------------0
4
0
154
128
Monitorando Tablespaces Temporrias

Viso V$SORT_SEGMENT
Esta viso contm informaes sobre cada segmento de sort de
tablespaces TEMPORARY na instncia.
Coluna
CURRENT_USERS
TOTAL_EXTENTS
USED_EXTENTS
EXTENT_HITS
Descrio
Nmero de usurios ativos
Nmero total de extenses
Extenses atualmente alocadas para ordenaes
Nmero de vezes que uma extenso no utilizada foi
encontrada no pool
MAX_USED_BLOCKS Nmero mximo de blocos utilizados
MAX_SORT_BLOCKS Nmero mximo de blocos utilizados por um sort individual
18

SQL>
2
3
4
5
SELECT session_num,
s.username, u."USER",
tablespace,
u.tablespace,
extents, blocks
u.contents,
u.extents, u.blocks
FROM v$sort_usage;
v$session s, v$sort_usage u
WHERE s.saddr
= u.session_addr
AND
u.contents = 'TEMPORARY';
USERNAME
-------STAT
ALUNO
USER
------SYSTEM
SYSTEM
TABLESPACE CONTENTS EXTENTS

BLOCKS
---------- ---------- ------- -------TEMP
TEMPORARY
20
1000
TEMP
TEMPORARY
2
100
Configurando Tablespaces Temporrias
Configure diferentes
necessidades de sort.
Utilize grupos de tablespaces temporrias.
Efetue o stripe de tablespaces temporrias.
Consulte informaes nas vises V$TEMPFILE e DBA_TEMP_FILES.
tablespaces
temporrias
baseado
nas
Diretrizes
Parmetros de Storage: uma vez que sorts so efetuados em memria
se forem menores que SORT_AREA_SIZE, voc deve considerar este valor
quando configurar tamanhos de extenses em tablespaces temporrias.
Selecione valores para INITIAL e NEXT como inteiros mltiplos de

SORT_AREA_SIZE, permitindo um bloco extra para o header do
segmento.
Se estiver sendo usada PGA_AGGREGATE_TARGET, ento use a
opo AUTOALLOCATE na tablespace.
Configure PCTINCREASE para 0.
Nota: se estiver sendo usada uma tablespace gerenciada localmente, o
parmetro PCTINCREASE no pode ser configurado. E se ainda for configurado
ATUOALLOCATE, ento tambm no haver INITIAL ou NEXT.
Diferentes Tablespaces Temporrias: para definir o espao de sort
necessrio para os usurios e obter informaes sobre as ordenaes em disco
atualmente ativas na instncia, efetue o join das vises V$SESSION e
V$SORT_USAGE:
A coluna USER na viso V$SORT_USAGE sempre exibe o usurio que est
consultando esta viso. O usurio efetuando o sort o username a partir da
viso V$SESSION.
O usurio STAT requisitando uma grande quantidade de espao em disco
ser atribudo a uma outra tablespace temporria com tamanhos de extenso
maiores.
19
Striping: a tablespace temporria deve ser dividida atravs de vrios

discos. Se a tablespace temporria estiver dividida somente atravs de dois
discos com um mximo de 50 I/Os por segundo cada, ento voc pode efetuar
somente 100 I/Os por segundo. Esta restrio pode tornar-se um problema,
fazendo com que as operaes de sort demorem muito tempo.
Data Files: os arquivos que compe tablespaces temporrias no so
mais chamados datafiles, no Oracle 10g, mas tempfiles, e informaes sobre
eles so visualizadas nas vises V$TEMPFILE e DBA_TEMP_FILES, ao invs de
V$DATAFILES e DBA_DATA_FILES.
Grupo de Tablespaces Temporrias

Novo conceito inserido no Oracle 10g, onde temos um grupo de
tablespaces temporrias com as seguintes propriedades:
Contm uma ou mais tablespaces temporrias.
Pode conter somente tablespaces temporrias.
No criado explicitamente. Criamos implicitamente quando a

primeira tablespace temporria configurada para o grupo, e
removemos o grupo quando a ltima tablespace temporria
removida do grupo.
Benefcios
Permite que mltiplas tablespaces temporrias sejam especificadas

como default.
Permite que os usurios utilizem mltiplas tablespaces temporrias

em diferentes sesses ao mesmo tempo.
Permite que um nico comando SQL utilize diversas tablespaces

temporrias para ordenao.
20
Exerccios 9
Os objetivos desta seo de exerccios utilizar as ferramentas de
diagnstico disponveis para monitorar e efetuar o tuning de ordenaes.
1. Conecte-se como SYSTEM e execute o script lab09_1.sql, que fora
ordenaes a escreverem para disco.
2. Efetue a medida da proporo entre sorts (disk) e sorts (memory).
3. Configure o parmetro SORT_AREA_SIZE para resultar somente sorts
(memory).
4. Conecte-se como ALUNO e execute o script lab09_2.sql e recalcule a
proporo.
5. Crie uma nova tablespace do tipo TEMPORARY e faa com que as
operaes de ordenao de ALUNO, quando ordenarem para disco,
ocorram nesta tablespace.
6. Conecte-se como ALUNO e reexecute o script lab09_2.sql. Monitore a
tablespace TEMPORARY.
21
Espao para anotaes
22
10. Latches
Latches
Objetivos
Descrever latches e seus usos.
Descrever os diferentes tipos de requisies por latches.
Diagnosticar conteno em latches.
Identificar formas de minimizar a conteno em latches.
Latches
Latches: Viso Geral
Figura 10-1: Viso geral de latches
Definio
Em um ambiente Oracle, estruturas de memria so mantidas em um
estado consistente por um curto perodo de tempo enquanto um processo as
est acessando. Isto necessrio para garantir que a estrutura no se
modifique enquanto est sendo acessada.
Latches so utilizados para garantir que estas estruturas no se
modifiquem, como uma espcie de lock sobre estruturas. Por exemplo, latches
protegem a lista de usurios que acessam o banco de dados, e protegem as
estruturas de dados que descrevem os blocos no buffer cache. Um processo
deve adquirir o latch que acompanha uma determinada estrutura de dados
compartilhada antes que ele comece a manipul-la, e deve liber-lo quando
terminar. Quando mltiplos processos tentam adquirir estes latches
simultaneamente, existem contenes.
Propsitos
Latches servem mais especificamente para:
Serializar o acesso
Protegem estruturas de dados na SGA.
Protegem alocaes de memria compartilhada
Para serializar a execuo
Previnem a execuo simultnea de certos blocos de cdigo crticos.
Previnem corrupo.
Latches
Tuning
A meta de tuning para conteno de latches minimizar a conteno
entre processos quando latches so requisitados. Entretanto, no se faz o
tuning de latches diretamente, mas usam-se as estatsticas de conteno de
latches como ferramenta de diagnstico para tuning de outras estruturas ou
processos.
Quando ocorre conteno nas requisies por latches, sinal de uso
anormal de recursos por parte de alguma estrutura da SGA. Para resolver o
problema, examine a utilizao de recursos das partes da SGA que mostram
conteno.
Latches
Procedimento de Requisio e Espera por

Latches
Latches obtidos normalmente so mantidos por perodos muito curtos de
tempo (da ordem de micro segundos). Quando um latch requisitado por um
processo, mas j foi obtido por outro, o processo requisitante deve esperar
para requisitar novamente. Essa espera pode ser dar na forma de um sleep ou
um spin.
Sleep
Em sistemas com uma nica CPU, esse o nico mode de espera por
latches disponvel. Um sleep consiste em o processo requisitante liberar a CPU
e "dormir" por algumas instrues (variando de acordo com a plataforma).
Essa liberao da CPU para outro processo implica em uma operao de troca
de contexto relativamente cara para o sistema. Um sleep representado por
uma contagem do evento latch free wait.
Spin
Em sistemas com mltiplas CPUs, possvel que o processo que possui o
latch esteja executando em uma das CPUs e o processo requisitante esteja em
outra. Nesse caso, para evitar a troca de contexto, o processo requisitante faz
um spin na CPU. Ou seja, ele a ocupa com uma contagem at um nmero
especfico, para depois tentar adiquirir o latch novamente. Se este ainda no
houver sido liberado, ento o processo requisitante faz outro spin. Se passarem
um nmero especificado de spins e o latch no for adquirido, ento o processo
requisitante libera a CPU e faz um sleep, como descrito anteriormente.
Entretanto, na maioria das vezes os latches so logo liberados, evitando assim
as trocas de contexto.
Latches
Tipos de Requisies por Latches

Diferentes tipos de latches existem no ambiente Oracle. Estatsticas para
cada categoria de latch, Willing-To-Wait e Immediate, podem ser encontradas
na viso V$LATCH.
Willing-To-Wait: se o latch requisitado com uma requisio Willing-ToWait no estiver disponvel, o processo requisitando aguarda um
pequeno perodo de tempo e requisita o latch novamente. O
processo continua aguardando e requisitando at que o latch esteja
disponvel. Esse o tipo mais comum.
Immediate: se o latch requisitado com uma requisio Immediate
no estiver disponvel, o processo requisitante no aguarda, mas
continua processando outras instrues.
Latches
Diagnosticando Problemas de Conteno por

Latches
Se o relatrio de STATSPACK mostrar o evento latch free como um dos 5
principais, ou se a viso V$WAITSTAT mostrar este com um tempo muito alto
de espera, verifique as estatsticas em V$LATCH.
Informaes em V$LATCH mostram:

GETS: nmero de requisies Willing-To-Wait com sucesso.
MISSES: nmero de vezes que uma requisio Willing-To-Wait inicial
no obteve sucesso.
SLEEPS: nmero de vezes que um processo aguardou e requisitou um
latch aps uma requisio Willing-To-Wait inicial.
WAIT_TIME: tempo em milisegundos aguardado aps uma requisio
Willing-to-Wait.
CWAIT_TIME: medida de tempo cumulativa, incluindo o tempo gasto
em sleeps e spins e trocas de contexto.
SPIN_GETS: nmero de requisies que falharam na primeira tentativa
mas obtiveram o latch aps um spin.
IMMEDIATE GETS: nmero de requisies Immediate com sucesso
para cada latch.
IMMEDIATE MISSES: nmero de requisies Immediate que no
obtiveram sucesso para cada latch.
Exemplo do relatrio de STATSPACK

Top 5 Wait Events
~~~~~~~~~~~~~~~~~
Events
Waits
--------------------------- --------enqueue
482,210
latch free
1,000,676
buffer busy waits
736,524
log file sync
849,791
log file parallel write
533,563
-----------------------------------
Wait Time % Total

(cs)
Wt Time
--------- -------1,333,260
36.53
985,646
27.01
745,857
20.44
418,009
11.45
132,524
3.63
Latch Activity for DB: ED31 Instance: ed31 Snaps: 1 -2

->"Get Requests", "Pct Get Miss" and "Avg Slps/Miss" are statistics for
willing-to-wait latch get requests
->"NoWait Requests", "Pct NoWait Miss" are for no-wait latch get requests
->"Pct Misses" for both should be very close to 0.0
-> ordered by Wait Time desc, Avg Slps/Miss, Pct NoWait Miss desc
Latches
Exemplo do relatrio de STATSPACK (continuao)

Pct
Avg
Pct
Get
Get Slps/ NoWait
NoWait
Latch
Requests
Miss Miss Requests
Miss
----------------------- ----------- ---- ---- --------- -----
cache buffers chains
142,028,625 0.3 0.4 1,193,834
0.7
cache buffers lru chain
8,379,760 0.1 0.7
414,979
0.1
library cache
36,870,207 2.1 0.7
0
0.4
Redo allocation
10,478,825 0.9 0.3
0
Row cache objects

27,905,682 0.3 0.1
0
Latches
Categorias de Latches
Existem poucos latches sobre os quais o DBA possui controle direto. Em
Oracle 10g, o nmero de latches necessrios calculado com base nos valores
de parmetros de inicializao e parmetros do sistema operacional. O tipo de
latch que sofre muita conteno pode indicar o tipo de problema de
desempenho ocorrendo. Muitas vezes, o tuning feito em nvel de aplicao,
mudando-se o seu comportamento. Se isso no for eficaz, considere ento
alterar as configuraes da SGA, como tamanho do buffer cache ou da shared
pool.
Categorias de latches:
shared pool: protege alocaes de memria na shared pool.

library cache: usado para localizar comandos SQL na shared pool.
cache buffer LRU chain: protege a lista LRU do buffer cache.
cache buffers chain: necessrio quando procura-se por blocos de
dados em cache na SGA.
redo allocation: gerencia a alocao de espao de redo no log buffer
para entradas de redo.
redo copy: usado para escrever registros de redo no redo log buffer.
Conteno de latches e seus significados

A conteno dos latches pode significar o segunite, de acordo com a
categoria:
shared pool e library cache
Comandos SQL e PL/SQL no devem estar sendo reutilizados,
possivelmente por no estarem utilizando variveis BIND, ou pelo tamanho do
cache ser muito pequeno. Para melhorar o desempenho, considere:
Fazer o tuning da shared pool.

Fazer o tuning dos comandos SQL.
Procure blocos muito utilizados.
Configure CURSOR_SHARING.
Configure a Large Pool: o uso de Shared Servers sem a large pool
pode levar a conteno por latches tipo shared pool.
cache buffers lru chain:
Conteno para esse latch indica uso excessivo de operaes de cachebased sorts, comandos SQL acessando ndices ineficientemente, ou muitos full
tables scans. Tambm possvel que o processo DBWR no esteja sendo capaz
de acompanhar as mudanas feitas nos blocos de dados, e fazendo com que
processos servidor estejam esperando mais por buffers livres.
cache buffers chain
Conteno para esse latch indica que alguns blocos especficos esto
sendo repetidamente acessados ("hot blocks").
Latches
Espao para anotaes
10
11. Tuning de Segmentos de

Undo
Tuning de Segmentos de Undo
Objetivos
Descrever o conceito de gerenciamento automtico de undo.
Criar e manter a tablespace de undo gerenciada automaticamente.
Utilizar as vises de performance dinmica

performance de segmentos de undo.
para
verificar

SQL>
SELECT (RD *==(UPS
* OVERHEAD)
+} OVERHEAD)
AS "Bytes"
UNDO_MANAGEMENT
MANUAL
| AUTO
UNDO_RETENTION
n{(segundos,
default
900)
2 FROM
(SELECT value AS RD
3
FROM
v$parameter
4
WHERE name = 'undo_retention'),
5
(SELECT (SUM(undoblks) /
6
SUM( ((end_time - begin_time) *
7
86400))) AS UPS
8
FROM
v$undostat),
9
(SELECT value AS Overhead
10
FROM
v$parameter
11
WHERE name = 'db_block_size');
Automatic Undo Management (AUM)

No Oracle 10g podemos configurar o gerenciamento dos segmentos de
undo para manual (utilizao de segmentos de rollback), ou para automtico.
Fazemos isso atravs do parmetro de inicializao (no dinmico)
UNDO_MANAGEMENT:
Com o gerenciamento automtico, o Oracle calcula o nmero e tamanho
de segmentos de undo necessrios. O DBA tem apenas que criar e
dimensionar a tablespace de undo.
Parmetro UNDO_RETENTION
Pode-se tambm especificar o perodo tempo em que as informaes
presentes nos segmentos de undo devem ser retidas para leituras
consistentes, atravs do parmetro UNDO_RETENTION (em segundos). A
tablespace de undo deve ter espao suficiente ao menos para comportar a
quantidade de informao gerada durante o perodo especificado em
UNDO_RETENTION.
O parmetro UNDO_RETENTION estabelece apenas uma meta na
preservao de dados nos segmentos de undo para leitura consistente. Se o
segmento de undo no puder mais crescer, ele sobrescrever as informaes,
mesmo que estas no tenham sido mantidas pelo tempo configurado em
UNDO_RETENTION, o que pode acarretar em erros SNAPSHOT TOO OLD.
Esse parmetro pode ser modificado dinamicamente, e pode-se usar a
seguinte query para determinar o valor dele e o tamanho da tablespace de
undo:

init<SID>.ora:
...
UNDO_MANAGEMENT=AUTO
UNDO_TABLESPACE=UNDO_TBS
-------------------------------Na criao do banco:
CREATE DATABASE db1
...
UNDO TABLESPACE UNDO_TBS
DATAFILE '/oracle/oradata/<SID>/undotbs1.ora' SIZE 100M
...
-------------------------------Aps a criao do banco:
CREATE UNDO TABLESPACE UNDO_TBS
DATAFILE '/oracle/oradata/<SID>/undotbs1.ora' SIZE 100M;
Undo Tablespace
Configurar o parmetro UNDO_MANAGEMENT para AUTO, requer que se
configure tambm o parmetro UNDO_TABLESPACE com o nome da tablespace
de undo. No modo de gerenciamento automtico de undo, pode haver apenas
uma tablespace de undo ativa de cada vez.
Essa tablespace pode ser criada com a clusula UNDO TABLESPACE no
comando CREATE DATABASE, ou com o comando CREATE UNDO TABLESPACE.
Se o parmetro UNDO_TABLESPACE no for especificado, ser criada a
tablespace SYS_UNDOTBS.
A tablespace de undo no suporta nenhum outro objeto alm de
segmentos de undo criados e gerenciados pelo Oracle.
Exemplo:

ALTERTABLESPACE
SYSTEM SETnome_undo_ts;
UNDO_TABLESPACE = nova_undo_ts;
DROP
Alterao de Tablespace de Undo

Algumas alteraes podem ser feitas na tablespace de undo iguais s
tablespaces comuns. Clusulas do comando ALTER TABLESPACE aceitas so:
ADD DATAFILE
RENAME
DATAFILE [ONLINE|OFFLINE]
BEGIN BACKUP
END BACKUP
Entretanto, no possvel colocar offline um segmento de undo de uma
tablespace de undo.
Trocando de tablespace de undo

Como citado anteriormente, apenas uma tablespace undo pode estar
ativa de cada vez. Para alternarmos o uso de uma tablespace para outra,
usamos o comando ALTER SYSTEM:
A nova tablespace de undo j deve estar criada, e todas as novas
transaes sero direcionadas para ela. As transaes correntes continuaro a
utilizar a tablespace anterior at que sejam completadas.
Removendo uma tablespace de undo

Uma tablespace de undo pode ser removida apenas se ela no for a
tablespace de undo ativa, e se no possuir nenhum segmento ainda em
utilizao por qualquer transao. Utiliza-se o comando DROP TABLESPACE,
sem a necessidade da clusula INCLUDING CONTENTS:
Utilizao de Segmentos de Undo
Figura 11-1: Utilizao de segmentos de undo
Rollback de Transao
Quando uma transao efetua modificaes para uma linha em uma
tabela, a imagem anterior salva no segmento de undo. Se a transao sofrer
rollback, o valor do segmento de undo escrito de volta para a linha,
restaurando o valor original.
Recuperao de Transao
Se a instncia falhar quando transaes estiverem em progresso, o
servidor Oracle deve efetuar o rollback das modificaes que no sofreram
commit quando o banco de dados for aberto novamente. Este rollback
conhecido como recuperao de transao e somente possvel se as
modificaes para o segmento de undo tambm forem protegidas pelos redo
log files.
Leitura Consistente
Quando transaes esto em progresso, outros usurios do banco de
dados no devem visualizar quaisquer modificaes que no sofreram commit
que tenham sido efetuadas por estas transaes. Alm disso, um comando no
deve visualizar quaisquer modificaes que sofram commit aps o incio da
execuo do comando. Os valores antigos nos segmentos de undo so
utilizados tambm para fornecer a quem est efetuando leitura dos dados uma
imagem consistente para um determinado comando.

SQL> SELECT segment_name, tablespace_name, owner, status
2 FROM dba_rollback_segs;
SEGMENT_NAME
------------------------SYSTEM
_SYSSMU1$
_SYSSMU2$
_SYSSMU3$
_SYSSMU4$
_SYSSMU5$
_SYSSMU6$
_SYSSMU7$
_SYSSMU8$
_SYSSMU9$
_SYSSMU10$
TABLESPACE_NAME
--------------SYSTEM
UNDOTBS1
UNDOTBS1
UNDOTBS1
UNDOTBS1
UNDOTBS1
UNDOTBS1
UNDOTBS1
UNDOTBS1
UNDOTBS1
UNDOTBS1
OWNER
-----SYS
PUBLIC
PUBLIC
PUBLIC
PUBLIC
PUBLIC
PUBLIC
PUBLIC
PUBLIC
PUBLIC
PUBLIC
STATUS
------ONLINE
ONLINE
ONLINE
ONLINE
ONLINE
ONLINE
ONLINE
ONLINE
ONLINE
ONLINE
ONLINE
11 rows selected.
Obtendo Informaes sobre Segmentos de

Undo
Segmentos de Undo no Banco de Dados
DBA_ROLLBACK_SEGS
Identificao:
-
SEGMENT_ID
SEGMENT_NAME
Localizao, tipo e status:

-
TABLESPACE_NAME
OWNER (PUBLIC ou SYS)
STATUS (ONLINE ou OFFLINE)

Para obter informaes sobre todos os segmentos de undo no banco de
dados, consulte a viso DBA_ROLLBACK_SEGS:
A coluna OWNER especifica o tipo de um segmento de undo:
SYS referencia um segmento de undo privado.
PUBLIC referencia um segmento de undo pblico.
Estatsticas dos Segmentos de Undo
Figura 11-2: Estatsticas dos segmentos de undo
Efetue um join entre as vises V$ROLLSTAT e V$ROLLNAME para obter as

estatsticas dos segmentos de undo atualmente utilizados pela instncia:
SQL> SELECT n.name, s.extents, s.rssize/1024 "size KB",

2
s.hwmsize/1024 "HWM KB", s.xacts, s.status
3 FROM v$rollname n, v$rollstat s
4 WHERE n.usn = s.usn;
NAME
EXTENTS
size KB
HWM KB
XACTS
STATUS
--------------- ---------- ---------- ---------- --------------SYSTEM
6
376
376
0
ONLINE
_SYSSMU11$
2
120
120
1
ONLINE
_SYSSMU1$
3
184
184
0
ONLINE
_SYSSMU2$
144
33208
33208
0
ONLINE
_SYSSMU3$
164
28728
28728
0
ONLINE
_SYSSMU4$
41
4536
4536
1
ONLINE
_SYSSMU5$
2
120
120
0
ONLINE
_SYSSMU6$
2
120
120
0
ONLINE
_SYSSMU7$
2
120
120
0
ONLINE
_SYSSMU8$
2
120
120
0
ONLINE
_SYSSMU9$
2
120
120
0
ONLINE
_SYSSMU10$
2
120
120
0
ONLINE
12 rows
selected.
TargetTrust
Treinamento
e Consultoria
As principais colunas em V$ROLLSTAT incluem:

Coluna
USN
EXTENTS
RSSIZE
XACTS
HWMSIZE
STATUS
Descrio
Nmero do segmento de undo, relacionado com
V$ROLLNAME.USN para obter o nome.
Nmero de extenses do segmento de undo.
Tamanho atual do segmento em bytes.
Nmero de transaes que esto utilizando o segmento.
High water mark: tamanho mximo em bytes para o qual o
segmento cresceu desde o startup.
Status do segmento de undo. ONLINE indica que o segmento
de undo est disponvel para uso.

SQL> SELECT s.username, t.xidusn, t.ubafil,
2
t.ubablk, t.used_ublk
3 FROM v$session s, v$transaction t
4 WHERE s.saddr = t.ses_addr;
USERNAME
XIDUSN
UBAFIL
UBABLK USED_UBLK
---------- ---------- ---------- ---------- ---------ALUNO
4
2
8781
1
ALUNO
11
2
171
1
Atividade Atual nos Segmentos de Undo
Figura 11-3: Atividade atual nos segmentos de undo
Para verificar o uso dos segmentos de undo pelas transaes correntes

ativas, efetue um join entre as vises V$TRANSACTION e V$SESSION:
As colunas relevantes em V$TRANSACTION e suas descries esto
apresentadas abaixo:
Coluna
SES_ADDR
XIDUSN
UBAFIL
UBABLK
UBASQN
UBAREC
USED_UBLK
Descrio
Endereo (address) da seo, que pode ser relacionado
com V$SESSION.SADDR.
Nmero do segmento de undo utilizado pela transao.
utilizado como parte do transaction ID.
As colunas UBAFIL, UBABLK, UBASQN e UBAREC
especificam a localizao atual no segmento de undo onde
a transao est escrevendo.
Nmero de blocos de undo gerados pela transao.
10

SQL> SELECT begin_time, end_time, undoblks,
2
txncount, maxquerylen
3 FROM
v$undostat;
BEGIN_TI
-------04/01/05
04/01/05
04/01/05
04/01/05
04/01/05
...
END_TIME
UNDOBLKS
TXNCOUNT MAXQUERYLEN
-------- ---------- ---------- ----------04/01/05
18
25
0
04/01/05
60
106
0
04/01/05
33
182
0
04/01/05
90
181
0
04/01/05
53
117
0
Monitorando o Gerenciamento Automtico de

Undo
Viso V$UNDOSTAT
Utilize a viso V$UNDOSTAT para monitorar a alocao de espao e
utilizao de segmentos de undo automticos. Cada linha dessa viso guarda
informaes estatsticas sobre um intervalo de 10 minutos da instncia. Essa
viso pode ser usada para estimar a quantidade de espao para redo
necessria para a carga atual de trabalho do sistema.
O tuning de undo automtico pode ser feito em dois pontos:
O tamanho da tablespace de undo.

A quantidade de tempo em que blocos de undo so mantidos antes
de serem sobrescritos.
11
Diretrizes: Utilizando Menos Undo

Transaes
Voc pode ser capaz de reduzir algum desperdcio de segmento de undo
treinando usurios e desenvolvedores a fazerem o seguinte:
Usurios devem comitar seu trabalho regularmente.

Desenvolvedores
no
devem
codificar
transaes
desnecessariamente.
longas
12
Problemas com Segmentos de Undo

Espao Insuficiente para as Transaes
Causas Possveis
Uma transao no pode utilizar mltiplos segmentos de undo e pode
falhar se no existir espao suficiente no segmento de undo. Isto pode ser
causado pela seguinte situao:
O espao da tablespace insuficiente (ORA-01560).
Soluo
Aumente o espao disponvel para a tablespace:
Estendendo os datafiles da tablespace.
Permitindo que os datafiles cresam automaticamente (AUTOEXTEND).
Adicionando novos arquivos para a tablespace.
13
Erro de Leitura Consistente
Figura 11-4: Leitura consistente
Causas Possveis
O servidor Oracle garante que um comando processar somente dados
que sofreram commit at um determinado momento. Quaisquer modificaes
que no haviam sofrido commit quando o comando foi disparado ou que foram
efetuadas aps o comando iniciar sua execuo, no sero vistas pelo
comando. Se o servidor Oracle no conseguir construir uma imagem de leitura
consistente dos dados, o usurio receber um erro ORA-01555: Snapshot too
old. Este erro pode ocorrer quando a transao que efetuou as modificaes j
sofreu commit e:
A entrada da transao no header do undo foi reutilizada.
A before-image (imagem anterior) do segmento de undo foi sobrescrita
por outra transao.
Soluo
Erros de leitura consistente podem ser minimizados garantindo que as
tablespaces de undo possuam espao suficiente para as transaes do usurio.
14
Exerccios 11
diagnstico disponveis para monitorar e efetuar o tuning de segmentos de
undo.
1. Identifique suas configuraos atuais de gerenciamento de undo.
2. Como usurio ALUNO, execute o script insere_dados.sql. O script insere
1000 novas linhas para a tabela TCONTRATOS sem efetuar o commit.
3. Conecte-se como SYSTEM. Identifique a atividade atual dos segmentos
de undo.
4. Retorne para a sesso do aluno e efetue o commit.
5. Como SYSTEM identifique a atividade atual dos segemntos de undo.
6. Tente remover a tablespace de undo. O que acontece?
7. Como SYSTEM, encontre se voc teve qualquer conteno de segmento
de undo desde o startup, utilizando duas origens de informao
diferentes.
8. A viso V$SYSTEM_EVENT apresenta quaisquer esperas relacionadas
com segmentos de undo?
15
Espao para anotaes
16
12. Tuning de SQL
Tuning de SQL
Objetivos
Identificar os papis do DBA no tuning de aplicao.
Conhecer os modos de otimizao do Oracle.
Utilizar ferramentas Oracle para

comandos SQL.
Rastrear e registrar a utilizao de mdulos para packages,

procedures e triggers.
Identificar comandos
performance.
SQL
diagnosticar performance
alternativos
para
incrementar
de
Tuning de SQL
Viso Geral
Tuning de aplicao a parte mais importante do tuning.

Administradores de banco de dados:
Podem no ser diretamente envolvidos no tuning de aplicao.
Devem estar familiarizados com o impacto que comandos SQL
escritos de forma despreocupada podem ter sobre a performance do
banco de dados.
O design da aplicao e o tuning da aplicao devem fornecer os
melhores benefcios de performance. O mtodo pelo qual os dados so
selecionados e a quantidade de dados que so selecionados possuem srias
implicaes sobre a performance da aplicao se os comandos que executam
estas operaes no forem corretamente escritos.
Tarefas do Administrador do Banco de Dados

Como um administrador de banco de dados (DBA), voc pode no estar
diretamente envolvido no tuning de uma aplicao, assim como
desenvolvedores so normalmente responsveis pelo desenvolvimento da
aplicao e pela escrita de comandos SQL. Entretanto, como um DBA, voc
necessita estar atento ao impacto que comandos SQL escritos sem
preocupao podem ter sobre o ambiente do banco de dados. Voc deve ser
capaz de fornecer assistncia no tuning da aplicao e de prontamente
identificar comandos SQL ineficientes.
Tuning de SQL
Modos de Otimizao
Rule-based (baseado em regra).

Utiliza um sistema de ranking.
Dirigido pela sintaxe.
Cost-based (baseado em custo).
Escolhe o caminho de menor custo.
Dirigido por estatsticas.
Otimizao Baseada em Regras

Neste modo, o processo servidor escolhe seu caminho de acesso para os
dados examinando a consulta. Este otimizador possui um conjunto completo
de regras por ranking de caminhos de acesso (access paths). Desenvolvedores
Oracle experientes freqentemente possuem um entendimento muito bom
destas regras, e efetuam o tuning dos seus comandos SQL adequadamente.
Otimizao Baseada em Custo

Neste modo, o otimizador examina cada comando e identifica todos os
caminhos de acesso possveis para os dados. Ele ento calcula o custo de
recursos de cada caminho de acesso e escolhe o de menor custo. O custo
baseado principalmente no nmero de leituras lgicas.
O otimizador baseado em custo dirigido por estatsticas utilizando as
estatsticas geradas para os objetos envolvidos no comando SQL para
determinar o plano de execuo mais efetivo. O otimizador baseado em custo
utilizado se qualquer objeto em um comando SQL teve suas estatsticas
geradas.
Nota: Otimizao baseada em regras foi depreciada na verso Oracle
10g, sendo somente suportada a otimizao baseada em custo. A otimizao
baseada em regras ainda existe porm nenhuma modificao ser realizada
para verses posteriores.
Tuning de SQL
SELECT /*+ FIRST_ROWS */ * FROM aluno.tclientes;
Configurando o Modo de Otimizao
Parmetro OPTIMIZER_MODE
Valore possveis so:
CHOOSE (depreciado)
RULE (depreciado)
FIRST_ROWS - minimiza o tempo de resposta imediata (possivelmente
as custas de um tempo de resposta global maior)
ALL_ROWS - minimiza o tempo total de resposta
Em nvel de instncia
Em nvel de sesso
Em nvel de comando, utilizando hints
O DBA responsvel pela configurao do OPTIMIZER_MODE a nvel de

instncia uma vez que isto requer a reinicializao da instncia. Tipicamente,
desenvolvedores de aplicao devem possuir a habilidade para configurar o
OPTIMIZER_MODE a nvel de sesso como tambm utilizar hints em comandos
SQL.
Parmetro OPTIMIZER_MODE
O valor default ALL_ROWS.
ALTER SESSION SET OPTIMIZER_MODE = value
Desenvolvedores podem configurar este parmetro utilizando o comando

ALTER SESSION.
Hints de Otimizao
Voc pode codificar hints em um comando, como mostrado abaixo:
Os hints de otimizao possveis so FIRST_ROWS e ALL_ROWS.
Nota: Os parmetros CHOOSE e RULE no so mais suportados no Oracle

10g. Se voc configurar esses parmetros retornar um warning. As
funcionalidades desses parmetros ainda existem, mas vo ser removidas em
futuras verses. No Oracle 10g, ALL_ROWS o valor default do parmetro de
inicializao OPTIMIZER_MODE.
Tuning de SQL
Ferramentas de Diagnstico
Vrias ferramentas de diagnstico esto disponveis para avaliar a
performance de comandos SQL e mdulos PL/SQL. Cada uma fornece ao
desenvolvedor ou DBA um nvel varivel de informaes.
EXPLAIN PLAN: executado dentro de uma sesso para um comando

SQL e gera os resultas na tabela PLAN_TABLE.
SQLTRACE: este utilitrio fornece informaes detalhadas relativas a
execuo de um comando SQL.
TKPROF: este um utilitrio do sistema operacional que obtm os
resultados a partir de uma sesso SQLTRACE e os coloca em uma
forma legvel.
AUTOTRACE: gera um plano de execuo para um comando SQL e
fornece estatsticas relativas ao processamento do comando.
Tuning de SQL
EXPLAIN
PLAN FOR
SQL> @$ORACLE_HOME/rdbms/admin/utlxplan
SELECT ...
Explain Plan
Pode ser utilizado sem a opo de tracing.

Necessita da tabela PLAN_TABLE, criada pelo script utlxplan.sql.
Modificaes podem invalidar o plano.
Voc pode utilizar o comando EXPLAIN no SQL*Plus sem utilizar a opo

de tracing. Voc deve criar a tabela chamada PLAN_TABLE utilizando o script
fornecido utlxplan.sql. As colunas teis para a maioria dos propsitos so
OPERATION, OPTIONS e OBJECT_NAME.
Para visualizar o plano para uma consulta, utilize a seguinte sintaxe:
Ento consulte a tabela PLAN_TABLE para verificar o plano de execuo.
A PLAN_TABLE exibe como o comando ser executado se voc decidir
execut-lo naquele momento. Lembre-se que se voc efetuar modificaes
antes de executar o comando (criar um ndice, por exemplo) a execuo atual
pode ser realizada diferentemente.
Alm disso, se voc no utilizar um statemend_id no explain plan, voc
pode necessitar truncar a tabela PLAN_TABLE antes de gerar outro plano de
execuo.
Tuning de SQL
SELECT
id,
operation, options, object_name,position
SQL> SQL>
EXPLAIN
PLAN
for
2 FROM
plan_table;
2 UPDATE
s_emp
3 SET salary = salary * 1.10
4 WHERE dept_id = (select id from s_dept
5
where name = 'Finance');
ID OPERATION
--- -----------------0 UPDATE STATEMENT
1
FILTER
2
TABLE ACCESS
3
TABLE ACCESS
4
INDEX
OPTIONS
OBJECT_NAME
POSITION
----------- ---------------------- -------1
1
FULL
EMP
1
BY ROWID
DEPT
2
RANGE SCAN DEPT_NAME_REGION_ID_UK
1
Exemplo de Plano de Execuo

Para visualizar o plano de execuo a partir da tabela plan_table, execute
a seguinte consulta:
Para este exemplo somente cinco colunas da tabela PLAN_TABLE so
selecionadas:
ID: um nmero atribudo para cada passo no plano de execuo.

OPERATION: o nome da operao interna efetuada neste passo.
OPTIONS: uma variao da operao descrita na coluna OPERATION.
OBJECT_NAME: o nome da tabela ou ndice.
POSITION: a ordem de processamento para passos que possuem o
mesmo PARENT_ID.
Interpretando o Plano de Execuo

Cada passo do plano de execuo recupera linhas a partir do banco de
dados ou recebe uma linha como entrada a partir de um ou mais outros
passos. Planos de execuo so lidos de baixo para cima.
A operao filter recebe o conjunto de linhas retornadas pelo TABLE

ACCESS (full) da tabela EMP.
O INDEX (RANGE_SCAN) da operao 4 envia linhas para a operao
3.
O custo de um plano de execuo um valor proporcional ao tempo

decorrido esperado necessrio para executar o comando utilizando o plano de
execuo.
Planos de execuo podem ajudar voc a determinar qual ser o benefcio
na criao e utilizao de ndices para consultas. Voc pode alcanar melhorias
de performance significativas atravs de um tuning sensato. Identifique reas
para melhorias potenciais utilizando SQL Trace ou Autotrace.
Tuning de SQL
Diagnosticando a Performance de Comandos

SQL
Uma certa seqncia de passos necessria
adequadamente a performance de comandos SQL.
para
diagnosticar
1. O primeiro passo no diagnstico de performance de comandos SQL

garantir que os parmetros de inicializao estejam adequados. Estes
podem ser configurados a nvel de instncia, ou a configurao de
alguns parmetros suportada a nvel de sistema ou sesso.
2. SQL Trace deve ser invocado em nvel de instncia ou sesso.
Geralmente, melhor a partir de um ponto de vista global de
performance se for invocado em nvel de sesso.
3. Execute a aplicao ou comando SQL que voc deseja diagnosticar.
4. Desligue o SQL Trace. Isto necessrio para fechar o arquivo de trace
corretamente em nvel de sistema operacional (ou o utilitrio TKPROF
pode no fornecer um resultado vlido).
5. Utilize o TKPROF para formatar o arquivo de trace gerado durante a
sesso de trace. A menos que o arquivo seja formatado, fica muito
difcil de interpretar os resultados.
6. Utilize o resultado do TKPROF para diagnosticar a performance do
comando SQL.
Tuning de SQL
MAX_DUMP_FILE_SIZE
= n
TIMED_STATISTICS
= true
USER_DUMP_DEST = diretrio
Parmetros de Inicializao Importantes
MAX_DUMP_FILE_SIZE
USER_DUMP_DEST
TIMED_STATISTICS
Dois parmetros do arquivo init<SID>.ora controlam o tamanho e o

destino do arquivo de sada do SQL Trace.
Voc deve configurar um terceiro parmetro para obter informaes de
tempo:
As estatsticas de tempo possuem uma resoluo de um centsimo de
segundo. Isto significa que qualquer operao que demore um centsimo de
segundo ou menos pode no ser medida com preciso, especialmente para
consultas simples que executam rapidamente.
No Oracle 10g, o parmetro TIMED_STATISTICS pode ser configurado
dinamicamente em nvel de sesso utilizando o comando ALTER SESSION.
10
Tuning de SQL
ALTER SESSION SET SQL_TRACE = [TRUE | FALSE]
EXECUTE sys.dbms_session.set_sql_trace( [TRUE | FALSE] )
EXECUTE sys.dbms_system.set_sql_trace_in_session(
session_id, serial_id, [ TRUE | FALSE ] );
Ligando e Desligando o Trace

Em nvel de instncia:
SQL_TRACE = [ TRUE | FALSE ]
Em nvel de sesso utilizando:
SQL Trace pode ser habilitado ou desabilitado utilizando diferentes

mtodos a nvel de instncia ou sesso.
Nvel de Instncia
A configurao do parmetro SQL_TRACE em nvel de instncia um
mtodo para habilitar o tracing. Entretanto, requer que a instncia seja
reiniciada quando o trace no for mais necessrio. Isto impe um hit de
performance significativo, porque ser efetuado trace para todas as sesses da
instncia.
Nvel de Sesso
Trace em nvel de sesso resulta em um hit de performance global menor,
porque pode-se efetuar o trace apenas de sesses especficas. Os trs
mtodos para habilitar ou desabilitar o SQL Trace so:
Utilizar o comando ALTER SESSION, que resulta em trace durante

toda a sesso ou at que o valor seja configurado para FALSE.
Utilizar a procedure PL/SQL DBMS_SESSION para a sesso.
Utilizar a procedure PL/SQL DBMS_SYSTEM para habilitar o trace em
nvel de sesso para um usurio diferente do usurio conectado.
11
Tuning de SQL
tkprof ora_19999.trc
tracefile outputfile
$ tkprof
myfile.txt explain=aluno/aluno
[sort=option] [print=n]
[explain=username/password] [insert=filename]
[sys=NO] [record=filename]
[table=schema.tablename]
Formatando o Arquivo de Trace
Figura 12-3: Formatando o arquivo de trace
Utilize o TKPROF para formatar o arquivo de trace em um relatrio legvel.

O arquivo de trace criado no diretrio especificado pelo parmetro
USER_DUMP_DEST e o relatrio gerado no diretrio especificado pelo nome
outputfile.
Opes do TKPROF
Opo
TRACEFILE
OUTPUTFILE
SORT=option
PRINT=n
EXPLAIN=username/passw
ord
INSERT=filename
SYS=NO
Descrio
Nome do arquivo de trace
Nome do arquivo formatado
A ordem pela qual deve-se ordenar os comandos
Exibe os primeiros n comandos
Executa o EXPLAIN PLAN no usurio especificado
Gera comandos INSERT

Ignora comandos SQL recursivos executados como
usurio sys
AGGREGATE=[Y | N]
Se voc especificar AGGREGATE=N, ento o TKPROF
no agregar mltiplos usurios do mesmo texto
SQL
RECORD=filename
Registra os comandos encontrados no arquivo de
trace
TABLE=schema.tablename Coloca o plano de execuo na tabela especificada
(ao invs do default PLAN_TABLE)
12
Tuning de SQL
call
count cpu elapsed disk query current rows
------- ----- ---- ------- ---- ----- ------- ---Parse
2 0.11
0.22
0
2
0
0
Execute
4 0.00
0.00
0
4
0
0
Fetch
428 0.00
0.06 600
806
808 6400
-------- ---- ------- ---- ----- ------- ---total
434 0.11
0.28 600
806
814 6400
Estatsticas de Trace (TKPROF)

Estatstica
Count
CPU
Elapsed
Disk
Query
Current
Rows
Significado
O nmero de vezes que o comando sofreu
parse ou execute e o nmero de
chamadas de fetch emitidas para o
comando
Tempo de processamento para cada fase,
em segundos (se o comando foi
encontrado na shared pool, isto 0 para a
fase de parse)
Tempo decorrido, em segundos (isto
normalmente no muito til porque
outros processos afetam o tempo
decorrido)
Blocos de dados fsicos lidos a partir dos
arquivos do banco de dados (esta
estatstica pode ser baixa se os dados
estavam em buffer)
Buffers lgicos recuperados por leituras
consistentes (normalmente para
comandos SELECT)
Buffers lgicos recuperados em modo
corrente (normalmente para comandos
DML)
Linhas processadas pelo comando externo
(para comandos SELECT, isto exibe a fase
de fetch; para comandos DML, isto exibe a
fase de execute)
A soma de Query e Current o nmero total de buffers lgicos acessados.
13
Tuning de SQL
Examinando a Performance de Comandos

Outros Resultados do TKPROF
Recursive SQL
O trace obtm estatsticas para comandos SQL recursivos. Voc no
pode diretamente afetar a quantidade de SQL recursivo que o servidor
efetua, de forma que estas informaes no so muito teis. As
estatsticas recursivas tambm so includas nas estatsticas para o
comando SQL que causou a execuo recursiva. Utilize a opo
SYS=NO do TKPROF para suprimir a apresentao destas informaes.
O TKPROF fornece totais sumarizados separados para comandos
recursivos e no recursivos, o que deve ajudar a evitar erros de clculo.
Library Cache Misses
Isto indica o nmero de vezes que o comando no foi encontrado no
library cache nas fases de parse e execute. Se o comando estava na
memria cache e no ocorreram library cache misses, ento a
estatstica no listada.
User
Isto o ID do ltimo usurio a efetuar o parse do comando.
Execution Plan
Quando voc especifica o parmetro EXPLAIN, o TKPROF conecta-se
para o banco de dados com o usurio e senha fornecidos.
Ento ele monta os caminhos de acesso para cada comando SQL que
sofreu trace e inclui isto no relatrio. Uma vez que o TKPROF conecta-se
para o banco de dados, ele utiliza as informaes disponveis no
momento em que o TKPROF est executando e no do momento em
que as estatsticas de trace foram geradas. Isto poderia fazer diferena
se, por exemplo, um ndice fosse criado ou removido desde o trace do
comando.
O relatrio inclui ainda o nmero de linhas processadas por cada passo
do plano de execuo.
Optimizer Hint
Isto indica o optimizer hint utilizado durante a execuo do comando.
Se no existir um hint, ento exibido o modo de otimizao utilizado.
14
Tuning de SQL
@$ORACLE_HOME/rdbms/admin/utlxplan
SQL> set
@$ORACLE_HOME/sqlplus/admin/plustrce
autotrace [on | traceonly]
Autotrace
Crie a tabela PLAN_TABLE:
Crie a role plus_trace:
Configure o Autotrace:
O AUTOTRACE pode ser utilizado ao invs do SQL Trace. A vantagem em

utilizar o autotrace que voc no precisa formatar um arquivo de trace
podendo exibir automaticamente o plano de execuo para o comando SQL.
Entretanto, o autotrace efetua o parse e o execute do comando, enquanto
que o explain plan somente efetua o parse.
Os passos para utilizar o AUTOTRACE consistem de:
1. Criar a tabela PLAN_TABLE utilizando o script utlxplan.sql.
2. Efetuar o grant da role de trace para o usurio executando o script
plustrce.sql. Isto concede privilgios de SELECT para as vises V$.
3. Habilitar o trace:
Se voc configurar AUTOTRACE ON, ser produzido o result set, o
explain plain e a lista com estatsticas.
Se voc configurar AUTOTRACE TRACEONLY, ser exibido o explain
plain e as estatsticas.
15
Tuning de SQL
Comandos SQL Ineficientes

Sintomas de Comandos SQL Ineficientes
Comandos SQL executam mal por vrios tipos de razes. Alguns dos mais
comuns esto listados abaixo.
O Otimizador no pode Utilizar um ndice
Existem muitas situaes nas quais o otimizador no consegue utilizar um
ndice, embora fosse mais eficiente. Voc deve examinar o comando SQL e
reescrev-lo para utilizar um ndice.
O Comando Inclui uma Tree Walk
Uma tree walk utiliza a clusula CONNECT BY para recuperar dados que
esto armazenados de maneira hierrquica. Se voc tiver que utilizar tree
walking, indexe as colunas das clusula START WITH e CONNECT BY.
O Comando Inclui Funes de Grupo
Existem dois problemas possveis:
Voc pode conseguir remover a funo de grupo se voc armazenar

um valor derivado no registro mestre. Entretanto, esta soluo torna
o cdigo da aplicao para inserts e updates mais complicado, e
pode tornar estas operaes inaceitavelmente lentas.
Voc deve excluir linhas com a clusula WHERE; a clusula HAVING
deve ser utilizada somente com uma condio agregada. O uso
indevido da clusula HAVING aumenta o tempo de resposta.
O Comando Inclui a Palavra Chave DISTINCT

Quando voc utiliza DISTINCT, os dados so ordenados. Se o comando
selecionar um grande nmero de linhas, o servidor pode gerar segmentos
temporrios para tratar a execuo individual de sorts. Isto gera overhead em
I/O e processamento, devendo ser evitado.
O Comando est Baseado em uma Viso Complexa
Quando se estiver utilizando vises, voc pode querer integrar a viso
com a consulta para limitar o nmero de linhas processadas. Voc deve
tambm garantir que a consulta no visite a tabela desnecessariamente para
recuperar colunas que so parte da viso, que poderiam ser recuperadas
diretamente consultando a tabela.
Consultas Alternativas
Lembre que freqentemente existe mais de um comando SQL que fornece
o resultado desejado. Cada um pode utilizar um caminho de acesso diferente e
executar de forma diferente. Ambos, DBAs e desenvolvedores devem estar
familiarizados como diferentes consultas podem ser utilizadas para obter os
mesmos resultados.
16
Tuning de SQL
Packages, Procedures e Triggers

Metas de tuning:
Uso eficiente da memria da shared pool.

Minimizar o parse.
Fixar (pin) o cdigo utilizado freqentemente em memria.
Rastrear a utilizao de cdigo PL/SQL freqentemente disparado.
Tuning de aplicao tambm consiste de como packages, procedures e

triggers so utilizadas. O fato de que cada tipo de objeto PL/SQL armazenado
de forma compilado dentro do Oracle no impede a necessidade de efetuar
tuning do seu uso.
Uma vez que tenha sido efetuado o parse de um objeto, este
armazenado no cache da shared pool, e esta verso compilada pode ser
reutilizada. Entretanto, se o objeto for removido da shared pool, ento ele deve
ser recompilado quando executado, resultando em hits de performance
adicionais.
Voc pode fixar um objeto na shared pool, o que garante que este no
seja removido da memria, portanto minimizando operaes de parse.
O desenvolvedor da aplicao ou o DBA pode rastrear a utilizao de tais
procedures PL/SQL para garantir que estejam utilizando efetivamente
estruturas compartilhadas do Oracle.
17
Tuning de SQL
Performance de Mdulo
Se um mdulo da aplicao se registrar com o banco de dados quando for
chamado, voc pode rastrear o seguinte para cada mdulo:
Performance
Utilizao de Recursos
Configurando a Package DBMS_APPLICATION_INFO

Esta package j deve existir uma vez que criada pelo script catproc.sql
no momento da criao do banco de dados. Voc pode executar o script
dbmsutil.sql para criar esta package se necessrio.
18
Tuning de SQL
SQL> CREATE OR REPLACE PROCEDURE add_employee
2
(name IN VARCHAR2,
3
salary IN NUMBER,
4
manager IN NUMBER,
5
title IN VARCHAR2,
6
commission IN NUMBER,
7
department IN NUMBER)
8 IS
9 BEGIN
10
DBMS_APPLICATION_INFO.SET_MODULE('add_employee','insert into
s_emp');
11 ...
12 END;
13 /
Registrando um Mdulo
SET_MODULE(module, action)
SET_ACTION(action)
SET_CLIENT_INFO(client)
O Oracle fornece na package DBMS_APPLICATION_INFO as procedures

apresentadas a seguir. Quando uma aplicao efetua uma chamada destas
procedures, estas registram informaes sobre a chamada nas vises
V$SESSION e V$SQLAREA.
Procedure
SET_MODULE(module,
action)
SET_ACTION(action)
Descrio
Configura o nome do mdulo e, opcionalmente, a ao
(dispare esta procedure no incio de cada mdulo)
Configura o nome da ao corrente em um mdulo
registrado (chame esta procedure antes de cada nova
transao e novamente aps a transao para
configurar a ao para NULL)
SET_CLIENT_INFO(client_inf Configura informaes do cliente para a sesso
o)
Onde:
module
o nome do mdulo, com at 48 caracteres, sendo

armazenado na V$SQLAREA.
action
o nome, ou descrio, da ao. Pode ser at 32

caracteres e armazenada na V$SQLAREA.
client_info
contm informaes adicionais, com at 64 caracteres.

armazenado na V$SESSION.
19
Tuning de SQL
SQL> SELECT sql_text, disk_reads, module, action

2 FROM v$sqlarea
3 WHERE module = 'add_employee';
SQL_TEXT
DISK_READS MODULE
ACTION
--------------------------- ---------- ------------ --------------INSERT INTO emp(ename,
1 add_employee insert into emp
empno, sal, hiredate,
comm, deptno) VALUES (name,
emp_seq.next, manager,
title, SYSDATE, commission,
department)
Rastreando um Mdulo
READ_MODULE(module, action)
READ_CLIENT_INFO(client)
O Oracle fornece na package DBMS_APPLICATION_INFO as duas

procedures apresentadas abaixo. Quando uma aplicao executa estas
procedures, as informaes so obtidas a partir das vises V$SESSION e
V$SQLAREA.
Procedure
READ_MODULE(module,
action)
READ_CLIENT_INFO(action)
Descrio
Recupera os nomes do ltimo mdulo e
ao configurados por SET_ACTION ou
SET_MODULE
Recupera a ltima informao de cliente
configurada para a sesso
20
Tuning de SQL
Obtendo Informaes do Dicionrio

Vises de Performance Dinmica
Voc pode consultar vises de performance dinmica para derivar
informaes sobre a sesso corrente ou instncia.
V$MYSTAT: contm estatsticas para a sesso corrente.

V$PARAMETER: contm os valores para os parmetros que
pertencem a sesso corrente que est consultando a viso.
V$SYSTEM_PARAMETER: contm os valores para os parmetros que
foram configurados a nvel de instncia.
Vises do Dicionrio de Dados

Muitas das vises do dicionrio de dados podem ser consultadas para
derivar informaes sobre objetos e estatsticas. Estas incluem muitas das
vises USER_*, ALL_* e DBA_*. Como exemplo podemos citar: USER_TABLES,
ALL_TABLES e DBA_TABLES ou USER_INDEXES, ALL_INDEXES e DBA_INDEXES.
21
Tuning de SQL
Exerccios 12
O objetivo desta seo de exerccios familiarizar voc com o uso do
EXPLAIN PLAN e com a interpretao do relatrio formatado de um arquivo de
trace gerado utilizando-se o TKPROF.
1. Conecte-se como ALUNO e crie a tabela PLAN_TABLE sobre o schema do
ALUNO.
2. Execute um describe da tabela PLAN_TABLE.
3. Utilize o EXPLAIN PLAN para visualizar o plano de execuo trabalhado
pelo otimizador para o comando SQL do script lab12_1.sql.
4. Utilize o Trace e TKPROF para visualizar a performance destes planos.
a. Configure sua sesso para o modo de trace.
b. Execute o script lab12_2.sql.
c. Encerre o SQL*Plus e formate seu arquivo de trace utilizando o
TKPROF. Utilize as opes SYS=NO e EXPLAIN.
22
Tuning de SQL
Espao para anotaes
23
Tuning de SQL
24
13. Consideraes de Tuning

para Diferentes Aplicaes
Consideraes de Tuning para Diferentes Aplicaes
Objetivos
Utilizar os mtodos de acesso a dados disponveis para efetuar o

tuning do design lgico do banco de dados.
Identificar as demandas
transaes online (OLTP).
Identificar as demandas de sistemas de suporte a deciso (DSS).
Reconfigurar
sistemas
necessidades especficas.
de
sistemas
de
temporariamente
processamento
para
atender
de
Viso Geral
Fase de Design de Dados
Voc deve determinar quais dados so necessrios para sua aplicao.
Voc necessita estruturar a informao para melhor satisfazer as metas de
performance.
O processo de design do banco de dados sofre um estgio de

normalizao, no qual os dados so analisados para garantir que
dados redundantes no sejam mantidos em nenhum lugar.
Entretanto, voc pode necessitar desnormaliz-lo por razes de
performance.
Exemplo: ao invs de forar uma aplicao a recalcular o preo total
de todas as linhas de um determinado pedido cada vez que este for
acessado, voc pode decidir incluir o valor total de cada pedido no
banco de dados.
Outra considerao conteno nos dados. Considere um banco de

dados de 1 terabyte de tamanho, no qual mil usurios acessam
apenas 0.5% dos dados. Isto poderia causar problemas de
performance.
Estrutura Lgica do Banco de Dados

A preocupao inicial deve ser:
O design de ndices, garantindo que os dados no estejam muito

nem pouco indexados (isto no leva em considerao os ndices de
PK, definidos no estgio anterior, mas os ndices adicionais para
suportar a aplicao).
A utilizao correta dos diferentes tipos de ndices:
B-Tree
Bitmap
Reverse
O uso apropriado de seqncias, clusters, tabelas index-organized.
A necessidade de coleta de histogramas para o CBO.
O uso opcional de dados particionados.
Processamento de Transaes Online
Figura 13-1: Processamento de transaes online
So sistemas com grande processamento e intensivas operaes de

insert/update.
Contm grandes volumes de dados que:
Crescem continuamente.
So acessados concorrentemente por milhares de usurios.
Aplicaes Tpicas de OLTP
Sistemas de reservas de empresas de aviao.

Aplicaes com grandes entradas de pedidos.
Aplicaes bancrias.
Requisitos
Alta disponibilidade (7 dias/24 horas)

Alta velocidade.
Alta concorrncia.
Tempo de recovery reduzido.
Sistemas de Suporte a Deciso (DSS)
Figura 13-2: Sistemas de suporte a deciso
Efetua consultas em grandes quantidades de dados.

Faz muito uso de full table scans.
Caractersticas
Aplicaes de suporte a deciso agrupam grandes quantidades de
informao em relatrios compreensveis.
Eles obtm dados a partir de sistemas OLTP e utilizam sumrios e
agregaes na recuperao destes. Efetua muito uso de full table scans como
mtodo de acesso.
Pessoas que formulam decises em uma organizao utilizam estes dados
para determinar qual estratgia a organizao deve tomar.
Exemplo: uma ferramenta de marketing determina os padres de
compras dos consumidores baseada nas informaes obtidas a partir de dados
demogrficos para determinar quais itens vendem melhor em quais
localizaes.
Requisitos
Excelente tempo de resposta.
Quando voc desenha um DSS, voc deve garantir que as consultas
sobre grandes quantidades de dados possam ser efetuadas dentro de
um tempo razovel.
Preciso.
Disponibilidade diria.
Aplicaes com Mltiplos Propsitos
Figura 13-3: Aplicaes com mltiplos propsitos
Sistemas Hbridos
Muitas aplicaes confiam em vrias configuraes e opes Oracle. Voc
deve decidir que tipo de atividade sua aplicao efetua e determinar quais
caractersticas so melhor adaptadas para ela.
Metas de performance conflitantes podem ser resolvidas copiando dados
coletados a partir de bancos de dados OLTP para um banco de dados DSS que
ser somente consultado. Mas este exemplo compromete a meta de preciso
para a aplicao DSS.
Portanto, voc deve determinar quais metas so mais importantes.
Escolhendo a Estrutura Fsica Mais Adequada

Fatores que afetam a escolha:
Linhas lidas em grupos

Comandos DML ou SELECT
Tamanho da tabela
Tamanho da linha, grupo de linhas, e tamanho do bloco
Transaes grandes ou pequenas
O Objetivo do DBA fazer com que leituras e escritas sejam feitas o mais
rapidamente possvel. Esses fatores devem ser considerados.
Linhas lidas em grupos

Se determinados grupos de linhas forem acessados em conjunto,
considere o uso de clusters, que as armazenam dessa forma. Entretanto,
clusters no tem bom desempenho com grandes cargas de DML.
Tamanho da tabela
Considere colocar tabelas grandes tabelas em tablespaces separadas.
Para tabelas muito grandes, use particionamento, e coloque as diferentes
parties em diferentes tablespaces, e espalhe os datafiles em diferentes
discos/controladoras. Isso ajuda a distribuir a carga de trabalho pelos
dispositivos fsicos de I/O.
Tamanho da linha, grupo de linhas, e tamanho de

bloco
Em Oracle 10g possvel termos mltiplos tamanhos de blocos. Dessa
forma, tabelas com registros muito grandes, ou que acessem os registros em
grupos, podem ter blocos de tamanhos maiores.
Transaes grandes ou pequenas

Se houverem transaes grandes, que adicionem muitos dados, considere
alocar mais espao para os objetos alm daquele necessrio para a carga
inicial de dados. Se as transaes forem pequenas, ser necessrio menos
espao para undo.
Mtodos de Acesso aos Dados

Para melhorar a performance, voc pode utilizar os seguintes mtodos de
acesso aos dados:
ndices:
B-Tree
Bitmap
Chave Reversa
Function-based
Tabelas Index-Organized.
Clusters.
Histogramas.
ndices, IOT e Clusters

Estas so estruturas de dados lgicas criadas pelo DBA se necessrio.
ndices so utilizados pelo servidor Oracle se o otimizador baseado

em custo (CBO), confiando nas estatsticas existentes, estimar que o
comando ir executar mais rpido.
Tabelas index-organized e clusters contm dados que podem ser
recuperados mais rapidamente do que se fossem armazenados em
tabelas normais.
Histogramas
Estes so estatsticas coletadas pelo comando ANALYZE, armazenadas em
vises do dicionrio e utilizadas pelo otimizador baseado em custo (Cost Based
Optimizer) para efetuar o tuning de execuo dos comandos SQL.
ndices B-Tree
Figura 13-4: ndices B-Tree
Quando Criar ndices B-Tree

ndices B-Tree aumentam a performance de consultas que selecionam
uma pequena percentagem das linhas de uma tabela. Como regra geral, voc
deve criar ndices em tabelas que so freqentemente consultadas por menos
do que 5% das linhas. Este valor pode ser maior em situaes onde todos os
dados podem ser recuperados a partir de um ndice, ou onde as colunas do
ndice possam ser utilizadas para joins com outras tabelas.
Como os ndices Crescem

ndices so sempre balanceados e crescem a partir dos nodos finais
(nodos folha, ou leaf nodes).
Nas situaes de crescimento uniforme de uma chave, isto pode causar o
aumento do nvel (BLEVEL) do ndice: a medida que as linhas so adicionadas,
novas entradas so adicionadas para o bloco do ndice. Quando um bloco folha
estiver preenchido, o Oracle o divide em dois blocos e coloca 50% do bloco no
original e 50% em um novo bloco folha. Isso chamado split de bloco. Uma
nova entrada/ponteiro adicionada para bloco ramo (parent block ou branch
block), acima dos blocos folha trabalhados.
Se o bloco ramo estiver cheio, ele tambm sofre o split, e um novo bloco
ramo criado. Este padro repetido vrias vezes a medida que as linhas
forem inseridas, at que o bloco raiz tenha que ser dividido em dois, e um
novo bloco raiz seja criado.
Quando um novo bloco raiz adicionado, a rvore cresce em um nvel de

profundidade. Quanto mais profundo um ndice for, menos eficiente ele se
torna.
importante manter o BLEVEL de ndices B-Tree o mais baixo possvel:
no maior que quatro.
Para obter esta informao, execute o comando ANALYZE para coletar
estatsticas nas vises *_INDEXES do dicionrio e armazen-las na coluna
SQL> ANALYZE INDEX aluno.tcursos_id_pk COMPUTE STATISTICS;
BLEVEL.
10

SQL> ALTER INDEX aluno.tcursos_id_pk REBUILD ONLINE;
Como Resolver a Degradao de Performance de

ndices B-Tree
Regularmente reconstrua o ndice:
Particione a tabela indexada e crie ndices particionados, de forma

que valores chave sejam divididos atravs de B-Trees distintas
(somente possvel se voc instalou a opo Partitioning). Comandos
de consulta podem ento obter vantagens com a eliminao de
parties.
A clusula ONLINE permite que operaes DML sejam feitas durante

a reconstruo do ndice.
11

SQL> CREATE index func_nome_idx
2 ON funcionarios (nome , sobrenome)
3
compress;
SQL> ALTER index func_nome_idx
2
rebuild compress;
ndices Comprimidos
Comprimindo um ndice:
O uso da clusula COMPRESS elimina repeties de valores de colunas do
ndice, e pode diminuir consideravelmente o espao necessrio para o ndice.
Use um nmero inteiro para especificar quantas colunas devem ser
comprimidas, comeando da primeira e seguindo em direo ltima coluna
do ndice.
Para ndices nicos, o nmero de colunas comprimidas vai de 1 at o
nmero total de colunas menos 1 (default). Para ndices no-nicos, valores
vlidos vo de 1 at o nmero total de colunas.
ndices comprimidos so teis porque:
Em ndices no-nicos, o Oracle armazena o valor da chave uma vez,

como um prefixo, seguida de uma lista de ROWIDs que possuem
aquele valor.
Em ndices nicos compostos, isso pode ser til em casos como o de
chaves com cdigo e hora, como USURIO e HORA_LOG. Milhares de
registros possuem o mesmo cdigo de USURIO, mas com diferentes
valores de HORA_LOG. Com compresso, pode ocorrer de, em um
bloco de ndice, o cdigo de USURIO ser armazenado uma nica
vez, seguido de pares HORA_LOG, ROWID.
Compresso no possvel em ndices nicos de chave simples.
12
ndices Bitmap
Figura 13-5: ndices bitmap
Quando Criar ndices Bitmap
ndices bitmap foram desenvolvidos para colunas com baixa

cardinalidade, as quais contm um nmero limitado de valores.
Se voc utilizar uma consulta com mltiplas condies WHERE, o
Oracle pode utilizar as operaes lgicas bit-AND ou bit-OR para
combinar este bitmap com bitmaps para outras colunas.
Consideraes de Performance
Utilizam pouco espao para armazenamento: uma entrada para cada

valor de chave distinto, armazenada de forma comprimida. Cada
bitmap dividido em segmentos bitmap de at 1/2 bloco.
Operam muito rpido com mltiplos predicados sobre colunas de
baixa cardinalidade.
ndices bitmap so particularmente adaptados para sistemas
grandes e somente de leitura, como os DSSs.
Comandos DML reduzem a performance: ndices bitmap no so
eficientes em aplicaes OLTP.
Lock efetuado em nvel de segmento bitmap, e no a nvel de
entrada.
Parallel Query, PDML (Parallel Data Manipulation Language) e
CREATE paralelizado trabalham com ndices bitmap.
13
Armazenam valores nulos.
14

SQL> CREATE BITMAP INDEX aluno.tclientes_estado_idx
2 ON aluno.tclientes(estado)
3 TABLESPACE indx;
Criando e Mantendo ndices Bitmap

Consideraes de Manuteno
Em um ambiente DSS, os dados normalmente sofrem manuteno atravs
de grandes inseres e atualizaes. A manuteno de ndices adiada at o
final de cada operao DML. Por exemplo, se voc inserir 1000 linhas em uma
tabela que possui um ndice bitmap, a informao da coluna bitmap e a
informao das linhas inseridas so colocadas no buffer de sort e ento a
atualizao de todas as 1000 entradas de ndice so agrupadas. Por isto que o
SORT_AREA_SIZE deve ser configurado corretamente para obter-se uma
performance satisfatria em inseres e atualizaes em ndices bitmap. Desta
forma cada segmento bitmap atualizado somente uma vez para cada
operao DML, mesmo se mais de uma linha daquele segmento for
modificada.
15
Comparando ndices B*Tree e Bitmap

B-tree
Adequado para colunas com alta
cardinalidade
Atualizaes nas chaves so
relativamente de baixo custo
Ineficiente para consultas utilizando
predicados OR
Lock em nvel de linha
Maior necessidade de armazenamento
teis para OLTP
Bitmap
Adequado para colunas com baixa
cardinalidade
Atualizaes nas colunas possuem um
alto custo
Eficiente para consultas utilizando
predicados OR
Lock em nvel de segmento bitmap
Menor necessidade de
armazenamento
teis para DSS
16
ndices de Chave Reversa
Figura 13-6: ndices de chave reversa
Definio
A criao de um ndice de chave reversa inverte os bytes do valor de cada
coluna chave, mantendo a ordem das colunas no caso de uma chave
composta.
Quando Criar ndices de Chave Reversa
Uma chave que est continuamente crescendo (como os nmeros

seqnciais de faturas, empregados ou pedidos) podem
repetidamente degradar o BLEVEL do ndice; voc pode evitar a
diviso forada de blocos distribuindo as entradas do ndice mais
uniformemente.
Em um ambiente Parallel Server, quando modificaes para um
ndice esto concentradas em um pequeno conjunto de blocos folha,
a inverso de valores chave permite a distribuio das linhas do
ndice atravs de todos os blocos folha.
Desvantagens
Quando os comandos da aplicao especificam intervalos, o explain plan
produz um full table scan.
17

SQL> CREATE
SELECT index_name,
UNIQUE INDEXindex_type
aluno.tcontratos_id_idx
2 FROM
ON aluno.tcontratos(id)
dba_indexes
REVERSE
3 WHERE
TABLESPACE
ROWNUM
indx;
< 10;
INDEX_NAME
SQL>
ALTER INDEX aluno.tcontratos_id_idx
INDEX_TYPEREBUILD
-----------------------------2 REVERSE;
--------------TCLIENTES_ESTADO_IDX
BITMAP
TDS_CLASSE_PK
NORMAL
TCONTRATOS_ID_IDX
NORMAL/REV
Criando ndices de Chave Reversa

Viso do Dicionrio
Utilize a seguinte consulta para listar os nomes de todos os ndices de
chave reversa:
18
Tabelas Index-Organized
Figura 13-7: Tabelas organizadas pelo ndice
Definio
Uma tabela index-organized semelhante a uma tabela normal com um
ndice sobre um ou mais de suas colunas, mas ao invs de manter dois
segmentos separados para a tabela e o ndice B-Tree, o banco de dados
mantm um nico ndice B-Tree que contm:
O valor da chave primria.

Os valores das outras colunas para a linha correspondente.
Benefcios de Performance
No existe a duplicao dos valores para a coluna da chave primria

(colunas de ndice e tabela em tabelas indexadas) menos
requisitos de storage.
Tabelas index-organized fornecem acesso baseado na chave mais
rpido para consultas envolvendo correspondncia exata ou
pesquisa de intervalos, ou ambas.
Quando Criar Tabelas Index-Organized

Tabelas index-organized so satisfatrias para acesso freqente aos dados
atravs da chave primria ou atravs de qualquer chave que seja um prefixo
da chave primria, como em aplicaes utilizando ndices invertidos, utilizados
em pesquisas de texto. Estes ndices mantm o valor e todas as suas
localizaes juntas. Portanto cada palavra possui uma entrada, e esta entrada
registra todos os locais onde a palavra ocorre. Tabelas index-organized so
mecanismos muito eficientes para modelar ndices invertidos.
19
Information Retrieval Applications: pesquisas baseadas em contedo

sobre colees de documentos.
Spatial Applications: spatial queries para objetos residindo em uma
coleo de grids.
OLAP Applications: Online Analytical Processing applications
manipulando blocos multidimensionais.
20
Tabelas Index-Organized Comparadas com

Tabelas Normais
Tabela Normal
Identificador nico ROWID
ROWID implcito
Suporta vrios ndices
Full Table Scan retorna linhas sem
ordem especfica
Constraints de unique so permitidas
Maior necessidade de storage
Suporta distribuio, replicao e
particionamento
Tabela Index-Organized
Identificada pela PK
Sem ROWID
Sem ndices secundrios
Full Table Scan retorna linhas na ordem
da PK
Constraints de unique no so
permitidas
Menor necessidade de storage
Distribuio, replicao e
particionamento no so suportados
Outras caractersticas de IOT:
Possui obrigatoriamente uma chave primria.

Possui ROWID lgico, e no fsico, que estima a localizao do
registro. Essa estimativa precisa na criao do ndice, mas torna-se
manos acurada medida que ocorrem splits de blocos.
O tipo de dado UROWID pode ser usado para armazenar ROWIDs
lgicos.
21

CREATE TABLE aluno.vendas
(id_loja
NUMBER(3),
data
DATE,
comentarios VARCHAR2(1000),
CONSTRAINT vendas_pk
PRIMARY KEY (id_loja,dia) )
ORGANIZATION INDEX
TABLESPACE indx
PCTTHRESHOLD 20;
Criando Tabelas Index-Organized

Uma entrada de ndice em uma IOT armazena tanta informao quanto
possvel, at o limite especificado por PCTTHRESHOLD.
PCTTHRESHOLD estabelece a porcentagem mxima do bloco que pode ser
usada por um registro. Se um registro ultrapassar o limite, as informaes da
linha so colocadas na rea de overflow da tabela. Entretanto, as colunas da
chave primria obrigatoriamente ficam no ndice, mesmo que ultrapassem o
limite.
22

SELECT *
CREATE
INDEX diferenca_contrato_idx
upper_nome_idx
ON tcontratos
FROM
tclientes
tclientes
tcontratos
(UPPER(nome))
(total-desconto)
TABLESPACE
WHERE
UPPER(nome)
total
indx;
- desconto
= 'ANA
> 1000;
MARIA';
ndices Baseados em Funes

Um ndice baseado em funo, inclue colunas que podem ser utilizadas
com funes SQL, como por exemplo, LOWER e UPPER, ou adicionadas em
uma expresso, como coluna1 + coluna2. Com a utilizao de um ndice
function-based, podemos armazenar funes e expresses no ndice.
Na definio de um ndice baseado em funo, aquelas colunas ou
expresses podem ser utilizadas para otimizar o acesso de comandos que
utilizam a clusula WHERE ou ORDER BY.
Por exemplo, definindo uma ndice como UPPER(nome_coluna) ou
LOWER(nome_coluna) podemos ter uma busca sem nos preocuparmos com
letras maisculas ou minsculas.
Exemplo 1:
O ndice criado com o seguinte comando:
Pode facilitar consultas como:
Exemplo 2:
O ndice criado com o seguinte comando:
Pode facilitar consultas como:
23

SQL> SELECT segment_name,
table_name, index_type,
index_name,
tablespace_name,
tablespace_name,
iot_name,
segment_type
iot_type
2 FROM dba_segments
dba_tables
tablespace_name, table_name
3 WHERE
FROM owner
dba_indexes
like '%ALUNO%';
4 WHERE owner like '%ALUNO%';
TABLE_NAME
SEGMENT_NAME
TABLESPACE_NAME
TABLESPACE_NAME
IOT_NAME SEGMENT_TYPE
--------------- --------------INDEX_NAME
-------------------------------------INDEX_TYPE
----------------------------------------------TABLESPACE_NAME
VENDAS
-----------------------TITENS
USERS
--------------------TABLE--------------VENDAS_PK
TCONTRATOS_ID_PK
INDX
IOT - TOP
INDEXINDX
TCLIENTES_ESTADO_IDX
BITMAP
INDX
TIT_TCONTRATOS_ID_SEQ_PK NORMAL
INDX
DIFERENCA_CONTRATO_IDX
FUNCTION-BASED NORMAL INDX
UPPER_NOME_IDX
FUNCTION-BASED NORMAL USERS
IOT_TYPE
-------TABLE_NAME
IOT
---------VENDAS
TCLIENTES
TITENS
TCONTRATOS
TCLIENTES
Vises do Dicionrio
24
Clusters
Figura 13-8: Clusters
Definio
Um cluster um grupo de uma ou mais tabelas que compartilham os
mesmos blocos de dados porque compartilham colunas comuns e so
freqentemente utilizadas juntas em consultas com joins. O uso de clusters
permite ao DBA desnormalizar tabelas enquanto elas parecem estar
normalizadas para o usurio.
Benefcios de Performance
I/O de disco reduzido e o tempo de acesso melhorado para joins

das tabelas clusterizadas.
Cada valor da chave do cluster armazenado somente uma vez para
todas as linhas do mesmo valor chave: portanto, utilizam menos
espao.
25
Consideraes de Performance
Full table scans so geralmente mais lentos em tabelas clusterizadas do
que em tabelas no clusterizadas.
26
Particionamento
Tipos de particionamento
O que leva a escolha de particionamento de tabelas e ndices o
crescimento incrvel no tamanho desses objetos. Esse recurso diminui o down
time, aumenta a performance e a facilidade de configurao. Existem quatro
mtodos de particionamento.
Particionamento por intervalo (Range Partitioning)

Particionamento por intervalo utiliza intervalos de valores de colunas para
mapear os registros para as parties. Esse mtodo adequado para dados
histricos. Entretanto, muitas vezes no possvel prever quantos registros
sero mapeados para cada partio, deixando-as muito diferentes em
tamanho, e fornecendo menores vantagens de performance, principalmente no
uso de Parallel Queries.
Particionamento por hash (Hash Partitioning)

Esse mtodo utiliza uma funo de hash sobre as colunas da partio para
distribuir os registros por elas. Dessa forma controla-se a localizao fsica dos
dados atravs de um nmero de parties.
Particionamento composto (Composite Partitioning)

Esse mtodo utiliza intervalos de valores para distribuir os registros por
parties, e dentro de cada partio, subparties distribudas por funo de
hash. Assim, se obtm divises histricas em nvel de partio, e vantagens de
paralelismo e distribuio fsica em nvel de subpartio.
Particionamento por lista (List Partitioning)

O mtodo List permite um controle explcito de como registros so
mapeados para parties. Para isso, so definidas listas de valores discretos
para a coluna particionada na descrio de cada partio. Esse mtodo
permite a modelagem de distribuio de dados no ordenados, ou no
relacionados.
27

Inserted partition key
CREATE ORA-14400:
TABLE vendas
partition NUMBER(5),
key.
(conta
cliente
VARCHAR2(30),
quantidade
NUMBER(8),
semana
NUMBER(2))
PARTITION BY RANGE (semana)
(PARTITION P1 VALUES LESS THAN (4)
PARTITION P2 VALUES LESS THAN (8)
...
PARTITION P13 VALUES LESS THAN (53)
is beyond highest legal
TABLESPACE data0,
TABLESPACE data1,
TABLESPACE data12);
Exemplo de Particionamento por Intervalo

Nesse exemplo, a chave da partio SEMANA.
Regras:
As chaves podem ser compostas de at 16 colunas.

Cada partio deve ter valores menores que (LESS THAN) a partio
anterior.
Falhas nos intervalos no so permitidas.
Os valores devem ser especificados como literais.
Atributos de tablespace e storage podem ser especificados por
partio.
Colunas LONG e LONG RAW no so permitidas.
At 64K-1 parties podem ser definidas.
Na especificao de VALUE LESS THAN devem ser usadas literais ou as

funes TO_DATE ou RPAD, com argumentos constantes. Se for usada uma
coluna do tipo DATE na chave, deve ser usado o ano com 4 dgitos, atravs da
funo TO_DATE ou da configurao de NLS.
Se for tentado um INSERT com valor da chave superior ao intervalo da
ltima partio (semana 58), um erro retornado:
Se quiser evitar isso, utilize MAXVALUE como valor da chave da ltima
partio. Dessa forma, todos valores sero possveis de serem inseridos,
incluindo NULL (considerado um valor superior a todos os demais, exceto
MAXVALUE).
28
Exemplo de Particionamento por Lista

SQL> CREATE TABLE cidades
2
(id
NUMBER(2),
3
endereo VARCHAR2(50),
4
cep
VARCHAR2(10),
5
cidade
VARCHAR2(30),
6
estado
VARCHAR2(2),
7
pais_id
NUMBER(3))
8 PARTITION BY LIST (estado)
9 (PARTITION regiao_sul
10
VALUES('RS','SC','PR')
TABLESPACE aluno_data,
11
PARTITION regiao_sudeste
12
VALUES('SP','MG','ES','RJ') TABLESPACE aluno_data2);
Regras:
Parties sem atributos fsicos, herdam atributos da tabela.

No existe uma partio que aceite "outros valores", como
MAXVALUE faz em parties de intervalo. Se for inserido um valor
fora de qualquer partio, o erro ORA-14400 ocorre.
29

SQL> SELECT SUM(quantidade)
2 FROM
vendas
3 WHERE data BETWEEN TO_DATE(01-DEZ-2004,
4
DD-MON-YYYY)
5
AND TO_DATE(31-DEZ-2004,
6
DD-MON-YYYY);
Parties das semanas 10 a 15 so acessadas.
Acessos s Parties
Dependendo do comando SQL, o Oracle capaz de reconhecer as
parties e subparties de tabelas e ndices relevantes, e evitar o acesso s
demais parties. Essa otimizao chamada partition pruning.
30
Histogramas
Descrevem a distribuio dos dados de uma coluna especfica.

Permitem que o Otimizador Baseado em Custo (Cost Based
Optimizer) estime melhor a seletividade de uma consulta.
Definio
Para dados distribudos uniformemente, o otimizador baseado em custo
supe com preciso o custo de execuo de um determinado comando.
Entretanto, quando os dados no esto uniformemente distribudos, o
otimizador no consegue estimar com preciso a seletividade de uma
consulta. Nestes casos, histogramas so necessrios para descrever a
distribuio de uma coluna especfica.
Quando Utilizar Histogramas

Em colunas freqentemente utilizadas em clusulas WHERE, deste modo
em colunas indexadas, e alm disso possuindo distribuio dos dados
altamente desproporcional.
Quando no Utilizar Histrogramas
Em colunas utilizadas em predicados com variveis bind.

Em colunas com dados uniformemente distribudos.
Em colunas unique utilizadas em predicados de igualdade.
31

SQL> ANALYZE TABLE aluno.tcontratos COMPUTE STATISTICS
2 FOR COLUMNS total SIZE 10;
Tabela analisada.
SQL> ANALYZE TABLE aluno.tcontratos COMPUTE STATISTICS
2
FOR ALL INDEXED COLUMNS;
Tabela analisada.
Como Gerar Estatsticas de Histogramas

A clusula SIZE declara o nmero mximo de buckets.
Se o nmero de ocorrncias de valores distintos em uma coluna for
relativamente pequeno, ento til configurar o nmero de buckets para ser
maior que o nmero de valores distintos que freqentemente ocorrem.
O nmero default de buckets de 75, e o mximo de 254.
Vises do Dicionrio
*_HISTOGRAMS: histogramas para tabelas normais.

*_TAB_COLUMNS: informaes sobre buckets.
*_PART_HISTOGRAMS: histogramas para as parties de tabelas.
32
Requisitos para OLTP

Alocao de Espao
Evite a sobrecarga de performance devido a alocao dinmica de

espao: aloque espao explicitamente para tabelas, clusters e
ndices.
Verifique os padres de crescimento regularmente, para encontrar a
taxa na qual as extenses esto sendo alocadas, de forma que voc
possa planejar a criao de extenses.
Indexao
A indexao crtica para a recuperao de dados em sistemas

OLTP. Comandos DML sobre tabelas indexadas necessitam de
manuteno de ndices, e isto um overhead significativo na
performance. Desta forma sua estratgia de indexao deve estar
prxima da necessidade real da aplicao.
A indexao de chaves estrangeiras permite a modificao dos
dados filhos sem bloquear os dados pais.
Indexao b-tree preferida ao invs de indexao bitmap, por
causa dos locks afetando as operaes DML: quando uma entrada de
ndice b-tree bloqueada, uma nica linha fica bloqueada, enquanto
que quando uma entrada de ndice bitmap bloqueada, um
intervalo inteiro de linhas fica bloqueado.
ndices de chave reversa previnem a freqente diviso de blocos btree para colunas seqnciais. Tambm tornam aplicaes com o
Real Application Cluster mais rpidas.
Voc necessita reconstruir ndices regularmente, como sugerido
anteriormente.
Clusterizao com Hash
A utilizao de hash clusters deve melhorar a performance de acesso

em consultas com igualdade. Mas voc no deve escolher esta
estrutura de dados para uma tabela na qual ocorrem:
Pesadas inseres, devido ao uso de espao e o nmero de blocos que
necessitam ser visitados.
Pesadas atualizaes, utilizando valores de coluna grandes, devido a
probabilidade de migrao.
Se uma tabela estiver crescendo, provvel que ocorram vrias
colises nas chaves de hash e isto nos leva ao armazenamento de
linhas em blocos de overflow. Para evitar esta situao, estime
corretamente o valor de HASHKEYS. Com um nmero grande de
hash keys para um determinado nmero de linhas, a probabilidade
de uma coliso diminui.
33
Index-Organized Tables
IOTs fornecem acesso mais rpido a dados.
34
Detalhes sobre Aplicaes OLTP

Constraints de Integridade
Se existir uma escolha entre manter a lgica da aplicao em cdigo
procedural ou utilizar constraints declarativas, tenha em mente que
constraints possuem sempre menor custo de processamento. Constraints de
integridade referencial e CHECK so os principais tipos a considerar aqui.
Cdigo Compartilhado
Caso contrrio, voc deve certificar-se que o cdigo seja compartilhado
por stored procedural objects, como packages, procedures e funes.
Variveis Bind
Voc deseja manter o overhead de parse em um nvel mnimo. Tente
garantir que o cdigo da aplicao utilize variveis bind ao invs de literais.
Parmetro CURSOR_SHARING
O parmetro CURSOR_SHARING ajuda os usurios a compartilhar cdigo
compilado. Os seguintes valores so vlidos:
EXACT (default): compartilha apenas cursores com comandos SQL

idnticos.
SIMILAR: compartilha cursores se a troca de literais por variveis
bind resulte no mesmo plano de execuo que seria gerado se o
valor EXACT estivesse sendo usado.
FORCE: compartilha cursores trocando literais por variveis bind,
mesmo que o plano de execuo no seja o mesmo.
35
Requisitos para DSS

DB_BLOCK_SIZE e
DB_FILE_MULTIBLOCK_READ_COUNT
Voc normalmente deve configurar o parmetro DB_BLOCK_SIZE para o
valor mximo suportado para a sua plataforma. Mesmo se isto significar a
recriao de um grande banco de dados, isto quase certamente vale a pena,
porque um tamanho de bloco maior facilita operaes de leitura intensivas que
so caractersticas de aplicaes DSS.
Dispense uma ateno particular para a configurao do parmetro
DB_FILE_MULTIBLOCK_READ_COUNT. Este determina, durante full table scans,
quantos blocos do banco de dados sero lidos com uma nica chamada de
leitura ao sistema operacional.
Um valor maior fornece um custo de table scan menor e favorece table
scans sobre ndices.
Indexao
Considere como voc pode minimizar a alocao de espao e o overhead
de performance da manuteno de ndices. Uma vez que a maioria das
consultas utilizam full table scans, voc pode:
Dispensar completamente o uso de ndices.

Mant-los somente para algumas tabelas que so acessadas
seletivamente.
Regularmente gerar histogramas para aquelas com distribuio de
dados no uniforme.
Escolher ndices bitmap para consultas em colunas com poucos
valores distintos. Eles oferecem acesso para recuperao muito mais
rpido.
Utilize tabelas index-organized para acesso rpido aos dados da
tabela
baseado
na
chave
para
consultas
envolvendo
correspondncia exata e/ou pesquisa de intervalos e recuperao
completa da linha de dados.
Clusterizao
Ambos os tipos de clusters devem ser considerados, e especialmente hash
clusters por sua melhor performance de acesso, excluindo-se tabelas com
crescimento regular durante as cargas de dados, exceto se voc possui a
possibilidade de recriar o cluster.
Particionamento
Embora seja uma opo, esta caracterstica deve ser considerada para
grandes quantidades de dados para os quais as consultas concentram o
36
acesso em linhas que foram geradas recentemente. Ela oferece partition scan
ao invs de full table scan.
37

SQL> SELECT * FROM big_table
2 WHERE number_column = :1;
Detalhes sobre Aplicaes DSS

Tempo de Parse
provvel que o tempo gasto para efetuar o parse de comandos SELECT
seja uma proporo muito pequena do tempo gasto para executar a consulta.
O tuning do library cache muito menos importante para DSS do que para
OLTP.
Sua prioridade um caminho de acesso excelente no plano de execuo;
pequenas variaes podem custar minutos ou horas. Os desenvolvedores
devem:
Utilizar consultas paralelizadas que permitem que mltiplos

processos trabalham simultaneamente para processar um nico
comando SQL.
Configuraes com Symmetric Multiprocessors (SMP), clustered ou
Massively Parallel Processing (MPP) obtm os maiores benefcios de
performance, porque a operao pode ser efetivamente dividida
atravs de vrias CPUs em um nico sistema.
Utilize o comando EXPLAIN PLAN para efetuar o tuning de comandos

SQL, e hints para controlar os caminhos de acesso.
Se sua lgica de aplicao utiliza variveis bind, voc perde os benefcios

desta caracterstica: o otimizador efetua uma suposio geral sobre a
seletividade da coluna, enquanto que com literais, o otimizador baseado em
custo utiliza histogramas.
Exemplo: se voc enviar o seguinte comando, o valor de :1 no
conhecido quando o otimizador determina o plano de execuo.
O otimizador no pode calcular o nmero de linhas retornadas por este
passo exatamente. Isto pode significar que o servidor utilizar um plano de
execuo sub-timo. Portanto, embora seja fortemente recomendado o uso de
variveis bind em sistemas OLTP com acesso indexado, elas no so ideais
para DSS uma vez que existem poucas probabilidades que o mesmo comando
seja executado novamente.
Cuidado com o uso do parmetro CURSOR_SHARING, pois ele fora a troca
de valores literais para variveis bind geradas pelo sistema.
38
Sistemas Hbridos
OLTP
Necessita de mais ndices
ndices B-Tree
ndices de chave reversa
PCTFREE de acordo com a atividade de
atualizao esperada
Cdigo compartilhado com variveis
bind
ANALYZE em ndices
CURSOR_SHARING = similar
DSS
Efetua mais full table scans
ndices bitmap
Tabelas IOT
PCTFREE pode ser configurado para 0,
se houver recriao da tabela
atualizada
Literais e hints
Gerao de histogramas
CURSOR_SHARING = exact
Mesmo Banco de Dados para OLTP e DSS

Muitos clientes Oracle que esto mantendo grandes bancos de dados
freqentemente querem utilizar a mesma instncia para o processamento de
transaes e para o suporte a deciso. impossvel efetuar o tuning do
armazenamento de seus dados para ambas as necessidades, e as aplicaes
iro enfrentar-se por recursos.
A Oracle realmente aconselha aos clientes para utilizarem bancos de
dados separados para o trabalho de OLTP e DSS, carregando dados como
necessrio.
Detalhes
OLTP necessita de mais ndices que DSS. Eles no utilizam

necessariamente os mesmos tipos de ndices devido s
caractersticas de DML/OLTP e consultas/DSS.
OLTP no deve utilizar parallel query, enquanto que DSS necessita
dela.
DSS necessita de blocos de dados com espao bem aproveitado para
obter excelentes full table scans. Linhas individuais geralmente no
sero atualizadas em um ambiente DSS. Portanto, o PCTFREE deve
ser configurado para 0 para bancos de dados DSS onde um PCTFREE
de 0 para OLTP causaria a migrao das linhas.
O Otimizador Baseado em Custo considera as estatsticas de
histogramas quando consultas utilizam literais e no variveis bind.
OLTP deve utilizar variveis bind, DSS no. Isto significa que a coleta
de estatsticas para histogramas uma perda de tempo e consumo
de recursos para transaes OLTP.
Recomendaes
Porm, manter dois grandes bancos de dados ao invs de um possui um
custo financeiro bvio, e algumas organizaes podem ainda decidir a
execuo de sistemas hbridos:
39
Voc deve manter grandes relatrios e sumrios executando fora das

horas de maior atividade.
Voc necessita de dois arquivos de parmetros separados para o
trabalho dirio e noturno, efetuando o shutdown e startup no incio e
final do trabalho dirio.
40
Espao para anotaes
41
14. Tuning do Sistema

Operacional
Tuning do Sistema Operacional
Objetivos
Descrever os principais passos de tuning do sistema operacional.
Identificar similaridades entre o tuning do sistema operacional e do

banco de dados.
Explicar a diferena de um processo contra uma thread.
Descrever paging e swapping.
Introduo
Figura 14-1: Processos do sistema operacional
O administrador do sistema, a pessoa responsvel por efetuar o tuning do

sistema operacional, possui preocupaes com tuning semelhantes aquelas do
administrador do banco de dados. Mas o administrador do sistema est
tambm preocupado em como as aplicaes no Oracle afetam a
performance. Quando estiver efetuando tuning, o administrador do sistema
considera, nessa ordem:
Utilizao de memria.
Nveis de I/O.
Utilizao de CPU.
Trfego de rede.
Configuraes Multi-CPU
Figura 14-2: Configurao multi-CPU
Alm de um computador com uma nica CPU, existem duas outras

configuraes para CPUs.
SMP: Symmetrical Multi-Processor ou processadores tightly-coupled.

Nesta configurao existem mltiplas CPUs que compartilham o
mesmo espao de memria, dispositivos de I/O, e barramentos, com
um nico sistema operacional para gerenciar a arquitetura.
MPP: Massively Parallel Processor ou processadores loosely-coupled.
Nesta configurao, existem mltiplas unidades de CPU. Cada
unidade de CPU possui seu prprio espao de memria e cada
unidade de CPU pode ser um SMP. Dispositivos de I/O podem ser
propriedade de uma nica CPU, compartilhados atravs de vrias
CPUs ou ambos.
Uma vez que existem mltiplos espaos de memria, possvel
executar uma instncia Oracle em cada espao de memria. Para que
todas as instncias acessem o mesmo banco de dados, voc deve
possuir a opo Real Application Cluster instalada. Sem esta opo,
cada instncia possui seu prprio banco de dados, e a configurao se
parece com um banco de dados distribudo.
Em ambas as configuraes, o sistema operacional, ou o hardware, ou
ambos gerenciam a conteno de CPU por memria ou dispositivos de I/O.
Paging e Swapping
Figura 14-3: Paging e Swapping
Sistemas gerenciam a memria utilizando a mesma tcnica que o Oracle:

tentando manter as pginas mais recentemente utilizadas na memria real.
Recursos de memria inadequados causam a ocorrncia de muito paging ou
spwapping. Este sintoma freqentemente chamado de trashing porque
causa a transferncia de blocos de um lado para outro entre memria e disco.
Paging ocorre quando um processo necessita uma pgina (bloco) de
memria que no est mais na memria real mas sim na memria virtual. O
bloco deve ser lido (paged) a partir do disco, e o bloco em memria que este
substituir pode tambm necessitar ser escrito para disco.
Swapping similar ao paging, exceto que o espao de memria do
processo inteiro removido a partir da memria. Se existirem muitos
processos executando em um determinado momento, o swapping pode crescer
a um nvel inaceitvel.
Ambos swapping e paging necessitam de espao em disco adequado para
temporariamente armazenar os blocos de memria em disco. Estes arquivos
possuem I/O intensivo, de forma que tambm devem ser considerados na hora
de efetuar o balanceamento de I/O. O swapping no efetuado por todos os
sistemas operacionais. O Windows, por exemplo, utiliza somente paging.
Tuning de Memria
Tuning do Banco de Dados Afeta a Paginao
(Paging)
Alm do tuning da SGA, existem algumas coisas que o DBA pode fazer
que podem afetar o desempenho de paging/swapping:
Em alguns sistemas operacionais, o DBA pode bloquear a SGA na

memria real, configurando o parmetro do init<SID>.ora LOCK_SGA
para TRUE, de forma que nunca seja efetuado o paging dela para
disco. Normalmente, o Oracle executa melhor se toda a SGA for
mantida na memria real.
Essa tcnica deve ser utilizada somente em sistemas que possuam

memria suficiente para armazenar todas as pginas da SGA sem degradar a
performance em outras reas.
Monitoramento da Utilizao de Memria

A utilizao de memria real e virtual e o efeito de paging e swapping
normalmente podem ser monitorados por processo ou para todo o sistema
operacional. A quantidade de paging e swapping que aceitvel varia de
acordo com o sistema operacional; alguns toleram mais que outros.
Tuning de I/O
Figura 14-4: Tuning de I/O
O administrador do sistema melhora a performance de I/O em disco

balanceando a carga atravs dos discos e controladoras.
Sistemas de I/O intensivo, como servidores de banco de dados, executam
melhor com vrios discos pequenos ao invs de poucos discos grandes. Mais
discos reduz a probabilidade que um disco possa se tornar um gargalo.
Operaes de Parallel Query tambm so beneficiadas pela distribuio da
carga de trabalho de I/O sobre mltiplos discos.
Raw Devices
Um raw device um disco ou partio de disco sem uma estrutura de
arquivo ou diretrio. Embora sejam mais difceis de administrar que arquivos
do sistema operacional, podem fornecer alguns benefcios de performance,
porque leituras e escritas para um raw device evitam o cache do sistema
operacional.
Em alguns sistemas operacionais, como em Windows, o Oracle no utiliza
o sistema de cache de file system do sistema operacional em operaes de I/O
Nesses casos, o uso de raw devices no fornece ganhos significativos de
performance.
Monitoramento
Estatsticas de performance de I/O normalmente incluem o nmero de
leituras e escritas, leituras e escritas por segundo, e tamanhos das filas de
requisio de I/O. Cargas aceitveis variam de acordo com o dispositivo e
controladora.
Diretrizes para Tuning de CPU
Diretrizes:
Taxa mxima de ocupao de CPU: 90%.
Proporo mxima de processamento sistema operacional/usurio:
40/60.
Carga de CPU balanceada atravs das CPUs.
Monitoramento:
CPU.
Processos.
Diretrizes
Quando estiver efetuando tuning da utilizao de CPU, o administrador do
sistema deve preocupar-se principalmente se:
Existem recursos de CPU adequados? O administrador do sistema

garante que a CPU no esteja muito ocupada. Como regra geral, se a
CPU estiver 90% do tempo ocupada, ento existem possibilidades de
atingir sua capacidade.
Existe uma boa proporo entre processamento do sistema
operacional e processamento da aplicao? Processamento do
sistema operacional inclui as tarefas que o sistema operacional
realiza para as aplicaes. Por exemplo: leitura e escrita para
dispositivos, envio de mensagens entre processos e programao
(schedule) de processos.
A meta no possuir mais que 25% a 40% de tempo de CPU gasto
efetuando tarefas do sistema operacional e os outros 60% a 75% do
tempo de CPU gasto executando a aplicao. Quanto menos tempo
for gasto efetuando tarefas do sistema operacional, melhor ser a
performance. Se muito tempo for gasto no modo do sistema
operacional, isto um sintoma de um problema, como:
Memria insuficiente, o que tambm causa swapping e/ou paging.
Design incorreto da aplicao, causando muitas chamadas ao
sistema operacional.
Para sistemas multi-processados, o administrador do sistema
tambm necessita verificar qual carga de CPU est balanceada
atravs de todas as CPUs, especialmente se qualquer das CPUs
possuir uma taxa de utilizao muito alta.
Estas so diretrizes gerais. Nmeros reais podem variar de acordo com a
plataforma de hardware e sistema operacional. Verifique as diretrizes de tuning
de seu hardware e sistema operacional para maiores informaes.
Monitoramento
Monitores do sistema operacional para utilizao de CPU normalmente
incluem o percentual de tempo que a CPU est ativa e o tempo gasto em
tarefas do sistema operacional versus usurio. Monitores de processo exibem o
status de processos e estatsticas sobre o nmero de I/Os, chamadas ao

sistema operacional e taxas de page/swap.
Processos e Threads
Figura 14-5: Processos e threads
Na maioria dos sistemas operacionais, cada processo Oracle tambm

um processo do sistema operacional. Em alguns sistemas operacionais,
entretanto, como no Windows, todos os processos background e servidor do
Oracle executam como um nico processo do sistema Operacional. Cada
processo Oracle uma thread dentro do processo do sistema operacional. Uma
thread
uma
seqncia
de
instrues
que
podem
executar
independentemente de outras threads no mesmo processo. Esta configurao
torna o acesso a SGA e a comunicao entre os processos Oracle mais
eficiente, mas fica limitada a quantidade mxima de memria por processo.
10
Diretrizes
Efetue o Tuning do Sistema Inteiro
Para ter um sistema bem configurado, efetue o tuning do sistema
operacional, do banco de dados e da aplicao. O sistema operacional ou o
banco de dados podem estar rodando incorretamente devido a uma aplicao
mal escrita.
Por exemplo, uma aplicao que est efetuando muitos full table scans,
que aumentam o I/O do sistema e possuem um efeito negativo sobre as
estatsticas do database buffer cache. O desenvolvedor efetua o tuning da
aplicao adicionando ndices. A reduo de full table scans causa a utilizao
mais eficiente do database buffer cache e reduz I/O no sistema operacional.
Efetue Tuning do Sistema Operacional Utilizando

Estatsticas do Oracle
O administrador do sistema pode utilizar informaes passadas pelo
administrador do banco de dados para efetuar o tuning do sistema
operacional. Por exemplo, as estatsticas de I/O da V$FILESTAT pode ser
utilizadas para determinar quais os data files Oracle devem ser movidos para
balancear o I/O.
Parmetros de Inicializao Indiretamente Afetam a

Performance
Alm dos parmetros do init<SID>.ora que diretamente afetam o tuning,
existem parmetros que indiretamente possuem um efeito negativo sobre a
performance. Por exemplo, a configurao de DB_BLOCK_CHECKSUM para
TRUE possui um efeito negativo sobre a performance de CPU, uma vez que o
clculo de checksum uma operao intensiva de CPU.
Reduo da Demanda de Hardware

Designers de sistema podem reduzir a demanda de hardware no servidor
pela:
Redistribuio de cargas para momentos de baixa utilizao.

Redirecionamento de trabalhos de cargas para outra camada de
hardware via particionamento da aplicao.
Recursos de Hardware Escalveis

Como recursos de hardware atingem sua capacidade, podem tornar-se um
gargalo. Em alguns casos, o sistema requer tuning aps um novo hardware
ser adicionado. Por exemplo, quando discos so adicionados, o I/O deve ser
redistribudo. Entretanto, refazer o tuning nem sempre necessrio. Por
exemplo, quando uma nova CPU adicionada para um SMP processor, o
11
sistema pode imediatamente fazer uso dos recursos adicionais de CPU. Mesmo
embora refazer o tuning no seja necessrio, o sistema pode melhorar com
ele.
Espao para anotaes
12
13
Apndice - Resoluo dos

Exerccios
Apndice - Resoluo dos Exerccios
Solues Exerccios 1
1. No servidor linux voc deve executar os seguintes passos:
a. Acessar o diretrio /oracle/scripts/criabanco,
localizados os arquivos de criao do banco.
onde
esto
b. Execute o comando: ./create db_1.sh <nome do banco>

c. Edite o arquivo init<nome do banco>.ora, localizado no
diretrio $ORACLE_HOME/dbs
d. Execute o comando: ./createdb_2.sh <nome do banco>
O banco de dados foi criado.
2. Execute o comando emca, informando os dados solicitados.

a. Listener port number: 1521
b. Database SID: <nome do banco>
c. Service name: <nome do banco>
d. Password for dbsnmp: oracle
e. Password for sysman: oracle
f. Password for sys: oracle
g. Continue a instalao
A instncia do Enterprise Manager foi criada para o banco de dados.
Solues 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.
No Linux:
export ORACLE_SID = <SID>
sqlplus sys as sysdba
SQL> SHOW PARAMETER BACKGROUND_DUMP_DEST

SQL> SHOW PARAMETER USER_DUMP_DEST
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.
No Linux:
cat <diretrio background_dump_dest>/alert_<SID>.log.ora
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.
SQL> ALTER SESSION SET SQL_TRACE = TRUE;
SQL> SELECT owner, table_name FROM dba_tables;
SQL> SELECT spid, user FROM v$session s, v$process p WHERE
s.paddr = p.addr;
SQL> ALTER SESSION SET SQL_TRACE = FALSE;
5. Examine o arquivo de trace resultante, sem se preocupar com seu contedo,

pois isto ser discutido em um captulo posterior.
No Linux:
cat <diretrio user_dump_dest>/<SID>ora_<SPID>.trc
Solues 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
No Linux:
sqlplpus sys as sysdba
SQL> @$ORACLE_HOME/rdbms/admin/spcreate.sql
1. Antes de criar um snapshot, verifique se o parmetro necessrio do

init.ora foi configurado para TRUE.
SQL> SHOW PARAMETER TIMED_STATISTICS
SQL> ALTER SYSTEM SET TIMED_STATISTICS = TRUE;
2. Crie um snapshot, conectado como PERFSTAT. Anote o nmero desse

snapshot.
SQL> CONN perfstat/perfstat

SQL> VAR numero NUMBER
SQL> EXEC :numero := statspack.snap;
SQL> PRINT numero
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.
sqlplus aluno/aluno
SQL>@lab03_1
sqlplus aluno/aluno
SQL>@lab03_2
sqlplus aluno/aluno
SQL>@lab03_3
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.
SQL> set lines 2000

SQL> column name format a20
SQL> SELECT * FROM v$librarycache;
SQL> SELECT * FROM v$sysstat WHERE name LIKE '%sort%';
SQL> SELECT ses.* FROM v$sesstat ses, v$statname stat
WHERE ses.statistic# = stat.statistic#
AND upper(stat.name) LIKE '%PGA%'
AND ses.value > 10000;
SQL> SELECT ses.STATISTIC#, sum(ses.VALUE)
FROM v$sesstat ses,
v$statname stat
AND upper(stat.name) like '%PGA%'
AND ses.value > 10000
GROUP BY ses.STATISTIC#;
SQL> SELECT *
FROM v$rollstat;
SQL> SELECT *
FROM dba_rollback_segs;
SQL> SELECT *
FROM v$filestat;
SQL> SELECT *
FROM v$datafile;
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.
SQL> PRINT numero
SQL> @$ORACLE_HOME/rdbms/admin/spreport.sql
6. Examine o arquivo alunoN_report.tx resultante e compare com os valores

que voc consultou anteriormente.
No linux:
cat alunoN_report.txt
7. Mostre a lista com os nomes dos eventos de espera.

SQL> SELECT *
FROM v$event_name;
SQL> SELECT *
FROM v$system_event
WHERE event LIKE '%wait%';
SQL> SELECT *
FROM v$session_event
WHERE event LIKE '%wait%';
8. Existem sesses atualmente aguardando por recursos?

SQL> SELECT *
FROM v$session_wait
WHERE state = 'WAITING';
Solues Exerccios 4
O objetivo desta seo de exerccios utilizar as ferramentas de diagnstico
disponveis para monitorar e efetuar o tuning da shared pool.
1. Verifique o tamanho da shared pool.
SQL> SHOW PARAMETER SHARED_POOL_SIZE
1.
como ALUNO e execute o script lab04_1.sql e em paralelo lab04_2.sql.
sqlplus aluno/aluno
SQL>@lab04_1
SQL>@lab04_2
2.
3. Efetue a medida do hit ratio para o library cache.
SQL> CONN sys as sysdba
SQL> SELECT namespace, gethitratio
FROM v$librarycache;
3.
4. Efetue a medida do hit ratio para o data dictionary cache.
SQL> SELECT SUM(getmisses) / SUM(gets)
FROM v$rowcache;
SQL> SELECT 1 - (SUM(getmisses) / SUM(gets))
FROM v$rowcache;
4.
5. Crie um novo snapshot, conectado como PERFSTAT, e crie um novo
relatrio comparando este com o seu ltimo snapshot do exerccio
anterior.
SQL> PRINT numero
5.
6. Utilize o resultado do relatrio para obter ambos os hit ratios.
No linux:
cat relatorio.txt
6.
7. Que solues voc iria aplicar se qualquer dos hit ratios estivesse ruim ?
Aumentar a memria, atravs do parmetro SHARED_POOL_SIZE uma
soluo.
Outra melhorar a aplicao, atravs da escrita correta de
comandos SQL (aumentar o compartilhamento), ou o uso de roles,
para diminuir o uso de Data Dictionary Cache.
7.
8. Determine que packages, procedures e triggers esto fixadas na shared
pool.
SQL> CONN sys as sysdba
SQL> SELECT name, namespace, sharable_mem
FROM v$db_object_cache
WHERE kept = 'YES'
AND type in ('PACKAGE','PACKAGE
BODY','FUNCTION','PROCEDURE');
8.
9. Fixe uma das packages fornecidas pelo Oracle que necessite ser mantida
em memria. Por exemplo a package DBMS_OUTPUT.
EXEC DBMS_SHARED_POOL.KEEP ('DBMS_OUTPUT');
9.
10.
Determine a quantidade de memria de sesso utilizada na shared
pool para sua sesso.
SQL> SELECT 250*ses.VALUE
FROM v$sesstat ses, v$statname stat, v$session sess
AND stat.name = 'opened cursors current'
AND sess.sid = ses.sid
AND sess.username = 'SYS';
SQL> SELECT 250*ses.VALUE
FROM v$mystat ses, v$statname stat
AND stat.name = 'opened cursors current';
10.
Solues 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.
SQL> PRINT numero
No linux:
cat relatorio.txt

como ALUNO e execute o script lab05_1.sql.
sqlplus aluno/aluno
SQL>@lab05_1
3. Conecte-se como SYSTEM e efetue a medida do hit ratio para o database

buffer cache.
SQL> CONN system/oracle
SQL> SHOW PARAMETER DB_CACHE_SIZE
SQL> SELECT 1 - (phy.value - lob.value - dir.value) / ses.value
"cache hit ratio"
FROM v$sysstat ses, v$sysstat lob, v$sysstat phy, v$sysstat
WHERE ses.name = 'session logical reads'
AND lob.name = 'physical reads direct (lob)'
AND dir.name = 'physical reads direct'
AND phy.name = 'physical reads';
dir

SQL> PRINT numero
10
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.

No linux:
cat relatorio.txt
6. Dimensione o buffer pool keep para armazenar as tabelas ALUNO.S_EMP

e ALUNO.S_DEPT.
sqlplus aluno/aluno
SQL> SELECT *
FROM tab;
SQL> ANALYZE TABLE s_emp ESTIMATE STATISTICS;
SQL> ANALYZE TABLE s_dept ESTIMATE STATISTICS;
SQL> SELECT table_name, SUM(blockS*8192)/1024/1024 mb
FROM user_tables
WHERE table_name in ('S_EMP','S_DEPT')
GROUP BY table_name;
7. Habilite as tabelas ALUNO.S_EMP e ALUNO.S_DEPT para efetuar o cache

no pool keep.
SQL> ALTER TABLE aluno.s_emp storage (BUFFER_POOL KEEP);
SQL> ALTER TABLE aluno.s_dept storage (BUFFER_POOL KEEP);
SQL> SELECT name, 1 - (physical_reads /
(db_block_gets+consistent_gets)) "hit radio"
FROM v$buffer_pool_statistics
WHERE db_block_gets+consistent_gets > 0;
SQL> SELECT name, physical_reads, db_block_gets, consistent_gets
FROM v$buffer_pool_statistics;
SQL> SELECT *
FROM aluno.s_emp;
SQL> SELECT *
FROM aluno.s_dept;
SQL> SELECT name, physical_reads, db_block_gets, consistent_gets
FROM v$buffer_pool_statistics;
11
12
Solues Exerccios 6
1. Conecte-se como SYSTEM e efetue a medida do ratio para as requisies
de espao para o redo log buffer.
sqlplus system/oracle
SQL> SHOW PARAMETER LOG_BUFFER
SQL> SELECT ret.value/entries.value
FROM v$sysstat ret, v$sysstat entries
WHERE ret.name = 'redo buffer allocation retries'
AND entries.name = 'redo entries';
2. Que solues poderiam ser aplicadas se o ratio estivesse ruim?

Aumentar o valor do parmetro LOG_BUFFER ou reduzir a gerao de
redo para operaes de grandes cargas, por exemplo.
sqlplus aluno/aluno
3. Acompanhe o instrutor na modificao do tamanho do parmetro

apropriado.
No init<SID>.ora:
LOG_BUFFER = n , onde n um valor em bytes maior do que o
anterior.
13
Solues 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?
14
SQL> SELECT tablespace_name, file_name

FROM dba_temp_files;
SQL> SELECT name
FROM v$tempfile;
FROM dba_data_files;
SQL> SELECT name
FROM v$datafile;
FROM dba_data_files;
FROM dba_data_files
UNION ALL
SELECT tablespace_name, file_name
C
dados
redo file
system
C
system
redo(a)
control(a)
C
system
redo(a)
control(a)
archive(a)
C
system
dados
redo(a)
control(a)
D
indices
archive
temp
undo
D
dados
redo(b)
control(b)
temp
undo
D
dados
redo(b)
control(b)
temp
undo
D
temp
indices
archive(b)
E
indices
archive
E
indices
archive(b)
E
redo(b)
control(b)
F
archive(a)
undo
<< Padro OFA >>

ORACLE_HOME=/oracle/product/10.1.0/db_1/
/oracle/oradata/<SID>/data
index
system(system, temp, undo, redo, control)
/oracle/admin/<SID>/bdump
udump
cdump
pfile
scripts
b.
Existem objetos que no so do dicionrio de dados na tablespace

SYSTEM?
15
SQL> SELECT DISTINCT owner

FROM dba_segments
WHERE tablespace_name = 'SYSTEM';
SQL> SELECT owner, segment_type, count(1)
FROM dba_segments
WHERE tablespace_name = 'SYSTEM'
GROUP BY owner, segment_type;
SQL> SELECT default_tablespace
FROM dba_users
WHERE username = 'ALUNO';
SQL> SELECT username, default_tablespace
FROM dba_users;
2. Descubra se checkpoints freqentes esto ocorrendo. Este tempo o

ideal? Se no for, qual seria?
SQL> SELECT *
FROM v$sysstat
WHERE name like '%checkpoint%';
Verificar no relatrio a estatstica DBWR checkpoints. Um nmero
alto indica checkpoints demais ocorrendo.

como ALUNO e execute o script lab07_1.sql. Monitore as estatsticas de
I/O.
sqlplus aluno/aluno
SQL>@lab07_1
SQL> SELECT *
FROM v$filestat;
SQL> SELECT f.name, s.*
FROM v$datafile f, v$filestat s
WHERE f.file# = s.file#;
16
Solues Exerccios 8
O objetivo destes exerccios utilizar as ferramentas de diagnstico
disponveis para monitorar e efetuar o tuning da utilizao de espao de bloco.
1. Conecte-se como SYSTEM e encontre o PCTFREE, CHAIN_CNT e high
water mark para a tabela S_ORD do usurio ALUNO. Crie o procedimento
encontra_hw_mark no schema do usurio SYSTEM a partir do script
procedure_hw_mark.sql.
SQL> SELECT table_name,pct_free, chain_cnt
FROM dba_tables
AND table_name ='S_ORD';
SQL> @procedure_hw_mark.sql
SQL> SET serveroutput ON
SQL> EXEC encontra_hw_mark('ALUNO','S_ORD','TABLE')
2. Execute o script lab08_1.sql para atualizar linhas em ALUNO.S_ORD.

sqlplus aluno/aluno
SQL> @lab08_1

usurio ALUNO.
FROM dba_tables
SQL> ALTER TABLE aluno.s_ord MOVE TABLESPACE system;

SQL> ALTER INDEX aluno.s_ord_id_pk REBUILD;
SQL> ANALYZE TABLE aluno.s_ord COMPUTE STATISTICS;
5. Elimine quaisquer linhas migradas.

17

usurio ALUNO.
FROM dba_tables
6. Transfira as linhas migradas da tabela S_ORD para uma nova tabela

chamada S_ORD_TEMP, a partir da tabela CHAINED_ROWS.
connect system as sysdba
SQL> @$ORACLE_HOME/rdbms/admin/utlchain.sql
SQL> ANALYZE TABLE aluno.s_ord LIST CHAINED ROWS;
SQL> SELECT *
FROM chained_rows;
SQL> CREATE TABLE aluno.s_ord_temp
AS SELECT *
FROM aluno.s_ord, chained_rows
WHERE aluno.s_ord.rowid = chained_rows.head_rowid;
18
Solues Exerccios 9
diagnstico disponveis para monitorar e efetuar o tuning de ordenaes.
1. Conecte-se como SYSTEM e execute o script lab09_1.sql, que fora
ordenaes a escreverem para disco.
SQL> @lab09_1
2. Efetue a medida da proporo entre sorts (disk) e sorts (memory).

SQL> SELECT (disk.value / mem.value ) * 100 "Ratio %"
FROM v$sysstat disk, v$sysstat mem
WHERE disk.name = 'sorts (disk)'
AND mem.name = 'sorts (memory)';
/* Deve ser menor que 5% */
3. Configure o parmetro SORT_AREA_SIZE para resultar somente sorts

(memory).
SQL> ALTER SYSTEM SET sort_area_size = 1048576; -- 1MB
/* S pelo init */
SQL> ALTER SESSION SET sort_area_size = 1048576;
4. Conecte-se como ALUNO e execute o script lab9_02.sql e recalcule a

proporo.
sqlplus aluno/aluno
SQL> @lab09_2
SQL> SELECT (disk.value / mem.value ) * 100 "Ratio %"
FROM v$sysstat disk, v$sysstat mem
WHERE disk.name = 'sorts (disk)'
AND mem.name = 'sorts (memory)';
/* Deve ser menor que 5% */
5. Crie uma nova tablespace do tipo TEMPORARY e faa com que as

operaes de ordenao de ALUNO, quando ordenarem para disco,
ocorram nesta tablespace.
19

SQL> CREATE TEMPORARY TABLESPACE temp2
TEMPFILE '/oracle/oradata/<banco>/temp02.dbf'
SIZE 30M UNIFORM SIZE 2M;
SQL> ALTER USER aluno
TEMPORARY TABLESPACE temp2;
6. Conecte-se como ALUNO e reexecute o script lab9_02.sql. Monitore a

tablespace TEMPORARY.
sqlplus aluno/aluno
SQL> @lab09_2
SQL> SELECT *
FROM v$sort_usage;
20
Solues Exerccios 11
diagnstico disponveis para monitorar e efetuar o tuning de segmentos de
undo.
1. Identifique suas configuraos atuais de gerenciamento de undo.
SQL> SHOW PARAMETER UNDO_MANAGEMENT
SQL> SHOW PARAMETER UNDO_RETENTION
SQL> SHOW PARAMETER UNDO_TABLESPACE
SQL> SELECT *
FROM v$rollname;
SQL> SELECT *
FROM v$rollstat;
SQL> SELECT segment_name, status
FROM dba_rollback_segs;
2. Como usurio ALUNO, execute o script insere_dados.sql. O script insere

1000 novas linhas para a tabela TCONTRATOS sem efetuar o commit.
sqlplus aluno/aluno
SQL> @insere_dados
3. Conecte-se como SYSTEM. Identifique a atividade atual dos segmentos

de undo.
SQL> SELECT *
FROM v$transaction;
SQL> SELECT s.username,t.USED_UBLK * 8192/1024
<DB_BLOCK_SIZE>
FROM v$transaction t, v$session s
WHERE s.TADDR = t.ADDR;
--
4. Retorne para a sesso do aluno e efetue o commit.

SQL> COMMIT;
SQL> SELECT *
FROM v$transaction;
SQL> SELECT s.username,t.USED_UBLK * 8192/1024
<DB_BLOCK_SIZE>
TargetTrust FROM
Treinamento
e Consultoria
v$transaction
t, v$session s
WHERE s.TADDR = t.ADDR;
-21
5. Como SYSTEM identifique a atividade atual dos segmentos de undo.
6. Tente remover a tablespace de undo. O que acontece?

SQL> DROP TABLESPACE UNDOTBS1;
DROP TABLESPACE UNDOTBS1
*
ERRO na linha 1:
ORA-30013: undo tablespace 'UNDOTBS1' is currently in use
A tablespace de UNDO est sendo utilizada pelo banco, para
remover uma tablespace de UNDO devemos criar uma nova, configurar
a nova tablespace como sendo a default e depois podemos removla.
7. Como SYSTEM, encontre se voc teve qualquer conteno de segmento

de undo desde o startup, utilizando duas origens de informao
diferentes.
SQL> SELECT SUM(waits)*100/SUM(gets) "ratio", SUM(waits),
SUM(gets)
FROM v$rollstat;
SQL> SELECT usn , waits*100/gets, waits, gets
FROM v$rollstat;
SQL> SELECT class, count
FROM v$waitstat
WHERE class like '%undo%';
8. A viso V$SYSTEM_EVENT apresenta quaisquer esperas relacionadas

com segmentos de undo?
SQL> SELECT *
FROM v$system_event
WHERE event like '%undo%';
22
Solues Exerccios 12
O objetivo desta seo de exerccios familiarizar voc com o uso do
EXPLAIN PLAN e com a interpretao do relatrio formatado de um arquivo de
trace gerado utilizando-se o TKPROF.
1. Conecte-se como ALUNO e crie a tabela PLAN_TABLE sobre o schema do
ALUNO.
No Linux:
sqlplus aluno/aluno
SQL> @$ORACLE_HOME/rdbms/admin/utlxplan
2. Execute um describe da tabela PLAN_TABLE.

SQL> DESC plan_table
3. Utilize o EXPLAIN PLAN para visualizar o plano de execuo trabalhado

pelo otimizador para o comando SQL do script lab12_1.sql.
SQL> @lab12_1
4. Utilize o Trace e TKPROF para visualizar a performance destes planos.

a. Configure sua sesso para o modo de trace.
SQL> ALTER SESSION SET SQL_TRACE = TRUE;
b. Execute o script lab12_2.sql.

SQL> @lab12_2
/* Em uma outra sesso */
SQL> SELECT p.spid
FROM v$process p, v$session s
WHERE s.username = 'ALUNO'
AND p.addr = s.paddr;
SQL> SHOW PARAMETER USER_DUMP_DEST
c. Encerre o SQL*Plus e formate seu arquivo de trace utilizando o

TKPROF. Utilize as opes SYS=NO e EXPLAIN.
23
SQL> ALTER SESSION SET SQL_TRACE=FALSE;

No linux:
cd <diretrio de dump>
tkprof <SID>_ora_<spid>.trc lab12-tkprof.txt sys=no
explain=aluno/aluno
24

Tuning Banco Dados Oracle 10g

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tuning Banco Dados Oracle 10g

Uploaded by

Copyright:

Available Formats

Otimizao e Performance do Banco de

Dados Oracle 10g

Apostila desenvolvida especialmente para Target Informtica Ltda.

Otimizao e Performance do Banco de Dados Oracle 10g

Otimizao e Performance do Banco de Dados Oracle 10g

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

Otimizao e Performance do Banco de Dados Oracle 10g

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

Otimizao e Performance do Banco de Dados Oracle 10g

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

Otimizao e Performance do Banco de Dados Oracle 10g

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

Otimizao e Performance do Banco de Dados Oracle 10g

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

TargetTrust Treinamento e Consultoria

Otimizao e Performance do Banco de Dados Oracle 10g

1. Viso Geral sobre Tuning

TargetTrust Treinamento e Consultoria

Viso Geral sobre Tuning

Listar as diferentes responsabilidades associadas com o processo de

Definir os passos associados com o processo de tuning.

Identificar diferentes metas de tuning.

TargetTrust Treinamento e Consultoria

Viso Geral sobre Tuning

Questes sobre Tuning

Porque Realizar o Tuning?

O hardware pode satisfazer demandas de usurio.

Se decises erradas forem feitas cedo, ou se os usurios esperarem muito

Como Efetuar o Tuning?

Processar 10,000 pedidos por dia.

Neste curso, descrevemos freqentemente os objetivos de tuning do

TargetTrust Treinamento e Consultoria

Viso Geral sobre Tuning

Comandos SQL acessem o menor nmero possvel de blocos Oracle.

TargetTrust Treinamento e Consultoria

Viso Geral sobre Tuning

Exemplos de Metas de Tuning Mensurveis

Quando estiver efetuando o tuning de um ambiente de banco de dados

TargetTrust Treinamento e Consultoria

Viso Geral sobre Tuning

TargetTrust Treinamento e Consultoria

Viso Geral sobre Tuning

Design (se no for tarde demais).

Repita o processo se suas metas no forem atingidas.

TargetTrust Treinamento e Consultoria

Viso Geral sobre Tuning

Desempenho versus Segurana

Mltiplos control files

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

TargetTrust Treinamento e Consultoria

Viso Geral sobre Tuning

TargetTrust Treinamento e Consultoria

Viso Geral sobre Tuning

Espao para anotaes

TargetTrust Treinamento e Consultoria

Otimizao e Performance do Banco de Dados Oracle 10g

2. Oracle Alert e Arquivos de

TargetTrust Treinamento e Consultoria

Oracle Alert e Arquivos de Trace

Identificar a localizao e a utilidade do arquivo de alert log.

Identificar a localizao e a utilidade dos arquivos de trace de

TargetTrust Treinamento e Consultoria

Oracle Alert e Arquivos de Trace