armazenamento FILESTREAM - Microsoft Center

Artigo técnico do SQL Server
Autor: Paul S. Randal (SQLskills.com)
Revisor técnico: Alexandru Chirica, Arkadi Brjazovski, Prem Mehra, Joanna Omel,
Mike Ruthruff, Robin Dhamankar
Publicado em: outubro de 2008
Aplica-se a: SQL Server 2008
Resumo: este white paper descreve o recurso FILESTREAM do SQL Server 2008, que permite
o armazenamento de dados BLOB e o acesso eficiente a eles por meio de uma combinação
do SQL Server 2008 e do sistema de arquivos NTFS. O documento aborda as opções de
armazenamento BLOB, a configuração do Windows e do SQL Server para uso de dados
FILESTREAM, considerações sobre a combinação do FILESTREAM com outros recursos
e detalhes da implementação, como particionamento e desempenho.
Este white paper é destinado a arquitetos, profissionais de TI e DBAs responsáveis por avaliar
ou implementar o FILESTREAM. Ele supõe que o leitor esteja familiarizado com o Windows
e o SQL Server, e que tenha pelo menos um conhecimento básico dos conceitos de banco de
dados, como transações, por exemplo.
Introdução
Na sociedade atual, os dados são gerados em proporções inacreditáveis e, frequentemente, precisam
ser armazenados e acessados de maneira controlada e eficiente. Existem várias tecnologias para
se fazer isso, e a melhor opção muitas vezes depende da natureza dos dados que estão sendo
armazenados – estruturados, semiestruturados ou não estruturados:

Os dados estruturados são aqueles que podem ser facilmente armazenados em um esquema
relacional, como os que representam os dados de vendas de uma empresa. Eles podem ser
armazenados em um banco de dados com uma tabela de informações sobre produtos que
a empresa vende, outra com informações sobre clientes e outra que detalhe as vendas dos
produtos aos clientes. Os dados podem ser acessados e manipulados por meio de uma
linguagem de consulta avançada, como Transact-SQL.


Os dados semiestruturados são os dados que se adaptam a um esquema impreciso, mas não
servem para serem armazenados em um conjunto de tabelas de banco de dados, por exemplo,
dados em que cada ponto de dados pode ter atributos radicalmente diferentes. Os dados
semiestruturados muitas vezes são armazenados com o uso do tipo de dados xml no software
de banco de dados Microsoft® SQL Server® e acessados com uma linguagem de consulta
baseada em elemento, como XQuery.
Os dados não estruturados podem não ter absolutamente nenhum esquema (como uma porção
de dados criptografados) ou podem ser uma grande quantidade de dados binários (muitos MBs
ou até mesmo GBs) que podem parecer não ter um esquema, mas na realidade têm um
esquema muito simples inerente a eles, como arquivos de imagens, vídeos de streaming ou
clipes de som. Nesse caso, dados binários se referem a dados que podem ter qualquer valor,
não apenas aqueles que podem ser inseridos em um teclado. Esses valores de dados
geralmente são conhecidos como Objetos Binários Grandes, ou simplesmente BLOBs.
Este white paper descreve o recurso FILESTREAM do SQL Server 2008, que permite o armazenamento
de dados BLOB e o acesso eficiente a eles por meio de uma combinação do SQL Server 2008 e do
sistema de arquivos NTFS. O documento aborda o recurso FILESTREAM propriamente dito, opções
de armazenamento de BLOB, configuração do sistema operacional Windows® e do SQL Server para
usar dados FILESTREAM, considerações sobre a combinação do FILESTREAM com outros recursos
e detalhes de implementação, como particionamento e desempenho.
Opções para o armazenamento de BLOB
Embora os dados estruturados e semiestruturados possam ser armazenados com facilidade em um
banco de dados relacional, a escolha de onde armazenar dados não estruturados ou BLOB é mais
complicada. Ao decidir onde armazenar dados BLOB, considere os seguintes requisitos:




2
Desempenho: a maneira como os dados serão usados é um fator crítico. Se o acesso streaming
for necessário, armazenar os dados em um banco de dados do SQL Server pode ser mais lento
do que armazená-los externamente em um local como o sistema de arquivos NTFS. Usando
o armazenamento do sistema de arquivos, os dados são lidos no arquivo e transferidos para
o aplicativo cliente (diretamente ou com buffer adicional). Quando o BLOB é armazenado em um
banco de dados do SQL Server, primeiro os dados devem ser lidos na memória do SQL Server
(o pool de buffers) e depois transferidos de volta por meio de uma conexão do cliente ao
aplicativo cliente. Isso não só significa que os dados passam por uma etapa de processamento
extra, mas também que a memória do SQL Server é desnecessariamente "poluída" com dados
BLOB, o que pode causar problemas de desempenho em operações futuras do SQL Server.
Segurança: os dados confidenciais que precisam ter acesso rigidamente gerenciado podem
ser armazenados em um banco de dados, e a segurança pode ser controlada com os controles
de acesso normais do SQL Server. Se os mesmos dados forem armazenados no sistema de
arquivos, deverão ser implementados outros métodos de segurança, como as ACLs (listas de
controle de acesso).
Tamanho dos dados: com base na pesquisa citada mais adiante neste white paper, os BLOBs
com menos de 256 KB (como ícones do widget) são mais bem armazenados dentro de um
banco de dados, e os BLOBs com mais de 1 MB são mais bem armazenados fora do banco de
dados. Para esses dados com tamanhos entre 256 KB e 1 MB, a solução de armazenamento
mais eficiente depende da proporção de leitura e gravação dos dados, bem como da taxa
de "substituição". O armazenamento de dados BLOB exclusivamente no banco de dados
(por exemplo, usando o tipo de dados varbinary (max)) é limitado a 2 GB por BLOB.
Acesso para cliente: o protocolo que o cliente usa para acessar dados do SQL Server, como
o ODBC, pode não ser adequado para aplicações como o streaming de arquivos grandes de
vídeo. Isso pode exigir o armazenamento de dados no sistema de arquivos.




Semântica transacional: se os dados BLOB tiverem sido associados a dados estruturados
que serão armazenados no banco de dados, as alterações nos dados BLOB precisarão aderir
à semântica transacional para que os dois conjuntos de dados permaneçam sincronizados.
Por exemplo, se uma transação criar dados BLOB e uma linha em uma tabela de banco de
dados, mas, em seguida, for revertida, a criação dos dados BLOB também deverá ser revertida,
assim como a criação da linha de tabela. Isso pode se tornar bastante complexo se os dados
BLOB forem armazenados no sistema de arquivos sem nenhum vínculo com o banco de dados.
Fragmentação de dados: atualizações e substituições frequentes farão com que os BLOBs se
movam, seja dentro dos arquivos de banco de dados do SQL Server ou dentro do sistema de
arquivos, dependendo de onde os dados estiverem armazenados. Nesse caso, se os BLOBs
forem grandes, eles poderão ser fragmentados (isto é, não armazenados em uma parte contígua
do disco). É mais fácil lidar com essa fragmentação quando se usa o sistema de arquivos em vez
do SQL Server.
Capacidade de gerenciamento: uma solução que usa várias tecnologias que não são integradas
apresentará um gerenciamento mais complexo e caro do que uma solução integrada.
Custo: o custo da solução de armazenamento varia de acordo com a tecnologia usada.
As explicações acima em relação ao tamanho e à fragmentação são baseadas no conhecido documento
do Microsoft Research intitulado Para BLOB ou não: armazenamento de objeto grande em um banco de
dados ou sistema de arquivos? (Gray, Van Ingen e Sears). O documento apresenta mais informações
sobre as compensações envolvidas e pode ser baixado em:
http://research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2006-45
Há uma variedade de soluções para o armazenamento de BLOB, cada uma com seus prós e contras
baseados nos requisitos acima. A tabela a seguir compara três opções comuns de armazenamento de
dados BLOB, incluindo o FILESTREAM, no SQL Server 2008.
Ponto de
comparação
Tamanho máximo
do BLOB
Desempenho do
streaming de
BLOBs grandes
Segurança
Solução de armazenamento
Servidor de arquivos SQL Server (usando
FILESTREAM
/ sistema de arquivos varbinary(max))
Tamanho do volume
2 GB – 1 byte
Tamanho do volume
NTFS
NTFS
Excelente
Fraco
Excelente
ACLs manuais
Integrada
ACLs integradas +
automáticas
Baixo
Integrada
Custo por GB
Baixo
Alto
Capacidade de
Difícil
Integrada
gerenciamento
Integração com
Difícil
Consistência no nível
Consistência no nível
dados estruturados
de dados
de dados
Desenvolvimento
Mais complexo
Mais simples
Mais simples
e implantação
de aplicativos
Recuperação
Excelente
Fraca
Excelente
da fragmentação
de dados
Desempenho
Excelente
Moderado
Fraco
de atualizações
frequentes
e pequenas
Tabela 1: Comparação de tecnologias de armazenamento de BLOB anteriores ao SQL Server 2008
3
O FILESTREAM é a única solução que proporciona consistência transacional a dados estruturados
e não estruturados, assim como gerenciamento integrado, segurança, baixo custo e excelente
desempenho de streaming. Esses benefícios resultam do armazenamento de dados estruturados
nos arquivos de banco de dados e de dados BLOB não estruturados no sistema de arquivos,
enquanto se mantém a consistência transacional entre os dois repositórios. Mais detalhes da arquitetura
FILESTREAM são fornecidos na seção "Visão geral do FILESTREAM", mais adiante neste white paper.
Visão geral do FILESTREAM
O FILESTREAM é um novo recurso na versão SQL Server 2008. Ele permite que dados estruturados
sejam armazenados no banco de dados e que os dados associados não estruturados (isto é, BLOB)
sejam armazenados diretamente no sistema de arquivos NTFS. Você pode acessar os dados BLOB por
meio das APIs de streaming de alto desempenho do Win32®, em vez de se prejudicar com a perda de
desempenho por acessar dados BLOB usando o SQL Server.
O FILESTREAM mantém a consistência transacional entre os dados estruturados e não estruturados
o tempo todo, permitindo até mesmo a recuperação pontual dos dados FILESTREAM usando backups
de log. A consistência é mantida automaticamente pelo SQL Server e não requer nenhuma lógica
personalizada no aplicativo. O mecanismo do FILESTREAM faz isso mantendo o equivalente de um
log de transações do banco de dados, que contém muitos dos mesmos requisitos de gerenciamento
(descritos mais detalhadamente na seção "Configurando a coleta de lixo do FILESTREAM", mais adiante
neste white paper). A combinação do log de transações do banco de dados com o log de transações
do FILESTREAM permite que os dados FILESTREAM e estruturados sejam recuperados de modo
transacional e correto.
Em vez de ser um tipo de dados completamente novo, o FILESTREAM é um atributo de armazenamento
do tipo de dados varbinary (max) existente. O FILESTREAM preserva a maior parte do comportamento
existente do tipo de dados varbinary (max). Ele altera a forma como os dados BLOB são armazenados no sistema de arquivos, e não nos arquivos de dados do SQL Server. Como o FILESTREAM é implementado
como uma coluna varbinary (max) e é integrado diretamente a um mecanismo de banco de dados,
a maioria das ferramentas e funções de gerenciamento do SQL Server funciona sem modificação nos
dados FILESTREAM.
Deve ser observado que o comportamento do tipo de dados varbinary (max) regular permanece
completamente inalterado no SQL Server 2008, incluindo o limite de tamanho de 2 GB. A adição do
atributo FILESTREAM faz com que uma coluna varbinary (max) seja essencialmente ilimitada em
tamanho (na realidade, o tamanho limita-se ao do volume NTFS subjacente).
Os dados FILESTREAM são armazenados no sistema de arquivos em um conjunto de diretórios NTFS
chamados contêineres de dados, que correspondem aos grupos de arquivos especiais no banco de
dados. O acesso transacional a dados FILESTREAM é controlado pelo SQL Server e por um driver de
filtro do sistema de arquivos que é instalado como parte da habilitação do FILESTREAM no nível do
Windows. O uso de um driver de filtro do sistema de arquivos também permite o acesso remoto a dados
FILESTREAM por meio de um caminho UNC. O SQL Server mantém um vínculo de classificações das
linhas da tabela com os arquivos FILESTREAM associados a elas. Isso significa que excluir ou renomear
qualquer arquivo FILESTREAM diretamente pelo sistema de arquivos corromperá o banco de dados.
4
O uso do FILESTREAM exige várias modificações de esquema nas tabelas de dados (especialmente
o requisito de que cada linha deve ter uma ID de linha exclusiva) e também tem algumas restrições
quando combinado a outros recursos (como a incapacidade de criptografar dados FILESTREAM).
Tudo isso é descrito em detalhes na seção "Configurando o SQL Server para o FILESTREAM",
mais adiante neste white paper.
Os dados FILESTREAM podem ser acessados e manipulados de duas maneiras: com o modelo
de programação padrão Transact-SQL ou por meio das APIs de streaming do Win32. Ambos os
mecanismos são totalmente habilitados para transações e oferecem suporte à maioria das operações
DML, incluindo inserção, atualização, exclusão e seleção. Os dados FILESTREAM também contam com
o suporte das operações de manutenção, como backup, restauração e verificação de consistência.
A grande exceção é que não há suporte às atualizações parciais nos dados FILESTREAM. Qualquer
atualização em um valor dos dados FILESTREAM converte-se na criação de uma cópia do arquivo de
dados FILESTREAM. O arquivo antigo é removido de modo assíncrono, conforme descrito na seção
"Configurando a coleta de lixo do FILESTREAM", mais adiante neste white paper.
Acesso a dados BLOB pelo modelo de programação dupla
Depois que os dados são armazenados em uma coluna FILESTREAM, é possível acessá-los usando
transações Transact-SQL ou APIs do Win32. Esta seção fornece alguns detalhes de alto nível dos
modelos de programação e de como usá-los.
Acesso por Transact-SQL
Usando o Transact-SQL, os dados FILESTREAM podem ser inseridos, atualizados e excluídos da
seguinte forma:



É possível pré-popular os campos FILESTREAM usando uma operação de inserção
(com um valor vazio ou valores pequenos não nulos). No entanto, as interfaces do Win32
são uma maneira mais eficiente de transmitir uma grande quantidade de dados.
Quando os dados FILESTREAM são atualizados, os dados BLOB subjacentes no sistema
de arquivos são modificados. Quando um campo FILESTREAM é definido como NULL,
os dados BLOB associados ao campo são excluídos. As atualizações em partes do TransactSQL implementadas como UPDATE.Write() não podem ser usadas para executar atualizações
parciais nos dados FILESTREAM.
Quando uma linha que contém dados FILESTREAM é excluída ou uma tabela que contém dados
FILESTREAM é excluída ou truncada, os dados BLOB subjacentes no sistema de arquivos
também são excluídos. A remoção física real dos arquivos FILESTREAM é um processo em
segundo plano assíncrono, conforme explicado na seção "Configurando a coleta de lixo do
FILESTREAM", mais adiante neste white paper.
Para obter mais informações e exemplos de como usar o Transact-SQL para acessar dados
FILESTREAM, consulte o tópico "Gerenciando dados FILESTREAM usando o Transact-SQL" nos
Manuais Online do SQL Server 2008 (http://msdn.microsoft.com/pt-br/library/cc645962.aspx).
5
Acesso por streaming do Win32
Para permitir o acesso do sistema de arquivos transacional aos dados FILESTREAM, uma nova
função intrínseca, GET_FILESTREAM_TRANSACTION_CONTEXT(), fornece o token que representa
a transação atual à qual a sessão está associada. A transação deve ter sido iniciada e ainda não
confirmada ou revertida. Ao obter um token, o aplicativo associa as operações de streaming do sistema
de arquivos FILESTREAM a uma transação iniciada. A função retorna NULL quando nenhuma transação
foi explicitamente iniciada. É necessário obter um token para que os arquivos FILESTREAM possam ser
acessados.
No FILESTREAM, o mecanismo de banco de dados controla o namespace do sistema de arquivos
físico do BLOB. Uma nova função intrínseca, PathName, fornece o caminho UNC lógico do BLOB que
corresponde a cada campo FILESTREAM na tabela. O aplicativo usa esse caminho lógico para obter
o identificador do Win32 e operar nos dados BLOB usando interfaces normais de sistema de arquivos
do Win32. A função retornará NULL se o valor da coluna FILESTREAM for NULL. Portanto, um arquivo
FILESTREAM deve ser pré-criado para que possa ser acessado nível do Win32. Isso pode ser feito
conforme descrito anteriormente.
O suporte ao streaming do Win32 funciona no contexto de uma transação do SQL Server. Depois de
obter um token da transação e um nome de caminho, a API OpenSqlFilestream do Win32 é usada
para obter um identificador de arquivo do Win32. Como alternativa, é possível usar a API SqlFileStream
gerenciada. Esse identificador pode então ser usado pelas interfaces de streaming do Win32, como
ReadFile() e WriteFile(), para acessar e atualizar o arquivo por meio do sistema de arquivos. Novamente,
observe que os arquivos FILESTREAM não podem ser excluídos diretamente e não podem ser renomeados
com o sistema de arquivos. Caso contrário, a consistência no nível de vínculo entre o banco de dados
e o sistema de arquivos será perdida (isto é, o banco de dados basicamente torna-se corrompido).
O acesso do sistema de arquivos FILESTREAM modela uma instrução Transact-SQL usando abertura
e fechamento de arquivo. A instrução inicia quando um identificador de arquivo é aberto e termina
quando o identificador é fechado. Por exemplo, quando um identificador de gravação é fechado,
qualquer gatilho AFTER que esteja registrado na tabela será acionado como se uma instrução UPDATE
tivesse sido concluída.
Para obter mais informações e exemplos de como usar as APIs do Win32 para acessar dados
FILESTREAM, consulte o tópico "Gerenciando dados FILESTREAM usando o Win32" nos Manuais
Online do SQL Server 2008 (http://msdn.microsoft.com/pt-br/library/cc645940.aspx).
Semântica transacional
Todos os identificadores de arquivo devem ser fechados antes da confirmação ou reversão da transação.
Se um identificador for deixado aberto quando ocorrer a confirmação de uma transação, haverá falha
na confirmação e leituras e gravações adicionais no identificador causarão uma falha, como é esperado.
Assim, a transação deverá ser revertida. De maneira semelhante, se o banco de dados ou a instância
do mecanismo de banco de dados for desligado, todos os identificadores abertos serão invalidados.
Sempre que um arquivo FILESTREAM é aberto para uma operação de gravação, um novo arquivo de
comprimento zero é criado e todo o valor dos dados FILESTREAM atualizados é gravado nele. O arquivo
antigo é removido de modo assíncrono, conforme descrito na seção "Configurando a coleta de lixo do
FILESTREAM", mais adiante neste white paper.
6
Com o FILESTREAM, o mecanismo de banco de dados garante a durabilidade da transação na
confirmação de dados BLOB FILESTREAM que são modificados no acesso streaming ao sistema de
arquivos. Isso é feito usando o log do FILESTREAM mencionado anteriormente e uma liberação explícita
do conteúdo do arquivo FILESTREAM no disco.
Semântica de isolamento
A semântica de isolamento é administrada pelos níveis de isolamento da transação do mecanismo do
banco de dados. Quando os dados FILESTREAM são acessados por meio das APIs do Win32, apenas
o nível de isolamento confirmado por leitura tem suporte. O acesso Transact-SQL também permite os
níveis de isolamento serializáveis e de leitura repetida. Além disso, usando o acesso Transact-SQL,
as leituras sujas são permitidas por meio do nível de isolamento não confirmado por leitura ou pela dica
de consulta NOLOCK, mas esse acesso não mostrará atualizações em curso dos dados FILESTREAM.
As operações de abertura de acesso ao sistema de arquivos não aguardam nenhum bloqueio. Em vez
disso, as operações de abertura falham imediatamente caso não possam acessar os dados por causa do
isolamento da transação. As chamadas da API de streaming falharão com ERROR_SHARING_VIOLATION
se a operação de abertura não puder continuar por causa de violação de isolamento.
Atualizações parciais
Para permitir a realização de atualizações parciais, o aplicativo pode emitir um controle de FS de
dispositivo (FSCTL_SQL_FILESTREAM_FETCH_OLD_CONTENT) para buscar o conteúdo antigo
no arquivo ao qual o identificador aberto faz referência. Também é possível fazer isso usando a API
gerenciada SqlFileStream com o sinalizador ReadWrite. Isso dispara uma cópia do conteúdo antigo
no lado do servidor, conforme explicado anteriormente. Para obter melhor desempenho do aplicativo
e evitar possíveis tempos limites ao trabalhar com arquivos muito grandes, você deve usar E/S assíncrona.
Se o FSCTL for emitido após o identificador ter sido gravado, a última operação de gravação persistirá
e as gravações anteriores feitas no identificador serão perdidas.
Para obter mais informações sobre atualizações parciais, consulte o tópico
"FSCTL_SQL_FILESTREAM_FETCH_OLD_CONTENT" nos Manuais Online do SQL Server 2008
(http://technet.microsoft.com/pt-br/library/cc627407.aspx).
Write-Through de clientes remotos
O acesso do sistema de arquivos remoto a dados FILESTREAM é habilitado pelo protocolo SMB (Server
Message Block). Se o cliente for remoto, o cache de operações de gravação dependerá das opções
especificadas na API usada. Por exemplo, o padrão para APIs de código nativo é executar write-through,
ao passo que, para as APIs gerenciadas, o padrão é usar o buffer. Essa diferença reflete comentários
do cliente em várias APIs e seus usos em versões CTP de pré-lançamento do SQL Server 2008.
É recomendável que os aplicativos em execução em clientes remotos consolidem operações de
gravação pequenas (por meio de buffer) para fazer menos operações de gravação usando um tamanho
maior de dados. Além disso, se o buffer estiver sendo usado, uma liberação explícita deverá ser emitida
pelo cliente antes da confirmação da transação.
Não há suporte para a criação de exibições mapeadas de memória (E/S mapeada de memória) usando
um identificador FILESTREAM. Se o mapeamento de memória for usado para dados FILESTREAM,
o mecanismo de banco de dados não poderá garantir a consistência e a durabilidade dos dados ou
a integridade do banco de dados.
7
Quando usar FILESTREAM
Embora a tecnologia FILESTREAM tenha muitos recursos atraentes, talvez ela não seja a melhor opção
em todas as situações. Conforme mencionado anteriormente, o tamanho dos dados BLOB e os padrões
de acesso são os fatores mais significativos quando é necessário tomar a decisão de armazenar os
dados BLOB totalmente no banco de dados ou usando FILESTREAM.
O tamanho afeta os seguintes itens:


A eficiência com que os dados BLOB podem ser acessados com qualquer um dos mecanismos
de armazenamento. Como mencionado anteriormente, o acesso streaming de dados BLOB
volumosos é mais eficiente usando FILESTREAM, mas as atualizações parciais são
(potencialmente muito) mais lentas.
A eficiência do backup de dados BLOB e estruturados combinados com qualquer um dos
mecanismos de armazenamento. Um backup que combina arquivos de banco de dados do SQL
Server e um número grande de arquivos FILESTREAM é mais lento do que um backup somente
de arquivos de banco de dados do SQL Server de um tamanho total equivalente. Isso se deve
à sobrecarga adicional do backup de cada arquivo NTFS (um por valor de dados FILESTREAM).
Essa sobrecarga se tornará mais perceptível quando os arquivos FILESTREAM forem menores
(pois a sobrecarga de tempo torna-se uma porcentagem maior do tempo total para o backup por
MB de dados).
Como exemplo, o gráfico a seguir mostra a taxa de transferência relativa de leituras locais de vários
tamanhos de dados BLOB usando varbinary (max), FILESTREAM com Transact-SQL e FILESTREAM
com NTFS. Pode ser visto (na linha azul) que o acesso Win32 dos dados FILESTREAM torna-se várias
vezes mais rápido do que o acesso Transact-SQL dos dados varbinary (max) à medida que o tamanho
dos dados aumenta. Observe que as medidas de taxa de transferência estão em megabits por segundo
(Mbps).
Figura 1: Desempenho de leitura de vários tamanhos de BLOB
8
Os números de NTFS incluem o tempo necessário para iniciar uma transação, recuperar o nome do
caminho e o contexto de transação do SQL Server, e abrir um identificador do Win32 para os dados
FILESTREAM. Cada teste foi executado usando o mesmo computador com quatro núcleos de
processador e um pool de buffers do SQL Server a quente.
O outro fator a ser considerado é se o cliente ou a camada intermediária podem ser gravados
(ou alterados) para usar as APIs de streaming do Win32, bem como o acesso normal ao SQL Server.
Se esse não for o caso, o FILESTREAM não será adequado, pois o melhor desempenho é obtido com
as APIs de streaming do Win32.
Configurando o Windows para FILESTREAM
Assim como em qualquer outra implantação, antes de implantar um aplicativo que usa FILESTREAM,
é importante preparar o servidor Windows que hospedará o banco de dados do SQL Server e os
contêineres de dados FILESTREAM associados. Esta seção explica como configurar o hardware de
armazenamento e o sistema de arquivos NTFS em preparação para usar o FILESTREAM. A seção
mostra como habilitar o FILESTREAM no nível do Windows.
Seleção e configuração de hardware
Uma das causas mais comuns do desempenho insatisfatório de uma carga de trabalho é uma
configuração de hardware inadequada. Às vezes, a causa é insuficiência de memória, o que resulta
em "sobrecarga" no pool de buffers do SQL Server e, às vezes, a causa é simplesmente o fato de que
o hardware de armazenamento não tem a capacidade de taxa de transferência de E/S que a carga de
trabalho demanda. Para aplicativos que usarão o FILESTREAM para streaming de alto desempenho dos
dados BLOB usando as APIs do Win32, a escolha e a configuração do hardware de armazenamento são
essenciais.
As seções a seguir descrevem algumas práticas recomendadas sobre a escolha e o layout do
armazenamento. Para ver uma discussão detalhada sobre isso, consulte o white paper "Design de
armazenamento do banco de dados físico" do TechNet (http://www.microsoft.com/technet/prodtechnol/
sql/2005/physdbstor.mspx). Depois de criar um layout ideal, convém executar testes de carga para
validar a capacidade de desempenho do subsistema de E/S. Isso é discutido em detalhes no artigo sobre
práticas recomendadas do SQL Server no TechNet, "Práticas recomendadas de pré-implantação de E/S"
(http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/pdpliobp.mspx).
Layout do armazenamento físico
Lembre-se de levar em consideração a carga de trabalho prevista em um contêiner de dados
FILESTREAM quando estiver decidindo onde colocá-la, bem como as cargas de trabalho em qualquer
contêiner de dados colocalizado ou arquivos do SQL Server. Cada contêiner de dados FILESTREAM
pode precisar estar em seu próprio volume, uma vez que ter vários contêineres de dados com cargas de
trabalho pesadas em um único volume pode resultar em contenção.
O ponto a ser considerado aqui é que, sem pensar nas cargas de trabalho envolvidas, simplesmente
colocar de tudo em um único volume pode gerar problemas de desempenho. O grau de separação
exigido variará de cliente para cliente.
Também é possível criar um esquema de tabela dentro do SQL Server que permita o balanceamento
de carga bruto de dados FILESTREAM entre vários volumes. Isso é descrito na seção "Balanceamento
de carga de dados FILESTREAM".
9
Escolha do nível de RAID
Os benefícios de usar a tecnologia RAID são conhecidos, e muito já foi escrito sobre como escolher um
nível de RAID apropriado para os requisitos do aplicativo, portanto este white paper não tentará repetir
todas essas informações. O white paper já mencionado, "Design de armazenamento do banco de dados
físico", tem uma excelente seção sobre níveis de RAID e opções de nível de RAID. O que se segue aqui
é uma visão geral simples dos fatores a serem considerados.
Os níveis de RAID diferem de várias formas, especialmente em termos de desempenho de
leitura/gravação, resiliência a falhas e custo. Por exemplo, o RAID 5 tem um custo relativamente baixo,
pode tratar a falha de apenas uma unidade na matriz RAID e pode ser inadequado para cargas de
trabalho de intensa gravação. Por outro lado, o RAID 10 fornece excelente desempenho de leitura
e gravação, além de poder tratar várias falhas de unidade (dependendo do grau de espelhamento
envolvido), mas é mais caro, já que pelo menos 50% das unidades na matriz RAID são redundantes.
Esses são os três principais fatores envolvidos na escolha de um nível de RAID. A escolha do nível
de RAID pode ser diferente para o volume em que cada banco de dados de usuário é armazenado,
podendo ser diferente até mesmo entre o volume que está armazenando os arquivos de dados e o que
está armazenando os arquivos de log para um único banco de dados.
Se a carga de trabalho for envolver streaming de alto desempenho de dados FILESTREAM, a opção
imediata talvez seja a de que o volume do contêiner de dados FILESTREAM use o nível de RAID que
ofereça o desempenho de leitura mais alto. No entanto, isso talvez não proporcione um alto grau de
resiliência contra falhas. Por outro lado, a opção imediata pode ser usar o mesmo nível de RAID usado
para outros volumes que armazenam os dados do banco de dados, mas isso pode não oferecer os
níveis de desempenho que a carga de trabalho demanda.
Neste white paper, o ponto a ser enfatizado é que uma escolha consciente do nível de RAID deve
ser feita para os volumes de contêiner de dados FILESTREAM após a avaliação das compensações
envolvidas, e não apenas decidir com base em um único fator.
Escolha da interface da unidade
Em bancos de dados comuns que envolvem dados BLOB, o tamanho total dos dados BLOB muitas
vezes pode ser maior do que o tamanho total dos dados estruturados. Ao implementar uma solução
que envolve os dados FILESTREAM armazenados em volumes separados, você pode usar um
armazenamento mais barato para o volume, como IDE ou SATA (daqui por diante simplesmente
chamado de "SATA"), em vez de um armazenamento SCSI mais caro. Antes de fazer essa escolha,
é necessário entender os prós e contras envolvidos. Esta seção fornece uma visão geral das diferentes
características do SCSI em oposição ao IDE/SATA para permitir que seja feita uma escolha informada
com base no desempenho e na confiabilidade, bem como no custo.
Capacidade e desempenho
As unidades SATA tendem a ter uma capacidade mais alta do que as unidades SCSI, mas elas têm uma
velocidade de rotação (RPM) mais lenta do que as unidades SCSI. Embora haja algumas unidades SATA
de 10.000 RPM, a maioria é de 5.400 ou 7.200 RPM. As unidades SCSI de alto desempenho que estão
disponíveis são de 10.000 e até 15.000 RPM. Embora a RPM possa ser uma métrica de comparação útil,
os dois números que devem ser realmente usados para uma comparação são as taxas de latência
(o tempo que o cabeçote do disco leva para ficar na posição correta sobre a superfície do disco) e as
taxas médias de transferência (a quantidade de dados que pode ser transferida para dentro e para fora
da superfície do disco por segundo). Também é importante que as unidades possam processar padrões
complexo de E/S com eficiência. Ao escolher unidades, verifique se as unidades SATA oferecem suporte
a NCQ (Native Command Queue) e as unidades SCSI oferecem suporte a CTQ (Command Tag Queu),
para que possam processar várias operações de E/S de disco intercaladas para proporcionar um melhor
desempenho efetivo.
10
Resumindo, as unidades SCSI geralmente apresentam melhores taxas de transferência e latência,
de modo que fornecerão melhor desempenho de streaming, mas possivelmente a um custo mais alto.
Confiabilidade
O SQL Server se baseia em ordenação de gravação e durabilidade garantidas para oferecer
confiabilidade e chances de recuperação por meio de seu mecanismo de log write-ahead. Para obter
mais informações sobre esses requisitos de E/S, consulte o white paper "Noções básicas de E/S do
SQL Server" no TechNet (http://www.microsoft.com/technet/prodtechnol/sql/2005/iobasics.mspx).
Para confiabilidade, o SCSI geralmente é melhor do que o SATA, pois oferece suporte à imposição de
dados a serem gravados no disco, diferentemente do SATA. Isso é feito com suporte a write-through,
onde os dados a serem gravados não são de modo algum armazenados em cache, ou o suporte
à liberação forçada do conteúdo do cache no disco. A falta de um deles pode afetar as chances de
recuperação após uma falha de hardware, software ou energia. Todos os tipos de interfaces podem
oferecer suporte à permutação automática, de modo a permitir reparos enquanto a disponibilidade
é mantida.
O recurso FILESTREAM se baseia em duas garantias - ordenação de gravação e durabilidade:


Durabilidade de dados no momento da confirmação da transação
Log write-ahead para a criação e a exclusão de arquivos FILESTREAM
A durabilidade dos dados é atingida pelo driver do sistema de arquivos FILESTREAM que emite
uma liberação explícita de arquivos que foram modificados antes da confirmação de uma transação
(os detalhes do mecanismo estão além do escopo deste white paper). Isso garante que, em caso de queda
de energia, os discos sem cache com reserva de bateria suficiente não percam os dados FILESTREAM
confirmados que não foram liberados. Se as unidades SATA não oferecerem suporte a uma operação de
liberação forçada, as chances de recuperação poderão ser afetadas e os dados poderão ser perdidos.
O log write-ahead se baseia na consistência dos metadados NTFS. Isso, por si só, depende da
confiabilidade das unidades subjacentes. Não há nenhum problema com o SCSI, mas se as unidades
SATA não derem suporte à liberação forçada, algumas alterações de metadados NTFS poderão ser
perdidas em uma situação de falha de energia. Isso pode resultar em vários cenários:



O NTFS não pode ser recuperado e o volume não pode ser montado (isto é, o contêiner de
dados FILESTREAM está basicamente offline.
O NTFS é recuperado, mas as alterações dos metadados do NTFS são perdidas e o SQL Server
não sabe reverter uma transação não confirmada que executa uma inserção de dados
FILESTREAM (isto é, os dados FILESTREAM são "perdidos").
O NTFS é recuperado, mas as alterações dos metadados são perdidas e o SQL Server não
sabe reverter uma transação não confirmada que executa uma exclusão de dados FILESTREAM
(isto é, os dados FILESTREAM são perdidos).
Deve ser lembrado que todos os três cenários não são piores do que se os dados BLOB estivessem
armazenados fora do banco de dados em um volume NTFS com unidades SATA subjacentes sem
suporte para a imposição de dados no disco. O uso de FILESTREAM em um volume com unidades
SATA subjacentes nesse caso é realmente melhor do que armazenar os dados BLOB em arquivos
NTFS brutos no mesmo volume, pois a consistência em nível de vinculação do FILESTREAM fornece
um mecanismo para detectar quando tais "corrupções" ocorreram (por meio da execução de DBCC
CHECKDB no banco de dados).
11
Resumindo, os dados FILESTREAM podem ser confiavelmente armazenados em volumes com
armazenamento SATA subjacente, desde que as unidades SATA ofereçam suporte à imposição
de dados no disco por meio da liberação do cache.
Configuração de NTFS
Mesmo o subsistema de E/S mais bem-desenvolvido sendo executado em um hardware de alto
desempenho poderá não funcionar da forma desejada se o sistema de arquivos (nesse caso, NTFS)
não estiver configurado corretamente. Esta seção descreve algumas das opções de configuração que
podem afetar uma carga de trabalho que envolve dados FILESTREAM.
Para obter uma visão geral mais completa do NTFS, consulte os artigos da Biblioteca TechNet
"Referência técnica do NTFS" (http://technet.microsoft.com/pt-br/library/cc758691.aspx) e "Como
trabalhar com sistemas de arquivos" (http://technet.microsoft.com/pt-br/library/bb457112.aspx).
Otimizando o desempenho do NTFS
Por padrão, o NTFS não está configurado para manipular uma carga de trabalho de alto desempenho
com dezenas de milhares de arquivos em um diretório individual do sistema de arquivos (isto é, o cenário
de FILESTREAM). Há duas opções de NTFS que precisam ser configuradas para facilitar o desempenho
do FILESTREAM. É especialmente importante definir essas opções da forma correta antes de se
comprometer com qualquer avaliação de desempenho; caso contrário, os resultados não representarão
o desempenho real do FILESTREAM.
A primeira opção de configuração é desabilitar a geração de nomes 8.3 quando novos arquivos são
criados (ou renomeados). Esse processo gera um nome secundário para cada arquivo que serve apenas
para compatibilidade com aplicativos de 16 bits de versões anteriores. O algoritmo gera um novo nome
8.3 e, em seguida, precisa verificar todos os nomes de arquivo 8.3 existentes no diretório para garantir
que o novo nome seja exclusivo. À medida que o número de arquivos no diretório aumenta (geralmente
acima de 300.000), esse processo se torna cada vez mais demorado. O tempo de criação de um arquivo
por sua vez aumenta e o desempenho diminui; portanto, desativar esse processo pode aumentar
consideravelmente o desempenho. Para desativar esse processo, digite o seguinte em um prompt
de comando e reinicie o computador:
fsutil behavior set disable8dot3 1
Observação: essa opção desabilita a geração de nomes 8.3 em todos os volumes NTFS no servidor.
Se algum volume estiver sendo usado por aplicativos de 16 bits, estes poderão enfrentar problemas
depois que você alterar esse comportamento.
A segunda opção para desativação é atualizar a hora do último acesso de um arquivo quando ele for
acessado. Se a carga de trabalho acessar brevemente muitos arquivos, uma quantidade de tempo
desproporcional será gasta atualizando a hora do último acesso de cada arquivo. Desativar essa
opção também pode aumentar significativamente o desempenho. Para desativar esse processo,
digite o seguinte em um prompt de comando e reinicie o computador:
fsutil behavior set disablelastaccess 1
12
Tamanho do cluster
Todos os sistemas de arquivos do Windows têm o conceito de um "cluster", que é a unidade de alocação
quando o espaço em disco é alocado. Uma vez que um cluster é a menor quantidade de espaço em
disco que pode ser alocada, se um arquivo for muito pequeno, alguns dos clusters podem ser inutilizados
(basicamente, desperdiçados). Desse modo, o tamanho do cluster geralmente é pequeno o suficiente
para que os arquivos pequenos não desperdicem espaço em disco.
Os arquivos grandes podem ter muitos clusters alocados para eles ou os arquivos podem aumentar
ao longo do tempo e os clusters são alocados à medida que eles aumentam. Se um arquivo aumentar
muito, mas em pequenas partes, os clusters alocados provavelmente não serão contíguos no disco
(isto é, eles serão "fragmentos"). Isso significa que quanto menores forem os clusters, e quanto mais
um arquivo aumentar, mais "fragmentado" ele se tornará.
O tamanho do cluster é, portanto, uma compensação entre o desperdício do espaço em disco e a redução
da fragmentação. Mais detalhes sobre os vários tamanhos de clusters nos sistemas de arquivos do
Windows podem ser encontrados no artigo da Base de Dados de Conhecimento "Tamanho de cluster
padrão para FAT e NTFS" (http://support.microsoft.com/kb/140365).
A recomendação para usar o FILESTREAM é quando as unidades individuais de dados BLOB tiverem
um tamanho de 1 MB ou superior. Se esse for o caso, é recomendável que o tamanho do cluster NTFS
para o volume do contêiner de dados FILESTREAM seja definido para 64 KB, de modo a reduzir a
fragmentação. Isso deve ser feito manualmente, uma vez que o padrão para volumes NTFS de até 2 TB
(terabytes) é 4 KB. Para fazer isso, você pode usar a opção /A do comando de formato. Por exemplo, em
um prompt de comando, digite:
format F: /FS:NTFS /V:MyFILESTREAMContainer /A:64K
Essa configuração deve ser combinada com tamanhos de buffer maiores, conforme descrito na seção
"Considerações sobre avaliação e ajuste de desempenho", mais adiante neste white paper.
Gerenciando a fragmentação
Conforme descrito anteriormente, quando muitos arquivos em um volume aumentam, eles se tornam
fragmentados. Isso significa que a coleção de clusters alocada para o arquivo não é contígua. Quando
o arquivo é lido em sequência, os cabeçotes de disco subjacentes precisam ler todos os clusters em
sequência, o que pode significar que precisam ler diferentes partes do disco. Mesmo que os arquivos
não aumentem depois que são criados, se forem criados em um volume em que o espaço livre
disponível não esteja em uma única parte contígua, eles poderão ser fragmentados imediatamente,
pois os clusters necessários para acomodá-los não estão disponíveis de modo contíguo.
Essa fragmentação faz com que o desempenho sequencial de leitura seja menor do que quando não há
nenhuma (ou pouca) fragmentação. O problema é bastante semelhante ao da fragmentação do índice
em um banco de dados que reduz o desempenho de verificação do intervalo de consultas.
Portanto, é essencial que a fragmentação seja periodicamente removida com uma ferramenta de
desfragmentação de disco para manter o desempenho de leitura sequencial. Além disso, se o volume
que será usado para hospedar o contêiner de dados FILESTREAM foi usado anteriormente, ou se ele
ainda contiver outros dados, o nível de fragmentação deverá ser verificado e corrigido, se necessário.
13
Compactação
Os dados armazenados em NTFS podem ser compactados para economizar espaço em disco, mas
à custa de CPU adicional para compactar e descompactar os dados quando eles são gravados ou lidos,
respectivamente. A compactação também não será útil se os dados forem basicamente incompactáveis.
Por exemplo, dados aleatórios, dados criptografados ou dados que já tenham sido compactados não
terão uma boa compactação, mas mesmo assim deverão passar pelo algoritmo de compactação NTFS
e incorrerão em sobrecarga de CPU.
Por esses motivos, só faz sentido habilitar a compactação quando os dados puderem ser altamente
compactados e quando a CPU extra exigida não causar redução de desempenho da carga de trabalho.
Também deve ser observado que a compactação pode ser habilitada somente quando o tamanho do
cluster NTFS tem 4.096 bytes ou menos.
A compactação pode ser habilitada no volume do contêiner de dados FILESTREAM quando ele
é formatado com a opção /C do comando format. Por exemplo:
format F: /FS:NTFS /V:MyFILESTREAMContainer /A:4096 /C
Um volume existente também pode ser habilitado para compactação por meio das seguintes etapas:
1. Em Meu Computador ou no Windows Explorer, clique com o botão direito do mouse no volume
a ser compactado ou descompactado.
2. Clique em Propriedades para exibir a caixa de diálogo Propriedades.
3. Na guia Geral, marque ou desmarque a caixa de seleção Compactar disco para economizar
espaço e clique em OK.
4. Na caixa de diálogo Confirmar Alterações de Atributo, selecione se a compactação se aplica
ao volume inteiro ou somente à pasta raiz.
Isso é mostrado na figura a seguir.
14
Figura 2: Compactando um volume existente usando o Windows Explorer
Gerenciamento de espaço
Embora vários contêineres de dados FILESTREAM possam ser colocados em um único volume NTFS,
há motivo para ter um mapeamento 1:1 entre os contêineres de dados e os volumes NTFS. À exceção
do potencial para contenção dependente da carga de trabalho, não há como gerenciar o uso do espaço
do contêiner de dados FILESTREAM de dentro do SQL Server, portanto será necessário usar cotas de
disco NTFS se isso for uma exigência. As cotas de disco são rastreadas por usuário e por volume; por
isso o fato de ter vários contêineres de dados FILESTREAM em um único volume torna difícil saber qual
contêiner de dados está usando mais espaço em disco. Observe que todos os arquivos FILESTREAM
serão criados sob a conta de serviço do SQL Server. Se isso for alterado, o espaço em disco começará
a ser carregado para a nova conta de serviço.
Há um único driver de filtro do sistema de arquivos FILESTREAM para cada volume NTFS que tenha um
contêiner de dados FILESTREAM, assim como há um para cada versão do SQL Server que tenha um
contêiner de dados FILESTREAM no volume. Cada driver de filtro é responsável por gerenciar todos os
contêineres de dados FILESTREAM desse volume, para todas as instâncias que usam uma versão
específica do SQL Server.
15
Por exemplo, um volume NTFS que está hospedando três contêineres de dados FILESTREAM, um para
cada uma das três instâncias do SQL Server 2008, terá apenas um driver de filtro do sistema de arquivos
FILESTREAM do SQL Server 2008.
Segurança
Há dois requisitos de segurança para usar o recurso FILESTREAM. Em primeiro lugar, o SQL Server
deve ser configurado para a segurança integrada. Em segundo lugar, se o acesso remoto for usado,
a porta SMB (445) deverá ser habilitada em todos os sistemas de firewall. Esse requisito é o mesmo
exigido para acesso regular ao compartilhamento remoto. Para obter mais informações, consulte o artigo
da Base de Dados de Conhecimento "Visão geral de serviços e requisitos de porta de rede para
o sistema do Windows Server" (http://support.microsoft.com/kb/832017).
Considerações sobre antivírus
O software antivírus é onipresente no ambiente atual. O FILESTREAM não pode impedir o software
antivírus de verificar os arquivos no contêiner de dados FILESTREAM (isso criaria problemas de
segurança). Normalmente, o software tem uma configuração de política sobre o que fazer em um
arquivo que é suspeito de estar contaminado com um vírus: excluir o arquivo ou restringir o acesso a ele
(conhecido como colocar o arquivo em "quarentena"). Em ambos os casos, o acesso aos dados BLOB
no arquivo afetado será impedido e, para o SQL Server, o arquivo parecerá ter sido excluído.
É recomendável que o software antivírus seja definido para colocar arquivos em quarentena, não para
excluí-los. O DBCC CHECKDB pode ser usado no SQL Server para descobrir quais arquivos parecem
estar ausentes e, em seguida, o administrador do Windows pode correlacionar os nomes de arquivo com
o log do software antivírus e tomar uma medida corretiva.
Habilitando o FILESTREAM no Windows
O FILESTREAM é um recurso híbrido que exige que o administrador do Windows e o administrador
do SQL Server executem ações para que o recurso seja habilitado. Isso é necessário para preservar
a separação de tarefas entre os dois administradores, especialmente se o administrador do SQL Server
não for também o administrador do Windows. Habilitar o FILESTREAM no nível do Windows instala um
driver de filtro do sistema de arquivos, que é algo que somente um administrador do Windows tem
privilégios para fazer.
No nível do Windows, o FILESTREAM é habilitado durante a instalação do SQL Server 2008 ou pela
execução do SQL Server Configuration Manager. Veja as etapas a serem seguidas:
1.
2.
3.
4.
5.
6.
7.
16
No menu Iniciar, aponte para Todos os Programas, para Microsoft SQL Server 2008,
para Ferramentas de Configuração e clique em SQL Server Configuration Manager.
Na lista de serviços, clique com o botão direito do mouse em Serviços do SQL Server
e clique em Abrir.
No snap-in SQL Server Configuration Manager, localize a instância do SQL Server na qual
deseja habilitar o FILESTREAM.
Clique com o botão direito do mouse na instância e clique em Propriedades.
Na caixa de diálogo Propriedades do SQL Server, clique na guia FILESTREAM.
Marque a caixa de seleção Habilitar FILESTREAM para Acesso Transact-SQL.
Se desejar ler e gravar dados FILESTREAM do Windows, clique em Habilitar FILESTREAM
para acesso streaming de E/S de arquivo. Insira o nome do compartilhamento do
Windows na caixa Nome de Compartilhamento do Windows.
8.
9.
Se os clientes remotos precisarem acessar os dados FILESTREAM armazenados nesse
compartilhamento, selecione Permitir que os clientes remotos tenham acesso streaming
aos dados FILESTREAM.
Clique em Aplicar.
A figura a seguir mostra a guia FILESTREAM, conforme descrito no procedimento.
Figura 3: Configurando o FILESTREAM usando o SQL Server Configuration Manager
Esse procedimento deve ser concluído para cada instância do SQL Server que usará o recurso
FILESTREAM, para que ele possa ser usado pelo SQL Server. Observe que não há especificação do
contêiner de dados FILESTREAM nessa fase – que é feita quando um grupo de arquivos FILESTREAM
é criado em um banco de dados depois que FILESTREAM tiver sido habilitado no SQL Server.
Observe que é possível desabilitar o acesso ao FILESTREAM no nível do Windows mesmo que o SQL
Server o tenha habilitado. Nesse caso, depois que a instância do SQL Server for reiniciada, todos os
dados FILESTREAM estarão indisponíveis. O aviso a seguir será exibido.
17
Figura 4: Aviso exibido ao desabilitar o FILESTREAM usando o SQL Server Configuration Manager
Configurando o SQL Server para FILESTREAM
Cada instância do SQL Server que usará o recurso FILESTREAM deverá ser configurada
separadamente, tanto no nível do Windows como no do SQL Server. Depois que o FILESTREAM estiver
habilitado, um banco de dados deverá ser configurado para armazenar dados FILESTREAM, e só então
as tabelas que incluem colunas FILESTREAM poderão ser definidas. Esta seção descreve como configurar
o FILESTREAM no nível do SQL Server e como criar tabelas e bancos de dados habilitados para
FILESTREAM, além de explicar como o FILESTREAM interage com outros recursos do SQL Server 2008.
Considerações sobre segurança
O FILESTREAM requer o uso de segurança integrada (isto é, a Autenticação do Windows). Quando um
aplicativo que usa o Win32 tentar acessar dados FILESTREAM, o usuário do Windows será validado
por meio do SQL Server. Se o usuário tiver acesso Transact-SQL aos dados FILESTREAM, o acesso
também será concedido no nível do Win32, desde que o token de transação seja obtido no contexto de
segurança do usuário do Windows que está abrindo o arquivo.
O requisito para Autenticação do Windows se deve à natureza das APIs de E/S do Arquivo do Windows.
A única maneira de passar a identidade do cliente do aplicativo cliente para o SQL Server durante uma
operação de E/S de Arquivo é usar o token do Windows associado ao thread do cliente.
Quando o contêiner de dados FILESTREAM é criado, ele é automaticamente protegido para que apenas
a conta de serviço do SQL Server e os membros do grupo BUILTIN\Administradores possam acessar
a árvore de diretórios do contêiner de dados. É preciso tomar cuidado para que o conteúdo do contêiner
de dados nunca seja alterado, exceto por meio de métodos transacionais com suporte, pois a alteração
por outros métodos resultará na corrupção do contêiner.
Habilitando o FILESTREAM no SQL Server
A segunda etapa para habilitar o FILESTREAM é executada na instância do SQL Server 2008. Isso não
pode ser feito até que o FILESTREAM tenha sido habilitado no nível do Windows, e o volume NTFS que
armazenará os dados FILESTREAM tenha sido preparado adequadamente (conforme descrito na seção
anterior "Configurando o Windows para o FILESTREAM").
O acesso ao FILESTREAM é controlado no SQL Server usando sp_configure para definir a opção de
configuração filestream_access_level para uma das três configurações. As configurações possíveis são:



18
0 – desabilitar o suporte a FILESTREAM nesta instância
1 – habilitar FILESTREAM para acesso Transact-SQL
2 – habilitar FILESTREAM para acesso Transact-SQL e acesso streaming do Win32
O exemplo a seguir mostra como habilitar o FILESTREAM para Transact-SQL e acesso streaming do
Win32.
EXEC sp_configure filestream_access_level, 2;
GO
RECONFIGURE;
GO
A instrução RECONFIGURE é necessária para que o valor recém-configurado entre em vigor. Observe
que, se FILESTREAM não estiver habilitado no nível do Windows, ele não será habilitado no nível do
SQL Server quando o código acima for executado. O valor configurado atual pode ser localizado com
o código a seguir.
EXEC sp_configure filestream_access_level;
GO
Se FILESTREAM não estiver configurado no nível do Windows, "config_value" na saída sp_configure
será diferente (isto é, 0) de "run_value" depois que a instrução RECONFIGURE tiver sido executada.
Criando um banco de dados habilitado para FILESTREAM
Depois que FILESTREAM estiver habilitado nos níveis do Windows e do SQL Server, um contêiner de
dados FILESTREAM poderá ser definido. Faça isso definindo um grupo de arquivos FILESTREAM em
um banco de dados. Há um mapeamento 1:1 entre grupos de arquivos FILESTREAM e contêineres de
dados FILESTREAM.
Um grupo de arquivos FILESTREAM pode ser definido quando um banco de dados é criado, ou pode
ser criado separadamente com uma instrução ALTER DATABASE. O exemplo a seguir cria um grupo de
arquivos FILESTREAM em um banco de dados existente.
ALTER DATABASE Production ADD
FILEGROUP FileStreamGroup1 CONTAINS FILESTREAM;
GO
19
A cláusula CONTAINS FILESTREAM é necessária para distinguir o novo grupo de arquivos dos grupos
de arquivos normais de banco de dados. Se o recurso FILESTREAM for desabilitado, essa instrução
falhará com o erro a seguir.
Msg 5591, Level 16, State 3, Line 1
FILESTREAM feature is disabled.
Supondo-se que o FILESTREAM esteja habilitado nos níveis do Windows e do SQL Server, o grupo de
arquivos será criado. Nesse ponto, o contêiner de dados FILESTREAM é definido pela adição de um
único arquivo ao grupo de arquivos. O nome de caminho especificado é o nome do caminho do diretório
que será criado como a raiz do contêiner de dados. O nome de caminho inteiro até, mas não incluindo,
o nome do diretório final já devem existir. O exemplo a seguir define o contêiner de dados para o grupo
de arquivos FileStreamGroup1 criado anteriormente.
ALTER DATABASE Production ADD FILE (
NAME = FSGroup1File,
FILENAME = 'F:\Production\FSDATA')
TO FILEGROUP FileStreamGroup1;
GO
Neste ponto, o diretório FSDATA será criado. Ele estará vazio, com exceção de dois elementos:


O arquivo filestream.hdr. Este é o metadados FILESTREAM para o contêiner de dados.
O diretório $FSLOG. Esse é o equivalente FILESTREAM de um log de transações do banco
de dados.
Deve ser observado que um banco de dados pode ter vários grupos de arquivos FILESTREAM.
Isso pode ser útil para separar o armazenamento BLOB para várias tabelas no banco de dados.
Criando uma tabela para armazenar dados FILESTREAM
Assim que o banco de dados tiver um grupo de arquivos FILESTREAM, tabelas que contenham colunas
FILESTREAM poderão ser criadas. Como mencionado anteriormente, uma coluna FILESTREAM
é definida como uma coluna varbinary (max) que tem o atributo FILESTREAM. O código a seguir cria
uma tabela com uma única coluna FILESTREAM.
USE Production;
GO
20
CREATE TABLE DocumentStore (
DocumentID INT IDENTITY PRIMARY KEY,
Document VARBINARY (MAX) FILESTREAM NULL,
DocGUID UNIQUEIDENTIFIER NOT NULL ROWGUIDCOL
UNIQUE DEFAULT NEWID ())
FILESTREAM_ON FileStreamGroup1;
GO
Uma tabela pode ter várias colunas FILESTREAM, mas os dados de todas as colunas FILESTREAM
em uma tabela devem ser armazenados no mesmo grupo de arquivos FILESTREAM. Se a cláusula
FILESTREAM_ON não for especificada, qualquer grupo de arquivos FILESTREAM será definido para
ser o padrão que será usado. Essa pode não ser a configuração desejada e pode gerar problemas de
desempenho.
Uma vez que a tabela seja criada, o contêiner de dados FILESTREAM conterá outro diretório, correspondente
à tabela, com um subdiretório que corresponde à coluna FILESTREAM na tabela. Esse subdiretório
conterá os arquivos de dados uma vez que os dados sejam inseridos na tabela. A estrutura do diretório
variará conforme o número de colunas FILESTREAM na tabela e se a tabela é particionada ou não.
Observe que, para que uma tabela contenha uma ou mais colunas FILESTREAM, ela também deverá
conter uma coluna do tipo de dados uniqueidentifier que tenha o atributo ROWGUIDCOL. Essa coluna
não deve permitir valores nulos e deve ter uma restrição de coluna única UNIQUE ou PRIMARY KEY.
O valor GUID da coluna deve ser fornecido por um aplicativo na inserção de dados ou por uma restrição
DEFAULT que use a função NEWID() (ou NEWSEQUENTIALID() se a replicação de mesclagem estiver
configurada, conforme mencionado na seção "Combinações e restrições de recursos", mais adiante).
Para obter mais informações sobre os detalhes e as restrições no esquema de tabela necessário e sobre
as opções, consulte o tópico "CREATE TABLE (Transact-SQL)" nos Manuais Online do SQL Server 2008
(http://msdn.microsoft.com/pt-br/library/ms174979.aspx).
Configurando a coleta de lixo do FILESTREAM
Os arquivos de dados FILESTREAM no contêiner de dados FILESTREAM não podem ser parcialmente
atualizados. Isso significa que qualquer alteração nos dados BLOB da coluna FILESTREAM criará um
arquivo de dados FILESTREAM totalmente novo. O arquivo "antigo" deve ser preservado até que não
seja mais necessário para fins de recuperação. Os arquivos que representam dados FILESTREAM
excluídos, ou as inserções revertidas de dados FILESTREAM, são preservados de forma semelhante.
Os arquivos que não são mais necessários são removidos por um processo de coleta de lixo.
Esse processo é automático, ao contrário dos serviços do Windows SharePoint® Services, em que
a coleta de lixo deve ser implementada manualmente no repositório de BLOB externo.
21
Todas as operações de arquivo FILESTREAM são mapeadas para um LSN (número de sequência de
log) no log de transações do banco de dados. Uma vez que o log de transações tenha sido truncado
após a operação LSN do FILESTREAM, o arquivo não é mais necessário e pode ser coletado pela
lixeira. Desse modo, tudo que possa impedir o truncamento do log de transações também pode evitar
que um arquivo FILESTREAM seja excluído fisicamente. Alguns exemplos são:



Os backups de log não foram executados no modelo de recuperação FULL ou BULK_LOGGED.
Há uma transação ativa de execução longa.
O trabalho do leitor do log de replicação não foi executado.
A coleta de lixo do FILESTREAM é uma tarefa em segundo plano que é disparada pelo processo de
ponto de verificação do banco de dados. Um ponto de verificação será executado automaticamente
quando logs de transações suficientes tiverem sido gerados. Para obter mais informações, consulte
o tópico "PONTO DE VERIFICAÇÃO e a parte ativa do log" nos Manuais Online do SQL Server 2008
(http://msdn.microsoft.com/pt-br/library/ms189573.aspx). Considerando que as operações de arquivo
FILESTREAM são minimamente registradas no log de transações do banco de dados, pode demorar
um pouco para que o número de registros do log de transações gerado dispare um processo de ponto
de verificação e ocorra uma coleta de lixo. Se isso se tornar um problema, você poderá forçar a coleta
de lixo usando a instrução CHECKPOINT.
Considerações sobre particionamento
Se a tabela que contém dados FILESTREAM for particionada, a cláusula FILESTREAM_ON deverá
especificar um esquema de particionamento envolvendo grupos de arquivos FILESTREAM e baseados
na função de particionamento da tabela. Isso é necessário porque o esquema normal de particionamento
envolverá grupos de arquivos regulares que não podem ser usados para armazenar dados FILESTREAM.
A definição de tabela (em uma instrução CREATE TABLE ou CREATE CLUSTERED INDEX … WITH
DROP_EXISTING) especifica ambos os esquemas de particionamento.
O esquema de particionamento FILESTREAM pode especificar que todas as partições sejam mapeadas
para um único grupo de arquivos, mas isso não é recomendado porque pode resultar em problemas de
desempenho.
O exemplo (inventado) a seguir mostra essa sintaxe.
CREATE PARTITION FUNCTION DocPartFunction (INT)
AS RANGE RIGHT FOR VALUES (100000, 200000);
GO
CREATE PARTITION SCHEME DocPartScheme AS
PARTITION DocPartFunction TO (Data_FG1, Data_FG2, Data_FG3);
GO
22
CREATE PARTITION SCHEME DocFSPartScheme AS
PARTITION DocPartFunction TO (FS_FG1, FS_FG2, FS_FG3);
GO
CREATE TABLE DocumentStore (
DocumentID INT IDENTITY PRIMARY KEY,
Document VARBINARY (MAX) FILESTREAM NULL,
DocGUID UNIQUEIDENTIFIER NOT NULL ROWGUIDCOL
UNIQUE DEFAULT NEWID () ON Data_FG1)
ON DocPartScheme (DocumentID)
FILESTREAM_ON DocFSPartScheme;
GO
Observe que, para usar a coluna DocumentID como a coluna de particionamento, o índice não clusterizado
subjacente que aplica a restrição UNIQUE em DocGUID deve ser explicitamente colocado em um grupo
de arquivos, para que a coluna DocumentID possa ser a coluna de particionamento. Isso significa que
a alternância de partição será possível somente se as restrições UNIQUE forem desabilitadas antes da
execução da alternância de partição, já que são índices desalinhados, e reabilitadas posteriormente.
Continuando com o exemplo anterior, o código a seguir cria uma tabela e tenta uma alternância de partição.
CREATE TABLE NonPartitionedDocumentStore (
DocumentID INT IDENTITY PRIMARY KEY,
Document VARBINARY (MAX) FILESTREAM NULL,
DocGUID UNIQUEIDENTIFIER NOT NULL ROWGUIDCOL
UNIQUE DEFAULT NEWID ());
GO
ALTER TABLE DocumentStore SWITCH PARTITION 2 TO NonPartitionedDocumentStore;
GO
23
A alternância de partição falhará apresentando a mensagem a seguir.
Msg 7733, Level 16, State 4, Line 1
Falha na instrução ‘ALTER TABLE SWITCH’. A tabela
‘FileStreamTestDB.dbo.DocumentStore’ é particionada, enquanto o índice
‘UQ_Document_8CC1617F60ED59’ não é particionado.
Desabilitar o índice exclusivo na tabela de origem e tentar novamente fornece o código a seguir.
ALTER INDEX [UQ__Document__8CC331617F60ED59] ON DocumentStore DISABLE;
GO
ALTER TABLE FileStreamTest3 SWITCH PARTITION 2 TO NonPartitionedFileStreamTest3;
GO
Isso também falha, exibindo a mensagem a seguir.
Msg 4947, Leve 16, State 1, Line 1
Falha na instrução ALTER TABLE SWITCH. Não existe um índice idêntico na tabela de
origem ‘FileStreamTestDB.dbo.DocumentStore’ para o índice
‘UQ_NonParti_8CC3316103317E3D’ na tabela de destino
‘FileStreamTestDB.dbo.NonPartitionedDocumentStore’.
Os índices exclusivos nas tabelas particionadas e não particionadas devem ser desabilitados para que
a alternância possa prosseguir.
ALTER INDEX [UQ__NonParti__8CC3316103317E3D] ON NonPartitionedDocumentStore DISABLE;
GO
ALTER TABLE DocumentStore SWITCH PARTITION 2 TO NonPartitionedDocumentStore;
GO
ALTER INDEX [UQ__NonParti__8CC3316103317E3D] ON
NonPartitionedDocumentStore REBUILD WITH (ONLINE = ON);
24
ALTER INDEX [UQ__Document__8CC331617F60ED59] ON
NonPartitionedDocumentStore REBUILD WITH (ONLINE = ON);
GO
Mais informações sobre dados FILESTREAM de particionamento serão incluídas no próximo white paper
sobre particionamento no SQL Server 2008.
Balanceamento de carga de dados FILESTREAM
O particionamento também pode ser usado para criar um esquema da tabela que permita o balanceamento
de carga bruto de dados FILESTREAM entre vários volumes. Isso pode ser desejável por vários motivos,
como limitações de hardware ou para permitir que os pontos de acesso em uma tabela sejam armazenados
em diferentes volumes.
O código a seguir mostra uma função e um esquema de particionamento com base na coluna
uniqueidentifier, que efetivamente espalha os dados FILESTREAM por 16 volumes, enquanto distribui
os dados estruturados entre dois grupos de arquivos.
USE master;
GO
-- Create the database
CREATE DATABASE Production ON PRIMARY
(NAME = 'Production', FILENAME = 'E:\Production\Production.mdf'),
FILEGROUP DataFilegroup1
(NAME = 'Data_FG1', FILENAME = 'F:\Production\Data_FG1.ndf'),
FILEGROUP DataFilegroup2
(NAME = 'Data_FG2', FILENAME = 'G:\Production\Data_FG2.ndf'),
FILEGROUP FSFilegroup0 CONTAINS FILESTREAM
(NAME = 'FS_FG0', FILENAME = 'H:\Production\FS_FG0'),
FILEGROUP FSFilegroup1 CONTAINS FILESTREAM
(NAME = 'FS_FG1', FILENAME = 'I:\Production\FS_FG1'),
FILEGROUP FSFilegroup2 CONTAINS FILESTREAM
(NAME = 'FS_FG2', FILENAME = 'J:\Production\FS_FG2'),
25
FILEGROUP FSFilegroup3 CONTAINS FILESTREAM
(NAME = 'FS_FG3', FILENAME = 'K:\Production\FS_FG3'),
FILEGROUP FSFilegroup4 CONTAINS FILESTREAM
(NAME = 'FS_FG4', FILENAME = 'L:\Production\FS_FG4'),
FILEGROUP FSFilegroup5 CONTAINS FILESTREAM
(NAME = 'FS_FG5', FILENAME = 'M:\Production\FS_FG5'),
FILEGROUP FSFilegroup6 CONTAINS FILESTREAM
(NAME = 'FS_FG6', FILENAME = 'N:\Production\FS_FG6'),
FILEGROUP FSFilegroup7 CONTAINS FILESTREAM
(NAME = 'FS_FG7', FILENAME = 'O:\Production\FS_FG7'),
FILEGROUP FSFilegroup8 CONTAINS FILESTREAM
(NAME = 'FS_FG8', FILENAME = 'P:\Production\FS_FG8'),
FILEGROUP FSFilegroup9 CONTAINS FILESTREAM
(NAME = 'FS_FG9', FILENAME = 'Q:\Production\FS_FG9'),
FILEGROUP FSFilegroupA CONTAINS FILESTREAM
(NAME = 'FS_FGA', FILENAME = 'R:\Production\FS_FGA'),
FILEGROUP FSFilegroupB CONTAINS FILESTREAM
(NAME = 'FS_FGB', FILENAME = 'S:\Production\FS_FGB'),
FILEGROUP FSFilegroupC CONTAINS FILESTREAM
(NAME = 'FS_FGC', FILENAME = 'T:\Production\FS_FGC'),
FILEGROUP FSFilegroupD CONTAINS FILESTREAM
(NAME = 'FS_FGD', FILENAME = 'U:\Production\FS_FGD'),
FILEGROUP FSFilegroupE CONTAINS FILESTREAM
(NAME = 'FS_FGE', FILENAME = 'V:\Production\FS_FGE'),
FILEGROUP FSFilegroupF CONTAINS FILESTREAM
(NAME = 'FS_FGF', FILENAME = 'W:\Production\FS_FGF');
GO
26
USE Production;
GO
-- Create a partition function based on the last 6 bytes of the GUID
CREATE PARTITION FUNCTION LoadBalance_PF (UNIQUEIDENTIFIER)
AS RANGE LEFT FOR VALUES (
CONVERT (uniqueidentifier, '00000000-0000-0000-0000-100000000000'),
CONVERT (uniqueidentifier, '00000000-0000-0000-0000-200000000000'),
CONVERT (uniqueidentifier, '00000000-0000-0000-0000-300000000000'),
CONVERT (uniqueidentifier, '00000000-0000-0000-0000-400000000000'),
CONVERT (uniqueidentifier, '00000000-0000-0000-0000-500000000000'),
CONVERT (uniqueidentifier, '00000000-0000-0000-0000-600000000000'),
CONVERT (uniqueidentifier, '00000000-0000-0000-0000-700000000000'),
CONVERT (uniqueidentifier, '00000000-0000-0000-0000-800000000000'),
CONVERT (uniqueidentifier, '00000000-0000-0000-0000-900000000000'),
CONVERT (uniqueidentifier, '00000000-0000-0000-0000-a00000000000'),
CONVERT (uniqueidentifier, '00000000-0000-0000-0000-b00000000000'),
CONVERT (uniqueidentifier, '00000000-0000-0000-0000-c00000000000'),
CONVERT (uniqueidentifier, '00000000-0000-0000-0000-d00000000000'),
CONVERT (uniqueidentifier, '00000000-0000-0000-0000-e00000000000'),
CONVERT (uniqueidentifier, '00000000-0000-0000-0000-f00000000000'));
GO
-- Create a filestream partitioning scheme that allows mapping to 16 filestream
filegroups
CREATE PARTITION SCHEME LoadBalance_FS_PS
AS PARTITION LoadBalance_PF TO (
FSFileGroup0, FSFileGroup1, FSFileGroup2, FSFileGroup3,
27
FSFileGroup4, FSFileGroup5, FSFileGroup6, FSFileGroup7,
FSFileGroup8, FSFileGroup9, FSFileGroupA, FSFileGroupB,
FSFileGroupC, FSFileGroupD, FSFileGroupE, FSFileGroupF);
GO
-- Create a data partitioning scheme to round-robin between two filegroups
CREATE PARTITION SCHEME LoadBalance_Data_PS
AS PARTITION LoadBalance_PF TO (
DataFileGroup1, DataFileGroup2, DataFileGroup1, DataFileGroup2,
DataFileGroup1, DataFileGroup2, DataFileGroup1, DataFileGroup2,
DataFileGroup1, DataFileGroup2, DataFileGroup1, DataFileGroup2,
DataFileGroup1, DataFileGroup2, DataFileGroup1, DataFileGroup2);
GO
-- Create the partitioned table
CREATE TABLE DocumentStore (
DocumentID INT IDENTITY,
Document VARBINARY (MAX) FILESTREAM NULL,
DocGUID UNIQUEIDENTIFIER NOT NULL ROWGUIDCOL
DEFAULT NEWID (),
CONSTRAINT DocStorePK PRIMARY KEY CLUSTERED (DocGUID),
CONSTRAINT DocStoreU UNIQUE (DocGUID))
ON LoadBalance_Data_PS (DocGUID)
FILESTREAM_ON LoadBalance_FS_PS;
GO
28
O balanceamento de carga pode ser facilmente testado com o código a seguir.
SET NOCOUNT ON;
GO
-- Insert 10000 rows to test load balancing
DECLARE @count INT = 0;
WHILE (@count < 10000)
BEGIN
INSERT INTO DocumentStore DEFAULT VALUES;
SET @count = @count + 1;
END;
GO
-- Check the distribution
SELECT COUNT ($PARTITION.LoadBalance_PF (DocGUID))
FROM DocumentStore
GROUP BY $PARTITION.LoadBalance_PF (DocGUID);
GO
Os resultados da execução de um exemplo desse teste foram 631, 641, 661, 640, 649, 637, 618, 618,
576, 608, 595, 645, 640, 616, 602 e 623 linhas em cada um dos grupos de arquivos FILESTREAM
FS_FG0 a FS_FGF.
Combinações e limitações de recursos
Como o recurso FILESTREAM armazena dados no sistema de arquivos, há algumas restrições
e considerações quando o FILESTREAM é combinado com outros recursos do SQL Server. Esta seção
fornece uma visão geral das combinações de recursos que se deve conhecer. Para obter mais informações,
consulte o tópico "Usando o FILESTREAM com outros recursos do SQL Server" nos Manuais Online do
SQL Server 2008 (http://msdn.microsoft.com/pt-br/library/bb895334.aspx).
29
Replicação
A replicação transacional e a replicação de mesclagem oferecem suporte a dados FILESTREAM, mas há
muitas considerações como estas:




Quando a topologia de replicação engloba as instâncias que usam versões diferentes do SQL
Server, há limitações quanto ao tamanho dos dados que podem ser enviados a instâncias de
nível inferior.
As opções de filtro de replicação determinam se o atributo FILESTREAM será replicado ou não
usando a replicação transacional.
O tamanho máximo do valor de dados varbinary (max) que pode ser replicado na replicação
transacional sem replicar o atributo FILESTREAM é 2 GB.
Quando a replicação de mesclagem é usada, ela e o FILESTREAM exigem uma coluna
uniqueidentifier. É preciso ter cuidado com o esquema de tabela ao usar a replicação de
mesclagem para que os GUIDs sejam sequenciais (isto é, use NEWSEQUENTIALID() em vez
de NEWID()).
Espelhamento de banco de dados
O espelhamento de banco de dados não oferece suporte a FILESTREAM. Um grupo de arquivos
FILESTREAM não pode ser criado no servidor principal. O espelhamento de banco de dados não
pode ser configurado para um banco de dados que contenha grupos de arquivos FILESTREAM.
Criptografia
Os dados FILESTREAM não podem ser criptografados com métodos de criptografia do SQL Server.
Se a criptografia de dados transparente for habilitada, os dados FILESTREAM não serão criptografados.
Clustering de failover
O FILESTREAM tem suporte completo com clustering de failover. Todos os nós no cluster devem ter
o FILESTREAM habilitado no nível do Windows, e os contêineres de dados FILESTREAM devem ser
colocados no armazenamento compartilhado para que os dados sejam disponibilizados para todos os
nós. Para obter mais informações, consulte o tópico "Como configurar o FILESTREAM em um cluster de
failover" nos Manuais Online do SQL Server 2008 (http://msdn.microsoft.com/pt-br/library/cc645886.aspx).
Texto completo
A indexação de texto completo funciona com uma coluna FILESTREAM exatamente da mesma maneira
que com uma coluna varbinary (max). A tabela deve ter uma coluna extra que contenha a extensão de
nome de arquivo para os dados BLOB que estão sendo armazenados na coluna FILESTREAM.
Instantâneos de banco de dados
O SQL Server não oferece suporte a instantâneos de banco de dados para contêineres de dados
FILESTREAM. Se um arquivo de dados FILESTREAM for incluído em uma cláusula CREATE
DATABASE ON, a instrução falhará e um erro será gerado.
30
Se um banco de dados contiver dados FILESTREAM, ainda poderá ser criado um instantâneo de banco
de dados dos grupos de arquivos regulares. Nesse caso, uma mensagem de aviso será retornada e os
grupos de arquivos FILESTREAM serão marcados como offline no instantâneo de banco de dados.
As consultas funcionarão conforme o esperado no instantâneo de banco de dados, a menos que tentem
acessar os dados FILESTREAM. Se isso ocorrer, um erro será gerado.
Um banco de dados não poderá ser revertido para um instantâneo se o banco de dados contiver dados
FILESTREAM, pois não há como saber em que estado os dados FILESTREAM estavam no momento
representado pelo instantâneo de banco de dados.
Exibições, índices, estatísticas, gatilhos e restrições
As colunas FILESTREAM não podem fazer parte de uma chave de índice nem especificadas como uma
coluna INCLUDE em um índice não clusterizado. É possível definir uma coluna computada que faça
referência a uma coluna FILESTREAM, mas a coluna computada não pode ser indexada.
As estatísticas não podem ser criadas em colunas FILESTREAM.
Restrições PRIMARY KEY, FOREIGN KEY e UNIQUE não podem ser criadas em colunas
FILESTREAM.
As exibições indexadas não podem conter colunas FILESTREAM, mas as exibições não indexadas
podem.
Em vez disso, não é possível definir gatilhos em tabelas que contenham colunas FILESTREAM.
Níveis de isolamento
Quando os dados FILESTREAM são acessados por meio das APIs do Win32, apenas o nível de
isolamento confirmado por leitura tem suporte. O acesso Transact-SQL também permite os níveis de
isolamento serializáveis e de leitura repetida. Além disso, usando o acesso Transact-SQL, as leituras
sujas são permitidas por meio do nível de isolamento não confirmado por leitura ou pela dica de consulta
NOLOCK, mas esse acesso não mostrará atualizações em curso dos dados FILESTREAM.
Backup e restauração
O FILESTREAM funciona com todos os modelos de recuperação e todas as formas de backup
e restauração (completo, diferencial e log). Em caso de desastre, se a opção CONTINUE_AFTER_ERROR
for especificada em uma opção BACKUP ou RESTORE, os dados FILESTREAM talvez não possam
ser recuperados sem perda de dados (da mesma forma que a recuperação de dados regulares quando
CONTINUE_AFTER_ERROR é especificada).
Segurança
A instância do SQL Server deverá ser configurada para usar a segurança integrada se o acesso Win32
a dados FILESTREAM for necessário.
Envio de logs
O envio de logs oferece suporte a FILESTREAM. Os servidores primário e secundário devem estar
executando o SQL Server 2008 ou uma versão posterior e ter o FILESTREAM habilitado no nível do
Windows.
31
SQL Server Express
O SQL Server Express oferece suporte a FILESTREAM. O limite de tamanho do banco de dados de
4 GB não inclui o contêiner de dados FILESTREAM.
No entanto, se os dados FILESTREAM estiverem sendo enviados para dentro ou fora da instância
do SQL Server Express usando o Service Broker, será preciso ter cuidado, pois o Service Broker
não oferece suporte ao armazenamento de dados como FILESTREAM nas filas de transmissão ou de
destino. Isso significa que, se uma das filas aumentar, o limite de tamanho do banco de dados de 4 GB
poderá ser atingido.
Uma alternativa, nesse caso, é usar um esquema no qual a conversa do Service Broker transmita
notificações de que os dados FILESTREAM precisam ser enviados ou recebidos. A transmissão real dos
dados FILESTREAM é feita usando o acesso remoto por meio do compartilhamento do FILESTREAM do
contêiner de dados FILESTREAM da instância do SQL Server Express.
Considerações sobre avaliação e ajuste de desempenho
Há várias considerações importantes ao ajustar uma carga de trabalho FILESTREAM:






Verifique se o hardware está configurado corretamente para FILESTREAM.
Verifique se a geração de nomes 8.3 está desabilitada no NTFS.
Verifique se o rastreamento de hora do último acesso está desabilitado no NTFS.
Verifique se o contêiner de dados FILESTREAM não está em um volume fragmentado.
Verifique se o tamanho de dados BLOB é apropriado para armazenamento com FILESTREAM.
Verifique se os contêineres de dados FILESTREAM têm seus próprios volumes dedicados.
Um fator importante a ser destacado é o tamanho do buffer usado pelo protocolo SMB que é usado
para armazenar em buffer as leituras dos dados FILESTREAM. No teste em que o sistema operacional
Windows Server® 2003 foi usado, os tamanhos maiores de buffer tendem a obter melhores taxas de
transferências, com tamanhos de buffer de um múltiplo de, aproximadamente, 60 KB. Os tamanhos de
buffer maiores podem ser mais eficientes em outros sistemas operacionais.
Há considerações adicionais ao comparar uma carga de trabalho FILESTREAM com outras opções de
armazenamento (uma vez que a carga de trabalho FILESTREAM tenha sido ajustada):



32
Verifique se o hardware de armazenamento e o nível de RAID são os mesmos em ambos
os casos.
Verifique se a configuração de compactação de volume é a mesma em ambos os casos.
Leve em consideração se o FILESTREAM está executando write-through com base na API em
uso e nas opções especificadas.
Considerações sobre migração de dados
Um cenário comum de uso do SQL Server 2008 será a migração de dados BLOB existentes para
o armazenamento FILESTREAM. Embora fornecer uma ferramenta completa ou um conjunto de códigos
para executar migrações esteja além do escopo deste white paper, veja a seguir um fluxo de trabalho
simples a ser seguido:









Examine as considerações sobre o tamanho dos dados para uso de FILESTREAM a fim de
garantir que a média de tamanhos de dados envolvidos seja, assim como no armazenamento
do FILESTREAM, adequada.
Revise as informações disponíveis sobre combinações e limitações de recursos para garantir
que o armazenamento FILESTREAM funcione com todos os outros requisitos do aplicativo.
Siga as recomendações da seção anterior "Considerações sobre avaliação e ajuste de
desempenho".
Verifique se a instância do SQL Server está usando a segurança integrada e se o FILESTREAM
foi habilitado nos níveis do Windows e do SQL Server.
Verifique se o local do contêiner de dados FILESTREAM de destino tem espaço em disco
suficiente para armazenar os dados BLOB migrados.
Crie os grupos de arquivos FILESTREAM necessários.
Duplique os esquemas de tabela envolvidos, alterando as colunas BLOB necessárias para
serem FILESTREAM.
Migre todos os dados não BLOB para o novo esquema.
Migre todos os dados BLOB para as novas colunas FILESTREAM.
Práticas recomendadas de uso do FILESTREAM
Esta seção é uma coleção de práticas recomendadas que resultaram do uso do FILESTREAM durante
os testes internos e públicos de pré-lançamento do recurso. Assim como todas as práticas recomendadas,
essas são generalizações e podem não se aplicar a cada situação e cenário. As práticas recomendadas
seguem abaixo sem ordem específica:




33
Vários anexos pequenos a um arquivo FILESTREAM devem ser evitados sempre que possível,
pois cada anexo cria um arquivo FILESTREAM inteiramente novo. Isso poderia ser bastante
oneroso para arquivos FILESTREAM grandes. Se possível, vários anexos devem ser agrupados
juntos em uma coluna varbinary (max) e, em seguida, acrescentados à coluna FILESTREAM
quando um limite de tamanho é atingido.
Com uma carga de trabalho de gravação com intenso número de threads, considere
a possibilidade de configurar o parâmetro AllocationSize para as APIs OpenSqlFilestream ou
SqlFilestream. Os tamanhos de alocação inicial maiores limitarão o potencial de fragmentação
no nível de sistema de arquivos, especialmente quando combinados com um tamanho grande
de cluster NTFS, conforme descrito anteriormente.
Se os arquivos FILESTREAM forem grandes, evite as atualizações de Transact-SQL que
acrescentam ou pré-acrescentam dados a um arquivo. Isso (geralmente) armazenará dados
no spool em tempdb e novamente em um novo arquivo físico, o que afetará o desempenho.
Ao ler um valor FILESTREAM, considere o seguinte:
o Se as leituras exigirem apenas a leitura dos primeiros bytes, considere a funcionalidade
de subcadeia de caracteres.
o Se o arquivo inteiro deve ser lido, considere o acesso Win32.
o
o
o
Se partes aleatórias do arquivo devem ser lidas, considere abrir o identificador de
arquivo usando SetFilePointer.
Ao ler um arquivo inteiro, especifique o sinalizador FILE_SEQUENTIAL_ONLY.
Use os buffers feito sob medida em múltiplos de 60 KB (conforme descrito
anteriormente).
É possível atingir o tamanho de um arquivo FILESTREAM sem precisar abrir um identificador para
o arquivo adicionando uma coluna computada persistente à tabela que armazena o tamanho do arquivo
FILESTREAM. A coluna computada é atualizada quando o arquivo já está aberto para operações de
gravação.
Conclusão
Este white paper descreveu o recurso FILESTREAM do SQL Server 2008, que permite
o armazenamento de dados BLOB e o acesso eficiente a eles por meio de uma combinação
do SQL Server 2008 e do sistema de arquivos NTFS. Para concluir, vale reiterar os principais
pontos destacados neste white paper.
O armazenamento FILESTREAM não é apropriado em todos os casos. Com base na pesquisa
anterior e no comportamento do recurso FILESTREAM, os dados BLOB de 1 MB e maiores
que não serão acessados por Transact-SQL são mais bem armazenados como dados
FILESTREAM.
Também deve ser considerada a carga de trabalho de atualização, uma vez que qualquer
atualização parcial em um arquivo FILESTREAM gera uma cópia completa do arquivo.
Com uma carga de trabalho de atualização especialmente pesada, o desempenho pode se
apresentar de uma forma que o FILESTREAM não seja apropriado.
Os detalhes das combinações de recursos devem ser estudados para garantir que
a implantação seja bem-sucedida. Por exemplo, na versão RTM do SQL Server 2008,
o espelhamento de banco de dados não pode usar dados FILESTREAM, nem aproveitar
o isolamento de instantâneo. A maioria das outras combinações de recursos tem suporte,
mas algumas podem ter limitações (como a replicação). Este white paper não fornece uma
taxonomia exaustiva dos recursos e de sua interação, de modo que as seções mais recentes
dos Manuais Online do SQL Server devem ser verificadas antes da implantação, especialmente
porque algumas limitações poderão aumentar em versões futuras.
Por fim, se o FILESTREAM for implantado sem a configuração correta do Windows e do
SQL Server, os níveis de desempenho previstos talvez não sejam atingidos. As práticas
recomendadas e os detalhes de configuração descritos acima devem ser usados para ajudar
a evitar problemas de desempenho.
34
Para obter mais informações:
http://www.microsoft.com/sqlserver/: Site do SQL Server
http://technet.microsoft.com/pt-br/sqlserver/: TechCenter do SQL Server
http://msdn.microsoft.com/pt-br/sqlserver/: SQL Server DevCenter
Este documento ajudou você? Envie seus comentários. Em uma escala de 1 (ruim) a 5
(excelente), como você classificaria este white paper e por quê? Por exemplo:


Você está classificando-o como excelente devido aos bons exemplos, às excelentes
capturas de tela, à clareza do texto ou por outro motivo?
Você está classificando-o como ruim devido aos exemplos insatisfatórios, às capturas
de tela confusas ou ao texto mal-escrito?
Estes comentários nos ajudam a melhorar a qualidade dos white papers que lançamos.
Enviar comentários.
35