RDBMS Tuning
Pedro da Silva
Indice
1. Schema Tuning


1.1. Vertical Partitioning
1.2. Tunnig Denormalization
2. Query Tuning


2.1. Query Monitoring
2.2. Query Rewriting
Schema Tunning - Introdução
Qual o melhor esquema?


Compra(keyFornecedor, keyPeça, quantidade,
moradaFornecedor)
Compra(keyFornecedor, keyPeça, quantidade)
Fornecedor(keyFornecedor, moradaFornecedor)
Resposta: DEPENDE

(Espaço? Informação? Performance?)
Vertical Partitioning
Contexto: Cada conta tem associada uma
morada e um saldo
Dois esquemas possíveis:


Conta(keyConta, morada, saldo)
Saldos(keyConta, saldo)
MoradasContas(keyConta, morada)
Se o saldo é acedido/actualizado muito
frequentemente então o segundo
esquema é melhor
Vertical Partitioning - Resumo
A Partição Vertical é
positiva se:

O acesso não se
dirige principalmente
aos dois atributos
SELECT morada, saldo
FROM conta
Througput (queries/sec)
0,02
0,015
0,01
0,005
0

Os dois atributos têm
valores muito
extensos
No Partitioning XYZ
Vertical
No Partitioning Partitioning - XYZ
XY
Vertical
Partitioning - XY
Partitioning vs No Portitioning
Vertical Partitioning - Resumo
1000
Throughput (queries/sec)
A Partição Vertical
melhora a
performance quando
a quantidade de
query’s a aceder
apenas a dois
atributos é maior que
20%
800
600
400
no vertical partitioning
vertical partitioning
200
0
0
20
40
60
% of access that only concern XY
80
100
Vertical Antipartitioning
É uma boa solução em casos onde é
sabido haver muitos mais acessos a uma
pequena parte dos registos associados
Contexto: Os 5 últimos movimentos são
mais importantes:

Conta(keyConta, saldo, morada, movimento1, movimento2, ... ,
movimento5)
Movimentos(keyConta, movimento)
Tuning Denormalization
Contexto: Cada conta pertence a um cliente, o
qual reside numa região

Conta(keyConta, saldo, ultimoMovimento, keyCliente)
Cliente(keyCliente, nome, keyRegião)
Região(keyRegião, região, clima)
Com o esquema anterior uma query para
mostrar as contas e a região das mesmas tornase pesada (3 JOINS)
Solução desnormalizada:

Conta(keyConta, saldo, ultimoMovimento, keyCliente, região)
Tuning Denormalization - Resumo
Desnormalização significa violar a
normalização do esquema para aumentar
a performance
Este método aumenta a performance
quando, muitas vezes, os atributos de
várias tabelas normalizadas são acedidos
conjuntamente
A performance é deteriorada quando
existem muitos updates
Query Monitoring
Duas formas de identificar uma query
lenta:

Acede a demasiada informação em disco
(uma query pontual que percorre toda a
tabela – table scan)
SELECT *
FROM Conta
WHERE bi = 12312456

O plano de execução (escolhido pelo
Optimizador) recorre a índices pouco
produtivos.
Query Rewriting - Índices
Muitos dos Optimizadores não usam índices
quando existem:

Expressões Aritméticas
(WHERE salario/12 >= 400)

Expressões com Substrings
(WHERE SUBSTR(nome, 1, 1) = ‘P’


Comparações numéricas entre atributos de tipos
diferentes
Comparações com NULL
Utilizar índices esparsos nas condições dos
JOINS é uma boa ideia.
Query Rewriting – DISTINCT’s
Eliminar DISTINCTS desnecessários

SELECT DISTINCT keyEmpregado
FROM Empregado
WHERE departamento = ‘Pesca‘
Generalizar a relação entre DISTINCTS, keys e
joins



Denominar uma tabela T privilegiada se o SELECT retorna
algum atributo chave de T
R é uma tabela não privilegiada. Denominar R alcança S se R
for unida (JOINED), por igualdade da sua chave, com a tabela S
Definir que alcança é transitivo (se R1 alcança R2 e R2 alcança
R3 então R1 alcança R3.
Query Rewriting – DISTINCT’s
Não haverão duplicados, mesmo sem o
DISTINCT, se uma das seguintes
condições se verificar:


Todas as tabelas mencionadas no FROM são
privilegiadas
Todas as tabelas não privilegiadas alcançam
pelo menos uma tabela privilegiada
DISTINCT - Exemplos
Exemplo 1:

SELECT numEmpregado
FROM Empregado, TecDpt
WHERE Empregado.keyDpt = TecDpt.keyDpt
Tabela Empregado é privilegiada
Tabela TecDpt alcança a tabela Empregado
Exemplo 2:



SELECT Estudante.bi
FROM Estudante, Empregado, TecDpt
WHERE Estudante.mome = Empregado.nome
AND Empregado.keyDpt = TecDpt.keyDpt
Estudante é privilegiada
Empregado não alcança Estudante (nome não é key)
DISTINCT é necessário para evitar duplicados
Abuse of Temporaries
Contexto: Encontrar todos os empregados e a sua
localização, do departamento de Informática com salário
superior a 40000€


INSERT INTO Temporaria
SELECT *
FROM Empregado
WHERE salario >= 40000
SELECT bi, localização
FROM Temporaria
WHERE Temporaria.departamento = ‘Informática’
A selecção deveria ter sido efectuada na ordem inversa
A tabela temporária “enganou” o Optimizador
Use of Views
A utilização de Views, só por si, não produz incremento
de performance


CREATE VIEW TecnicoLocalizacao
AS
SELECT bi, Tecnico.departamento, localização
FROM Empregado, Tecnico
WHERE Empregado.departamento = Tecnico.departamento
SELECT localização
FROM TecnicoLocalizacao
WHERE bi = 12312795
Os Optimizadores expandem as vistas quando são
identificados os blocos das querys para serem
Optimizados
Use of Views
A query à TecnicoLocalizacao é traduzida num
JOIN

SELECT localizacao
FROM Empregado, Tecnico
WHERE Empregado.departamento = Tecnico.departamento
AND bi = 12312795
Bibliografia
“Database Systems and Concepts”, Silbertchatz, Korth
and Sudarshan, 2005
http://www.distlab.dk/dbtune/
http://publib.boulder.ibm.com/infocenter/db2help/index.js
p?topic=/com.ibm.db2.udb.doc/admin/c0005282.htm
http://msdn.microsoft.com/library/default.asp?url=/library/
en-us/optimsql/odp_tun_1_3nxv.asp