Outra pergunta de uma conversa com os gurus do SharePoint enquanto ensinava MCM ontem. As diretrizes do SharePoint indicam que não há suporte para bancos de dados de conteúdo acima de 100 GB. Sem entrar nos motivos por trás dessas diretrizes, estou interessado em saber mais sobre bancos de dados de conteúdomaiormais de 100 GB e suas experiências com eles (principalmente em relação a desempenho, recuperação de desastres e provisionamento de alta disponibilidade).
Até onde você conseguiu levar a instalação do SharePoint? Ouvi histórias de segunda mão sobre bancos de dados de conteúdo com > 1 TB, mas gostaria de ouvir histórias dos próprios administradores do SharePoint.
Obrigado por qualquer informação que você tenha.
Responder1
Temos bancos de dados de 111 e 102 GB, respectivamente, cujo backup é feito 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 vi nenhuma demonstração disso.
Uma boa citação do whitepaper "Scaling SharePoint 2007: Storage Architecture":
"...Isso é comumente referido como “limitação de tamanho do banco de dados de conteúdo de 100 GB”. Na verdade, esta não é uma limitação verdadeira, mas sim uma recomendação. Os bancos de dados SQL Server têm escalado muito além de 100 GB há anos. Na prática, o A recomendação baseia-se principalmente em dois fatores significativos:
Os requisitos do Acordo de Nível de Serviço (SLA) para uma determinada organização podem determinar 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 o backup.
O subsistema de armazenamento deve ser robusto o suficiente para lidar com os requisitos de E/S de disco da solução SharePoint que ele atende.
Contanto 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 tiveram implantações bem-sucedidas do SharePoint que implementaram tamanhos de bancos de dados de 100 GB, 150 GB, 200 GB, 250 GB, 300 GB, 350 GB e 400 GB."
Responder2
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 levarão mais tempo com bancos de dados grandes. No entanto, desde que o banco de dados não exceda o que pode ser copiado durante a noite, 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ê encontrará 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 no espaço livre e são implementados usando consultas que podem fazer coisas como acionar o crescimento automático fora de controle.
Responder3
Temos um banco de dados de conteúdo com 300 GB de tamanho. Não há problemas com backups após mudar para Lite Speed. Antes da mudança, veríamos uma grave degradação do desempenho dos sites.
Só para constar, NÃO queríamos 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 teriam sido muito difíceis de implementar se tivéssemos colocado o conteúdo em conjuntos de sites separados.
Quando entramos no ar pela primeira vez, tivemos grandes problemas de bloqueio do banco de dados durante o pico de uso. Rastreamos isso até o uso do objeto CrossListQueryCache no SharePoint. Deixamos de usar essa API e ela corrigiu grande parte do nosso desempenho.
Escrevi um pequeno artigo no blog com mais informaçõesaqui.
Ainda vemos problemas de bloqueio com certos tipos de atualizações (exclusão de blobs > 20 MB), renomeação de webs (isso pode causar atualizações em muitos registros na tabela AllUserData. Estamos trabalhando com o suporte da MS em casos específicos (ou seja, remoção de itens grandes da lixeira ). Isso remonta à maneira 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 a MS comunicar isso às pessoas era dizer para ficar abaixo de 100 GB.
Sugiro enviar um ping para o pessoal da MS IT... Ouvi oficialmente que eles têm um banco de dados de conteúdo do SharePoint> 800 GB.
Responder4
Isso é falso. Não há limites quanto ao 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 sua infraestrutura SQL.