Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da SQL Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
dê seu feedback
post favorito
Artigo SQL Magazine 73 - Compressão de dados no SQL Server
O artigo aborda o tema de compressão de dados no SQL Server 2005 e o novo recurso disponibilizado pela versão 2008, descrevendo como utilizá-lo e seu benefícios.
SQL Magazine 73
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da SQL Magazine 73
[Artigo já está disponível no Leitor Digital DevMedia®. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da SQL Magazine 73
SQL Server
Compressão de dados no SQL Server
De que trata o artigo:
O artigo aborda o tema de compressão de dados no SQL Server 2005 e o novo recurso disponibilizado pela versão 2008, descrevendo como utilizá-lo e seu benefícios.
Para que serve:
Comprimir os dados armazenados em um banco de dados é bastante útil para se obter ganho de espaço e de desempenho, o que consiste em um dos principais desafios no gerenciamento de bancos de dados com grande volume de dados.
Em que situação o tema é útil:
Em qualquer ambiente onde se deseje economizar espaço de armazenamento do banco de dados, a aplicação de recursos de compressão de dados providos pelo SQL Server 2005 e 2008 se apresenta como uma alternativa interessante para minimizar tais problemas.
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."
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVP
Compressão de dados no SQL Server
De que trata o artigo:
O artigo aborda o tema de compressão de dados no SQL Server 2005 e o novo recurso disponibilizado pela versão 2008, descrevendo como utilizá-lo e seu benefícios.
Para que serve:
Comprimir os dados armazenados em um banco de dados é bastante útil para se obter ganho de espaço e de desempenho, o que consiste em um dos principais desafios no gerenciamento de bancos de dados com grande volume de dados.
Em que situação o tema é útil:
Em qualquer ambiente onde se deseje economizar espaço de armazenamento do banco de dados, a aplicação de recursos de compressão de dados providos pelo SQL Server 2005 e 2008 se apresenta como uma alternativa interessante para minimizar tais problemas.
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."
ATENÇÃO! A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da SQL Magazine DIGITAL ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Artigo SQL Magazine 52 - Estudos de Caso de Projeto de Bancos de Dados para Contas a Pagar e Receber
Artigo da SQL Magazine 26 - SQL Server 2000 fail-over clustering Parte II: Instalação e Configuração
Artigo SQL Magazine 23 - Influenciando o otimizador de consulta baseado em custo do Oracle - Parte 3
Artigo SQL Magazine 20 - Influenciando o otimizador de consulta baseadoem custo do Oracle - Parte II
Você está em:
canal SQL
Publicidade
Vladimir Michel Bacurau Magalhães
Space do autor
Bacharel em Ciência da Computação pela Universidade Federal do Rio Grande do Norte (UFRN), trabalhou durante vários anos como instrutor de informática do Senac/RN e atualmente trabalha como Analista de Banco de Dados da Universidade Potiguar (UnP), além de ser consultor de empresas, com foco na área...
Space do autor
0
0
