Desempenho da Base de Dados

Desempenho Parte I Base de Dados 1 Desempenho da Base de Dados O desempenho de uma base de dados pode ser optimizado e afinado, escolhendo os valores adequados dos parâmetros do SGBD usado, o desenho dos objectos (por exemplo, a estrutura de uma tabela) e a forma de implantação física (por exemplo, e heap, clustering index, partitioning, etc.) Convém notar que não existe nenhuma técnica de afinação que consiga melhorar o desempenho de interrogações se a base de dados estiver mal concebida, no entanto, existem algumas técnicas que podem produzir bons resultados em diferentes situações em que nos deparemos com problemas de desempenho. No módulo anterior (Organização Física) já ficámos com ideia i de como a organização física pode influenciar o desempenho de uma base de dados. Neste módulo vamos tentar dar uma visão integrada das principais questões que influenciam o desempenho de uma base de dados. 2 1

Aspectos relevantes Alguns dos aspectos que devem ser considerados a este nível: Dimensão das páginas Espaço livre Indexação Clustering Partições Localização e alocação dos ficheiros Compressão de dados Inlerleaving data 3 Aspectos relevantes Alguns dos aspectos que devem ser considerados a este nível (cont.): Reorganização Desnormalização (incluindo materialização de vistas) Alojamento em file systems ou directamente sobre partições do disco Estatísticas 4 2

Dimensão das páginas Como vimos no módulo 1, a dimensão da página tem consequências ao nível do número de linhas que nela cabem e, portanto, do número de acessos ao disco que serão necessários para executar determinada interrogação. Mas também tem consequências no desperdício de espaço. Em alguns sistemas é possível escolher (dentro de alguns limites) a dimensão da página para uma dada tabela. Exemplo: Para uma tabela com linhas de dimensão 3000 bytes, num sistema que permita páginas de 4 e 16 KB, que dimensão de página escolher. 4 KB (4096 bytes)? 16KB (16384 bytes)? Tem de se saber qual o overhead associado às páginas e às linhas, mas 5 Dimensão das páginas Supondo um overhead de página de 96 bytes e por linha de 6 bytes, teremos os seguintes casos a considerar: 1. Páginas de 4KB 4096 96 = 4000 bytes disponíveis 4000 div (3006) = 1 linha por página 994 bytes de desperdício dí por página em 4 KB por página (24%) 2. Páginas de 16 KB 16384-96 = 16288 bytes disponíveis 16288 div (3006) = 5 páginas por página 16288 5*3006 = 16288 15030 = 1258 bytes de desperdício em 16KB por página (7,7%) e, em média, apenas metade da última página estará preenchida. Logo 2,5*3006 = 7515 bytes de desperdício em toda a tabela (em média) Do ponto de vista de desperdício, se a tabela for pequena a diferença não é significativa, podendo, mesmo a melhor solução ser a página de 4KB (por exemplo, se a página tiver menos de 5 linhas). Se a tabela tiver número significativo de linhas, a melhor solução seria a página de 16KB. Do ponto de vista de número de operações de I/O, verifica-se situação semelhante. Se a tabela for pequena, a dimensão da página não é muito importante, podendo até ser preferível a página de 4KB (por exemplo, se a tabela apenas tiver uma linha), mas se a tabela tiver muitas linhas, a página de 16KB é preferível por, potencialmente, dividir por 5 o número de operações de I/O necessário para aceder a informação da tabela (sobretudo quando se faz acesso sequencial ou por gama de valores da chave de um clustered index) 6 3

Espaço livre Como vimos no módulo 1, a escolha do fill factor associado às folhas dos índices tem influência no desempenho. Em geral a reserva de eapaço livre tem influência no desempenho, devido às seguintes situações: 1.Quando uma folha está totalmente preenchida e se tem de inserir um novo registo (por exemplo, nas folhas de um clustered index), tem de se realizar um page split que toma tempo de CPU e de I/O e pode obrigar à propagação para níveis superiores de um índice (mais tempo de CPU e de I/O) 2.Os acessos para leitura realizados por gama de valores podem ficar mais lentos à medida que vai havendo page splits, pois as páginas consecutivas deixam de estar contíguas no disco 3.Se não existir espaço livre suficiente, as colunas de dimensão variável podem obrigar ao uso de zonas de overflow. Alguns sistemas permitem manter uma página após um determinado número de páginas preenchidas (FREEPAGE) e outros (como o Slq Server) permitem manter uma determinada percentagem de cada página livre (PCTFREE). Genericamente, fala-se em fill factor quando alguma destas possibilidades existe. Factores a ter em conta na decisão: Frequência de inserções e actualizações, volume de acessos sequências (ou por gama de valores) por oposição aos acessos aleatórios, impacto nos acessos nonclustered, probabilidade de page-splits encadeamento e migração de linhas. 7 Indexação Como vimos no módulo 1, em geral, os índices podem ter impacto positivo nos acessos para leitura, mas nem sempre isso acontece e, às vezes, os ganhos que deles advêm não são compensados pelos impactos negativos que têm em termos de ocupação de espaço e de desempenho na inserções, remoções e actualizações. Em geral devemos adoptar índices que permitam melhorar o desempenho de várias interrogações, mas é razoável fazê-lo para se melhorar o desempenho de uma interrogação se ela tirar um grande impacto no sistema (por exemplo, é executada frequentemente). A definição de índices nunca é definitiva. É necessário monitorizar o funcionamento do sistema para o ir afinando. A indexação não é, em geral, adequada nas seguintes situações: Tabelas muito pequenas Sobre colunas variáveis, se o SGBD considerar no índice sempre a dimensão máxima Sobre tabelas que apenas são acedidas com operadores sequenciais (table scan) O número de entradas por página de índice (ordem, fun out ou factor de ramificação) é pequeno. 8 4

Indexação A indexação é particularmente útil nas seguintes situações 1. Localizar um linha, dados os valores de determinadas colunas 2. Realizar acessos por gama de valores de uma coluna 3. Tornar os joins mais eficientes (se existirem índices sobre as colunas de join) 4. Relacionar dados entre tabelas diferentes (chaves estrangeiras) 5. Agregação de dados (se existire índices sobre as coluna em group by ) 6. Ordenar os dados para satisfazer uma interrogação (ex: SELECT DISCTINCT...) 9 Indexação Covering indexes Na interrogação Select A,B from T Where C = 20, um índice sobre a coluna C pode aumentar o desempenho, mas essa melhoria pode ser aumentada se criarmos um índice sobre as colunas (C,B,A), pois, nesse caso não é necessário aceder aos dados, bastando o índice para responder à interrogação (fala-se em index overloading). Com um índice sobre (C,B,A), também podemos melhorar o desempenho em interrogações que envolvam na cláusula WHERE a coluna C, as colunas C e B e as colunas C e B e A, mas se o objectivo é apenas melhorar o desempenho da interrogação do exemplo anterior, gastamos espaço desnecessário nos níveis superiores do índice. No Sql Server, em alternativa, podemos usar um índice sobre C com A e B como included columns. 10 5

Indexação Filtered ndexes No SQl Server, os filtered indexes permitem ter índices específicos sobre conjuntos diferentes de registos da mesma tabela. Uma das possibilidades de utilização deste índice é indexar apenas a zona da tabela que é mais frequentemente acedida. Por exemplo, num sistema de gestão de alunos, poderia fazer sentido criar índices apenas sobre a gama de números de aluno mais recentes, dado que são estes que, maioritariamente, correspondem aos alunos activos e, portanto, que figurarão em mais interrogações. Quando os alunos mais antigos aparecerem em interrogações, a resposta do sistema não tirará partido dos índices. Outra possibilidade é criar índices unique sobre colunas (por exemplo, C) que admitam valores null. Neste caso criar-se-ia o filtro com uma cláusula WHERE C is NOT NULL 11 Indexação Filtered ndexes Vantagens adicionais deste tipo de índices: facilidade de manutenção (manutenção separada de vários índices menores) Índices menores, portanto, mais rápidos Estatísticas mais correctas quando obtidas por amostragem porque todas as amostras são relativas à zona coberta pelo filtro e, portanto, a que será objecto das interrogações para a as quais ele se destina. Se incluíssemos toda a tabela, estaríamos a influenciar as estatísticas com dados que nunca serão acedidos usando o filtro. Menos espaço, dado que podemos excluir do índice alguns dos dados 12 6

Indexação Indexação Clustering Consiste na manutenção dos tados da tabela ordenados por ordem de um conjunto de colunas, normalmente, conseguido, como vimos, à custa de C um clustered index.(no máximo, um). O clustering facilita acessos sequências pela ordem das colunas sobre as quais é definido, sendo particularmente útil nos acessos por gama de valores destas colunas. Mas coloca um problema na inserção de novos valores, uma vez formado o cluster, podendo ocasionar page splits (*) (). A definição de um fill factor inferior a 100% pode ser necessária, se a tabela for sujeita a muitas inserções depois de criado o índice. (*) Em alguma literatura são referidos dois tipos de page split: o normal que corresponde ao que vimos no módulo 1 e o monotónico que corresponde basicamente à inserção de uma nova página (por exemplo, no fim de um heap). Neste texto apenas consideramos page split o primeiro caso. 13 Indexação Clustering Na criação de um clustering index deve ter-se em conta o seguinte: 1. Apenas pode haver um clustering index por tabela 2. Em alguns sistemas, a chave do clustered index aparece nas páginas dos índices non clustered (locator no SQL Server), contribuindo para o gasto de espaço e consequentemente, menos eficiência desses índices por resultar em factores de ramificação menores. Deve, portanto, tentar-se que, em especial, nos clusterd indexes, as chaves sejam de pequenas dimensões. A situação pode ser piorada para índices non clustered e non unique, pois, nesse caso, as entradas do índice nos níveis superiores também usam a chave do índice clustered como um uniquifier 3. Deve evitar-se a definição de índices clustered (em especial) cujas chaves sejam sujeitas a alterações frequentes (essas alterações obrigam a recalcular o índice). 4. Os índices clusterd devem, preferencialmente, ser calculados depois da tabela estar preenchida e, de preferência, não deveriam ser sujeitos a inserções depois deste momento. 5. Quando existem índices non clustered sobre um clusterd index, deve criar-se primeiro o clustered index (depois de preenchida a tabela) e depois os índices non clustered. De outro modo, este terão de ser recalculados quando se criar o clustered index. 14 7

Indexação Clustering Na criação de um clustering index deve ter-se em conta o seguinte: 6. Se sobre um índice clustered se realizarem inserções posteriores com valores da chave que sejam essencialmente aleatórios (ex: GUID), a probabilidade de page splits aumenta e distribui-se por todo o índice, contribuindo para o aumente da fragmenteção. Isto contrasta com a situação em que os valores inseridos são sempre na sequência ordenada dos últimos existentes no índice, onde o page split ocorre sempre na última página. Logo, o início do cluster mantém-se como inicialmente criado. Claro que, se fizermos muitas inserções em alturas do tempo distantes umas das outras,, a parte final do cluster também ficará muito fragmentada (NewSequentialID() no Sql Server). 7. Os page-splits contribuem para a fragmentação do cluster index, pelo que, pode ser necessário reorganizar o índice posteriormente. 8. De notar que alguns sistemas evitam os page-splits criando os novos registos numa zona de overflow, mas a consequência é que esses dados já não estão clustered e, portanto, os acessos a eles serão mais lentos 15 Indexação Boas práticas Explorar as possibilidades de uso de covering indexes e filtered indexes. Não se devem criar índices sem qualquer critério, na tentativa de que, tentando, se conseguirá melhorar o desempenho. Devem usar-se estatísticas ferramentas que nos auxiliem a tomas decisões sobre os índices mais promissores para melhoramento do desempenho. As chaves estrangeiras são boas candidatas para chaves de índices, dado serem frequentes os acessos a tabelas por essas chaves. Exemplo: Factura(NumFact,...) Item (NumItem, NumFact[FK],...) A existência de um índice sobre NumFact na tabela Item permite melhorar o desempenho na execução de interrogações do tipo SELECT * FROM Item WHERE NumFact = 1111 Para chaves de índices com mais do que uma coluna, devem (se possível) colocar-se primeiro as colunas mais selectivas, especialmente se elas aparecerem em predicados LIKE nas cláusulas WHERE das interrogações que se pretende optimizar. 16 8

Indexação Boas práticas Para operações de JOIN com muitos dados, um clustered index sobre as colunas de join de ambas as tabelas pode ter resultados excelentes, dado que poderá permitir realizar a operação com apenas um percurso em cada tabela (o operador merge join que veremos mais tarde trabalha sobre versões das tabelas ordenadas pelas colunas de join). Exemplo: Se a tabela T1 com coluna C1 tiver os valores 3, 1, 2 e a tabela T2 com a coluna C2 tiver os valores 2, 3, 0, se não ordenarmos os dados de ambas as tabelas, teremos de fazer múltiplos percursos numa das tabelas se se pretender realizar o join de T1 e T2 com a condição T1.C1 = T2.C2, mas se ordenarmos ambas as tabelas, basta fazer um percurso em cada uma delas. 1, 2, 3 0, 2, 3 ^ ^ ^ ^ ^ ^ (2,2) ^ ^ (3,3) 17 Indexação Boas práticas Para tabelas que sejam sujeitas a muitas alterações sobre as colunas do índice e muitas inserções, convém que os índices usem um fill factor apropriado (80 90%). Colunas usadas frequentemente para acesso a gamas de valores são boas candidatas para chave de um clustered index. É adequado que todas as criações, alterações e remoções de índices sejam testadas num ambiente de teste com a mesma estrutura da base de dados de produção e volume de dados e de acessos tão semelhante quanto possível, antes de serem concretizadas no sistema de produção 18 9

Partições Dependendo do SGBD utilizado, podemos encontrar várias formas de fazer corresponder as tabelas a unidades de alocação em disco ( ficheiros ). 1. Em alguns sistemas, a forma standard consiste em criar cada tabela num ficheiro usado apenas para ela. 2. Em alguns sistemas é possível colocar uma tabela em multíplos ficheiros (caso do Sql Server, com partições). Esta situação é conhecida como table partitioning. 3. Em alguns sistemas (caso do Sql Server) é possível colocar múltiplas tabelas num único ficheiro. (Recordar o que foi visto no módulo 1 sobre filegrpoups e partições no Sql Server) Como vimos no módulo 1, as partições realizadas sobre tabelas são uma forma de melhorar o desempenho por facilitarem a exploração do paralelismo de I/O e de CPU, Mas também pode ter efeito positivo na facilidade de manutenção (incluindo backups). Também podem contribuir para melhorar o desempenho em geral, por permitirem reduzir os espaços de procura em muitas interrogações. Por exemplo, num heap com 1000 alunos, a procura de um aluno teria, no pior caso de percorrer todo o heap. Com 4 partições de 250 alunos, apenas teríamos de percorrer, no prior caso 250 registos. 19 Localização e alocação dos ficheiros A localização física dos dados pode ter impactos enormes no desempenho. Não esquecer que as unidades de memória secundária mais comum (discos e tapes) têm partes mecânicas móveis o que as torna lentas relativamente às restantes componentes existentes nu SGBD. A colocação de toda a informação na mesma unidade de discos, para além de dificultar acções de manutenção (por exemplo backup e restore) tem como consequência aumentar a dimensão média das filas de acesso a disco, impedindo que se tire todo o proveito do potencial do servidor (por exemplo, multiprocessamento). Por outro lado o desempenho também se degrada porque haverá mais movimentos das cabeças do disco do que haveria se se utilizassem, de forma adequada, várias unidades de disco. É necessário ter noção dos padrões de acesso a cada porção dos dados para tomar decisões criteriosas, pois mais unidades de discos correspondem a maiores custos. A utilização dos níveis de RAID adequados é um exercício nesta linha, mas não permite um nível de controlo muito grande. 20 10

Localização e alocação dos ficheiros Existem, no entanto, algumas decisões genéricas que se podem avançar : 1. É bom colocar os ficheiros de índices em discos diferentes daqueles onde são colocados os dados. Por exemplo, o num clustered index, pouco fragmentado, os dados tendem a ficar em páginas consecutivas, mas numa zona diferente das do nível superior do índice, o que acarreta mais movimentos das cabeças no disco. A inserção de um registo num clustered index que obrigue a um page split é um bom exemplo desta situação. 2. Pode generalizar-se, dizendo que existindo tabelas ou índices que sejam acedidos frequentemente em conjunto, é vantajoso do ponto de vista de desempenho que eles se situem em discos diferentes. 3. Um caso especial é o ficheiro Log Transaccional que, por ter u padrão de acesso sobretudo sequencial e por ser muito usado por todas as transacções na mesma base de dados, por um lado, e, por outro, por exigir requisitos de robustez adicionais deve ser colocado em unidades reservadas. 21 Localização e alocação dos ficheiros Existem, no entanto, algumas decisões genéricas que se podem avançar : 4. É necessário ter cuidados especiais na formatação dos discos para serem usados pelo SGBD, devendo garantir-se o alinhamento adequado entre as unidades de alocação dos discos e as pistas (uma unidade de alocação não deve iniciar-se numa pista e terminar noutra) e entre as páginas e as unidades de alocação no disco (uma página não deve iniciar-se numa unidade de alocação e terminar noutra). Por exemplo, no Sql Server, dado que a alocação de espaço é feita em grupos de 8 páginas de 8KB, na melhor forma de alinhamento, os discos para Sql Server deveriam estar formatados para unidades de alocação de 64KB, de forma a alinharem completamente com um page extent. 22 11

Compressão de dados A compressão de dados pode contribuir para diminuir a necessidade de espaço, mas, também pode contribuir para melhorar o desempenho ao contribuir para reduzir o número de operações de I/O. Por exemplo, em Sql Server, uma tabela cujas linhas ocupem 5000 byte obriga a que cada página apenas contenha uma linha (logo mais desperdício de espaço e, potencialmente, mais operações de I/O nos acessos à tabela. Se, dependendo dos dados, a compressão permitir colocar duas linhas por página já teremos um ganho significativo, quer do ponto de vista de operações de I/O, quer do ponto de vista de desperdício de espaço. No Sql Server, a compressão também pode, potencialmente, reduzir o número vezes em que colunas variáveis necessitam de ser colocadas em páginas de overflow. É, no entanto, necessário ter em conta que a compressão tem um preço associado. Sempre que se acede à página para leitura é necessário descomprimir os dados e sempre que se escreve na página é necessário comprimir os dados. 23 Inlerleaving data Em alguns sistemas (por exemplo Oracle) é possível intercalar no mesmo ficheiro (cluster), o que é vantajoso se elas forem sujeitas a operações de junção frequentes. Exemplo: Professor(NumProf, NomePRof) 1111 Nome1111 2222 Nome2222 Discilina(CodDisc, DesigDisc, ProfReg[FK]) D1 Des1 1111 D2 Des2 2222 D3 Des3 1111 Poderiam ser intercaladas assim: 1111 Nome1111 D1 Des1 D3 Des3 2222 Nome2222 D2 Des2 O Sql Server não suporta este tipo de organização 24 12

Reorganização Por muito bom que tenha sido o desenho da base de dados e as técnicas de optimização utilizadas, não é possível garantir que o sistema exibirá sempre a mesma qualidade em termos de desempenho. Contribuem para a degradação do desempenho durante a exploração do sistema: Dados unclustered (ou porque à partida não se criou o cluster, ou porque o SGBD usou zonas de overflow para evitar as situações de page-split Fragmentação, por exemplo, devida a excessivo número de page-splits, ou porque se fez excessivo uso de zonas de overflow. Row chaining Uma actualização de uma linha leva a o SGBD a transferir parte dela para outra zona onde exista espaço (por exemplo, que acontece com o SQL Server quando uma coluna variável cresce e deixa de caber na página. Uma ocorrência do género (designada row migration) verifica-se quando toda a linha tem de migrar para uma nova zona e se deixa um apontador na página anterior para a nova localização da linha (não se verifica no Sql Server). Page -Splits levaram a que duas páginas logicamente contíguas ficaram fisicamente distantes. File extents ocorre quando o aumento do espaço associado a uma tabela é realizado à custa de um ficheiro diferente do que estava a ser usado originalmente. 25 Reorganização Estes problemas podem ser resolvidos reorganizando os dados. A maneira mais fácil de o fazer é fazer ma cópia dos dados actuais dos objectos envolvidos, refazer a estrutura desses objectos com os novos requisitos e importar para ela os dados da cópia feita. Mas, em muitos casos não é necessário tanto esforço, havendo tipicamente suporte para reorganizações localizadas (por exemplo reorganizar um índice) 26 13

Desnormalização Nos sistemas operacionais a regra é normalizar. Porém, em alguns casos, pode ser necessário desnormalizar para se poder garantir os desempenhos adequados em algumas interrogações. Em geral, podemos desnormalizar para atender às seguintes situações: Quando o custo de um join é proibitivo, mas ele não ocorre com frequência, utilizam-se pré-join tables. Cria-se uma tabela que não contenha colunas repetidas e que apenas tenham a informação necessária, sendo essa tabela periodicamente preenchida com os dados das tabelas base. Cuidado porque se trata de uma replicação assíncrona. As vistas materializadas podem ser usadas para resolve este problema do sincronismo. Um caso especial é o caso de informação para relatórios, dado que estes normalmente são baseados em informação histórica e são produzidos em momentos específicos (report tables). Quando é necessário suportar o funcionamento de vários componentes (aplicações) sobre os mesmos dados pode ser necessário replicar algumas tabelas (mirror tables) 27 Desnormalização Em geral, podemos desnormalizar para atender às seguintes situações (cont.): Na mesma linha, pode ser vantajoso criar réplicas de partes das tabelas e não de todas as tabelas com partições verticais ou horizontais (page-split) Uma situação especial é o fraccionamento de colunas de grande dimensão em várias colunas de dimensão menos Combinação de tabelas diferentes numa tabela quando entre elas existe uma relação de 1:1 (e alguns casos aplica-se mesmo quando essa relação é de 1:N) Acrescentar colunas de uma tabela T2 a uma tabela T1 sempre que seja frequente usar-se a tabela T1 em conjunto com essas colunas da tabela T2. Grupos repetitivos normalizar grupos repetitivos à 1NF usando várias linhas (não normalizar à 2NF) Persistir dados calculados se o seu cálculo for proibitivo Usar Speed up tables para lidar com hierarquias de associações 1:N 28 14

Alojamento em file systems ou directamente sobre partições do disco Alguns SGBDs implantam as suas bases de dados sobre discos sem qualquer estrutura de file system; outros (como o Sql Server) usam o file system fornecido pelo sistema operativo. Em princípio, o modo preferido é o primeiro, pois a existência de cache ao nível do file system pode ter consequências negativas na consistência de dados O que acontece se a seguir a um checkpoint que tenha sido executado com sucesso do ponto de vista do SGBD a cache do file system atrasar o envio dos dados para o disco e, entretanto ocorrer uma fala do sistema? Obviamente, os SGBDs que suportam as suas bases de dados sobre o file system terão de lidar com essa dificuldade de alguma forma. Poder-se-ia pensar que um segundo nível de cache (ao nível do file system) teria consequências positivas no desempenho, mas, em geral, isso não acontece, podendo a sua existência contribuir mesmo para a degradação do desempenho. 29 Estatísticas Para lidarmos com os problemas vistos anteriormente, é necessário termos ferramentas que nos ajudem nessa tarefa. Um instrumento importante são as estatísticas que o SGBD pode manter. Elas contribuem um pouco para a degradação do desempenho, mas são extremamente úteis para colhermos informação que nos ajude em algumas tarefas (por exemplo, saber se temos ou não de criar um determinado índice). Em geral os SGBD possuem um conjunto de comandos que nos permitem obter estes dados estatísticos. Por exemplo, no Sql Server existe um conjunto de Dynamic Management Viewes que são vistas virtuais que nos permitem aceder a alguma desta informação. A Oracle tem instrumento idêntico (Dynamic Performance Tables). No Sql Server há ainda a salientar nesta linha o Sql profiler e o Sql Server Tunning Advisor 30 15

Bibliografia Database Administration the Complete Guide to Practices and Procedures (cap. 11), Craig S. Mullins, Addison Wesley, 2002 Sql Server 2008 Administration in Action (cap. 13), Rod Colledge, Manning Publications, 2010 31 16