Tamanho máximo dos bancos de dados de conteúdo do SharePoint

Outra questão é conversar com os gurus do SharePoint enquanto ensinava o MCM ontem. As diretrizes do SharePoint são que os bancos de dados de conteúdo acima de 100 GB não são suportados. Sem entrar nas razões por trás dessas diretrizes, estou interessado em ouvir sobre bancos de dados de conteúdo maiores que 100 GB e suas experiências com eles (principalmente sobre desempenho, recuperação de desastres e provisionamento de alta disponibilidade).

Até onde você conseguiu enviar sua instalação do SharePoint? Ouvi histórias de segunda mão de bancos de dados de conteúdo> 1 TB, mas gostaria de ouvir os próprios administradores do SharePoint.

Obrigado por qualquer informação que você tem.

Temos um banco de dados de 111 e 102 GB, respectivamente, com backup em menos de 30 minutos em uma rede GigE. Ouvi dizer que bancos de dados maiores podem ter problemas com procedimentos armazenados de longa execução, mas não vi nenhuma demonstração disso.

Uma boa citação do white paper "Escalonando o SharePoint 2007: Arquitetura de Armazenamento":

"... Isso geralmente é chamado de" limitação do tamanho do banco de dados de 100 GB de conteúdo ". Na verdade, essa não é uma limitação verdadeira, mas uma recomendação. Os bancos de dados do SQL Server estão escalando muito além dos 100 GB há anos. Praticamente falando, o A recomendação baseia-se principalmente em dois fatores significativos:

1. Os requisitos do Contrato de nível de serviço (SLA) para uma determinada organização podem exigir que as operações de backup dos bancos de dados do SharePoint sejam executáveis ​​em um período limitado de tempo. O tamanho dos bancos de dados de conteúdo terá um impacto direto em quanto tempo leva para executar esse backup.

2. O subsistema de armazenamento deve ser robusto o suficiente para lidar com os requisitos de E / S de disco da solução do SharePoint que ele atende.

Desde que uma determinada organização seja capaz de mitigar essas duas considerações, os bancos de dados de conteúdo poderão crescer. As implementações no mundo real viram implantações bem-sucedidas do SharePoint que implementaram tamanhos de banco de dados de 100 GB, 150 GB, 200 GB, 250 GB, 300 GB, 350 GB e 400 GB ".

Para o uso diário, o tamanho do banco de dados não é tão importante - a maioria das consultas retorna os itens em uma lista e não importa o que mais há no banco de dados. No entanto, as operações que funcionam em todo o banco de dados se tornarão mais difíceis. Os backups são o exemplo mais óbvio - eles levarão mais tempo com bancos de dados grandes. No entanto, desde que o banco de dados não exceda o que pode ser feito o backup da noite para o dia, você estará bem - os backups são projetados para serem de longa duração e são bastante confiáveis, desde que você não fique sem espaço em disco.

Onde você encontra problemas reais é com coisas menos frequentes, como mover ou atualizar bancos de dados de conteúdo - eles podem exigir cerca de 5 vezes o tamanho do banco de dados em espaço livre e são implementados usando consultas que podem fazer coisas como disparar automaticamente o crescimento fora de controle.

Temos um banco de dados de conteúdo com 300 GB de tamanho. Não há problemas com os backups depois de mudar para o Lite Speed. Antes da troca, veríamos uma grave degradação do desempenho nos sites.

Para o registro, NÃO queremos ter um banco de dados de conteúdo tão grande. Tínhamos requisitos comerciais específicos em relação ao compartilhamento de conteúdo que seriam muito difíceis de implementar se tivéssemos colocado o conteúdo em conjuntos de sites separados.

Quando fomos ao ar, tivemos grandes problemas de bloqueio com o banco de dados durante o pico de uso. Rastreamos isso de volta ao uso do objeto CrossListQueryCache no SharePoint. Mudamos de usar essa API e ela corrigiu muito do nosso desempenho.

Escrevi um pequeno artigo de blog com mais informações aqui .

Ainda vemos problemas de bloqueio com certos tipos de atualizações (exclusão de blobs> 20 MB), renomeando Webs (isso pode causar atualizações em muitos registros na tabela AllUserData. Estamos trabalhando com o suporte da Microsoft em casos específicos (por exemplo, removendo itens grandes da lixeira) Eles foram rastreados até a maneira como procedimentos armazenados específicos no SharePoint estão excluindo dados, mas ainda não temos uma solução.

Pessoalmente, acho que os problemas ocorrem depois que você obtém tantos registros na tabela AllUserData e a maneira mais fácil de a Microsoft comunicar isso às pessoas era ficar abaixo de 100 GB.

Sugiro fazer ping nas pessoas da MS IT ... Ouvi dizer que elas têm um DB de conteúdo do SharePoint> 800 GB.

Nossa empresa possui um banco de dados atualmente em 140Mb. Estamos com um desempenho lento em uma lista específica que pode crescer para 1,5 Gb, que contém anexos, incluindo várias versões de anexos. (Eu só estive lá cerca de 2 meses a propósito). Agora, estamos planejando uma migração e parece que migrar para o SP 2010 usando a ferramenta Metalogix pode levar dias para ser realizado com base em nossos testes. O nosso é um banco de dados mal projetado, portal mal projetado, que agora exige que nós tenhamos que gerenciá-lo com problemas reais.

Temos um site de backup que usamos, que é uma cópia exata do nosso ambiente de produção. Mas o hardware é nosso hardware antigo após nossa última atualização de hardware - hardware antigo para desenvolvimento, novo para produção. Algumas áreas do nosso ambiente de desenvolvimento, no entanto, são inutilizáveis ​​devido a problemas de desempenho que obrigam o desenvolvimento de grandes listas a serem feitas na produção. Ai, ai, ai ....

Isso é falso. Não há limites para o tamanho. Eles recomendam não ter grandes bancos de dados, mas apenas para facilitar o gerenciamento de dados e minimizar o tempo de backup / restauração. Poderíamos dizer que a limitação de tamanho depende apenas da sua infra-estrutura SQL.