Atenção: esse artigo tem uma palestra complementar. Clique e assista!

Quando falamos em bancos de dados, um assunto recorrente é o espaço utilizado para armazená-los. Bancos de dados normalmente ocupam um grande espaço de armazenamento e não é incomum ver Administradores de Bancos de Dados (DBAs) tendo que negociar mais espaço para garantir o crescimento das bases sem problemas. O problema é que, muitas vezes, não há espaço disponível, e é necessário comprar mais discos, o que representa um custo a mais para a empresa. Por mais que o custo por Gigabyte tenha decrescido bastante nos últimos anos, a compra de novos discos sempre representa um custo, e nenhum gestor vai aceitá-lo sem uma boa justificativa, normalmente questionando se não há uma forma de aperfeiçoar o uso do espaço disponível de forma que não seja necessária uma nova compra.

Bancos de dados em geral são bastante passíveis de compressão, visto a natureza repetitiva dos dados armazenados. Outro ponto a considerar é que com a compressão há uma série de outros ganhos que podem ser conseguidos, como o aumento de desempenho devido a menor quantidade de I/O, já que a quantidade de Bytes armazenados será menor, além de um menor espaço utilizado para os backups.

O SQL Server dispõe de uma série de recursos, desde a versão 2005, que permitem fazer melhor uso do espaço em disco, garantido uma razoável economia. Ao longo deste artigo conheceremos um pouco sobre estes recursos de compressão de dados.

Compressão no SQL Server 2005

O SQL Server 2005 já dispunha de alguns recursos para permitir a compressão de dados. Uma delas era a habilidade de comprimir dados utilizando a compressão NTFS do Windows. Para utilizar tal recurso, você deve mover os dados que deseja comprimir para um arquivo de dados secundário (normalmente arquivos .ndf) e configurá-lo como read-only (somente leitura). Você pode até configurar todo o banco de dados como somente leitura, o que permitiria comprimir todos os arquivos de dados e até o arquivo de log, o que normalmente só faz sentido quando se tem apenas uma grande quantidade de dados históricos, pois há a perda de desempenho inerente a qualquer forma de compressão, devido ao processo de compressão/descompressão.

Outra forma de compressão presente na versão 2005, depois de aplicado o Service Pack 2, é a compressão de dados numeric/decimal, chamada de vardecimal. Para utilizar esta forma de compressão, você deve ativá-la no banco de dados e então em cada tabela nas quais deseja utilizar tal recurso. O vardecimal funciona de forma semelhante ao varchar, só que para dados numéricos. Quando você define o tamanho máximo de um campo numeric/decimal, o SQL Server define a quantidade de Bytes que o mesmo irá ocupar, independentemente do valor que é armazenado. Imagine então que você definiu um campo decimal(18,4). O SQL Server definirá um tamanho de 9 Bytes para cada registro deste campo, quer você utilize ele ou não. Caso você armazene neste campo o valor 12.3, que poderia ser armazenado em um campo decimal(3,1) e que ocuparia 5 Bytes, você estaria desperdiçando 4 Bytes por registro. Caso então você ative a compressão através do vardecimal e armazene o mesmo valor, este ocuparia 3 Bytes, ou seja, menos até que o decimal “puro”, representando um ganho de 6 Bytes por registro. Vale lembrar que o vardecimal não é garantia de ganho de espaço. Dependendo da situação, este pode representar até um aumento no espaço utilizado, então podemos recomendar um estudo mais aprofundado do mesmo e uma análise caso a caso antes de utilizar tal recurso.

Para testar a compressão NTFS, criaremos um banco de dados com o nome de Compressao, de acordo com a Listagem 1. Neste banco de dados, criaremos uma tabela no FileGroup Secondary, que depois será modificado para read only. Veja que além do arquivo de dados primário chamado Compressao1.mdf, criamos um arquivo de dados secundário, chamado Compressao2.ndf, que será armazenado na unidade F:.

Listagem 1. Criando o banco de dados de exemplo e testando a compressão NTFS"