8 votos

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

Otra cuestión de hablar a los gurús de SharePoint mientras que la enseñanza de MCM ayer. SharePoint directrices que las bases de datos de contenido por encima de 100 GB no son compatibles. Sin entrar en las razones detrás de esas directrices, estoy interesado en escuchar acerca de los contenidos de las bases de datos más grandes de 100 gb y de sus experiencias con ellos (principalmente en torno al rendimiento, recuperación de desastres, y HA de aprovisionamiento).

Cuan lejos se las arregló para empujar la instalación de SharePoint? He escuchado de segunda mano historias de > 1 TB bases de datos de contenido, pero me gustaría escuchar la opinión de los administradores de SharePoint a sí mismos.

Gracias por cualquier información que usted tiene.

5voto

Chris Puntos269

Para el día a día de uso, tamaño de base de datos no es importante - la mayoría de las consultas de devolver los artículos en una lista y no importa lo que los demás están en la base de datos. Sin embargo, las operaciones que funcionan en toda la base de datos será más difícil. Las copias de seguridad son el ejemplo más obvio - que le llevará más tiempo con grandes bases de datos. Sin embargo, mientras la base de datos no superan lo que se puede copia de seguridad de la noche a la mañana vas a estar bien - las copias de seguridad están diseñados para ser de larga ejecución y son bastante fiables, siempre y cuando no te quedarás sin espacio en disco.

Donde se va a ejecutar en problemas reales es menos frecuente cosas como mover o actualizar bases de datos de contenido puede requerir cerca de 5 veces el tamaño de base de datos en el espacio libre y se implementó el uso de consultas que se pueden hacer cosas como desencadenador de control automático.

3voto

roxan Puntos4926

Tenemos una base de datos en la 111 y 102GB, respectivamente, a los que se hizo copia de seguridad en menos de 30 minutos en un GigE de la red. He oído que las grandes bases de datos pueden tener problemas con la ejecución de procedimientos almacenados, pero he visto ninguna demostración de ello.

Una buena cita de La "ampliación de SharePoint 2007: Arquitectura de Almacenamiento" whitepaper:

"...Esto es comúnmente referido como el "100GB de datos de contenido de la limitación de tamaño". De hecho, esta no es una verdadera limitación, sino más bien una recomendación. Bases de datos SQL Server han sido escalado mucho más allá de 100 GB durante años. Prácticamente hablando, la recomendación se basa principalmente en dos factores importantes:

  1. Acuerdo de Nivel de servicio (SLA) requisitos para que una organización puede determinar que operaciones de copia de seguridad para las bases de datos de SharePoint debe ser ejecutable en una cantidad limitada de tiempo. El tamaño de las bases de datos de contenido tendrá un impacto directo en ¿cuánto tiempo se necesita para ejecutar la copia de seguridad.

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

Mientras una organización es capaz de mitigar estas dos consideraciones, a continuación, el contenido de las bases de datos pueden ser permitido crecer. Mundo Real implementaciones han visto el éxito de las implementaciones de SharePoint que han implementado la base de datos de tamaños de 100GB, 150 GB, 200 GB, 250 GB, 300 GB, 350GB y 400GB."

2voto

Antti Sykäri Puntos10381

Tenemos un contenido databse que es de 300 GB de tamaño. No hay problemas con las copias de seguridad después de pasar a la Lite de la Velocidad. Antes de que el interruptor veríamos seria degradación del rendimiento con los sitios web.

Para el récord que NO quería tener un Contenido DB de este tamaño. Tuvimos necesidades específicas de la empresa alrededor de intercambio de contenidos que habría sido muy difícil de implementar si no se nos había puesto el contenido en separar las colecciones de sitios.

Cuando fuimos por primera vez en vivo hemos tenido grandes problemas de bloqueo con la base de datos durante las horas pico de uso. Hemos remontado de nuevo el uso de CrossListQueryCache de objetos de SharePoint. Hemos cambiado de uso de la API y se fija un montón de nuestro desempeño.

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

Aún se pueden ver problemas de bloqueo con ciertos tipos de actualizaciones (eliminación de blobs > 20 MB), el cambio de nombre de webs (esto puede provocar que las actualizaciones a un montón de registros en AllUserData tabla. Estamos trabajando con MS de Apoyo en casos específicos (es decir, la eliminación de grandes elementos de la papelera de reciclaje). Estos han sido remonta a la forma específica de procedimientos almacenados en SharePoint son la eliminación de datos, pero no tenemos una solución todavía.

Personalmente creo que los problemas se producen después de que usted consiga tantos registros en la AllUserData tabla y el easist manera para MS a comunicar esto a la gente iba a decir permanecer por debajo de 100 GB.

Sugiero hacer ping a la gente de MS... he oído hablar off the record que tienen un Contenido de SharePoint DB > 800 GB.

1voto

Rodney Puntos11

Nuestra empresa cuenta con una base de datos actualmente en 140Mb. Estamos experimentando un rendimiento lento en una lista en particular que se le ha permitido crecer hasta 1,5 Gb que contiene archivos adjuntos, incluyendo varias versiones de los archivos adjuntos. (Sólo he estado allí aproximadamente 2 meses por el camino). Ahora estamos planificando la migración y es el aspecto de migrar a españa de 2010 con Metalogix herramienta podría tomar días para lograr sobre la base de nuestro análisis. El nuestro es un mal base de datos diseñada, mal diseñado portal que tiene ahora aquellos de nosotros tener que tratar con problemas reales.

Tenemos un sitio de copia de seguridad que utilizamos que es una copia exacta de nuestro entorno de producción. Pero el hardware es nuestro VIEJO hardware después de nuestra última actualización de hardware - hardware Antiguo para el Desarrollo, nueva para la producción. Algunas áreas de nuestro entorno de desarrollo, sin embargo, son inutilizables debido a los problemas de rendimiento que obliga el desarrollo de las grandes listas a las que se han realizado en la producción. Ouch, Ouch, Ouch....

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by:

;