Relatório de Curso

Oracle Performance Diagnostics & Tuning
9iR1 a 11gR2

Ricardo Portilho Proni [e-mail] Esta obra está licenciada sob a licença
Creative Commons Atribuição-SemDerivados 3.0 Brasil.
Para ver uma cópia desta licença, visite http://creativecommons.org/licenses/by-nd/3.0/br/. 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