Home / Artigos / Filegroup no SQL Server
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 casa 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.

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, FILEGROUP (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:

 

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.

Beleza, Luiz, 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 a configuração dos Data Files, que irei abordar em um próximo artigo. Aqui um bom vídeo sobre o assunto.

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

 

 

artigo-3 (1)

Por padrão, todo banco 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 criados 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 objetos de sistemas e usuários.

Vamos para a prática:

1. Criando banco de dados com mais de um data file e associando a outro Filegroup:

1 CREATE DATABASE [DB01]
2 ON PRIMARY
3           (NAME = N'DB01', FILENAME = N'D:\DB01.mdf' , SIZE = 1048576KB , FILEGROWTH = 1024KB ),
4 FILEGROUP [FG_TableBIG]
5            (NAME = N'DB01_02', FILENAME = N'E:\DB01_02.ndf' , SIZE = 1048576KB , FILEGROWTH = 1024KB )
6 LOG ON
7             (NAME = ', FILENAME = N'L:\DB01_log.ldf' , SIZE = 1048576KB , FILEGROWTH = 10%)
8 GO

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

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

1 ALTER DATABASE [DB01]
2 ADD FILE ( NAME = N'DB01_03', FILENAME = N'E:\DB01_03.ndf', SIZE = 1048576KB , FILEGROWTH = 1024KB )
3 TO FILEGROUP [FG_TableBIG]
4 GO

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

3. Criando tabela e associando ao Filegroup [FG_TableBIG]:

1 USE DB01
2 GO
3 CREATE TABLE Table01
4 (
5         ID                       INT IDENTITY PRIMARY KEY ,
6         Nome                 VARCHAR(50) NOT NULL,
7         DTNascimento   DATETIME NOT NULL
8 ) ON FG_TABLEBIG

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.

4. Listando todos os objetos mapeados em cada Filegroup:

1 SELECT
2         name = left(o.name,30),
3         filegroup = s.groupname
4 FROM sysfilegroups S, sysindexes I, sysobjects O
5 WHERE I.indid < 2
6 AND I.groupid = S.groupid AND I.id = O.id

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

Quando é interessante criar mais de um Filegroup por Database? Como dito anteriormente, o banco de dados vem com o 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ários (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 do 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. Mais sobre os conceitos de GAM, SGAM, aqui, aqui e aqui.

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 de 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 casa 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:Infobase

Sobre Todos de TI

Veja também

COMEÇOU O MAIOR CONGRESSO DE TECNOLOGIA

6ª EDIÇÃO: 11 A 17 DE SETEMBRO 2017 PARTICIPE AGORA* *Inscrição Gratuita Você é apaixonado por tecnologia …

Deixe uma resposta

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

blog lam dep | toc dep | giam can nhanh

|

toc ngan dep 2016 | duong da dep | 999+ kieu vay dep 2016

| toc dep 2016 | du lichdia diem an uong

xem hai

the best premium magento themes

dat ten cho con

áo sơ mi nữ

giảm cân nhanh

kiểu tóc đẹp

đặt tên hay cho con

xu hướng thời trangPhunuso.vn

shop giày nữ

giày lười nữgiày thể thao nữthời trang f5Responsive WordPress Themenha cap 4 nong thonmau biet thu deptoc dephouse beautifulgiay the thao nugiay luoi nutạp chí phụ nữhardware resourcesshop giày lườithời trang nam hàn quốcgiày hàn quốcgiày nam 2015shop giày onlineáo sơ mi hàn quốcshop thời trang nam nữdiễn đàn người tiêu dùngdiễn đàn thời tranggiày thể thao nữ hcmphụ kiện thời trang giá rẻ