Compartir a través de

Procedimientos recomendados para SQL Server en una granja de servidores de SharePoint

  • Artículo

SE APLICA A:yes-img-132013 yes-img-162016 yes-img-192019 yes-img-seSubscription Edition no-img-sopSharePoint en Microsoft 365

Al configurar y mantener bases de datos relacionales de SharePoint Server 2016 y 2019 en SQL Server 2014 con Service Pack 1 (SP1), SQL Server 2016 o SQL Server 2017 RTM, debe elegir opciones que promuevan el rendimiento y la seguridad. Del mismo modo, necesita seleccionar opciones para promover el rendimiento y la seguridad al configurar y mantener bases de datos relacionales de SharePoint Server 2013 en SQL Server 2008 R2 con Service Pack 1 (SP1), SQL Server 2012 y SQL Server 2014.

Los procedimientos recomendados de este artículo se ordenan según la secuencia en que necesitan aplicarse, desde instalar y configurar SQL Server, a implementar SharePoint Server y, después, mantener la granja de servidores. La mayoría de los procedimientos son válidos para todas las versiones de SQL Server. Los procedimientos que son únicos para versiones de SQL Server se muestran en secciones separadas.

Nota:

Si tiene pensado usar los componentes de SQL Server Business Intelligence en una granja de servidores de SharePoint Server 2016, debe usar SQL Server 2016 CTP 3.1 o una versión posterior. Ahora puede descargar SQL Server 2016 CTP 3.1 o una versión posterior para usar el complemento de SQL Server Power Pivot para SharePoint. También puede usar Power View instalando SQL Server Reporting Services (SSRS) en el modo integrado de SharePoint y el complemento front-end de SSRS desde el medio de instalación de SQL Server.

Para obtener más información, consulte las nuevas notas del producto Deploying SQL Server 2016 PowerPivot and Power View in SharePoint 2016 (Implementación de SQL Server 2016 PowerPivot y Power View en SharePoint 2016). Para obtener más información sobre la configuración e implementación de inteligencia empresarial en una granja de varios servidores de SharePoint Server 2016, descargue Deploying SQL Server 2016 PowerPivot and Power View in a Multi-Tier SharePoint 2016 Farm (Implementación de SQL Server 2016 PowerPivot y Power View en una granja de servidores de niveles múltiples de SharePoint 2016).

Nota:

Si planea usar componentes de inteligencia empresarial de SQL Server en una granja de servidores de SharePoint Server 2013, tiene que usar SQL Server 2012 con Service Pack 1 (SP1) o SQL Server 2014. Para obtener información sobre BI de SQL Server 2012 con SP1 y SharePoint Server 2013, vea Instalar las características BI de SQL Server con SharePoint 2013 (SQL Server 2012 SP1). Para obtener más información sobre SQL Server 2014 y SharePoint Server 2013, vea Instalar las características de Business Intelligence SQL Server 2014.

Importante

Los procedimientos recomendados de este artículo son válidos para el sistema de administración de bases de datos relacionales (RDBMS) de SQL Server con SharePoint Server.

Usar un servidor dedicado para SQL Server

Para garantizar un rendimiento óptimo de las operaciones de la granja de servidores, le recomendamos instalar SQL Server en un servidor dedicado que no ejecute otros roles de granja de servidores ni hospede bases de datos de otras aplicaciones. La única excepción es la implementación de SharePoint Server 2016 o 2019 en un rol de granja de Single-Server o SharePoint 2013 en un servidor independiente, que está diseñado para desarrollo o pruebas, y no se recomienda para su uso en producción. Para obtener más información, vea Descripción de MinRole y servicios asociados en SharePoint Servers 2016 y 2019 e Instalar SharePoint Servers 2016 o 2019 en un servidor.

Nota:

La recomendación de usar un servidor dedicado para las bases de datos relacionales también se aplica a la implementación de SQL Server en entornos virtuales.

Configurar opciones específicas de SQL Server antes de implementar SharePoint Server

Para garantizar un rendimiento y comportamiento uniformes, configure las siguientes opciones y valores antes de implementar SharePoint Server.

  • Debido a posibles problemas de rendimiento con el mantenimiento de varias instancias de SQL, se recomienda usar una única instancia de SQL Server por servidor de base de datos implementado.

  • No habilite la creación automática de estadísticas en bases de datos de contenido de SharePoint. No se admite la habilitación de estadísticas de creación automática para SharePoint Server. SharePoint Server configura las opciones necesarias durante el aprovisionamiento y la actualización. Habilitar manualmente las estadísticas de creación automática en una base de datos de SharePoint puede cambiar significativamente el plan de ejecución de una consulta. Las bases de datos de SharePoint usan un procedimiento almacenado que mantiene las estadísticas (proc_UpdateStatistics) o dependen de SQL Server para hacerlo.

  • Para SharePoint Server 2013, SharePoint administra los planes de mantenimiento:

    • Las estadísticas SQL se administran mediante la regla de mantenimiento "Las bases de datos usadas por SharePoint tienen estadísticas de índice obsoletas" que llama a proc_updatestatics
    • Las bases de datos de contenido tienen la propiedad Estadísticas de actualización automática establecida en False

  • Para SharePoint Server 2016 y 2019, el administrador de SQL debe crear planes de mantenimiento para bases de datos de contenido de SharePoint:

    • Las estadísticas sql no se administran mediante la regla de mantenimiento "Las bases de datos usadas por SharePoint tienen estadísticas de índices obsoletas"
    • Las bases de datos de contenido tienen la propiedad Estadísticas de actualización automática establecida en True `

  • Establezca el grado máximo de paralelismo (MAXDOP) en 1 para instancias de SQL Server que hospedan bases de datos de SharePoint para asegurarse de que un proceso de SQL Server único sirve cada solicitud.

    Importante

    Establecer el grado máximo de paralelismo en cualquier otro número puede producir un plan de consulta menos óptimo para usarse que disminuirá el rendimiento de SharePoint Server.

  • Para ayudar a simplificar el mantenimiento (por ejemplo, para facilitar el movimiento de las bases de datos a otro servidor), cree alias de DNS para que señalen a la dirección IP para todas las instancias de SQL Server. Para obtener más información sobre los alias de nombre de host o DNS, vea el artículo sobre cómo agregar un alias de nombre de host para una instancia de SQL Server.

Para obtener más información acerca de estos valores y opciones de SQL Server, vea Establecer opciones de SQL Server.

Proteger el servidor de bases de datos antes de implementar SharePoint Server

Se recomienda que planee y proteja el servidor de bases de datos antes de implementar SharePoint Server. Para más información, vea:

Configurar servidores de bases de datos para rendimiento y disponibilidad

Como en el caso de los servidores front-end y los servidores de aplicaciones, la configuración para los servidores de bases de datos afecta al correcto funcionamiento de SharePoint Server. Algunas bases de datos deben encontrarse en el mismo servidor que otras. De manera inversa, algunas bases de datos no pueden estar en el mismo servidor que otras bases de datos. Para obtener más información, vea Descripción de MinRole y servicios asociados en SharePoint Server 2016 y 2019 y Almacenamiento y planeamiento y configuración de la capacidad de SQL Server (SharePoint Server).

Para obtener información sobre las bases de datos altamente disponibles que usan la creación de reflejos, consulte Creación de reflejo de la base de datos (SQL Server).

Clúster de conmutación por error de SQL Server y grupos de disponibilidad AlwaysOn

SQL Server 2012 introdujo la característica Grupos de disponibilidad AlwaysOn. Esta característica es una solución de alta disponibilidad y de recuperación ante desastres que sirve como alternativa a las soluciones de trasvase de registros y de creación de reflejo de base de datos. Los grupos de disponibilidad AlwaysOn ahora admiten hasta nueve réplicas de disponibilidad.

Nota:

La creación de reflejo de base de datos quedará obsoleta en las versiones futuras de SQL Server. Se recomienda usar los grupos de disponibilidad AlwaysOn.

Los grupos de disponibilidad AlwaysOn requieren un clúster de clústeres de conmutación por error de Windows Server (WSFC). Se crea un grupo de recursos de WSFC para cada uno de los grupos de disponibilidad que se crean. Para obtener más información, consulte los recursos siguientes:

Diseñar el almacenamiento para un rendimiento y una manejabilidad óptimos

Se recomienda que separe y establezca la prioridad de sus datos entre las unidades del servidor de bases de datos. De manera idónea, debe colocar la base de datos tempdb, las bases de datos de contenido, la base de datos de uso, las bases de datos de búsqueda y los registros de transacción en unidades de disco duro físicas independientes. En la lista siguiente se ofrece alguna orientación. Para obtener más información, vea Configurar bases de datos.

  • Para obtener información sobre sitios intensivos de actualizaciones o colaboración, use la siguiente clasificación para distribución de almacenamiento.

    El elemento mejor clasificado debe estar en las unidades más rápidas.

    Jerarquia Elemento
    1 archivos de datos tempdb y registros de transacciones
    2 Archivos de registro de transacciones de base de datos de contenido
    3 Bases de datos de búsqueda, excepto para la base de datos de administración de búsqueda
    4 Archivos de datos de base de datos de contenido

  • En un sitio de portal excesivamente orientado a la lectura, establezca la prioridad de los datos y busque en registros de transacciones de la siguiente manera.

    El elemento mejor clasificado debe estar en las unidades más rápidas.

    Jerarquia Elemento
    1 archivos de datos tempdb y registros de transacciones
    2 Archivos de datos de base de datos de contenido
    3 Bases de datos de búsqueda, excepto para la base de datos de administración de búsqueda
    4 Archivos de registro de transacciones de base de datos de contenido

  • Las pruebas y los datos de usuario muestran que la E/S de disco insuficiente para tempdb puede impedir de manera significativa el rendimiento general de la granja de servidores. Para evitar este problema, asigne discos dedicados para la unidad que almacena archivos de datos tempdb.

  • Para un mejor rendimiento, use una matriz RAID 10 para la unidad que almacena archivos de datos tempdb. El número de datos tempdb debería ser igual al número de núcleos de CPU y cada archivo de datos tempdb debería establecerse en el mismo tamaño.

  • Separe datos de bases de datos y archivos de registros de transacciones en diferentes discos. Si los datos y los archivos de registros deben compartir discos debido a limitaciones de espacio, coloque archivos que tengan diferentes patrones de uso en el mismo disco para minimizar las solicitudes de acceso simultáneas.

  • Use varios archivos de datos para bases de datos de contenido de uso intensivo y coloque cada uno de ellos en su propio disco

  • Para mejorar la manejabilidad, controle y realice ajustes según sea necesario para conservar el tamaño de las bases de datos de contenido por debajo de 200 GB, en lugar de restringir el tamaño de la base de datos.

    Nota:

    Si restringe manualmente el tamaño de la base de datos en SQL Server, puede provocar la inactividad inesperada del sistema cuando se supera la capacidad.

La correcta configuración de subsistemas de E/S es muy importante para el funcionamiento y el rendimiento óptimos de los sistemas SQL Server. Para obtener más información, vea Monitoring Disk Usage (Supervisión del uso del disco)

Sugerencia

Piense en que la manera en que mide la velocidad del disco varía entre archivos de datos y archivos de registro. Las unidades más rápidas para los datos de bases de datos pueden no ser las más rápidas para los archivos de registro. Piense en patrones de uso, E/S y tamaño de archivo.

Administrar de manera proactiva el crecimiento de archivos de registro y de datos

A continuación encontrará algunas recomendaciones para administrar de manera proactiva el crecimiento de archivos de registro y de datos:

  • Cuando sea posible, aumente todos los archivos de datos y los archivos de registro a su tamaño final esperado o bien auméntelos periódicamente en períodos establecidos, por ejemplo, cada mes, cada seis meses o antes del lanzamiento de un nuevo sitio intensivo de almacenamiento como durante las migraciones de archivos.

  • Habilite el crecimiento automático de la base de datos como medida de protección para garantizar que no se queda sin espacio en archivos de registro y de datos. Tenga en cuenta lo siguiente:

    Importante

    Necesita tener en cuenta el rendimiento y los problemas de funcionamiento asociados con el uso del crecimiento automático. Para obtener más información, vea Consideraciones para la configuración "crecimiento automático" y "autoshrink" en SQL Server.

    • La configuración predeterminada para una nueva base de datos crecerá en incrementos de 1 MB. Dado que esta configuración predeterminada para los resultados de crecimiento automático da lugar a incrementos en el tamaño de la base de datos, no se base en la configuración predeterminada. En su lugar, use la orientación proporcionada en Establecer opciones de SQL Server.

    • Establezca los valores de crecimiento automático en un número fijo de megabytes en lugar de hacerlo en un porcentaje. Cuanto mayor sea la base de datos, mayor debería ser el incremento de crecimiento.

      Nota:

      Tenga cuidado al establecer la característica de crecimiento automático para las bases de datos de SharePoint. Si establece que una base de datos crezca automáticamente como porcentaje, por ejemplo, en una tasa de crecimiento del 10 por ciento (%), una base de datos de 5 GB crece unos 500 MB cada vez que un archivo de datos se tiene que expandir. En este escenario, se podría quedar sin espacio en el disco.

      Piense por ejemplo en un escenario donde el contenido aumenta de manera gradual, supongamos que en incrementos de 100 MB, y el crecimiento automático se establece en 10 MB. De pronto, un nuevo sitio de administración de documentos requiere una cantidad muy grande de almacenamiento de datos, puede que con el tamaño inicial de 50 GB. Para esta gran adición, el crecimiento en incrementos de 500 MB es más adecuado que en incrementos de 10 MB.

    • Para un sistema de producción administrado, piense que el crecimiento automático es simplemente una contingencia para un crecimiento inesperado. No use la opción de crecimiento automático para administrar sus datos ni registre el crecimiento diariamente. En lugar de eso, establezca el crecimiento automático para permitir un tamaño aproximado en un año y, a continuación, agregue un margen de error del 20 por ciento. Además, establezca una alerta para notificarle cuando la base de datos se quede con poco espacio o alcance un tamaño máximo.

  • Mantenga un nivel de al menos un 25 por ciento de espacio disponible en las unidades para acomodar el crecimiento y los patrones de uso máximo. Si agrega unidades a una matriz RAID o asigna más almacenamiento para administrar, controle atentamente la capacidad para evitar quedarse sin espacio.

Control continuo del almacenamiento y el rendimiento de SQL Server

Se recomienda que controle de manera continua el almacenamiento y el rendimiento de SQL Server para garantizar que cada servidor de bases de datos de producción maneja de manera adecuada la carga colocada en él. Además, el control continuo le permite establecer bancos de pruebas que puede usar para planificación de recursos.

Tenga una visión completa del control de recursos. No limite el control a recursos específicos de SQL Server. Es igualmente importante realizar un seguimiento de los siguientes recursos en equipos que ejecutan SQL Server: CPU, memoria, proporción de aciertos de la caché y el subsistema de E/S.

Cuando uno o más recursos de servidor parecen lentos o sobrecargados, piense en las siguientes orientaciones basadas en la carga de trabajo actual y proyectada.

Uso de la compresión de la copia de seguridad para acelerar las copias de seguridad y reducir los tamaños de archivo

La compresión de copia de seguridad puede acelerar las operaciones de copia de seguridad de SharePoint. Está disponible en SQL Server Standard y Enterprise Edition. Si establece la opción de compresión en el script de copia de seguridad o configura SQL Server para comprimir de forma predeterminada, puede reducir considerablemente el tamaño de las copias de seguridad de bases de datos y los registros enviados. Para obtener más información, vea Compresión de copia de seguridad (SQL Server) y Compresión de datos, o Habilitar la compresión en una tabla o índice.

Reconocimientos

El equipo de publicación de contenido de SharePoint Server agradece a las personas siguientes sus contribuciones a este artículo:

  • Kay Unkroth, administrador de programas sénior, SQL Server

  • Chuck Heinzelman, administrador de programas sénior, SQL Server

Consulte también

Conceptos

Información general sobre SQL Server en entornos de SharePoint Server 2016 y 2019

Configuración y planeamiento de capacidad de almacenamiento y SQL Server (SharePoint Server)

Otros recursos

Proteger SharePoint: Protección de SQL Server en entornos de SharePoint