Professional Documents
Culture Documents
OPDT - Oracle Performance Tuning Portilho (NERV)
OPDT - Oracle Performance Tuning Portilho (NERV)
9iR1 a 11gR2
1
Minha abordagem
●
Performance de Sistemas Computacionais só pode ser medida em TEMPO.
●
Performance Tuning deve ser reativa.
●
Performance Tuning deve ter ROI.
●
Apenas os maiores gargalos devem ser solucionados.
●
O processo deve ser Diagnostics, e depois Tuning.
●
Alto consumo de CPU não é um problema.
●
O usuário não executa um SQL por prazer.
●
O desenvolvedor não deveria saber como fazer um bom SQL (COBOL?).
●
Ferramentas Gráficas / Enterprise Manager / Wizards / Automação são bons auxiliares.
●
Bancos com bom desempenho devem ser observados.
●
Conheça outros RDBMSs: TI não é lugar para paixões.
●
Não acredite em nada (separar tabelas e índices?). Teste.
●
Se houvesse um parâmetro que sempre deixasse o Oracle mais rápido, sem nenhum efeito
colateral, ele já viria habilitado.
●
Desenvolva um método de convencimento gerencial.
●
Por algo chamar-se Storage, não quer dizer que ele não tenha problemas.
●
KISS (Keep It Simple, Stupid): a probabilidade de falha cresce linearmente com o aumento de
complexidade.
●
Saiba diser “Não”.
●
Saiba dizer “Não sei”.
2
Performance Diagnostics & Tuning
3
Mistificação
4
Métodos Antigos
5
Requisitos
●
Experiência
●
Intuição
●
Imprecisão
●
Tempo
●
Sorte
●
Recursos
6
TOP Tuning
• Verificar maior consumidor de CPU;
• Verificar o SQL agressor;
• Alterar o SQL e esperar que o desempenho melhore;
• Adicionar Índices e esperar que o desempenho melhore;
• Se não melhorar, matar a sessão.
• Se o desempenho não melhorar, voltar ao início.
7
Checklist Tuning
●
Verificar Sistema Operacional (free / taskmgr / Performance Monitor);
●
Verificar Sistema Operacional (vmstat / taskmgr / Performance Monitor);
●
Verificar Sistema Operacional (iostat / taskmgr / Performance Monitor);
●
Verificar SGA;
●
Verificar PGA;
●
Verificar coleta de estatísticas;
●
Verificar parâmetros do Oracle;
●
Verificar fragmentação de tabelas;
●
Verificar LOCKs;
●
Verificar SQLs que consomem mais recursos;
●
…
●
Construir uma teoria baseada nos dados observados;
●
Alterar algo e esperar que o desempenho melhore;
●
Se o cliente não gostar da teoria, apenas cite e altere alguns parâmetros
relacionados;
●
Se o desempenho não melhorar, voltar ao início.
8
Ratios Tuning
• Verificar Buffer Cache Hit Ratio;
• Verificar Data Dictionary Hit Ratio;
• Verificar SQL Cache Hit Ratio;
• Verificar Library Cache Hit Ratio;
•…
• Construir uma teoria baseada nos dados observados;
• Alterar algo (geralmente aumentar) e esperar que o desempenho melhore;
• Se o desempenho não melhorar, voltar ao início.
9
KIWI Tuning
●
KIWI = Kill It With Iron;
●
Adicionar Memória RAM;
●
Adicionar CPUs;
●
Melhorar o I/O;
●
Migrar para um Servidor maior;
●
Migrar para RAC;
●
Adicionar Nós no RAC;
●
…
●
Pagar a conta, e esperar que o desempenho melhore.
●
Se o desempenho não melhorar, voltar ao início.
10
Manager Tuning
●
Migrar Banco para outro servidor;
●
Executar Upgrade de Banco de Dados;
●
Executar Upgrade da Aplicação;
●
Executar Upgrade do Middleware;
●
Juntar Aplicação e Banco de Dados;
●
Separar Aplicação e Banco de Dados;
●
Voltar Backups;
●
…
●
Se o desempenho não melhorar, tentar outra coisa, até melhorar.
11
O que está errado?
12
Paradigma
13
Lendas do Oracle
14
Lendas do Oracle
●
Todo teu SELECT deverá utilizar um índice, para que ele seja rápido.
●
Terás uma área de SWAP com o dobro de tua RAM.
●
Não utilizarás mais que 50% de tua RAM para a SGA.
●
Utilizarás HINTs, pois tu és mais sábio que o Oracle.
●
Não coletarás estatísticas do dicionário de dados.
●
Deverás separar teus dados e índices.
●
Deverás separar teus dados em diversas TABLESPACEs.
●
Teus DATAFILEs deverão ter no máximo 2GB / 10GB / xGB.
●
Não habilitarás AUTOEXTEND ON.
●
Deverás executar COMMIT a cada N linhas.
●
Utilizarás RAID 5, pois é mais rápido para leituras
●
Não permitirás mais que um SWITCH a cada 20 minutos.
●
Mas não terás grandes REDO LOGs.
●
Executarás REBUILD de índices regularmente.
●
Executarás MOVE de tabelas regularmente.
●
Se grande a tabela tornar-se, a particionarás.
●
Se quiseres mais velocidade, usarás RAC.
●
Quanto mais CPUs, mais rápido teu banco de dados será.
●
Se teus RATIOS estiverem altos, felizes estarão teus usuários.
●
Sempre que possível, aumentarás seu DB_CACHE_SIZE e SHARED_POOL.
●
Desabilitarás o AWR, pois ele causa lentidão.
●
Não utilizarás memória automática. Tu és mais sábio que o Oracle.
●
Se usar, deixarás a SGA_TARGET um pouco menor que a SGA_MAX_SIZE.
●
AUTOMATIC SQL TUNING é um dos cavaleiros do apocalipse.
15
O carro e o leite
Seu filho leva 2 horas para comprar leite na padaria, de carro.
●
É necessário um carro mais rápido?
●
São necessários dois carros?
●
É necessário tornar a estrada mais larga?
●
É melhor só comprar 1 litro de leite de cada vez?
●
Deve-se utilizar uma padaria que só tenha 1 tipo de leite?
●
A porta da garagem deve estar sempre aberta?
16
Ponte Aérea
O carioca precisa acordar às 03:30 para chegar em SP às 09:00.
●
Utilizar um Concorde?
●
Voar mais rente ao solo?
●
Tornar o avião mais leve, transportando menos pessoas e bagagem?
17
O chefe e o atraso
18
Como saber quem vence?
19
O Método Correto
20
A Peste Negra
21
Tempo
22
Tempo Computacional
R=S+W
OU
23
Instrumentação: Mainframe
24
Instrumentação: Solaris
25
Oracle Wait Interface
26
Oracle Wait Interface
27
Nascimento da OWI
• Benchmark 7.0.12: Juan Loainza
• YAPP Paper: Anjo Kolk
28
Evolução da OWI
●
Versão 7.0.12: 104 Wait Events
●
Versão 8: 140 Wait Events
●
Versão 8i: 220 Wait Events
●
Versão 9i: 400 Waits Events
●
Versão 10gR1: >800 Wait Events
●
Versão 11gR2: >1100 Wait Events
29
Enterprise Manager
30
Conceitos Básicos
31
Arquitetura Oracle
32
Parâmetros elementares
●
db_block_size
●
db_file_multiblock_read_count
●
memory_max_target
●
memory_target
●
sga_max_size
●
sga_target
●
pga_aggregate_target
●
db_cache_size (db_2k_cache_size, db_4k_cache_size, db_8k_cache_size...)
●
buffer_pool_keep, buffer_pool_recycle
●
shared_pool_size, shared_pool_reserved_size
●
large_pool_size
●
java_pool_size
●
streams_pool_size
●
result_cache_max_result, result_cache_max_size, result_cache_mode
●
log_buffer
●
fast_start_mttr_target
●
log_checkpoint_interval, log_checkpoint_timeout
33
Hands ON !
Parâmetros elementares
34
Lab 1.1: Parâmetros elementares
●
Verifique os parâmetros elementares em seu banco de dados.
●
Altere o parâmetro memory_max_target para 0;
●
Altere o parâmetro memory_target para 0;
●
Altere o parâmetro sga_max_size para metade da RAM da máquina;
●
Altere o parâmetro sga_target para 0;
●
Altere o parâmetro db_cache_size para metade do sga_max_size.
●
Altere o parâmetro shared_pool_size para metade do db_cache_size.
●
Altere o parâmetro pga_aggregated_target para 100M;
35
Granularidades de Análise
●
SQL Statement
●
Session
●
Instance
36
Cenários de Análise
●
Há lentidão agora
●
Tivemos lentidão ondem
37
Ferramentas de Análise
●
Dynamic Performance Views
●
Extended SQL Trace (Event 10046)
●
Statspack / AWR
38
Wait Classes
• Administrative
• Application
• Cluster
• Commit
• Concurrency
• Configuration
• Idle
• Network
• Other
• Queueing
• Scheduler
• System I/O
• User I/O
39
Limitações da OWI
40
Limitações: OWI
●
Não é um monitoramento End-to-End
●
Sem dados de consumo de CPU
●
Sem dados de consumo de Memória
●
Bugs
●
Imprecisões
41
Limitações: Views
●
Sem histórico
42
Limitações: Extended SQL Trace
●
Muitos dados
●
Altíssima granularidade
●
Desempenho
●
Correlação de informações
●
Sessões PARALLEL
●
Sessões SHARED SERVER
●
Waits só disponíveis em >=9iR1
●
Suporte oficial só em >10gR1
43
Limitações: Statspack / AWR
●
Baixa granularidade
●
Apenas histórico
44
Hands ON !
Dynamic Performance Views
45
Lab 2.1: Views
→ V$SYSTEM_EVENT
→ V$SESSION_EVENT
→ V$SESSION_WAIT
●
Verifique as Dynamic Performance Views da OWI em seu banco de dados.
●
Quais suas colunas mais importantes?
●
Que Waits você tem em seu banco de dados?
●
Habitue-se a seu conteúdo.
46
Wait Events mais comuns
47
Wait Events mais comuns
●
buffer busy
●
free buffer
●
read by oher session
●
control file single write / control file parallel write / control file sequential read
●
db file single write / db file parallel read / db file parallel write
●
db file scatteread read / db file sequential read
●
direct path read / direct path write
●
enqueue
●
free buffer
●
latch free / latch: library cache / latch: cache buffers chains
●
library cache pin / library cache lock
●
log buffer space
●
log file parallel write / log file single write / log file sequential read
●
log file switch (archiving needed)
●
log file switch (checkpoint incomplete) / log file switch completion
●
log file sync
●
SQL*Net message from client / SQL*Net message to client
●
SQL*Net more data from client / SQL*Net more data to client
●
SQL*Net break/reset from client / SQL*Net break/reset to client
48
Hands ON !
Simulando Wait Events
Gravações
49
Lab 3.1: Gravações
Habilite o usuário SCOTT.
SQL> ALTER USER SCOTT ACCOUNT UNLOCK IDENTIFIED BY TIGER;
SQL> GRANT SELECT ANY DICTIONARY TO SCOTT;
Com o usuário SCOTT, crie uma grande tabela, com pelo menos 4GB.
SQL> CREATE TABLE T AS SELECT * FROM ALL_OBJECTS;
SQL> INSERT INTO T SELECT * FROM T;
SQL> INSERT INTO T SELECT * FROM T;
SQL> ...
SQL> INSERT INTO T SELECT * FROM T;
SQL> COMMIT;
50
Lab 3.2: Gravações
Feche e abra a sessão com o SCOTT com SET TIMING ON
SQL> CONN SCOTT/TIGER
SQL> SET TIMING ON
51
Lab 3.3: Gravações
Responda as seguintes perguntas:
- Onde foi gasto mais tempo nesta sessão?
- A que se referem os maiores Wait Events?
- Qual dos maiores Wait Events podem ser reduzidos?
- A eliminação de um Wait Event que pode ser reduzido, causará uma melhoria de quanto tempo?
- Como reduzir este Wait Event?
Remova a tabela T2, feche e abra a sessão com o SCOTT, e repita a operação.
52
Lab 3.4: Gravações
Responda as seguintes perguntas:
- Onde foi gasto mais tempo nesta sessão?
- A que se referem os maiores Wait Events?
- Qual dos maiores Wait Events podem ser reduzidos?
- A eliminação de um Wait Event que pode ser reduzido, causará uma melhoria de quanto tempo?
- Como reduzir este Wait Event?
Remova a tabela T2, feche e abra a sessão com o SCOTT, e repita a operação.
53
Lição de casa
• Verifiquem as Dynamic Performance Views de seus servidores.
• Tragam suas dúvidas para a aula.
54
Extended SQL Trace
55
Níveis Extended SQL Trace
●
0 = Standard Trace
●
4 = Bind Variables
●
8 = Wait States
●
12 = Bind Variables + Wait States
56
Ativar Extended SQL Trace
●
Em toda a instância
●
Em sua sessão
●
Em outra sessão
57
Detalhes Extended SQL Trace
*** 2010-03-22 11:43:12.276
WAIT #9: nam='db file scattered read' ela= 183330 file#=4 block#=9124 blocks=26 obj#=74574
WAIT #9: nam='db file scattered read' ela= 2528 file#=4 block#=9150 blocks=26 obj#=74574
WAIT #9: nam='db file scattered read' ela= 170358 file#=4 block#=9176 blocks=26 obj#=74574
WAIT #9: nam='db file scattered read' ela= 96261 file#=4 block#=9202 blocks=26 obj#=74574
WAIT #9: nam='db file scattered read' ela= 1669 file#=4 block#=9228 blocks=26 obj#=74574
WAIT #9: nam='db file scattered read' ela= 26055 file#=4 block#=9254 blocks=26 obj#=74574
WAIT #9: nam='db file scattered read' ela= 4760 file#=4 block#=9280 blocks=26 obj#=74574
WAIT #9: nam='db file scattered read' ela= 108783 file#=4 block#=9306 blocks=26 obj#=74574
tim=1269268992840594
=====================
58
tkprof
59
Limitações: Extended Trace
●
Não é um monitoramento End-to-End
●
Sem dados de consumo de CPU
●
Sem dados de consumo de Memória
●
Bugs
●
Imprecisões
●
Muitos dados
●
Altíssima granularidade
●
Desempenho
●
Correlação de informações
●
Sessões PARALLEL
●
Sessões SHARED SERVER
●
Waits só disponíveis em >=9iR1
●
Suporte oficial só em >10gR1
60
Hands ON !
Extended SQL Trace
Full Table Scan
61
Lab 4.1: Extended SQL Trace
Feche e abra a sessão com o SCOTT com SET TIMING ON
SQL> EXIT
$ sqlplus SCOTT/TIGER
SQL> SET TIMING ON
62
Lab 4.2: Extended SQL Trace
Com o usuário SCOTT, apague o conteúdo da grande tabela, altere o valor
do parâmetro db_file_multiblock_read_count (apenas na sessão) e reinsira
os dados.
SQL> TRUNCATE TABLE T2;
SQL> ALTER SESSION SET db_file_multiblock_read_count = 8;
SQL> INSERT INTO T2 SELECT * FROM T;
SQL> COMMIT;
63
Wait Events - Detalhes
64
Ensinar a Pescar
65
Referência
66
Performance Tuning Guide
67
MOS
68
buffer busy
Explicação: O bloco solicitado está em uso, pois outra sessão está carregando o
bloco para o DB_CACHE_SIZE, ou outra sessão está utilizando o bloco no
DB_CACHE_SIZE em um modo incompatível.
Causa: DB_CACHE_SIZE insuficiente, ou SQL ineficiente.
Correção: Aumente o DB_CACHE_SIZE ou altere o SQL.
69
buffer busy
70
free buffer
Explicação: O RDBMS aguarda blocos de DB_CACHE_SIZE livres.
Causa: DB_CACHE_SIZE insuficiente.
Correção: Aumente o DB_CACHE_SIZE.
71
read by other session
Explicação: O bloco solicitado está em uso, pois outra sessão está carregando o
bloco para o DB_CACHE_SIZE, ou outra sessão está utilizando o bloco no
DB_CACHE_SIZE em um modo incompatível.
Causa: DB_CACHE_SIZE insuficiente, ou SQL ineficiente.
Correção: Aumente o DB_CACHE_SIZE ou altere o SQL.
72
control file parallel write
Explicação: Espera de I/O para gravar em CONTROLFILEs.
Causa: Excesso de gravação nos CONTROLFILEs ou I/O ineficiente.
Correção: Minimize as gravações nos CONTROLFILEs ou melhore o mecanismo
de I/O.
73
control file single write
Explicação: Espera de I/O para gravar em CONTROLFILEs.
Causa: Excesso de gravação nos CONTROLFILEs ou I/O ineficiente.
Correção: Minimize as gravações nos CONTROLFILEs ou melhore o mecanismo
de I/O.
74
control file sequential read
Explicação: Espera de I/O para ler os CONTROLFILEs.
Causa: Excesso de leitura nos CONTROLFILEs ou I/O ineficiente.
Correção: Minimize as leituras nos CONTROLFILEs ou melhore o mecanismo de
I/O.
75
db file parallel write
Explicação: Gravações de dados nos DATAFILEs esperam pelo I/O.
Causa: Excesso de gravações ou lentidão de I/O.
Correção: Minimize as gravações ou melhore o mecanismo de I/O.
76
db file single write
Explicação: Uma gravação no HEADER do DATAFILE esperam pelo I/O.
Causa: Excesso de gravações no HEADER dos DATAFILEs ou lentidão de I/O.
Correção: Minimize as gravações no HEADER dos DATAFILEs ou melhore o
mecanismo de I/O.
77
db file parallel read
Explicação: Durante RECOVER ou durante PREFETCHING, leituras de
DATAFILEs esperam pelo I/O.
Causa: RECOVER muito longo, PREFETCHING excessivo, ou lentidão de I/O.
Correção: Acelere o RECOVER, minimize o PREFETCHING, ou melhore o
mecanismo de I/O.
78
User I/O
79
Influenciando o Otimizador
●
CURSOR_SHARING
●
DB_FILE_MULTIBLOCK_READ_COUNT
●
OPTIMIZER_INDEX_CACHING
●
OPTIMIZER_INDEX_COST_ADJ
●
OPTIMIZER_MODE
●
PGA_AGGREGATE_TARGET
●
STAR_TRANSFORMATION_ENABLED
80
db file scattered read
Explicação: Durante FTS, leituras de DATAFILEs esperam pelo I/O.
Causa: DB_CACHE_SIZE insuficiente, FTS desnecessário ou lentidão de I/O
Correção: Aumente o DB_CACHE_SIZE, elimine o FTS, ou melhore o
mecanismo de I/O.
81
db file sequential read
Explicação: Durante a leitura de um bloco, leituras de DATAFILEs esperam pelo
mecanismo de I/O.
Causa: DB_CACHE_SIZE insuficiente, leitura desnecessária ou lentidão de I/O
Correção: Aumente o DB_CACHE_SIZE, elimine a leitura desnecessária, ou
melhore o mecanismo de I/O.
82
direct path read / direct path write
Explicação: Leitura / gravação entre DATAFILEs / TEMPFILEs e PGA.
Causa: PGA insuficiente, ou lentidão de I/O.
Correção: Aumente a PGA, ou melhore o mecanismo de I/O.
83
enqueue
Explicação: Mecanismo de fila ordenada do RDBMS.
Causa: Diversas, dependendo do tipo de fila.
Correção: Diversas, dependendo do tipo de fila.
84
latch free
Explicação: Mecanismo de fila desordenada do RDBMS.
Causa: Diversas, dependendo do tipo de fila.
Correção: Diversas, dependendo do tipo de fila.
85
library cache pin / library cache lock
Explicação: Uso incompatível do objeto entre duas sessões.
Causa: Uso do objeto de forma incompatível entre duas sessões.
Correção: Finalizar o uso do objeto por uma das sessões.
86
log buffer space
Explicação: Mais espaço no LOG_BUFFER é necessário para gravações.
Causa: LOG_BUFFER insuficiente, REDO LOGs insuficientes, ou I/O lento.
Correção: Aumente o LOG_BUFFER, aumente a quantidade / tamanhode REDO
LOGs, ou melhore o mecanismo de I/O.
87
log file parallel write
Explicação: Durante gravação de REDO LOGs, o LGWR espera pelo I/O.
Causa: Excesso de membros nos grupos de REDO LOGs ou lentidão de I/O.
Correção: Reduza a quantidade de membros nos grupos de REDO LOGs ou
melhore o mecanismo de I/O.
88
log file single write
Explicação: Durante gravação no HEADER de um REDO LOGs, o LGWR
espera pelo I/O.
Causa: Excesso de gravações no HEADER do REDO LOG ou lentidão de I/O.
Correção: Reduza a quantidade de gravações no HEADER do REDO LOG ou
melhore o mecanismo de I/O.
89
log file sequential read
Explicação: Durante leitura de REDO LOGs, o LGWR espera pelo I/O.
Causa: Lentidão de I/O.
Correção: Melhore o mecanismo de I/O.
90
log file switch
Explicação: Todos os grupos de REDO LOGs foram utilizados e ainda são
necessários para um eventual RECOVER, pois o ARCn ainda não criou os
ARCHIVED REDO LOGs e o DBWR ainda não gravou seu conteúdo nos
DATAFILEs.
Causa: REDO LOGs sub-dimensionados, configuração inadequada de destino
de ARCHIVED REDO LOGs ou I/O ineficiente.
Correção: Aumentar os REDO LOGs em quantidade e/ou tamanho, corrigir a
configuração de destino do ARCn, ou melhorar o mecanismo de I/O.
Variações:
●
log file switch (archiving needed)
●
log file switch (checkpoint incomplete)
●
log file switch (clearing log file)
●
log file switch (private strand flush incomplete)
●
log file switch completion
91
log file sync
Explicação: Um CHECKPOINT foi executado, e precisa ser registrado no REDO
LOG, e o LGRW está aguardando pelo mecanismo de I/O.
Causa: COMMIT em quantidade excessiva, ou I/O ineficiente.
Correção: Reduzir a quantidade de COMMITs ou otimizar o mecanismo de I/O.
92
SQL*Net message to / from client
Explicação: Espera durante comunicação via rede com o protocolo SQL*Net.
Causa: Sessão inativa, latência de rede ou limitação do cliente.
Correção: Eliminar a sessão inativa, minimizar a latência na rede ou minimizar a limitação
do cliente.
Variações
●
SQL*Net message from client
●
SQL*Net message to client
●
SQL*Net more data from client
●
SQL*Net more data to client
●
SQL*Net break/reset to client
●
SQL*Net message from dblink
●
SQL*Net message to dblink
●
SQL*Net more data from dblink
●
SQL*Net more data to dblink
●
SQL*Net break/reset to dblink
93
Hands ON !
Simulando Wait Events
LGWR x DBWR
94
Lab 5.1: LGWR x DBWR
Feche e abra a sessão com o SCOTT com SET TIMING ON
SQL> CONN SCOTT/TIGER
SQL> SET TIMING ON
95
Parallel SQL
96
Parallel SQL
Permite Query, DML e DDL.
97
Parallel SQL
Parâmetros:
PARALLEL_ADAPTIVE_MULTI_USER = true ou false.
PARALLEL_AUTOMATIC_TUNING: Deprecated.
PARALLEL_DEGREE_LIMIT = CPU, IO ou Número.
PARALLEL_DEGREE_POLICY = MANUAL, LIMITED ou AUTO.
PARALLEL_EXECUTION_MESSAGE_SIZE = De 2148 a 32768
PARALLEL_FORCE_LOCAL = true ou false.
PARALLEL_INSTANCE_GRouP = Oracle RAC service_name ou group_name.
PARALLEL_IO_CAP_ENABLED = Deprecated.
PARALLEL_MAX_SERVERS = De 0 a 3600.
PARALLEL_MIN_PERCENT = De 0 a 100.
PARALLEL_MIN_SERVERS = Número entre 0 e PARALLEL_MAX_SERVERS.
PARALLEL_MIN_TIME_THRESHOLD = AUTO | Segundos.
PARALLEL_SERVERS_TARGET = Número entre 0 e PARALLEL_MAX_SERVERS.
PARALLEL_THREADS_PER_CPU = Qualquer número.
98
Hands ON !
Simulando Wait Events
Design de Aplicação
99
Lab 6.1: Design de Aplicação
Reinicie a Instance.
Verifique o conteúdo da V$SYSTEM_EVENT. Guarde esta consulta.
100
Lab 6.2: Design de Aplicação
Crie esta tabela com o usuário SCOTT:
SQL> CREATE TABLE T3 (NUMERO NUMBER);
101
Lab 6.3: Design de Aplicação
Crie um índice BITMAP na tabela T3 com o usuário SCOTT:
SQL> CREATE BITMAP INDEX IDX_BITMAP_T3 ON T3(NUMERO);
Abra outra sessão com o SCOTT, e faça outro INSERT na tabela T3:
SQL> INSERT INTO T3 VALUES (1);
102
Lab 6.4: Design de Aplicação
Abra uma sessão com o usuário SCOTT com SET TIMING ON:
103
Estatísticas
104
Estatísticas
Optimizer Statistics
Table statistics
Number of rows
Number of blocks
Average row length
Column statistics
Number of distinct values (NDV) in column
Number of nulls in column
Data distribution (histogram)
Extended statistics
Index statistics
Number of leaf blocks
Levels
Clustering factor
System Statistics
I/O performance and utilization
CPU performance and utilization
105
Estatísticas
DBMS_AUTO_TASK_ADMIN.DISABLE
DBMS_STATS.GATHER_DATABASE_STATS
DBMS_STATS.GATHER_DICTIONARY_STATS
DBMS_STATS.GATHER_SCHEMA_STATS
DBMS_STATS.GATHER_TABLE_STATS
DBMS_STATS.GATHER_INDEX_STATS
DBMS_STATS.DELETE_TABLE_STATS
DBMS_STATS.LOCK_TABLE_STATS
DBMS_STATS.EXPORT_*_STATS
DBMS_STATS.IMPORT_*_STATS
OPTIMIZER_DYNAMIC_SAMPLING
DBMS_STATS.GATHER_SYSTEM_STATS
106
Hands ON !
DBMS_SQLTUNE
107
Lab 7.1: DBMS_SQLTUNE
Escolha um dos SQLs mais lentos na V$SQL e o analise com DBMS_SQLTUNE.
108
Fragmentação
109
Fragmentação
●
Blocos logicamente contíguos espalhados fisicamente.
●
Espaço livre na TABLESPACE / DATAFILEs.
●
Espaço livre da TABELA.
●
Espaço livre no ÍNDICE.
●
Row Chaining.
●
Migrated Rows.
●
EXTENTs.
110
Fragmentação: COALESCE
111
Fragmentação: COALESCE
112
Fragmentação: Row Chaining
113
Fragmentação: Row Migration
114
Hands ON !
DBMS_ADVANCED_REWRITE
115
Lab 8.1: DBMS_ADVANCED_REWRITE
Abra uma sessão com o usuário SCOTT com SET TIMING ON:
116
Lab 8.2: DBMS_ADVANCED_REWRITE
Na sessão do usuário SCOTT, execute o DBMS_ADVANCE_REWRITE:
BEGIN
SYS.DBMS_ADVANCED_REWRITE.DECLARE_REWRITE_EQUIVALENCE (
NAME => 'PORTILHO_REWRITE',
SOURCE_STMT => 'SELECT /*+ INDEX(T_ALIAS,IDX_T) */ COUNT(*) FROM T T_ALIAS WHERE
OBJECT_NAME = ''T''',
DESTINATION_STMT => 'SELECT COUNT(OBJECT_NAME) FROM T T_ALIAS WHERE
OBJECT_NAME = ''T''',
VALIDATE => FALSE,
REWRITE_MODE => 'TEXT_MATCH');
END;
/
117
Cenários de Análise
●
O Banco de Dados está lento agora.
●
Encontrar indícios do gargalo na V$SESSION_WAIT.
●
Encontrar o SID na V$SESSION_WAIT.
●
Encontrar o maior Wait Event na V$SESSION_EVENT.
●
Corrigir o maior Wait Event possível.
●
O Banco de Dados estava lento ontem.
●
Encontrar indícios do gargalo na V$SYSTEM_EVENT.
●
Encontrar o maior Wait Event via Statspack / AWR.
●
Corrigir o maior Wait Event possível.
●
Este SQL está lento.
●
Executar com Extended SQL Trace.
●
Encontrar o maior Wait Event via tkprof.
●
Corrigir o maior Wait Event possível.
118
Statspack / AWR
119
Statspack / AWR
●
Statspack / SPreport
$ sqlplus / AS SYSDBA
SQL> @?/rdbms/admin/spcreate.sql
SQL> @?/rdbms/admin/spauto.sql
SQL> EXECUTE STATSPACK.SNAP;
SQL> @?/rdbms/admin/spreport.sql
120
Hands ON !
Statspack / AWR
121
Lab 9.1: AWR
Crie uma TABLESPACE chamada SOE, com AUTOEXTEND ON.
122
Resource Plan
123
Resource Plan
Separação de Recursos por:
●
ORACLE_USER
●
SERVICE_NAME
●
CLIENT_OS_USER
●
CLIENT_PROGRAM
●
CLIENT_MACHINE
●
MODULE_NAME
●
MODULE_NAME_ACTION
●
SERVICE_MODULE
●
SERVICE_MODULE_ACTION
124
Resource Plan
125
Resource Plan
Mudanças de planos:
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'PEAKTIME';
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'OFF-PEAK';
Monitoração:
●
DBA_RSRC_CONSUMER_GROUP_PRIVS
●
DBA_RSRC_PLANS
●
V$SESSION
●
V$RSRC_PLAN
●
V$RSRC_CONSUMER_GROUP
●
V$RSRC_SESSION_INFO
●
V$RSRC_PLAN_HISTORY
●
V$RSRC_CONS_GROUP_HISTORY
●
V$RSRCMGRMETRIC
●
V$RSRCMGRMETRIC_HISTORY
126
LAB 11 – Resource Plan
Hands On !
127
Lab 10.1 – Resource Plan
Analise o código do arquivo ResourcePlan.sql.
128
Revisão
129
Método de Tuning
●
O Banco de Dados está lento agora:
●
Encontrar indícios do gargalo na V$SYSTEM_EVENT.
●
Encontrar indícios do gargalo na V$SESSION_WAIT.
●
Encontrar o(s) SID(s) ofensor na V$SESSION_WAIT.
●
Encontrar o maior Wait Event deste(s) SID(s) na V$SESSION_EVENT.
●
Corrigir o maior Wait Event possível.
●
Se o tempo esta satisfatório, finalizar o processo.
●
O Banco de Dados estava lento ontem:
●
Encontrar indícios do gargalo na V$SYSTEM_EVENT.
●
Encontrar o maior Wait Event via Statspack / AWR.
●
Corrigir o maior Wait Event possível.
●
Se o tempo esta satisfatório, finalizar o processo.
●
Este SQL está lento:
●
Executar o comando SQL com Extended SQL Trace.
●
Encontrar indícios do gargalo durante a execução do SQL Trace.
●
Encontrar o maior Wait Event via tkprof.
●
Corrigir o maior Wait Event possível.
●
Se o tempo esta satisfatório, finalizar o processo.
130