Tunning de SQL
Tunning de SQL
O que é tunning de BD ?
• Ajustes que fazem a aplicação de BD executar mais rapidamente
• “Rapidamente” implica – maior throughput ( vazão) – menor tempo de resposta
O que pode ser feito ?
• Mudar – a forma de construção de aplicações– estruturas de dados– parâmetros do BD– Configuração do sistema operacional– Hardware
• Ênfase no conhecimento da aplicação e de sistemas computacionais
Princípios básicos
• Tunning é livre de modelos matemáticos ( facilidade )
• Conhecimento necessário ( difícil )– Aplicação– Sw do DB– Sistema operacional– Aspectos físicos do hw
Princípios básicos• Nunca usar funções de agregação quando o
tempo de transação é crítico– Esse tipo de função recupera grandes quantias de
informação, bloqueando outras consultas– Se função for aplicável a poucas tuplas
selecionadas por índice, isso pode não se aplicar
Regra: Não busque grandes qtde de dados em ambientes de grande concorrência
5 princípios básicos
1. Pense globalmente, corrija localmente
2. Balanceamento evita gargalos
3. Inicialização é mais cara que execução
4. Delegue ao servidor o que é de servidor
5. Prepare-se para mudanças e escolhas
Princípio 1 • Medir corretamente,
• na quantidade correta,
• Para chegar ao resultado correto
Princípio 1 • Tunning global:
1. Estatísticas de hardware1. Utilização da CPU
2. Atividade de E/S
3. Paginação, etc.
– Nota: observar valores altos e tomar ação- Ex. alta atividade de disco
– comprar mais hw para distribuir ( mais discos)
Princípio 1 • Ex. alta atividade de disco
–Pode ser inapropriado-> CAUSA- Alta busca de consulta em tabelas sem
índices - Log compartilha um disco com dados
acessados muito frequentemente (OFA)
- DBA não dimensionou buffer do BD ( mais E/S)
Princípio 1 • Ex. alta atividade de disco
–Medir tempo de execução de uma consulta- Se for pouco frequente : não perca tempo
para fazer esse ajuste
Princípio 1
• Questões de distribuição dos dados X acessos
1. Criação de índices
2. Logs que concorrem em discos com muitos dados acessados
- pode ser mais efetivos que comprar mais hw
Princípio 1 • DBA deve fazer seu papel
Ex. Alta atividade no disco pois o DBA esqueceu de incrementar o tamanho do buffer da DB
( mais acessos de disco)
• Medição de tempo de uma consulta específica– se o tempo é alto, REDUZIR ?
• Sse é executada frequentemente
Reduzir tempo de uma query somente se ela é usada com freqüência
Princípio 2
• “Dificilmente um sistema está lento porque TODOS seus componentes estão saturados”
• Uma parte do sistema limita a performance geral ( “gargalo”)
Princípio 2
• Balanceamento evita gargalos
• Uso de particionamento – Técnica para redução da carga em um
componente do sistema– Divisão da carga entre mais recursos OU– Gerenciamento de carga por intervalos de
tempo
Princípio 2: Particionamento
• Um banco tem N setores. Os clientes acessam suas contas de casa.
• Se o sistema central fica sobrecarregado :– dispor os dados das contas de clientes que acessam de
casa num subsistema
– Forma de particionamento de espaço ( recursos físicos)
Princípio 2• Problemas de conflito de bloqueio
– Envolve poucos recursos– Lista de páginas de buffers não usados no BD
sofrem concorrência/ conflito antes dos arquivos de dados
– Solução: dividir tais recursos em partes para diminuir conflitos em cada bloqueio
Princípio 2
• Ex. das listas : criar uma lista com ponteiros para apontar porções de páginas livres
• Uma thread bloqueia a lista em uso e um força o acesso a uma outra lista, randômica.
• Particionamento lógico ( de recursos “bloqueáveis”
Princípio 2
• Sistemas de poucas transações longas/curtas concorrendo nos mesmo dados sempre tem desempenho ruim devido a conflitos de bloqueio e de recursos.
• Deadlocks: Forçam transações longas a abortarem >> bloquear as curtas
• Transações longas usam maiores porções de pool de buffers >> atrasando as t. curtas
Princípio 2• Solução : executar transação longa qdo há
atividade de pequenas transações e e serializar as longas ( particionamento no tempo)
• Solução 2: permitir t. longas (read-only) submeter dados antigos em hw separado.
( particionamento no espaço)
Princípio 3:Inicialização é mais cara que execução
• Ex. operação de leitura– Início é caro, depois o disco provê dados em alta
velocidade– Leitura de segmento de 64 kbytes em um único
disco é cerca de 2 X mais barata que 512 bytes de uma trilha
– Tabelas lidas devem ser dispostas consecutivamente em disco
– Particionamento vertical : bom para consultas de poucas colunas em tabelas com centenas de colunas
Fragmentação/ Particionamento de dados
• Sob a perspectiva de esquemas,• Maior sentido em particionar subconjuntos
da tabela do que toda a tabela• Ao fragmentar, execução paralela de uma
única consulta ( DIV : subconsultas em fragmentos)
• Aumenta o nível de concorrência• Maior throughput( vazão)
Desvantagens da Fragmentação/ Particionamento de dados
• Aplicativos tem requisitos conflitantes q impedem a decomposição da relação em fragmentos mutuamente exclusivos
• Visões definidas sobre mais de um fragmento • Controle sobre semântica de dados ( controle de
integridade)
>> degrada desempenho
Alternativas de Fragmentação
• Vertical
• Horizontal
Fragmentação Horizontal ( tuplas)
Paris31.000ManutençãoP4
NY240.000CAD/CAMP3
NY20.000Desenv. BDP2
Montreal15.000INSTRUMENTACAOP1
LOCORÇAMPNOMEPNO
NY20.000Desenv. BDP2
Montreal15.000INSTRUMENTACAO
P1
LOCORÇAMPNOMEPNO
Paris31.000ManutençãoP4
NY240.000CAD/CAMP3
LOCORÇAMPNOMEPNO
Fragmentação Vertical ( atributos)
Paris31.000ManutençãoP4
NY240.000CAD/CAMP3
NY20.000Desenv. BDP2
Montreal15.000INSTRUMENTACAOP1
LOCORÇAMPNOMEPNO
31.000P4
240.000P3
20.000P2
15.000P1
ORÇAMPNO
ParisManutenção
NYCAD/CAM
NYDesenv. BD
MontrealINSTRUMENTACAO
LOCPNOME