Otra pregunta de una conversación con los gurús de SharePoint mientras enseñaba MCM ayer. Las pautas de SharePoint indican que no se admiten bases de datos de contenido de más de 100 GB. Sin entrar en las razones detrás de esas pautas, me interesa saber más sobre las bases de datos de contenido.más grandede 100 GB y sus experiencias con ellos (principalmente en torno al rendimiento, la recuperación ante desastres y el aprovisionamiento de HA).
¿Hasta dónde ha logrado impulsar su instalación de SharePoint? He escuchado historias de segunda mano sobre bases de datos de contenido de > 1 TB, pero me gustaría escucharlas de los propios administradores de SharePoint.
Gracias por cualquier información que tengas.
Respuesta1
Tenemos bases de datos de 111 y 102 GB, respectivamente, de las que se realiza una copia de seguridad 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 ejecución prolongada, pero no he visto ninguna demostración de ello.
Una buena cita del documento técnico "Scaling SharePoint 2007: Arquitectura de almacenamiento":
"... 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 los 100 GB durante años. En la práctica, la La recomendación se basa principalmente en dos factores importantes:
Los requisitos del Acuerdo de nivel de servicio (SLA) para una organización determinada pueden dictar que las operaciones de respaldo para las bases de datos de SharePoint deben poder ejecutarse 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.
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.
Siempre que una organización determinada sea capaz de mitigar estas dos consideraciones, se podrá 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 bases de datos de 100 GB, 150 GB, 200 GB, 250 GB, 300 GB, 350 GB y 400 GB".
Respuesta2
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 haya 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: llevarán más tiempo con bases de datos grandes. Sin embargo, siempre y cuando la base de datos no exceda lo que se puede respaldar durante la noche, todo estará bien: las copias de seguridad están diseñadas para durar mucho tiempo y son bastante confiables siempre y cuando no se quede sin espacio en el 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 el espacio libre y se implementan mediante consultas que pueden hacer cosas como desencadenar un crecimiento automático fuera de control.
Respuesta3
Contamos con una base de datos de contenidos 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 de los sitios web.
Para que conste, NO queríamos tener una base de datos de contenido tan grande. Teníamos requisitos comerciales específicos en torno al intercambio de contenido que habrían sido muy difíciles de implementar si hubiéramos colocado el contenido en colecciones de sitios separadas.
Cuando lanzamos por primera vez, tuvimos problemas importantes de bloqueo con la base de datos durante el uso pico. Remontamos esto al uso del objeto CrossListQueryCache en SharePoint. Dejamos 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 sitios web (esto puede causar actualizaciones de muchos registros en la tabla AllUserData. Estamos trabajando con el soporte de MS en casos específicos (es decir, eliminando elementos grandes de la papelera de reciclaje). ). Estos se remontan a la forma en que procedimientos almacenados específicos en SharePoint eliminan datos, pero aún 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 MS de comunicar esto a la gente era decir que se mantuviera por debajo de 100 GB.
Sugiero hacer ping a la gente de MS IT... He oído extraoficialmente que tienen una base de datos de contenido de SharePoint > 800 GB.
Respuesta4
Eso es falso. No hay límites sobre el tamaño. Recomiendan no tener bases de datos grandes, sino solo para facilitar la gestión de las bases de datos y minimizar el tiempo de copia de seguridad/restauración. Podríamos decir que la limitación de tamaño depende únicamente de su infraestructura SQL.