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

Question

Outra pergunta é falar com os gurus do SharePoint enquanto leciona MCM ontem. As diretrizes do SharePoint são de 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 os bancos de dados de conteúdo maiores do que 100 GB e suas experiências com eles (principalmente em desempenho, recuperação de desastres e provisionamento de alta disponibilidade).

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

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

    

Answer 1

Temos DBs de 111 e 102 GB, respectivamente, que são armazenados em menos de 30 minutos em uma rede GigE. Ouvi dizer que bancos de dados maiores podem ter problemas com procedimentos armazenados de longa duração, mas não viram nenhuma demonstração dele.

Uma boa cotação do white paper "Dimensionando o SharePoint 2007: Arquitetura de armazenamento":

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

1. Os requisitos do Acordo de Nível de Serviço (SLA) para uma determinada organização podem ditar que as operações de backup dos bancos de dados do SharePoint devem ser executáveis em um período de tempo limitado. O tamanho dos bancos de dados de conteúdo terá um impacto direto no tempo necessário 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 possa atenuar essas duas considerações, os bancos de dados de conteúdo poderão crescer. As implementações do mundo real viram implementações de SharePoint bem-sucedidas que implementaram tamanhos de banco de dados de 100 GB, 150 GB, 200 GB, 250 GB, 300 GB, 350 GB e 400 GB. "

    

Answer 2

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 esteja 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 demoram mais com grandes bancos de dados. No entanto, desde que o banco de dados não exceda o que pode ser armazenado durante a noite, você estará ok - os backups são projetados para serem de longa duração e são bastante confiáveis, contanto que você não fique sem espaço em disco.

Onde você se deparará com 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 o autogrow .

    

Answer 3

Temos um banco de dados de conteúdo com 300 GB de tamanho. Não há problemas com backups depois de mudar para o Lite Speed. Antes da mudança, veríamos sérios problemas de degradação de desempenho em sites da Web.

Para o registro, não queremos ter um banco de dados de conteúdo tão grande. Tínhamos requisitos de negócios 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 pela primeira vez, tivemos grandes problemas de bloqueio com o banco de dados durante o pico de uso. Nós rastreamos isso de volta ao uso do objeto CrossListQueryCache no SharePoint. Mudamos de usar essa API e consertamos muito nosso desempenho.

Eu escrevi um pequeno artigo no blog com mais informações aqui .

Ainda vemos problemas de bloqueio com determinados tipos de atualizações (exclusão de blobs > 20 MB), renomeação de webs (isso pode causar atualizações em vários registros na tabela AllUserData. Estamos trabalhando com o suporte MS em casos específicos itens da lixeira. Esses foram rastreados até a forma como procedimentos armazenados específicos no SharePoint estão excluindo dados, mas ainda não temos uma solução.

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

Sugiro fazer ping para as pessoas na MS IT ... Ouvi dizer que eles têm um banco de dados de conteúdo do SharePoint > 800 GB.

    

Answer 4

Nossa empresa tem um banco de dados atualmente em 140Mb. Estamos tendo um desempenho lento em uma lista específica que recebeu permissão para crescer até 1.5Gb, que contém anexos, incluindo várias versões de anexos. (Eu só tenho estado lá cerca de 2 meses pelo caminho). Estamos agora planejando uma migração e parece que migrar para o SP 2010 usando a ferramenta Metalogix pode levar dias para ser concluído com base em nossos testes. O nosso é um banco de dados mal projetado, portal mal projetado, que agora tem que ser gerenciado por nós 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 depois da 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, o que faz com que algum desenvolvimento em grandes listas tenha que ser feito na produção. Ai, ai, ai ....

    

Answer 5

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