Introdução e índice com os outros posts desta série.
Vimos nos post sobre Extents que as extensões do banco de dados podem ser de tamanho fixo ou variável. Uma extensão variável é criada com um tamanho inicial mínimo, que vai crescendo à medida que o banco de dados precise de espaço para armazenamento. Uma extensão fixa é criada com o tamanho definido no momento da sua criação, e seu espaço é pré-alocado em disco. O tamanho de uma extensão fixa não pode ser alterado após sua criação.
Uma extensão de tamanho variável é mais rápida para ser criada, e só o ocupa o espaço em disco necessário para armazenar os blocos realmente utilizados. Também é mais fácil acompanhar o crescimento de uma Storage Area quando sua última extensão é variável. O backup do banco de dados utilizando cópia é normalmente mais rápido e menor com extensões variáveis: se o banco de dados possui apenas 500MB de dados, é mais rápido copiar um arquivo de 500MB do que um de 10GB.
Estas vantagens descritas acima são provavelmente responsáveis pelo fato de que praticamente todos os bancos de dados OpenEdge que encontramos usam extensões variáveis. O que não é muito claro para a maioria dos administradores é que extensões variáveis também possuem muitas desvantagens.
Como uma extensão variável é criada com um tamanho inicial muito pequeno, quando há adição de dados ela precisa expandir. Durante este processo o banco de dados solicita ao sistema operacional que aumente o tamanho do arquivo. Esta operação envolve vários acessos a disco e demora. Não é possível controlar o horário que esta expansão irá ocorrer, e na prática, sempre ocorrerá quando algum usuário inserir dados e estiver aguardando a operação concluir. Também não é possível controlar o tamanho do expansão. Este valor é controlado pelo banco de dados, mas são poucos megabytes, no máximo.
Como as extensões variáveis expandem em pedaços muito pequenos, as expansões ocorrem com uma grande freqüência. Desta forma, é possível que o arquivo físico que representa a extensão fique bastante fragmentado se o sistema operacional não puder alocar uma área de disco contínua durante a operação de expansão. Quando há vários bancos de dados no mesmo disco, cada um com suas extensões variáveis crescendo em momentos e proporções diferentes, a chance de fragmentação é maior. Algumas operações de disco, principalmente leitura e gravação sequenciais, tornam-se muito mais lentas quando o nível de fragmentação é maior.
As extensões de tamanho fixo não sofrem dos problemas descritos anteriormente. Uma extensão de tamanho fixo nunca irá expandir, e portanto nunca fará um usuário aguardar este processo. A chance de fragmentação também é menor neste caso porque o arquivo é criado e expandido de uma única vez até o tamanho informado.
Entretanto, como o tamanho é pré-alocado, a criação de uma extensão fixa demora mais. Isto normalmente não representa um problema, porque o horário da criação pode ser controlado pelo DBA, que pode fazê-lo quando há pouca atividade no servidor. Outra característica é que a extensão sempre vai ocupar o mesmo tamanho, digamos 20GB, independente de ter ou não dados. Não penso que isto seja um problema, porque espaço em disco não é uma restrição muito severa atualmente. Além disso, se o banco tiver 20GB de dados, você precisará de 20GB de espaço, quer use extensão fixa ou variável.
O tamanho do backup do banco de dados com extensões fixas também não é um problema, desde que se use o probkup, que é o utilitário de backup do OpenEdge. Entre seus muitos benefícios, ele copia apenas os blocos que realmente contém dados do banco, ignorando os blocos vazios e ainda não utilizados. Outro benefício interessante é o suporte nativo para compressão de backup. E de quebra, ainda funciona com o banco de dados e usuários ativos (online).
Finalmente, como monitorar o espaço usado e disponível nas extensões, se elas tem sempre o mesmo tamanho? O comando prostrct statistics resolve isto facilmente. Para cada área do banco de dados o comando mostra um sumário da utilização de espaço:
Statistics for Area: Schema Area
Files in Area: Schema Area
C:\temp\blog\blog.d1 419430400
C:\temp\blog\blog.d2 419430400
Database Block Usage for Area: Schema Area
Active blocks: 391
Data blocks: 255
Free blocks: 136
Empty blocks: 204409
Total blocks: 204800
Extent blocks: 2
Records/Block: 32
Cluster size: 1
Este banco blog tem, na Schema Area, 204.800 blocos, o que representa exatamente 800MB (bloco de 4KB). O número total de blocos vazios (empty blocks) é 204.409, conforme listagem acima. Quando o número de blocos vazio chegar a 0, acabou o espaço nesta área do banco de dados.
Assinar feeds (RSS)