.png)
Fala galera, tudo bem? O post de hoje é para trazer algumas opções de solução para um problema que pode ocorrer quando o cliente usa o SQL Server Express.
A edição Express do SQL Server é gratuita e por isso tem várias limitações, vale destacar que muitos projetos rodam nessa edição pois apesar das limitações ela funciona muito bem em vários cenários pequenos.
Algumas das limitações que se destacam são: utiliza no máximo 1GB de memória (com isso se você tiver muitos usuários simultâneos pode sofrer bastante lentidão, mas até uns 10 não tendo cargas muito grandes de dados você consegue usar bem), não tem o SQL Agent (portanto não é possível "nativamente" criar jobs para automatizar rotinas) e uma base de dados pode ter no máximo 10GB de tamanho (da versão 2008 para trás o limite é de 4GB apenas, sim tem empresas que usam ainda SQLs bem antigos).
O que vamos ver hoje é sobre essa última limitação que falei acima, imagine o cenário:
A empresa trabalhando normal com o sistema, o banco de dados esta em um SQL Server Express, são 15h e os usuários começam a receber mensagem de erro ao tentar inserir um registro novo no sistema dizendo que o arquivo de dados esta cheio. Pânico total, ninguém consegue mais emitir as notas, gerar as movimentações, resumindo, o sistema para de funcionar em pleno horário de pico.
Claro que se você ou sua equipe administra esse ambiente vai ter percebido antes que isso estaria para acontecer e já teria tomado alguma ação (eu espero, rs), mas em alguns casos, empresas que você ainda não atua podem solicitar uma ajuda com o problema já em andamento. Nesse caso, o que você como DBA pode fazer para ajudar de maneira rápida?
1) Eliminar índices
Um índice consome espaço dentro do banco de dados, veja a imagem abaixo
1 - Tamanho total da base de dados = 10GB
2 - Coluna que indica o tamanho dos índices em uma tabela
3 - Mostra que a tabela TAB03 tem 1.1GB de índices
* Para gerar um report igual a esse acima, clique com o botão direito sobre a base e selecione a opção de 'Reports > Standard > Disk usage by Table'
Portanto, uma vez que você identifica que existem índices consumindo espaço dentro do banco, você como DBA pode excluir algum índice ou alguns dependendo de quanto consomem para que o cliente possa voltar a usar o sistema imediatamente. Claro que o índice esta ali por um motivo (que é melhorar o desempenho de alguns comandos no banco de dados) então no momento que você excluir esses comandos voltarão a ficar mais lentos, mas leve em consideração que a empresa esta sem conseguir usar o sistema, melhor que eles usem com alguns pontos mais lentos do que não consigam usar. Gere o script do índice para recriar posteriormente e exclua o mesmo da base.
Identificado o índice execute o DROP dele.
Problema resolvido momentaneamente, ao conferir novamente o tamanho das tabelas e tamanho total do arquivo de dados podemos ver a diferença, foram liberados 1.1GB de espaço dentro da base.
2) Utilizar a compressão de dados
Sabe quando você pega algum arquivo ou uma pasta no seu computador e comprime tudo usando um "winrar" ou "7zip" ? Você pode fazer algo parecido dentro do SQL Server, é possível usar a compressão de dados para que uma tabela diminua o espaço que ela consome dentro do banco. Vamos continuar usando o mesmo exemplo acima, já reduzimos 1GB nela, vamos diminuir mais agora com a compressão. Usaremos a TAB01 como exemplo.
Note que ela tem 9.2 milhões de linhas e consome atualmente 1.2GB de espaço dentro do banco.
A procedure sp_estimate_data_compression_savings te da a possibilidade de estimar quanto a aplicação da compressão em uma tabela vai reduzir o tamanho dela, é uma excelente visão do ganho que você vai ter sem ter que de fato aplicar direto a compressão.
Existem 2 tipos de compressão de dados:
ROW: Mais simplificado, não usa algoritmo de compressão e a variação de compressão é de acordo com a configuração da coluna.
PAGE: Mais completa, soma a compactação do tipo ROW e compactação no cabeçalho das páginas permitindo que mais dados caibam dentro de uma mesma página.
No exemplo abaixo executei a proc para ver a estimativa de compressão dos dados da TAB01 com o tipo PAGE, na coluna size_with_compression temos o tamanho atual consumido e na coluna size_with_requested a projeção de quanto irá ficar.
Estão retornando duas linhas pois a primeira é da tabela original e a segunda é de um índice que existe nela, nesse caso irá comprimir inclusive do índice.
Podemos ver que nesse exemplo, a tabela tem a projeção de cair de 1.2GB para cerca de 350MB de tamanho, vamos aplicar a compressão por pagina nesse caso.
Podemos ver a diferença real, perceba que a tabela continua com o mesmo número de linhas, 9.2 milhões, porém o tamanho consumido de espaço dentro da base diminuiu drasticamente.
Obs: a compressão de dados ajuda na economia de espaço em disco e ajuda também na leitura de dados, porém gera um consumo extra para escrever dados novos, lembre que com uma tabela com compressão, ao inserir uma linha nova não terá apenas que armazenar o dado, será necessário também comprimir ele automaticamente, portanto, use essa funcionalidade com cautela.
Essas duas alternativas resolvem o problema do cliente de maneira rápida, mas é muito importante que você após fazer isso, já informe o cliente que ele precisará comprar uma licença do SQL Server pois essa foi uma ação paliativa para voltar a usar o sistema rapidamente, com o tempo o banco irá crescer novamente e chegará ao limite.
Gostou do post? Compartilha com seus colegas que querem ser um DBA SQL Server!
Nos acompanhe em nossas redes sociais!
Grupo VIP Telegram: DBA On boarding
Youtube(vídeos novos todas as quartas): DBA On boarding
Face & Instagram(conteúdo diário): DBA On boarding
Até a próxima, tchau!