Taille maximale des bases de données de contenu SharePoint

Une autre question de parler aux gourous de SharePoint tout en enseignant MCM hier. Les directives SharePoint sont que les bases de données de contenu supérieures à 100 Go ne sont pas prises en charge. Sans entrer dans les raisons de ces directives, je suis intéressé d'entendre parler des bases de données de contenu de plus de 100 Go et de vos expériences avec elles (principalement en termes de performances, de reprise après sinistre et de provisioning HA).

Jusqu'où avez-vous réussi à pousser votre installation SharePoint? J'ai entendu des histoires de seconde main sur des bases de données de contenu> 1 To, mais j'aimerais entendre les administrateurs SharePoint eux-mêmes.

Merci pour toute information dont vous disposez.

Nous avons une base de données de 111 et 102 Go, respectivement, qui sont sauvegardées en moins de 30 minutes sur un réseau GigE. J'ai entendu dire que des bases de données plus importantes peuvent avoir des problèmes avec les procédures stockées de longue durée, mais je n'en ai vu aucune démonstration.

Une belle citation tirée du livre blanc "Scaling SharePoint 2007: Storage Architecture":

"... Ceci est communément appelé la" limitation de la taille de la base de données de contenu de 100 Go ". En fait, il ne s'agit pas d'une véritable limitation, mais plutôt d'une recommandation. Les bases de données SQL Server ont évolué bien au-delà de 100 Go depuis des années maintenant. la recommandation est basée principalement sur deux facteurs importants:

1. Les exigences de SLA (Service Level Agreement) pour une organisation donnée peuvent imposer que les opérations de sauvegarde des bases de données SharePoint soient exécutables dans un laps de temps limité. La taille des bases de données de contenu aura un impact direct sur le temps nécessaire à l'exécution de cette sauvegarde.

2. Le sous-système de stockage doit être suffisamment robuste pour gérer les exigences d'E / S disque de la solution SharePoint qu'il dessert.

Tant qu'une organisation donnée est en mesure d'atténuer ces deux considérations, les bases de données de contenu peuvent alors se développer. Les implémentations dans le monde réel ont connu des déploiements SharePoint réussis qui ont mis en œuvre des tailles de base de données de 100 Go, 150 Go, 200 Go, 250 Go, 300 Go, 350 Go et 400 Go. "

Pour une utilisation quotidienne, la taille de la base de données n'est pas si importante - la plupart des requêtes renvoient les éléments dans une liste et peu importe ce qui se trouve dans la base de données. Cependant, les opérations qui fonctionnent sur l'ensemble de la base de données deviendront plus difficiles. Les sauvegardes sont l'exemple le plus évident - elles prendront plus de temps avec de grandes bases de données. Cependant, tant que la base de données ne dépasse pas ce qui peut être sauvegardé du jour au lendemain, tout ira bien - les sauvegardes sont conçues pour durer longtemps et sont assez fiables tant que vous ne manquez pas d'espace disque.

Là où vous rencontrerez de vrais problèmes, c'est avec des choses moins fréquentes comme le déplacement ou la mise à niveau des bases de données de contenu - celles-ci peuvent nécessiter environ 5 fois la taille de la base de données dans l'espace libre et sont implémentées à l'aide de requêtes qui peuvent faire des choses comme déclencher une croissance automatique hors contrôle.

Nous avons une base de données de contenu d'une taille de 300 Go. Aucun problème avec les sauvegardes après le passage à Lite Speed. Avant le changement, nous constaterions une grave dégradation des performances des sites Web.

Pour mémoire, nous ne voulions PAS avoir une base de données de contenu aussi grande. Nous avions des exigences commerciales spécifiques concernant le partage de contenu qui auraient été très difficiles à mettre en œuvre si nous avions placé le contenu dans des collections de sites distinctes.

Lors de notre première mise en service, nous avons rencontré des problèmes de verrouillage majeurs avec la base de données lors des pics d'utilisation. Nous avons retracé cela à l'utilisation de l'objet CrossListQueryCache dans SharePoint. Nous avons changé d'utiliser cette API et cela a fixé une grande partie de nos performances.

J'ai écrit un petit article de blog avec plus d'informations ici .

Nous voyons toujours des problèmes de verrouillage avec certains types de mises à jour (suppression des objets blob> 20 Mo), renommer des sites Web (cela peut entraîner des mises à jour de nombreux enregistrements dans la table AllUserData. Nous travaillons avec MS Support sur des cas spécifiques (c'est-à-dire la suppression de gros éléments de la corbeille) Ceux-ci ont été retracés à la façon dont des procédures stockées spécifiques dans SharePoint suppriment des données, mais nous n'avons pas encore de solution.

Personnellement, je pense que des problèmes surviennent après que vous obteniez autant d'enregistrements dans la table AllUserData et que la manière la plus simple pour MS de communiquer cela aux gens était de rester en dessous de 100 Go.

Je suggère de cingler les gens de MS IT ... J'ai entendu dire qu'ils avaient une base de données de contenu SharePoint> 800 Go.

Notre entreprise dispose actuellement d'une base de données de 140 Mo. Nous constatons un ralentissement des performances dans une liste particulière qui a été autorisée à atteindre 1,5 Go, qui contient des pièces jointes, y compris plusieurs versions de pièces jointes. (Je ne suis là que depuis 2 mois d'ailleurs). Nous prévoyons maintenant une migration et il semble que la migration vers SP 2010 à l'aide de l'outil Metalogix pourrait prendre des jours à réaliser en fonction de nos tests. La nôtre est une base de données mal conçue, un portail mal conçu qui a maintenant ceux d'entre nous qui doivent le gérer avec de vrais problèmes.

Nous avons un site de sauvegarde que nous utilisons qui est une copie exacte de notre environnement de production. Mais le matériel est notre ancien matériel après notre dernière mise à jour matérielle - Ancien matériel pour le développement, nouveau pour la production. Cependant, certains domaines de notre environnement de développement sont inutilisables en raison de problèmes de performances obligeant certains développements dans de grandes listes à être effectués en production. Ouch, Ouch, Ouch ....

C'est faux. Il n'y a pas de limites sur la taille. Ils recommandent de ne pas avoir de grandes bases de données mais uniquement pour faciliter la gestion des bases de données et minimiser le temps de sauvegarde / restauration. Nous pourrions dire que la limitation de taille dépend uniquement de votre infrastructure SQL.