1. Administração de Bases de Dados
Afinação da Aplicação
(Desempenho da Aplicação)
Carlos Pampulim Caldeira
http://www.di.uevora.pt/~ccaldeira
http://makingdatawork.blogspot.pt

2. Optimizador Relacional
• SQL, standard para acesso à informação
• Alto nível de abstracção
• Quais são os dados pretendidos
• Não especifica como os ir buscar
• Access paths, caminhos de acesso aos dados
• Forma desestruturada de escrita
• Operações a nível de conjuntos de dados
• Permite a adaptação do SQL ao ambiente
dinâmico da base de dados:
• Tabelas crescem / diminuem
• Índices adicionados / removidos
• Base dados fragmentada / desfragmentada

3. Optimizador Relacional

4. Optimizador Relacional
Aplicações estão isoladas:
• Estrutura (independência Lógica)
• Forma armazenamento (independência Física)

5. Index Selectivity
Taxa de duplicação numa coluna indexada. Selectividade
ideal é 1, apenas alcansável em índices únicos.
Is = total valores distintos / número de linhas da tabela
Ex. Boa selectividade: 88 000 /100 000 = 0.88
Is < 0,1

6. Medição: Index Selectivity
SELECT COUNT (DISTINCT “Disciplina”)
“Valores distintos” FROM disciplina;
Valores distintos
---------------
5
SELECT COUNT(*) “Nº Total Linhas” FROM disciplina;
Nº Total Linhas
-----------------
14
Is = 5 / 14
= 0,35(714…)

7. Medição: Index Selectivity
Cardinalidade
[Código Postal] Quantos distintos haverá em PT?
Valores distintos
---------------
1000?
Se tiver uma tabela com registo de 10 milhões de
licenças de condução?
Selectividade = 1000 / 10 000 000
Is = 0,0001%

8. Medição: Index Selectivity
Ajuda a decidir entre:
• B*Tree
• Bitmap
1. Se SELECTIVIDADE > 4% é B*Tree
2. Se SELECTIVIDADE < 4% é Bitmap
Os índices, com uma selectividade inferior a 0,1%, devem ser do tipo Bitmap pois
caso contrário nem serão levados em consideração pelo optimizador relacional.

9. Medição: Index Selectivity
Auditoria aos índices em uso (Oracle)
SELECT
INDEX_NAME "Nome",
DISTINCT_KEYS / NUM_ROWS * 100
"SELECTIVITY %",
NUM_ROWS,
DISTINCT_KEYS "DISTINCT",
LEAF_BLOCKS,
CLUSTERING_FACTOR,
BLEVEL "LEVEL",
AVG_LEAF_BLOCKS_PER_KEY "ALFBPKEY"
FROM
DBA_INDEXES
WHERE
DISTINCT_KEYS / NUM_ROWS < .1 AND
NUM_ROWS > 0
ORDER BY "SELECTIVITY %" DESC;

10. Index Density
Percentagem de duplicados numa coluna indexada
Supor tabela com 2 milhões linhas:
1 / NUM_DISCTINCT (not null)
1 / 2 000 000 = 0,0000005
1 / 2 = 0,5

11. Joins
Dois métodos de join:
• Join em ciclo (nested-loop join)
uma linha é identificada na tabela outer e em seguida a tabela inner é
varrida à procura de uma ligação e, assim sucessivamente até à última
ocorrência na tabela outer.
• Join combinado (merge-scan join)
as linhas das tabelas são ordenadas e depois cada uma das tabelas é
lida sequencialmente e as colunas coincidentes são assinaladas e as
linhas devolvidas.
Notas: O join combinado deve ser o escolhido quando a tabela joined um número muito
grande linhas ou quando há muitas linhas que satisfazem a condição, ou ainda quando
os predicados do join não são muito selectivos.

12. Joins
Nº de tabelas na junção Nº de possíveis (ordens) de junções
1 1
2 2
3 6
4 24
5 120
6 720
7 5040
8 40320
9 363880
10 3628800
11 39916800
12 479001600
13 6227020800
14 87178291200
15 1307674368000
16 20922789888000

13. Caminho de acesso aos dados
Varrimento das tabelas:
• não existe(m) índice(s) ou as condições
[WHERE] excluem o(s) índice(s)
• grande número de linhas que satisfazem as
condições
• índices com baixo clustering (index page cluster ratio)
• a tabela é demasiado pequena (poucas linhas)

14. Caminho de acesso aos dados
Acesso directo pelo índice (direct index lookup)
SELECT número, apelido, nome
FROM empregado
WHERE cargo = “Gerente”
AND função = 1
AND departamento = “D01” ;
cargo função departamento

15. Caminho de acesso aos dados
Varrimento do índice:
Varrimento por comparação exacta
(matching index scan)
SELECT número, apelido, nome
FROM empregado
WHERE cargo = “Gerente”
AND função = 1
AND departamento = “D01” ;

16. Caminho de acesso aos dados
Varrimento do índice:
Varrimento por comparação exacta
(matching index scan)
Pág Raíz
Pág Pág
Nonleaf Nonleaf
Pág Pág Pág.
Nonleaf Nonleaf Nonleaf
Folha Folha Folha Folha Folha

17. Caminho de acesso aos dados
Varrimento do índice:
Varrimento pela posição relativa
(nonmatching index scan)
SELECT número, apelido, nome
FROM empregado Não há predicado de
WHERE função = 1 entrada no índice,
AND departamento = “D01” ; logo a estrutura do
índice não pode ser
utilizada.

18. Caminho de acesso aos dados
Varrimento do índice:
Varrimento pela posição relativa
(nonmatching index scan)
Pág Raíz
Pág Pág
Nonleaf Nonleaf
Pág Pág Pág.
Nonleaf Nonleaf Nonleaf
Folha Folha Folha Folha Folha

19. Caminho de acesso aos dados
Varrimento do índice:
• varrimento do índice > varrimento da tabela

20. Caminho de acesso aos dados
Clustered ou unclustered:
• Acesso associado ao índice: lê pág. dados uma única
• Acesso desassociado ao índice: múltiplas leituras
mesma pág. de dados
A CP não é uma boa opção para ser um índice clustered dado que o acesso
aos seus valores é aleatório enquanto que o clustered favorece o acesso
sequencial.
Os índices clustered ao lerem as páginas das folhas nunca lêm a mesma duas
vezes. Já os índices unclustered fazem múltiplos pedidos pois os dados estão
espalhados pela tabela.

21. Caminho de acesso aos dados
Index screening:
SELECT número, apelido
FROM empregado
WHERE cargo = “Gerente”
matching
AND função = 1
AND salário > 40000 ; pos. relativo
cargo função departamento salário

22. Caminho de acesso aos dados
Acesso restrito aos índices (index covering)
SELECT número, apelido
FROM empregado
WHERE cargo = “Gerente”
AND função = 1
AND salário > 40000 ;
cargo função departamento salário apelido número

23. Caminho de acesso aos dados
Acesso restrito aos índices (index covering)
• Não há I/O adicional à tabela
• “Encorajar” o acesso index-only
• Sobrecarga de colunas indexadas

24. Caminho de acesso aos dados
Acesso múltiplo (multi-index access):
SELECT número, apelido
FROM empregado
WHERE cargo = “Gerente”
AND função = 1 ;
cargo função

25. Caminho de acesso aos dados
Acesso múltiplo (multi-index access):
Por vezes pode minimizar-se o número de índices
criados promovendo múltiplos índices simples,
i.e., com uma única coluna, em vez de muitas
colunas compostas indexadas. A decisão de
aplicar uns e/ou outros depende da eficiência do
SGBDR na utilização das diversas formas de
indexação.
Nota: AND; OR

26. Ordenação de dados
A utilização de índices para evitar SORT's:
• Distinct
• Union
• Group by
• Order by

27. Desprezo pelo índice
O optimizador não utiliza o índice:
• Sem predicados
• Join com várias/muitas tabelas
• Estatísticas desactualizadas

28. Views: acesso
Dois métodos:
• View merging
• View materialization
O view merging é o método mais eficiente. O SQL aplicado no DDL da view é
aglutinado (merged) com o SQL que refere a view. O SQL resultante é então
utilizado para determinar o caminho de acesso aos dados.
Quando não é possível combinar o SQL da view com o SQL que acede à view é
criada uma tabela temporária que armazena os resultados da view. O SQL que
acede à view é depois aplicado aos resultados guardados na tabela temporária. Daí
a relativa ineficiência da view materialization.

29. Re(escrita) de queries
Alguns optimizadores:
WHERE coluna1 >= 1 AND coluna1 <= 100 , podem transformar esta
cláusula nesta:
WHERE coluna1 BETWEEN 1 AND 100

30. Re(escrita) de queries
transitividade do predicado (predicate transitive closure)
SELECT d."Nome do Departamento", e."Nome", e."Número de Funcionário"
FROM empregado e, departamento d
WHERE e."Código do Departamento" = d."Código do Departamento"
AND d."Código do Departamento" = "DO59";
SELECT d."Nome do Departamento", e."Nome", e."Número de Funcionário"
FROM empregado e, departamento d
WHERE e."Código do Departamento" = d."Código do Departamento"
AND e."Código do Departamento" = "DO59";

31. Optimização pelo custo
O optimizador relacional é o subsistema de um
SGBDR que gera planos de execução.
• Efeito da modificação dos parâmetros de
configuração (Oracle):
o cost-based

32. Análise do caminho de acesso
SQL Server:
• ShowPlan
Oracle:
• Explain
set timing on; (SQL*Plus)

33. SQL: regras de Mullins
Codificação do SQL para a eficiência:
Regra 1: Depende...
Regra 2: Posição na query da cláusula
mais restritiva
e prosseguindo até à 11ª regra.
Mullins, C. 2002. Chapter 12. Application Performance. Database Administration: The
Complete Guide to Practices and Procedures. Addison Wesley.

34. Optimização do SQL
Video [“esclarecedor”] sobre SQL
Optimization em Oracle: ver aqui.

35. Afinação da Aplicação - Oracle
SQL Analyse (Oracle): ver aqui.