Tamaño máximo de bases de datos de contenido de SharePoint

Otra pregunta de hablar con los gurús de SharePoint mientras enseñaba MCM ayer. Las pautas de SharePoint son que las bases de datos de contenido superiores a 100 GB no son compatibles. Sin entrar en las razones detrás de esas pautas, me interesa saber sobre bases de datos de contenido de más de 100 GB y sus experiencias con ellas (principalmente en relación con el rendimiento, la recuperación ante desastres y el aprovisionamiento de alta disponibilidad).

¿Hasta dónde has logrado llevar tu instalación de SharePoint? He escuchado historias de segunda mano de bases de datos de contenido> 1TB, pero me gustaría saber de los propios administradores de SharePoint.

Gracias por cualquier información que tengas.

Tenemos una base de datos de 111 y 102 GB, respectivamente, que se respalda en menos de 30 minutos en una red GigE. He oído que las bases de datos más grandes pueden tener problemas con los procedimientos almacenados de larga ejecución, pero no he visto ninguna demostración de ello.

Una buena cita del documento técnico "Scaling SharePoint 2007: Storage Architecture":

"... Esto se conoce comúnmente como la" limitación de tamaño de la base de datos de contenido de 100 GB ". De hecho, esto no es una verdadera limitación, sino más bien una recomendación. Las bases de datos de SQL Server han estado escalando mucho más allá de 100 GB durante años. En términos prácticos, el La recomendación se basa principalmente en dos factores importantes:

1. Los requisitos del Acuerdo de nivel de servicio (SLA) para una organización determinada pueden dictar que las operaciones de copia de seguridad para las bases de datos de SharePoint deben ser ejecutables en un período de tiempo limitado. El tamaño de las bases de datos de contenido tendrá un impacto directo en el tiempo que lleva ejecutar esa copia de seguridad.

2. El subsistema de almacenamiento debe ser lo suficientemente robusto para manejar los requisitos de E / S de disco de la solución de SharePoint a la que sirve.

Mientras una organización determinada pueda mitigar estas dos consideraciones, se puede permitir que las bases de datos de contenido crezcan. Las implementaciones del mundo real han visto implementaciones exitosas de SharePoint que han implementado tamaños de base de datos de 100GB, 150GB, 200GB, 250GB, 300GB, 350GB y 400GB ".

Para el uso diario, el tamaño de la base de datos no es tan importante: la mayoría de las consultas devuelven los elementos en una lista y no importa qué más hay en la base de datos. Sin embargo, las operaciones que funcionan en toda la base de datos serán más difíciles. Las copias de seguridad son el ejemplo más obvio: tomarán más tiempo con grandes bases de datos. Sin embargo, siempre y cuando la base de datos no supere lo que se puede hacer una copia de seguridad durante la noche, estará bien: las copias de seguridad están diseñadas para durar mucho tiempo y son bastante confiables siempre que no se quede sin espacio en disco.

Donde se encontrará con problemas reales es con cosas menos frecuentes, como mover o actualizar bases de datos de contenido; estas pueden requerir aproximadamente 5 veces el tamaño de la base de datos en espacio libre y se implementan mediante consultas que pueden hacer cosas como desencadenar el crecimiento automático fuera de control.

Tenemos una base de datos de contenido de 300 GB de tamaño. No hay problemas con las copias de seguridad después de cambiar a Lite Speed. Antes del cambio, veríamos una grave degradación del rendimiento con los sitios web.

Para el registro, NO queríamos tener una base de datos de contenido tan grande. Teníamos requisitos comerciales específicos sobre el intercambio de contenido que habría sido muy difícil de implementar si hubiéramos puesto el contenido en colecciones de sitios separadas.

Cuando comenzamos a funcionar, tuvimos problemas importantes de bloqueo con la base de datos durante el uso pico. Hemos rastreado esto hasta el uso del objeto CrossListQueryCache en SharePoint. Cambiamos de usar esa API y solucionó gran parte de nuestro rendimiento.

Escribí un pequeño artículo de blog con más información aquí .

Todavía vemos problemas de bloqueo con ciertos tipos de actualizaciones (eliminación de blobs> 20 MB), cambio de nombre de las webs (esto puede causar actualizaciones a muchos registros en la tabla AllUserData. Estamos trabajando con MS Support en casos específicos (es decir, eliminar elementos grandes de la papelera de reciclaje) Estos se remontan a la forma en que los procedimientos almacenados específicos en SharePoint están eliminando datos, pero todavía no tenemos una solución.

Personalmente, creo que los problemas ocurren después de obtener tantos registros en la tabla AllUserData y la forma más fácil para que MS comunique esto a las personas es decir mantenerse por debajo de 100 GB.

Sugiero hacer ping a las personas en MS IT ... He escuchado extraoficialmente que tienen un SharePoint Content DB> 800 GB.

Nuestra compañía tiene una base de datos actualmente en 140Mb. Estamos experimentando un rendimiento lento en una lista particular que se ha permitido crecer a 1.5 Gb que contiene archivos adjuntos que incluyen múltiples versiones de archivos adjuntos. (Por cierto, solo he estado allí unos 2 meses). Ahora estamos planeando una migración y parece que migrar a SP 2010 con la herramienta Metalogix podría llevar días para lograrlo según nuestras pruebas. La nuestra es una base de datos mal diseñada, un portal mal diseñado que ahora nos obliga a administrarlo con problemas reales.

Tenemos un sitio de respaldo que utilizamos, que es una copia exacta de nuestro entorno de producción. Pero el hardware es nuestro hardware ANTIGUO después de nuestra última actualización de hardware: hardware antiguo para desarrollo, nuevo para producción. Sin embargo, algunas áreas de nuestro entorno de desarrollo no se pueden utilizar debido a problemas de rendimiento que obligan a realizar algunos desarrollos en listas grandes en la producción. Ay, ay, ay ...

Eso es falso No hay límites sobre el tamaño. Recomiendan no tener grandes bases de datos, sino solo para facilitar la gestión de la base de datos y minimizar el tiempo de copia de seguridad / restauración. Podríamos decir que la limitación de tamaño depende solo de su infraestructura de SQL.