Dentro do SharePoint Criando uma solução de armazenamento externo para SharePoint

Pav Cherny

Download do código disponível em: ChernySharePoint2009_06.exe(2,006 KB)

Conteúdo

Armazenamento binário interno
Armazenamento binário externo
Criando um provedor EBS não gerenciado
Criando um provedor EBS gerenciado
Registrar um provedor EBS no SharePoint
Implementação de coleta de lixo
Conclusão

Microsoft estima que quanto 80 % dos dados armazenados no Microsoft Windows SharePoint Services (WSS) 3.0 e Microsoft Office SharePoint Server (MOSS) 2007 bancos de dados de conteúdo é dados não-relacional grande BLOB (objeto binário), tais como documentos do Microsoft Office Word, planilhas do Microsoft Office Excel e apresentações do Microsoft Office PowerPoint. Apenas 20 % é metadados relacional, que implica um uso inferior dos recursos do Microsoft SQL Server no backend do banco de dados. SharePoint não tirar proveito das recentes inovações do SQL Server para dados não estruturados introduzidos no SQL Server 2008, tais como o atributo FILESTREAM ou a API do armazenamento BLOB remota, mas fornece suas próprias opções para aumentar a eficiência de armazenamento e a capacidade de gerenciamento de volumes de dados grande.

Especificamente, o SharePoint inclui um provedor de armazenamento externo binário API, ISPExternalBinaryProvider, que Microsoft primeiro publicado como um hotfix em maio de 2007 e incorporada posterior ao Service Pack 1. A API ISPExternalBinaryProvider é separada da API do armazenamento BLOB remoto. Fornecedores de terceiros podem usar essa API para integrar o SharePoint com soluções de armazenamento avançadas, como sistemas de armazenamento endereçável de conteúdo (CAS). Você também pode usar essa API para manter os dados BLOB do SharePoint em um servidor de arquivos central fora do banco de dados de conteúdo se você quiser criar uma solução personalizada para aumentar a eficiência de armazenamento e a escalabilidade em um farm do SharePoint. Tenha em mente, entretanto, que essa API é específica para o WSS 3.0 e o MOSS 2007. Será alterada na próxima versão SharePoint, que significa que você terá que atualizar o seu provedor.

Nesta coluna, aborde como estender a arquitetura de armazenamento do SharePoint usando a API de ISPExternalBinaryProvider, incluindo as vantagens e desvantagens, detalhes de implementação, considerações sobre o desempenho e coleta de lixo. Também discutir uma compatibilidade de 64 bits da Microsoft Visual Studio que podem causar SharePoint Falha ao carregar gerenciados componentes ISPExternalBinaryProvider apesar de uma implementação de interface correta. Onde for apropriado, consulte a documentação do ISPExternalBinaryProvider no SDK do WSS 3.0. Outra referência que vale a pena mencionar é Blog do Kyle Tillman.

Kyle faz um ótimo trabalho explicando como ele dominado as barreiras de implementação em código gerenciado, mas o SDK do WSS 3.0 nem do Kyle postagem de blog inclui um projeto de exemplo do Visual Studio, portanto, decidi fornecer amostras de ISPExternalBinaryProvider no código não gerenciado e gerenciado no material de complementar desta coluna. O objetivo desses exemplos é ajudá-lo a começar se você estiver interessado em integração soluções de armazenamento externo com o SharePoint. Lembre-se, contudo, que esses exemplos são não testados e não está pronto para uso em produção.

Armazenamento binário interno

Por padrão, o SharePoint armazena dados BLOB na coluna de conteúdo da tabela AllDocStreams no banco de dados de conteúdo. A vantagem óbvia essa abordagem é simples consistência transacional entre dados relacionais e o conteúdo de arquivo não-relacional associado. Por exemplo, ele não é complicada para inserir os metadados de um documento do Word juntamente com o conteúdo não estruturado em um banco de dados de conteúdo, nem é complicada para associar metadados com o conteúdo não estruturado correspondente selecione, atualização ou exclusão de operações. No entanto, a desvantagem mais óbvia a abordagem padrão é um uso ineficiente de recursos de armazenamento. Apesar de um subsistema de E/s otimizado para alto desempenho, o mecanismo de armazenamento do SQL Server é não exatamente uma substituição de servidor de arquivos.

Um banco de dados do SQL Server consiste em arquivos de log e dados da transação, conforme ilustrado na Figura 1 . Para garantir comportamento transacional confiável, SQL Server primeiro grava todos os registros de transação no arquivo de log antes de ele libera os dados correspondentes em páginas de 8 KB para o arquivo de dados no disco. Dependendo do modelo de recuperação selecionado, isso requer mais duas vezes o tamanho do BLOB na capacidade de armazenamento até que você executa um backup e limpar o log de transações. Além disso, o SQL Server não armazena conteúdo do SharePoint não estruturado diretamente em páginas de dados. Em vez disso, o SQL Server usa uma coleção separada de páginas de texto/imagem e armazena apenas um ponteiro de texto de 16 bytes para o nó de raiz do BLOB na linha de dados. Páginas de texto/imagem são organizadas em uma árvore balanceada, ainda existe apenas um conjunto de páginas de texto/imagem para cada tabela. Para a tabela AllDocStreams, isso significa que o conteúdo de todos os arquivos é espalhado por texto/imagem mesmo conjunto de páginas. Uma página de texto/imagem simples pode conter fragmentos de dados de vários BLOBs ou ele pode armazenar nós intermediários de BLOBs maior do que 32 KB em tamanho.

Figura 1 armazenamento de BLOB padrão do SharePoint no SQL Server

Vamos não mergulhar profundamente em internos do SQL Server, no entanto. A questão é que quando ler o conteúdo não estruturado, SQL Server deve passar por linha de dados para obter o ponteiro de texto e, em seguida, através de nó raiz e, possivelmente, outros nós intermediários para localizar todos os dados do BLOB fragmentos espalhados por qualquer número de páginas de texto/imagem que o SQL Server devem carregar na memória por completo para obter todos os blocos de dados. Isso ocorre porque o SQL Server executa operações de E/s no nível da página. Essas complexidades prejudicar o desempenho de arquivos-fluxo contínuo em comparação com acesso direto pelo sistema de arquivo. SQL Server também impõe um limite de tamanho do disco rígido de 2 GB no SharePoint porque este é a capacidade máxima do tipo de dados de imagem. A coluna conteúda da tabela AllDocStreams é uma coluna de imagem, portanto você não pode armazenar arquivos maiores do que 2 GB em um banco de dados de conteúdo do SharePoint.

Armazenamento binário externo

A API ISPExternalBinaryProvider oferece uma alternativa inteligente para armazenamento BLOB interno no SharePoint bancos de dados de conteúdo. É uma interface COM simples com apenas dois métodos (StoreBinary e RetrieveBinary), que você pode usar para implementar um provedor de armazenamento externo binário (EBS). Para obter detalhes de arquitetura, consulte o tópico" Arquitetura de armazenamento BLOB externo"no SDK WSS 3.0.

SharePoint carrega provedor EBS quando você definir a propriedade ExternalBinaryStoreClassId do objeto SPFarm local (SPFarm.Local.ExternalBinaryStoreClassId) para o identificador de classe COM do provedor (CLSID). SharePoint, em seguida, chama o método de StoreBinary do provedor sempre que você enviar dados BLOB, tais como quando você estiver carregando um arquivo em uma biblioteca de documentos. O provedor EBS pode optar por armazenar o BLOB em seu sistema de armazenamento externo associado e retornar um identificador BLOB correspondente (ID de BLOB) ao SharePoint, ou ele pode definir o parâmetro pfAccepted no método StoreBinary como false para indicar que ele não manipular o BLOB. No último caso, o SharePoint armazena o BLOB no banco de dados de conteúdo como de costume. Por outro lado, se o provedor EBS aceita o BLOB, SharePoint apenas insere a identificação de BLOB a coluna de conteúdo da tabela AllDocStreams, conforme indicado na Figura 2 . A identificação de BLOB pode ser qualquer valor que permite que o provedor EBS localizar o conteúdo no sistema de armazenamento externo, como um nome de arquivo, um caminho de arquivo, um identificador global exclusivo (GUID) ou um resumo de conteúdo. Provedores de exemplo incluídos no material complementar, por exemplo, usar GUIDs como nomes de arquivo para identificação confiável de BLOBs em um servidor de arquivos.

A Figura 2 armazenando um BLOB de SharePoint em um sistema de armazenamento externo

SharePoint também mantém controle dos arquivos armazenados externamente definindo o bit de DocFlags mais alto desses arquivos como 1. DocFlags é uma coluna da tabela AllDocs. Quando um usuário solicita para baixar um arquivo armazenado externamente, o SharePoint verifica DocFlags e passa o valor de conteúdo da tabela AllDocStreams para o método RetrieveBinary do provedor de EBS. Como resposta à chamada RetrieveBinary, o o provedor EBS deve recuperar o BLOB indicado do sistema de armazenamento externo e retornar o conteúdo binário para o SharePoint no formulário de um objeto COM que implementa a interface ILockBytes. Observe que SharePoint não chama o método RetrieveBinary para BLOBs armazenados diretamente no banco de dados do conteúdo.

Observe também que os processos de armazenamento e recuperação são transparentes para o usuário, desde que o usuário não tentar ignorar SharePoint. Portanto, você não precisará substituir internos Web parts pelas versões personalizadas que metadados de empate em uma lista com um documento armazenado externamente; aplicativos de produtividade, como o Microsoft Office, não precisam saber como armazenar metadados em um local e, em seguida, o documento em outro; e pesquisa não precisa processar os metadados separados dos documentos. Além disso e isso é uma das minhas vantagens favoritas da arquitetura do provedor EBS, o usuário precisa passar por SharePoint para acessar armazenados externamente dados BLOB. Um usuário ignorar SharePoint e diretamente acessando um banco de dados de conteúdo por meio de uma conexão do SQL Server termina download BLOB identificações em vez do conteúdo do arquivo real, como ilustrado na Figura 3 . Você pode verificar esse comportamento se você implantar a SQL download de Web Part (que eu usado na coluna abril de 2009 para demonstrar como ignorar a proteção de RMS do AD de SharePoint) em um ambiente de teste. Além disso, os usuários não precisam — e não deve ter — permissões para o armazenamento externo do BLOB de acesso. Somente contas de segurança do SharePoint requerem acesso porque o SharePoint chama os métodos do provedor EBS no contexto de segurança da conta de pool de aplicativo do site.

A Figura 3 EBS O provedor pode ser um obstáculo para ignorar permissões de SharePoint para downloads de arquivo

Tenha em mente, entretanto, que provedores de EBS também têm desvantagens devido à complexidade de manutenção de integridade entre metadados nos bancos de dados conteúdo do farm do SharePoint e o armazenamento BLOB externo. Para obter uma boa abordagem dos prós e contras, confira o tópico" Limites operacionais e análise de Trade-Off"no SDK WSS 3.0. Verifique se que você ler este tópico muito importante antes de implementá um provedor EBS em um ambiente do SharePoint.

Criando um provedor EBS não gerenciado

Agora vamos lidar com os desafios da criação EBS provedores. A interface ISPExternalBinaryProvider é bem documentada no WSS 3.0 SDK em" A interface de acesso do BLOB: ISPExternalBinaryProvider." No entanto, ele parece que Microsoft esqueceu abordar os detalhes de provedor EBS. Afinal, nós estão não apenas consumindo a interface de um servidor COM existente. Nós são incumbidos de criação desse servidor COM sozinhos e implementar a interface ISPExternalBinaryProvider. Mais importante, o SDK do WSS 3.0 não mencione o tipo de servidor COM que deveriam compilação e o modelo de segmentação necessário. Um servidor COM clássico pode executar fora de processo ou em processo e ele pode oferecem suporte ao modelo single-threaded apartment (STA), o modelo do MTA (multithreaded apartment ou ambos, ou o modelo de segmentação livre. Para o provedor de EBS funcione corretamente, verifique se que você criar um thread-safe em processo COM servidor que suporta o modelo de segmentação "dois" para STAs e o MTA.

Você também precisará pensar sobre qual linguagem de programação para usar. Isso é importante porque a interface ISPExternalBinaryProvider é a API de nível mais baixo do SharePoint. Problemas de desempenho podem afetar o farm do SharePoint inteiro. Por esse motivo, recomendo o uso uma linguagem que permite que você criar pequeno e rápido objetos COM, tais como Visual C++ e ATL (Active Template Library). ATL fornece classes de C++ útil para simplificar o desenvolvimento de servidores do thread-safe COM em código não gerenciado com o nível correto de suporte a segmentação.

O Visual Studio também inclui uma variedade de assistentes ATL. Apenas criar um projeto ATL, selecione a biblioteca de vínculo dinâmico (DLL) para o tipo de servidor, cópia a definição de interface ISPExternalBinaryProvider do WSS 3.0 SDK no arquivo interface definition language (IDL) do seu projeto ATL, adicione uma nova classe para um objeto ATL simples, selecione "both" como o modelo de threading e nenhuma agregação, em seguida, clique com o botão direito do mouse a nova classe, aponte para Add, clique em implementar interface e selecione ISPExternalBinaryProvider. Isso é tudo! O Assistente de interface de implementar executa todas as tubulações necessária, para que você possa se concentrar na implementação os métodos StoreBinary e RetrieveBinary.

E não deixe que o código C++ não gerenciado intimide você. Se você analisar o arquivo SampleStore.cpp no material complementar, você pode ver que as implementações StoreBinary e RetrieveBinary são relativamente simples. Basicamente, o método de StoreBinary exemplo constrói um caminho de arquivo com base em um valor de registro StorePath, a identificação do site passado do SharePoint e um GUID gerada para o BLOB e, em seguida, usa a função Win32 WriteFile para salvar os dados binários obtidos a instância ILockBytes. O método de RetrieveBinary de exemplo, por outro lado, constrói o caminho do arquivo com base no mesmo valor do Registro StorePath, a identificação do site e a identificação de BLOB passado do SharePoint e usa a função ReadFile do Win32 para recuperar os dados não estruturados, que o provedor EBS copia para uma nova instância de ILockBytes que, em seguida, passa para o SharePoint. a Figura 4 ilustra como o provedor EBS constrói o caminho do arquivo.

A Figura 4 construir caminhos de arquivo para operações StoreBinary e RetrieveBinary nos provedores de EBS exemplo

Criando um provedor EBS gerenciado

Obviamente, SharePoint, os desenvolvedores podem preferir usar familiarizados idiomas gerenciados para criar provedores EBS, mesmo que criar gerenciado EBS provedores não é necessariamente menos complicado do que criar provedores não gerenciados devido à complexidade de interoperabilidade de COM. Tenha em mente que um aplicativo escrito em código não gerenciado só pode carregar uma versão do common language runtime (CLR), portanto, seu código precisará funcionar com a mesma versão do CLR que está usando o restante do SharePoint, caso contrário, você pode terminar com um comportamento inesperado. Além disso, você ainda deve lidar com interfaces não gerenciados e o empacotamento correspondente de parâmetros e de buffers. Apenas compare SampleStore.cpp com SampleStore.cs no material complementar. Não há nenhum ganhos usando uma linguagem gerenciada em termos de estrutura de código ou programação simplicidade.

Além disso, esteja ciente das questões de compatibilidade de 64 bits se você desenvolver provedores EBS gerenciados na plataforma x 64. a Figura 5 mostra um erro típica que resulta das configurações de registro COM inválido em um computador de desenvolvimento. Se você habilitar a Register for COM interop caixa de seleção nas propriedades do projeto no Visual Studio 2005 ou Visual Studio 2008, você acabará com configurações de registro COM do seu provedor no Registro em HKEY_CLASSES_ROOT\Wow6432Node\CLSID\ <providerclsid>. Visual Studio usa a versão de 32 bits da ferramenta de registro do assembly (regasm.exe) mesmo na plataforma x 64.

A Figura 5 devido a configurações de registro COM inválido, um provedor EBS gerenciado não pôde ser carregado

No entanto, a versão de 64 bits do SharePoint não é possível carregar um servidor de COM 32 bits registrado em Wow6432Node, para que você deve registrar manualmente seu provedor EBS gerenciado usando a versão de regasm.exe 64-bit, localizada no diretório %WINDIR%\Microsoft.NET\Framework64\v2.0.50727. Por exemplo, o comando % WINDIR%\Microsoft.NET\Framework64\v2.0.50727\Regasm.exe ManagedProvider.dll cria as configurações do Registro necessária para o provedor gerenciado de exemplo em HKEY_CLASSES_ROOT\CLSID\ <providerclsid>. Outra abordagem é criar um programa de instalação e marcar o provedor EBS para registro COM automático.

Lembre-se também de que provedores de EBS gerenciados acompanham penalidades de sobrecarga e o desempenho significativamente mais suas contrapartes não gerenciado ATL. Você pode ver isso se você comparar as configurações de registro COM no registro. Como a revela chave InProcServer32, o tempo de execução COM carrega não gerenciados EBS provedor DLLs diretamente, enquanto os provedores gerenciados de EBS dependem mscoree.dll como o servidor no procedimento, o que é o mecanismo principal do CLR. Portanto, para provedores gerenciados, o tempo de execução COM carrega o CLR e, em seguida, o CLR carrega o assembly de provedor EBS conforme registrado sob a chave do assembly e cria um proxy CCW (COM Callable Wrapper) para manipular a interação entre o cliente do SharePoint não gerenciado (Owssvr.dll) e o provedor EBS gerenciado.

Tenha em mente que o servidor não gerenciado do SharePoint não interage diretamente com o provedor gerenciado. É a CCW que empacota os parâmetros, chama os métodos gerenciados e manipula HRESULTs. Este engano é especialmente evidente nos diferentes tipos de retorno de métodos gerenciados em comparação para métodos não gerenciados. Não gerenciados métodos retornam HRESULTs para indicar êxito ou falhas enquanto métodos gerenciados devem para ter o tipo de retorno void. Portanto, não retorna HRESULTs explícitas no código gerenciado. Você deve aumentar o sistema ou exceções de definido pelo usuário em resposta a condições de erro. Se um método gerenciado for concluída sem exceção, a CCW retorna automaticamente S_OK para o cliente não gerenciado.

Por outro lado, se um método gerenciado gera uma exceção, a CCW mapeia os códigos de erro e mensagens para HRESULTs e informações de erro. A CCW implementa várias interfaces de tratamento de erros para essa finalidade, como ISupportErrorInfo e IErrorInfo, mas o SharePoint não tirar proveito dessas interfaces. Provedores de EBS devem implementar seu próprio relatório por meio de log de eventos do Windows, SharePoint logs de diagnóstico, arquivos de rastreamento ou outros meios de erros. SharePoint espera apenas os valores HRESULT S_OK para êxito e E_FAIL para qualquer erro. Você pode use o método Marshal.ThrowExceptionForHR para retornar E_FAIL para o SharePoint, conforme demonstrado no SampleStore.cs.

Registrar um provedor EBS no SharePoint

Facilmente a seção mais confusa sobre ISPExternalBinaryProvider no SDK do WSS 3.0 é o tópico" Instalando e configurando O provedor de BLOB." No momento da elaboração deste documento, esta seção foi preenchida com informações e erros falsos. Até mesmo os comandos do Windows PowerShell estavam incorretos. Se você atribuir o provedor EBS a $ yourProviderConfig e depois usar $ providerConfig.ProviderCLSID, não se surpreenda ao receber um erro informando que providerConfig $ não existe. Claro, você ainda não acessar este ponto porque as propriedades do Active Directory e ProviderCLSID não fazem parte da interface ISPExternalBinaryProvider. Essas propriedades misteriosas pertencem a uma interface dupla que não é abordada a documentação. Apenas por diversão, implementei uma versão de exemplo no código não gerenciado e gerenciado, mas sua implementação ISPExternalBinaryProvider não exige essas propriedades de proprietárias em todos os.

A propriedade ProviderCLSID pode ser útil, mas o CLSID é também disponível no Registro se você procurar o ProgID, como UnmanagedProvider.SampleStore ou ManagedProvider.SampleStore, e você também pode encontrar os CLSIDs nos arquivos de código SampleStore.rgs e SampleStore.cs. Como mencionado anteriormente, definindo a propriedade ExternalBinaryStoreClassId do objeto SPFarm local para o CLSID registra o provedor EBS. Definindo a propriedade ExternalBinaryStoreClassId do objeto SPFarm local como um GUID vazio ("00000000-0000-0000-0000-000000000000") remove o registro do provedor EBS. Não se esqueça de chamar método de atualização do objeto SPFarm para salvar as alterações no banco de dados de configuração e reinicie o Internet Information Services (IIS). A listagem de código a seguir ilustra como realizar essas tarefas no Windows PowerShell:

[System.Reflection.Assembly]::LoadWithPartialName('Microsoft.SharePoint')
$farm = [Microsoft.SharePoint.Administration.SPFarm]::Local

# Registering the CLSID of an EBS provider
$farm.ExternalBinaryStoreClassId = "C4A543C2-B7DB-419F-8C79-68B8842EC005"
$farm.Update()
IISRESET

# Removing the EBS provider registration
$farm.ExternalBinaryStoreClassId = "00000000-0000-0000-0000-000000000000"
$farm.Update()
IISRESET

Implementação de coleta de lixo

Outra seção no SDK do WSS 3.0 com componentes de misteriosas e trechos de código crítico é intitulada" Implementação de coleta de lixo lento." No momento da elaboração deste documento, esta seção continha referências a outra classe utilitário misteriosas com métodos DirFromSiteId e FileFromBlobid bem como uma atribuição incorreta de Directory.GetFiles resultados em uma matriz de FileInfo, mas vamos não ser muito exigentes na qualidade de documentação do WSS 3.0. Os métodos de auxiliar DirFromSiteId e FileFromBlobid revelam suas finalidades através de seus nomes e a matriz de FileInfo incorreta facilmente é substituída por uma matriz de seqüência de caracteres, ou você pode substituir o método Directory.GetFiles por uma chamada para o método GetFiles de um objeto DirectoryInfo. O programa de exemplo do coletor de lixo no material complementar usa a abordagem DirectoryInfo e segue a seqüência sugerida de etapas para coleta de lixo.

Um importante desvio da amostra de coletor de lixo das explicações SDK diz respeito a manipulação de condições de tempo. Isso é um problema crítico porque condições de tempo podem levar a misidentification e a exclusão de arquivos válidos durante a coleta de lixo. Dê uma olhada na Figura 6 , que ilustra a abordagem do WSS 3.0 SDK–recommended para determinar os arquivos órfãos enumerar todos os arquivos BLOB no armazenamento de EBS e, em seguida, removendo todas essas referências da lista BLOB que ainda estão em banco de dados de conteúdo conforme indicado pela coleção de ExternalBinaryIds do site. As referências restantes na lista de BLOB devem para indicar arquivos órfãos que devem ser excluídos.

A Figura 6 Misidentification de um BLOB válido como " órfão " devido a uma condição de tempo

No entanto, o provedor EBS deve, obviamente, primeiro terminar de escrever dados BLOB antes que possa retornar uma identificação de BLOB para o SharePoint. Dependendo do largura de banda de rede e outras condições, o desempenho de E/s pode flutuar. Portanto, há uma chance de que o provedor EBS foi possível criar um novo BLOB — que, em seguida, aparece na sua lista BLOB — mas conclui a gravar os dados BLOB de após ter determinado o ExternalBinaryIds portanto, a identificação de BLOB ainda não está presente nessa coleção. Da mesma forma, a referência para o novo BLOB permanece na lista de BLOB órfão e se você remover os BLOBs órfãos neste ponto, você acidentalmente excluir um item de conteúdo válido e perda de dados! Para evitar esse problema, o exemplo de coletor de lixo úteis das chaves verifica a hora de criação arquivo e adiciona apenas os itens à lista BLOB que são mais de uma hora anterior.

Conclusão

Ao integrar uma solução de armazenamento externo com o SharePoint, você pode aumentar a eficiência de armazenamento, o desempenho do sistema e a escalabilidade de um farm do SharePoint. Outra vantagem é que isso força os usuários a atravessar SharePoint para acessar o conteúdo não estruturado. Somente receber dados de conteúdo bancos de dados por meio de conexões diretas do SQL Server gera identificadores BLOB binários em vez dos arquivos reais. No entanto, provedores de EBS também tem desvantagens devido à complexidade de manutenção de integridade entre metadados nos bancos de dados conteúdo do farm do SharePoint e o armazenamento BLOB externo.

Para integrar o SharePoint com uma solução de armazenamento externo, você deve criar um provedor de EBS, que é um servidor COM que implementa a interface de ISPExternalBinaryProvider com seus métodos StoreBinary e RetrieveBinary. Você pode criar não gerenciado e gerenciado EBS provedores, mas lembre de problemas de desempenho e compatibilidade se você decidir usar código gerenciado. Também tenha em mente que a interface ISPExternalBinaryProvider não inclui um método DeleteBinary. Você deve explicitamente remover BLOBs órfãos pela coleção lixo lenta e tome cuidado para evitar condições de tempo que podem causar a exclusão acidental de itens BLOB válidos.

pav Cherny é um especialista IT e autor especializado em tecnologias Microsoft para colaboração e a comunicação unificada. Suas publicações incluem informes oficiais, manuais de produto e livros com um foco em operações de TI e administração do sistema. Pav é presidente da Biblioso Corporation, uma empresa especializada em serviços de documentação e localização gerenciados.