sqlserver
Tecnologia

Filegroup no SQL Server

Vamos falar sobre um assunto relativamente simples, porém, que ainda gera muitas dúvidas conceituais e de aplicabilidade, o destemido FILEGROUP.

O que é, por que e quando utilizar?

Conceitualmente, o FILEGROPU (FG) é uma estrutura lógica que mapeia o banco de dados e seus objetos relacionando com os Data Files (Arquivos de Dados MDF, NDFs).

Segundo o MSDN: “Every database has a primary filegroup. This filegroup contains the primary data file and any secondary files that are not put into other filegroups. User-defined filegroups can be created to group data files together for administrative, data allocation, and placement purposes.”

Como assim? Quando criamos o FG, informamos quais arquivos de dados estarão associados a ele, certo? Por exemplo, o Filegroup FG_TableBIG está associado aos arquivos de dados  D:\bdteste02.ndf e F:\bdteste03.ndf.

Mas para que serve o FILEGROUP na prática? Quando criamos um objeto, seja ele uma Table, Procedure, Index etc, ele é associado explicitamente ou implicitamente a um FILEGROUP que determina em quais Data Files aquele objeto estará fisicamente alocado.

Por exemplo, usando o case anterior, o Filegroup FG_TableBIG tem dois Data Files D:\bdteste02.ndf e F:\bdteste03.ndf, certo? Ao criarmos a tabela dbo.Cliente associando ao FG_TableBIG, estaremos dizendo que este objeto estará alocado nos arquivos D:\bdteste02.ndf e F:\bdteste03.ndf, ou seja, toda informação inserida nesta tabela estará fisicamente nesses diretórios.

A distribuição dos dados entre os arquivos é realizada pela Engine do SQL Server com base no algorítimo de Proportional Fill, que é assunto para outro artigo, mas podemos adiantar que esse algorítimo busca utilizar os dois arquivos proporcionalmente iguais, dividindo a carga de I/O e quantidade ocupada, porém, para isso acontecer tem uma série de observações referente à configuração dos Data Files, que será abordado mais para frente.

A imagem a seguir exemplifica a associação entre FILEGROUP, Data Files e Objetos:

filegoup

Por padrão, todo bando de dados possui o FILEGROUP PRIMARY e também por padrão, todos os objetos de sistema estão mapeados nele. No SQL Server 2014 até 32,767 FILEGROUP podem ser criado por banco de dados.

Por default, o Data File MDF está associado ao FILEGROUP PRIMARY e, com isso, é uma boa prática criar um novo FG associando a um Data File NDF para separação de objetivos de sistemas e usuários.

Vamos para a prática:

– Criando bando de dados com mais de um data file e associando a outro Filegroup:

filegroup 1

Podemos observar que existem dois FILEGROUP PRIMARY e FG_TableBIG e cada um contém seus respectivos arquivos de dados.

– Adicionando um novo Data File, utilizando um Filegroup já existente no banco de dados:

filegroup 2

Ao executar esse script, adicionamos mais um arquivo de dados, associando ao FILEGROUP [FG_TableBIG].

– Ciando tabela e associando ao Filegroup [FG_TableBIG]:

filegroup 3

Observe que ao final do CREATE TABLE apareceu um comando novo, o ON. É neste ponto que especificamos qual será o FILEGROUP para a tabela. O que acontece se não especificarmos o FILEGROUP? A tabela será criada no FILEGROUP default, que neste exemplo será o PRIMARY.

– Listando todos os objetos mapeados em cada Filegroup?

filegroup 4

O result deste SELECT irá retornar todos os objetos contidos nos FILEGROUPs FG_TableBig e PRIMARY. Note que no primeiro, existe a tabela TB01 e no segundo todos os objetos de sistema SQL Server para este bando de dados.

Quando é interessante criar mais de um Filegroup por Database? Como dito anteriormente, o banco de dados vem com um Filegroup PRIMARY por padrão e implicitamente todos os objetos de sistemas estão mapeados nele. É sempre uma boa prática dividir objetos de sistemas de objetos de usuário (objetos criados posteriormente). Primeiro, pela organização do seu banco de dados, sendo assim também é uma boa prática criar Filegroups para índices e tabelas com muita carga de escrita e leitura, separando fisicamente esses objetos teremos ganhos no processamento de I/O, além de estarmos mantendo o banco de dados estruturado da melhor forma possível.

Em segundo, tem a questão da utilização de algoritmo de Proportional Fill, que possibilita ganhos extremamente eficientes no quesito de performance. Além disso, existe a questão da contenção das páginas GAM e SGAM. Diminuindo o gargalo sobre estas páginas de sistema, é possível ganhos de performance.

Além dos ganhos de performance mencionados, também existe o lado da recuperação em caso de desastre (Disaster Recovery), existindo a possibilidade de realizar o Restore em nível Filegroup, diminuindo o tempo de RTO  (Recovery Time Objective) e RPO (Recovery Point Objective) e restabelecendo o banco de dados ou parte dele o mais rápido possível.

Uma vez que é possível realizar Restore de um Filegroup, então também é possível realizar backup. Existem casos em que o banco de dados é muito grande, passando da cada dos terabytes. Porém, uma boa parte dele é feita de dados históricos, que não são atualizados ou são atualizados muito raramente. Neste caso, o banco de dados poderia estar particionado (conceito aqui) e assim poderíamos criar uma lógica de backup mais inteligente e econômica, diminuindo GBs e tempo de execução.

Para finalizar, Filegroup é uma feature muito interessante que podemos utilizar para o bem do banco de dados e do DBA, auxiliando na administração e manutenção como um todo.

Fonte: Todos de TI

Agility Solutions
A Agility Solutions acredita que, com disciplina, planejamento e conhecimento é possível administrar positivamente qualquer projeto.
http://www.agilitysolutions.com.br/

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *