download.microsoft.comdownload.microsoft.com/.../filestreamstorage.docx · web viewisso garante...

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çãoNa 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 BLOBEmbora 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:

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.

2

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

Solução de armazenamentoServidor de arquivos / sistema de arquivos

SQL Server (usando varbinary(max))

FILESTREAM

Tamanho máximo do BLOB

Tamanho do volume NTFS

2 GB – 1 byte Tamanho do volume NTFS

Desempenho do streaming de BLOBs grandes

Excelente Fraco Excelente

Segurança ACLs manuais Integrada ACLs integradas + automáticas

Custo por GB Baixo Alto BaixoCapacidade de gerenciamento

Difícil Integrada Integrada

Integração com dados estruturados

Difícil Consistência no nível de dados

Consistência no nível de dados

Desenvolvimento e implantação de aplicativos

Mais complexo Mais simples Mais simples

Recuperação da fragmentação de dados

Excelente Fraca Excelente

Desempenho de atualizações frequentes e pequenas

Excelente Moderado Fraco

3

http://research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2006-45

Tabela 1: Comparação de tecnologias de armazenamento de BLOB anteriores ao SQL Server 2008

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 FILESTREAMO 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 duplaDepois 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 Transact-SQL 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

http://msdn.microsoft.com/pt-br/library/cc645962.aspx

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

http://technet.microsoft.com/pt-br/library/cc627407.aspx

Quando usar FILESTREAMEmbora 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 FILESTREAMAssim 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 hardwareUma 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ísicoLembre-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

http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/pdpliobp.mspx

http://www.microsoft.com/technet/prodtechnol/sql/2005/physdbstor.mspx

http://www.microsoft.com/technet/prodtechnol/sql/2005/physdbstor.mspx

Escolha do nível de RAIDOs 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 unidadeEm 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

http://www.microsoft.com/technet/prodtechnol/sql/2005/iobasics.mspx

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 NTFSMesmo 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

http://technet.microsoft.com/pt-br/library/bb457112.aspx

http://technet.microsoft.com/pt-br/library/cc758691.aspx

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

http://support.microsoft.com/kb/140365

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írusO 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 WindowsO 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. 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.

2. Na lista de serviços, clique com o botão direito do mouse em Serviços do SQL Server e clique em Abrir.

3. No snap-in SQL Server Configuration Manager, localize a instância do SQL Server na qual deseja habilitar o FILESTREAM.

4. Clique com o botão direito do mouse na instância e clique em Propriedades.5. Na caixa de diálogo Propriedades do SQL Server, clique na guia FILESTREAM.6. Marque a caixa de seleção Habilitar FILESTREAM para Acesso Transact-SQL.7. 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.

16

http://support.microsoft.com/kb/832017

8. Se os clientes remotos precisarem acessar os dados FILESTREAM armazenados nesse compartilhamento, selecione Permitir que os clientes remotos tenham acesso streaming aos dados FILESTREAM.

9. 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 FILESTREAMCada 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çaO 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 ServerA 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:

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

18

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 FILESTREAMDepois 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 FILESTREAMAssim 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 FILESTREAMOs 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

http://msdn.microsoft.com/pt-br/library/ms174979.aspx

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 particionamentoSe 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

http://msdn.microsoft.com/pt-br/library/ms189573.aspx

CREATE PARTITION SCHEME DocFSPartScheme AS

PARTITION DocPartFunction TO (FS_FG1, FS_FG2, FS_FG3);

GO





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 (




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

24

NonPartitionedDocumentStore REBUILD WITH (ONLINE = ON);

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 FILESTREAMO 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'),


(NAME = 'FS_FG1', FILENAME = 'I:\Production\FS_FG1'),


25

(NAME = 'FS_FG2', FILENAME = 'J:\Production\FS_FG2'),


(NAME = 'FS_FG3', FILENAME = 'K:\Production\FS_FG3'),


(NAME = 'FS_FG4', FILENAME = 'L:\Production\FS_FG4'),


(NAME = 'FS_FG5', FILENAME = 'M:\Production\FS_FG5'),


(NAME = 'FS_FG6', FILENAME = 'N:\Production\FS_FG6'),


(NAME = 'FS_FG7', FILENAME = 'O:\Production\FS_FG7'),


(NAME = 'FS_FG8', FILENAME = 'P:\Production\FS_FG8'),


(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-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 (

27

FSFileGroup0, FSFileGroup1, FSFileGroup2, FSFileGroup3,

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);

GO

-- Create the partitioned table


DocumentID INT IDENTITY,



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 recursosComo 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

http://msdn.microsoft.com/pt-br/library/bb895334.aspx

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 desempenhoHá 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):

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.

32

Considerações sobre migração de dadosUm 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 FILESTREAMEsta 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:

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.

33

o Se partes aleatórias do arquivo devem ser lidas, considere abrir o identificador de arquivo usando SetFilePointer.

o Ao ler um arquivo inteiro, especifique o sinalizador FILE_SEQUENTIAL_ONLY.o 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ãoEste 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

mailto:[email protected]?subject=Coment%E1rios%20sobre%20o%20white%20paper:%20Armazenamento%20FILESTREAM%20no%20SQL%20Server%202008

http://msdn.microsoft.com/pt-br/sqlserver/

http://technet.microsoft.com/pt-br/sqlserver/

http://www.microsoft.com/sqlserver/

download.microsoft.comdownload.microsoft.com/.../filestreamstorage.docx · web viewisso garante...

Documents