RDBMS Tuning Pedro da Silva. Indice 1. Schema Tuning 1.1. Vertical Partitioning 1.1. Vertical Partitioning 1.2. Tunnig Denormalization 1.2. Tunnig Denormalization.

Apresentação em tema: "RDBMS Tuning Pedro da Silva. Indice 1. Schema Tuning 1.1. Vertical Partitioning 1.1. Vertical Partitioning 1.2. Tunnig Denormalization 1.2. Tunnig Denormalization."— Transcrição da apresentação:

1 RDBMS Tuning Pedro da Silva

2 Indice 1. Schema Tuning 1.1. Vertical Partitioning 1.1. Vertical Partitioning 1.2. Tunnig Denormalization 1.2. Tunnig Denormalization 2. Query Tuning 2.1. Query Monitoring 2.1. Query Monitoring 2.2. Query Rewriting 2.2. Query Rewriting

3 Schema Tunning - Introdução Qual o melhor esquema? Compra(keyFornecedor, keyPeça, quantidade, moradaFornecedor) Compra(keyFornecedor, keyPeça, quantidade, moradaFornecedor) Compra(keyFornecedor, keyPeça, quantidade) Compra(keyFornecedor, keyPeça, quantidade) Fornecedor(keyFornecedor, moradaFornecedor) Resposta: DEPENDE (Espaço? Informação? Performance?) (Espaço? Informação? Performance?)

4 Vertical Partitioning Contexto: Cada conta tem associada uma morada e um saldo Dois esquemas possíveis: Conta(keyConta, morada, saldo) Conta(keyConta, morada, saldo) Saldos(keyConta, saldo) Saldos(keyConta, saldo) MoradasContas(keyConta, morada) Se o saldo é acedido/actualizado muito frequentemente então o segundo esquema é melhor

5 Vertical Partitioning - Resumo A Partição Vertical é positiva se: O acesso não se dirige principalmente aos dois atributos O acesso não se dirige principalmente aos dois atributos SELECT morada, saldo FROM conta Os dois atributos têm valores muito extensos Os dois atributos têm valores muito extensos Partitioning vs No Portitioning

6 Vertical Partitioning - Resumo A Partição Vertical melhora a performance quando a quantidade de query’s a aceder apenas a dois atributos é maior que 20%

7 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) Conta(keyConta, saldo, morada, movimento1, movimento2,..., movimento5) Movimentos(keyConta, movimento)

8 Tuning Denormalization Contexto: Cada conta pertence a um cliente, o qual reside numa região Conta(keyConta, saldo, ultimoMovimento, keyCliente) 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 torna- se pesada (3 JOINS) Solução desnormalizada: Conta(keyConta, saldo, ultimoMovimento, keyCliente, região) Conta(keyConta, saldo, ultimoMovimento, keyCliente, região)

9 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

10 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) 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. O plano de execução (escolhido pelo Optimizador) recorre a índices pouco produtivos.

11 Query Rewriting - Índices Muitos dos Optimizadores não usam índices quando existem: Expressões Aritméticas Expressões Aritméticas (WHERE salario/12 >= 400) Expressões com Substrings Expressões com Substrings (WHERE SUBSTR(nome, 1, 1) = ‘P’ Comparações numéricas entre atributos de tipos diferentes Comparações numéricas entre atributos de tipos diferentes Comparações com NULL Comparações com NULL Utilizar índices esparsos nas condições dos JOINS é uma boa ideia.

12 Query Rewriting – DISTINCT’s Eliminar DISTINCTS desnecessários SELECT DISTINCT keyEmpregado 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 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 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. Definir que alcança é transitivo (se R1 alcança R2 e R2 alcança R3 então R1 alcança R3.

13 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 mencionadas no FROM são privilegiadas Todas as tabelas não privilegiadas alcançam pelo menos uma tabela privilegiada Todas as tabelas não privilegiadas alcançam pelo menos uma tabela privilegiada

14 DISTINCT - Exemplos Exemplo 1: SELECT numEmpregado 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 SELECT Estudante.bi FROM Estudante, Empregado, TecDpt FROM Estudante, Empregado, TecDpt WHERE Estudante.mome = Empregado.nome 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

15 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 INSERT INTO Temporaria SELECT * FROM Empregado WHERE salario >= 40000 SELECT bi, localização 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

16 Use of Views A utilização de Views, só por si, não produz incremento de performance CREATE VIEW TecnicoLocalizacao CREATE VIEW TecnicoLocalizacaoAS SELECT bi, Tecnico.departamento, localização FROM Empregado, Tecnico WHERE Empregado.departamento = Tecnico.departamento SELECT localização SELECT localização FROM TecnicoLocalizacao WHERE bi = 12312795 Os Optimizadores expandem as vistas quando são identificados os blocos das querys para serem Optimizados

17 Use of Views A query à TecnicoLocalizacao é traduzida num JOIN SELECT localizacao SELECT localizacao FROM Empregado, Tecnico WHERE Empregado.departamento = Tecnico.departamento AND bi = 12312795

18 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