Consideraciones de diseño de SQL Server

System Center Operations Manager requiere acceso a una instancia de un servidor que ejecuta Microsoft SQL Server para admitir la base de datos operativa, de almacenamiento de datos y de auditoría de ACS. Las bases de datos operativas y de almacenamiento de datos son necesarias y se crean al implementar el primer servidor de administración en el grupo de administración, mientras que la base de datos de ACS se crea al implementar un recopilador de ACS en el grupo de administración.

En un entorno de laboratorio o una implementación a pequeña escala de Operations Manager, SQL Server se puede ubicar conjuntamente en el primer servidor de administración del grupo de administración.

En una implementación distribuida a escala mediana a empresarial, la instancia de SQL Server debe encontrarse en un servidor independiente dedicado o en una configuración de alta disponibilidad de SQL Server. En cualquier caso, SQL Server ya debe existir y ser accesible antes de comenzar la instalación del primer servidor de administración o del recopilador de ACS.

No se recomienda el uso de bases de datos de Operations Manager desde una instancia de SQL que tenga otras bases de datos de aplicación. Esto es para evitar posibles problemas con la E/S y otras restricciones de recursos de hardware.

Importante

Operations Manager no admite instancias de plataforma como servicio (PaaS) de SQL, incluidos productos como Azure SQL Managed Instance o Amazon Relational Database Service (AWS RDS). Usa una instancia de SQL Server instalada en una máquina Windows. La única excepción a esto se encuentra en la Instancia administrada de Azure Monitor SCOM, que usa Azure SQL MI y no es reconfigurable.

requisitos de SQL Server

Se admiten las siguientes versiones de SQL Server Enterprise y Standard Edition para una instalación existente de la versión de System Center Operations Manager para hospedar bases de datos del servidor de informes, operativas, de almacenamiento de datos y ACS:

• SQL Server 2022

• SQL Server 2019 con la actualización acumulativa 8 (CU8) o posterior, tal y como se detalla aquí

  Nota:

  • Operations Manager 2022 admite SQL 2019 con CU8 o posterior; sin embargo, no admite SQL 2019 RTM.
  • Usa ODBC 17.3 o 17.10.6 y MSOLEDBSQL 18.2 o 18.7.2.

• SQL Server 2017 y actualizaciones acumulativas, tal y como se detalla aquí

Antes de actualizar SQL Server, consulta la información de actualización de 2017 y la información de actualización de SQL 2019.

Nota:

• Cada uno de los siguientes componentes de SQL Server que admiten una infraestructura de SCOM debe estar en la misma versión principal de SQL Server:
  • Las instancias del motor de base de datos de SQL Server que hospedan cualquiera de las bases de datos SCOM (es decir, OperationManager, OperationManagerDW, y bases de datos de SSRS ReportServer y ReportServerTempDB).
  • Instancia de SQL Server Reporting Services (SSRS).
• La configuración de intercalación SQL Server debe ser uno de los tipos admitidos, tal como se describe en la sección Configuración de intercalación SQL Server siguiente.
• La búsqueda de texto completo de SQL Server es necesaria para todas las instancias del motor de base de datos de SQL Server que hospedan cualquiera de las bases de datos SCOM.
• Las opciones de instalación de Windows Server 2016 (Server Core, servidor con Experiencia de escritorio y Nano Server) compatibles con los componentes de base de datos de Operations Manager se basan en las opciones de instalación de Windows Server compatibles con SQL Server.

Nota:

System Center Operations Manager Reporting no se puede instalar en paralelo con una versión anterior del rol de informes y solo se debe instalar en modo nativo (no se admite el modo integrado de SharePoint).

Se aplican consideraciones adicionales de hardware y software en el planeamiento de diseño:

• Se recomienda ejecutar SQL Server en equipos con el formato de archivo NTFS.
• Debe haber al menos 1024 MB de espacio libre en disco para la base de datos operativa y de almacenamiento de datos. Se aplica en el momento de la creación de la base de datos y es probable que crezca significativamente después de la instalación.
• Se requiere .NET Framework 4.
• .NET Framework 4.8 se admite desde Operations Manager 2022.
• No se admite la instalación del servidor de informes en Windows Server Core.

Para más información, vea Requisitos de hardware y software para instalar SQL Server.

Nota:

Aunque Operations Manager solo usa autenticación de Windows durante la instalación, la configuración de autenticación en modo mixto de SQL seguirá funcionando si ninguna cuenta local tiene el rol db_owner. Se sabe que las cuentas locales con el rol db_owner provocan problemas con System Center Operations Manager. Quita el rol db_owner de todas las cuentas locales antes de instalar el producto y no agregues el rol db_owner a ninguna de las cuentas locales después de la instalación.

Configuración de intercalación de SQL Server

System Center Operations Manager admite las siguientes intercalaciones de SQL Server y Windows.

Nota:

Para evitar problemas de compatibilidad al comparar o copiar operaciones, se recomienda usar la misma intercalación para la base de datos de SQL y Operations Manager.

Intercalación de SQL Server

• SQL_Latin1_General_CP1_CI_AS

Intercalación de Windows

• Latin1_General_100_CI_AS
• French_CI_AS
• French_100_CI_AS
• Cyrillic_General_CI_AS
• Chinese_PRC_CI_AS
• Chinese_Simplified_Pinyin_100_CI_AS
• Chinese_Traditional_Stroke_Count_100_CI_AS
• Japanese_CI_AS
• Japanese_XJIS_100_CI_AS
• Traditional_Spanish_CI_AS
• Modern_Spanish_100_CI_AS
• Latin1_General_CI_AS
• Cyrillic_General_100_CI_AS
• Korean_100_CI_AS
• Czech_100_CI_AS
• Hungarian_100_CI_AS
• Polish_100_CI_AS
• Finnish_Swedish_100_CI_AS

Si la instancia de SQL Server no está configurada con una de las intercalaciones admitidas enumeradas anteriormente, se producirá un error al realizar una nueva instalación de Operations Manager. Sin embargo, una actualización local se completará correctamente.

Configuración de firewall

Operations Manager depende de SQL Server para hospedar sus bases de datos y una plataforma de informes para analizar y presentar datos operativos históricos. Los roles de servidor de administración, operaciones y consola web deben poder comunicarse correctamente con SQL Server y es importante comprender la ruta de comunicación y los puertos para configurar el entorno correctamente.

Si vas a diseñar una implementación distribuida que requerirá grupos de disponibilidad Always On de SQL para proporcionar funcionalidad de conmutación por error para las bases de datos de Operations Manager, hay opciones de configuración de firewall adicionales que deben incluirse en la estrategia de seguridad del firewall.

La tabla siguiente te ayuda a identificar los puertos de firewall requeridos por SQL Server que deberán permitirse como mínimo para que los roles de servidor del grupo de administración de Operations Manager se comuniquen correctamente.

Escenario	Port	Dirección	Rol de Operations Manager
SQL Server que hospeda bases de datos de Operations Manager	TCP 1433 *	Entrada	servidor de administración y consola web (para Application Advisor y Diagnóstico de aplicaciones)
servicio SQL Server Browser	UDP 1434	Entrada	servidor de administración
Conexión de administración dedicada de SQL Server	TCP 1434	Entrada	servidor de administración
Puertos adicionales usados por SQL Server - Llamadas a procedimiento remoto de Microsoft (MS RPC) - Instrumental de administración de Windows (WMI) - Coordinador de transacciones distribuidas de Microsoft (MS DTC)	TCP 135	Entrada	servidor de administración
Escucha de grupo de disponibilidad Always On de SQL Server.	Puerto configurado de administrador	Entrada	servidor de administración
SQL Server Reporting Services que hospeda Operations Manager Reporting Server	TCP 80 (valor predeterminado)/443 (SSL)	Entrada	servidor de administración y consola del operador

* Aunque el puerto estándar de la instancia predeterminada del motor de base de datos es TCP 1433, cuando se crea una instancia con nombre en un servidor de SQL Server independiente o se ha implementado un grupo de disponibilidad de SQL Always On, se definirá un puerto personalizado y se incluirá como referencia para que configure los firewalls correctamente y especifique esta información durante la instalación.

Para obtener información general más detallada sobre los requisitos de firewall para SQL Server, consulta Configuración de firewall de Windows para permitir el acceso a SQL Server.

Consideraciones sobre capacidad y almacenamiento

Base de datos de Operations Manager

La base de datos de Operations Manager es una base de datos de SQL Server que contiene todos los datos que necesita Operations Manager para la supervisión diaria. El dimensionamiento y la configuración del servidor de bases de datos es crítico para el rendimiento general del grupo de administración. El recurso más crítico que usa la base de datos de Operations Manager es el subsistema de almacenamiento, pero la CPU y la RAM también son importantes.

Los factores que influyen en la carga en la base de datos de Operations Manager incluyen:

• Tasa de recopilación de datos operativos. Los datos operativos constan de todos los eventos, alertas, cambios de estado y datos de rendimiento recopilados por los agentes. La mayoría de los recursos usados por la base de datos de Operations Manager se usan para escribir estos datos en el disco a medida que entran en el sistema. La tasa de datos operativos recopilados tiende a aumentar a medida que se importan módulos de administración adicionales y se agregan agentes adicionales. El tipo de equipo que un agente está supervisando también es un factor importante que se usa al determinar la tasa global de recopilación de datos operativos. Por ejemplo, se puede esperar que un agente que supervise un equipo de escritorio crítico para la empresa recopile menos datos que un agente que supervisa un servidor que ejecuta una instancia de SQL Server con un gran número de bases de datos.
• Tasa de cambios de espacio de instancia. Actualizar estos datos en la base de datos de Operations Manager es costoso en relación con la escritura de nuevos datos operativos. Además, cuando cambian los datos de espacio de instancia, los servidores de administración realizan consultas adicionales en la base de datos de Operations Manager para calcular los cambios de configuración y grupo. La tasa de cambios de espacio de instancia aumenta a medida que se importan módulos de administración adicionales en un grupo de administración. La adición de nuevos agentes a un grupo de administración también aumenta temporalmente la tasa de cambios de espacio de instancia.
• Número de consolas del operador y otras conexiones del SDK que se ejecutan simultáneamente. Cada consola del operador lee datos de la base de datos de Operations Manager. La consulta de estos datos consume potencialmente grandes cantidades de recursos de E/S de almacenamiento, tiempo de CPU y RAM. Las consolas de operaciones que muestran grandes cantidades de datos operativos en la vista eventos, la vista estado, la vista alertas y la vista de datos de rendimiento tienden a provocar la mayor carga en la base de datos.

La base de datos de Operations Manager es un único origen de error para el grupo de administración, por lo que se puede hacer de alta disponibilidad mediante configuraciones de conmutación por error admitidas, como grupos de disponibilidad AlwaysOn de SQL Server o instancias de clúster de conmutación por error.

Puede configurar y actualizar bases de datos de Operations Manager con una configuración Always On de SQL sin necesidad de realizar cambios posteriores a la configuración.

Habilitación de SQL Broker en la base de datos de Operations Manager

System Center Operations Manager depende de SQL Server Service Broker para implementar todas las operaciones de tareas. Si SQL Server Service Broker está deshabilitado, todas las operaciones de tareas se verán afectadas. El comportamiento resultante puede variar según la tarea iniciada. Por lo tanto, es importante comprobar el estado de SQL Server Service Broker siempre que se observe un comportamiento inesperado en torno a una tarea en System Center Operations Manager.

Para habilitar SQL Server Service Broker, sigue estos pasos.

1. Ejecute la siguiente consulta SQL:

   SELECT is_broker_enabled FROM sys.databases WHERE name='OperationsManager'
   

2. Omite este paso si el valor que se muestra en el campo is_broker_enabled es 1 (uno). De lo contrario, ejecuta las siguientes consultas SQL:

   ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE
   ALTER DATABASE OperationsManager SET ENABLE_BROKER
   ALTER DATABASE OperationsManager SET MULTI_USER
   

Base de datos de almacenamiento de datos de Operations Manager

System Center - Operations Manager inserta datos en el almacenamiento de datos de informes casi en tiempo real, por lo que es importante que este servidor disponga de capacidad suficiente que permita escribir todos los datos recopilados en el almacenamiento de datos de informes. Al igual que con la base de datos de Operations Manager, el recurso más crítico en el almacenamiento de datos de informes es el subsistema de E/S de almacenamiento. En la mayoría de los sistemas, las cargas en el almacenamiento de datos de informes son similares a la base de datos de Operations Manager, pero pueden variar. Además, la carga de trabajo que se coloca en el almacenamiento de datos de informes mediante informes es diferente de la carga puesta en la base de datos de Operations Manager por uso de la consola de Operations.

Los factores que influyen en la carga en el almacenamiento de datos de informes incluyen:

• Tasa de recopilación de datos operativos. Para permitir informes más eficaces, el almacenamiento de datos de informes calcula y almacena datos agregados además de una cantidad limitada de datos sin procesar. Realizar este trabajo adicional significa que la recopilación de datos operativos en el almacenamiento de datos de informes puede ser ligeramente más costosa que para la base de datos de Operations Manager. Este coste adicional suele equilibrarse con el coste reducido del procesamiento de los datos de detección por parte del almacenamiento de datos de informes frente a la base de datos de Operations Manager.
• Número de usuarios de informes simultáneos o generación de informes programada. Dado que los informes suelen resumir grandes volúmenes de datos, cada usuario de informes puede agregar una carga significativa en el sistema. El número de informes que se ejecutan simultáneamente y el tipo de informes que se ejecutan afectan a las necesidades de capacidad general. Por lo general, los informes que consultan grandes intervalos de fechas o un gran número de objetos requieren recursos adicionales del sistema.

En función de estos factores, hay varios procedimientos recomendados que se deben tener en cuenta al dimensionar el almacenamiento de datos de informes:

• Elige un subsistema de almacenamiento adecuado. Dado que el almacenamiento de datos de informes es una parte integral del flujo de datos general a través del grupo de administración, es importante elegir un subsistema de almacenamiento adecuado para el almacenamiento de datos de informes. Al igual que con la base de datos de Operations Manager, RAID 0 + 1 suele ser la mejor opción. En general, el subsistema de almacenamiento para el almacenamiento de datos de informes debe ser similar al subsistema de almacenamiento para la base de datos de Operations Manager y las instrucciones que se aplican a la base de datos de Operations Manager también se aplican al almacenamiento de datos de informes.
• Considera la colocación adecuada de los registros de datos frente a los registros de transacciones. En cuanto a la base de datos de Operations Manager, separar los datos SQL y los registros de transacciones suele ser una opción adecuada a medida que se escala verticalmente el número de agentes. Si tanto la base de datos de Operations Manager como el almacenamiento de datos de informes se encuentran en el mismo servidor y quieres separar los datos y los registros de transacciones, debes colocar los registros de transacciones para la base de datos de Operations Manager en un volumen físico independiente y los ejes de disco del almacenamiento de datos de informes para recibir cualquier ventaja. Los archivos de datos de la base de datos de Operations Manager y el almacenamiento de datos de informes pueden compartir el mismo volumen físico siempre que el volumen proporcione una capacidad adecuada y el rendimiento de E/S de disco no afecte negativamente a la funcionalidad de supervisión e informes.
• Considera la posibilidad de colocar el almacenamiento de datos de informes en un servidor independiente de la base de datos de Operations Manager. Aunque las implementaciones a menor escala suelen consolidar la base de datos de Operations Manager y el almacenamiento de datos de informes en el mismo servidor, resulta ventajoso separarlas a medida que se escala verticalmente el número de agentes y el volumen de datos operativos entrantes. Cuando el almacenamiento de datos de informes y el servidor de informes están en un servidor independiente de la base de datos de Operations Manager, experimentarás un mejor rendimiento de informes.

La base de datos de almacenamiento de datos de Operations Manager es un único origen de errores para el grupo de administración, por lo que se puede hacer de alta disponibilidad mediante configuraciones de conmutación por error admitidas, como grupos de disponibilidad Always On de SQL Server o instancias de clúster de conmutación por error.

SQL Server Always On

Los grupos de disponibilidad SQL Server Always On admiten entornos de conmutación por error para un conjunto discreto de bases de datos de usuario (bases de datos de disponibilidad). Cada conjunto de bases de datos de disponibilidad es hospedado por una réplica de disponibilidad.

Con System Center 2016 y versiones posteriores: Operations Manager, es preferible SQL Always On a agrupación de clústeres de conmutación por error para proporcionar alta disponibilidad para las bases de datos. Todas las bases de datos excepto la instalación de Reporting Services en modo nativo, que usa dos bases de datos para separar el almacenamiento de datos persistente de los requisitos de almacenamiento temporal, se pueden hospedar en un grupo de disponibilidad Always On.

Con Operations Manager 2022, puede configurar y actualizar bases de datos de Operations Manager con una configuración Always On de SQL sin necesidad de realizar cambios posteriores a la configuración.

Para configurar un grupo de disponibilidad, deberás implementar una agrupación de clústeres de conmutación por error de Windows Server (WSFC) para hospedar la réplica de disponibilidad y habilitar Always On en los nodos del clúster. Entonces, puedes agregar la base de datos de SQL Server de Operations Manager como base de datos de disponibilidad.

• Más información sobre los requisitos previos de Always On.
• Más información sobre cómo configurar un WSFC para grupos de disponibilidad Always On.
• Más información sobre cómo configurar un grupo de disponibilidad.

Nota:

Después de implementar Operations Manager en los nodos de SQL Server que participan en SQL Always On, para habilitar CLR strict security, ejecuta el script SQL en cada base de datos de Operations Manager.

Cadena de varias subredes

Operations Manager no admite las palabras clave de cadena de conexión (MultiSubnetFailover=True). Dado que un grupo de disponibilidad tiene un nombre de cliente de escucha (conocido como nombre de red o punto de acceso de cliente en el Administrador de clústeres de WSFC) en función de varias direcciones IP de diferentes subredes, como cuando se implementa en una configuración de conmutación por error entre sitios, las solicitudes de conexión de cliente de los servidores de administración al cliente de escucha de grupo de disponibilidad alcanzarán un tiempo de espera de conexión.

El enfoque recomendado para solucionar esta limitación cuando hayas implementado nodos de servidor en el grupo de disponibilidad en un entorno de varias subredes es hacer lo siguiente:

1. Establece el nombre de red del cliente de escucha de grupo de disponibilidad para registrar solo una sola dirección IP activa en DNS.
2. Configura el clúster para usar un valor TTL bajo para el registro DNS registrado.

Esta configuración permite, cuando se realiza la conmutación por error a un nodo de una subred diferente, una recuperación y resolución más rápidas del nombre del clúster con la nueva dirección IP.

Ejecuta los siguientes comandos de PowerShell en cualquiera de los nodos SQL para modificar su configuración:

Import-Module FailoverClusters
Get-ClusterResource "Cluster Name"|Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource "Cluster Name"|Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource "Cluster Name"
Start-ClusterResource "Cluster Name"
Start-ClusterGroup "Cluster Name"

Si usas Always On con un nombre de cliente de escucha, también debes realizar estos cambios de configuración en el cliente de escucha. Si quieres obtener más información sobre cómo configurar un cliente de escucha de grupo de disponibilidad, consulta Configuración de un agente de escucha para un grupo de disponibilidad Always On.

Ejecuta los siguientes comandos de PowerShell en el nodo SQL que hospeda actualmente el cliente de escucha para modificar su configuración:

Import-Module FailoverClusters
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource <Listener Cluster Resource name>
Start-ClusterResource <Listener Cluster Resource name>
Start-ClusterGroup <Listener Cluster Group name>

Cuando se usa una instancia de SQL Always On o en clúster para alta disponibilidad, debe habilitarse la característica de recuperación automática en los servidores de administración para evitar que el servicio de acceso a datos de Operations Manager se reinicie siempre que se produzca una conmutación por error entre nodos. Para obtener información sobre cómo configurar esto, consulta el siguiente artículo de KB El servicio de administración de System Center deja de responder después de que una instancia de SQL Server se desconecta.

Optimización de SQL Server

En general, la experiencia de implementación anterior con los clientes muestra que los problemas de rendimiento no suelen deberse a un uso elevado de recursos (es decir, procesador o memoria) con SQL Server en sí; en su lugar, está directamente relacionado con la configuración del subsistema de almacenamiento. Los cuellos de botella de rendimiento se suelen atribuir a no seguir la guía de configuración recomendada con el almacenamiento aprovisionado para la instancia de base de datos de SQL Server. Dichos ejemplos son:

• Asignación insuficiente de ejes para los LUN para admitir los requisitos de E/S de Operations Manager.
• Hospedaje de registros de transacciones y archivos de base de datos en el mismo volumen. Estas dos cargas de trabajo tienen características de E/S y latencia diferentes.
• La configuración de TempDB es incorrecta con respecto a la colocación, el dimensionamiento, etc.
• Desalineación de particiones de disco de los volúmenes que hospedan los registros de transacciones de base de datos, los archivos de base de datos y TempDB.
• Omisión de la configuración básica de SQL Server, como el uso de AUTOGROW para archivos de registro de transacciones y bases de datos, la configuración MAXDOP para paralelismo de consultas, la creación de varios archivos de datos tempDB por núcleo de CPU, etc.

La configuración de almacenamiento es uno de los componentes críticos para una implementación de SQL Server para Operations Manager. Los servidores de bases de datos tienden a estar muy enlazados a E/S debido a una rigurosa actividad de lectura y escritura de base de datos y procesamiento del registro de transacciones. El patrón de comportamiento de E/S de Operations Manager suele ser del 80 % de escrituras y el 20 % de lecturas. Como resultado, una configuración incorrecta de subsistemas de E/S puede dar lugar a un rendimiento y funcionamiento deficientes de los sistemas de SQL Server y se vuelve notable en Operations Manager.

Es importante probar el diseño de SQL Server realizando pruebas de rendimiento del subsistema de E/S antes de implementar SQL Server. Asegúrate de que estas pruebas pueden lograr los requisitos de E/S con una latencia aceptable. Usa la utilidad Diskspd para evaluar la capacidad de E/S del subsistema de almacenamiento que admite SQL Server. En el siguiente artículo de blog, creado por un miembro del equipo del servidor de archivos del grupo de productos, se proporcionan instrucciones detalladas y recomendaciones sobre cómo realizar pruebas de esfuerzo con esta herramienta con código de PowerShell y capturar los resultados mediante PerfMon. Para obtener una orientación inicial también puede consultar el asistente para ajuste de tamaño de Operations Manager.

Tamaño de la unidad de asignación de NTFS

La alineación del volumen, comúnmente denominada alineación del sector, debe realizarse en el sistema de archivos (NTFS) cada vez que se crea un volumen en un dispositivo RAID. Si no se hace, se puede provocar una degradación significativa del rendimiento y suele ser el resultado de la desalineación de particiones con límites de unidad de sección. También puede provocar desalineación de caché de hardware, lo que da lugar a un uso ineficaz de la caché de matriz. Al aplicar formato a la partición que se usará para los archivos de datos de SQL Server, se recomienda usar un tamaño de unidad de asignación de 64 KB (es decir, 65 536 bytes) para datos, registros y tempdb. Ten en cuenta, sin embargo, que el uso de tamaños de unidad de asignación mayores de 4 KB da como resultado la incapacidad de usar la compresión NTFS en el volumen. Aunque SQL Server admite datos de solo lectura en volúmenes comprimidos, no se recomienda.

Reservar memoria

Nota:

Gran parte de la información de esta sección procede de Jonathan Kehayias en su entrada de blog How much memory does my SQL Server actually need? (sqlskills.com).

No siempre es fácil identificar la cantidad correcta de memoria física y procesadores para asignar a SQL Server y admitir System Center Operations Manager (o para otras cargas de trabajo fuera de este producto). La calculadora de dimensionamiento que proporciona el grupo de productos ofrece instrucciones basadas en la escala de cargas de trabajo, pero sus recomendaciones se basan en las pruebas realizadas en un entorno de laboratorio que puede o no alinearse con la carga de trabajo y la configuración reales.

SQL Server permite configurar la cantidad mínima y máxima de memoria que se reservará y usará en su proceso. De forma predeterminada, SQL Server puede cambiar sus requisitos de memoria de manera dinámica basándose en los recursos del sistema disponibles. La configuración predeterminada para memoria mínima del servidor es 0 y para memoria máxima del servidor es 2147483647 MB.

Pueden producirse problemas relacionados con el rendimiento y la memoria si no se establece un valor adecuado para memoria máxima del servidor. Muchos factores influyen en la cantidad de memoria que necesitas asignar a SQL Server para garantizar que el sistema operativo pueda admitir otros procesos que se ejecutan en ese sistema, como la tarjeta HBA, los agentes de administración y el examen antivirus en tiempo real. Si no se establece suficiente memoria, el sistema operativo y SQL se paginarán en el disco. Esto puede hacer que la E/S de disco aumente, disminuyendo aún más el rendimiento y creando un efecto de ondas en el que se vuelve notable en Operations Manager.

Se recomienda especificar al menos 4 GB de RAM para memoria mínima del servidor. Esto debe hacerse para cada nodo SQL que hospeda una de las bases de datos de Operations Manager (operativa, almacenamiento de datos, ACS).

Para memoria máxima del servidor, se recomienda reservar inicialmente un total de:

• 1 GB de RAM para el sistema operativo
• 1 GB de RAM por cada 4 GB de RAM instalado (hasta 16 GB de RAM)
• 1 GB de RAM por cada 8 GB de RAM instalado (por encima de 16 GB de RAM)

Después de establecer estos valores, supervisa el contador Memoria\MBytes disponibles en Windows para determinar si puedes aumentar la memoria disponible para SQL Server. Windows indica que la memoria física disponible se está ejecutando a un nivel bajo de 96 MB, por lo que idealmente el contador no debería ejecutarse por debajo de unos 200-300 MB, para asegurarse de tener un búfer. En el caso de los servidores con RAM de 256 GB o superior, probablemente querrás asegurarte de que no se ejecute por debajo de 1 GB.

Ten en cuenta que estos cálculos suponen que quieres que SQL Server pueda usar toda la memoria disponible, a menos que la modifique para tener en cuenta otras aplicaciones. Considera los requisitos de memoria específicos para el sistema operativo, otras aplicaciones, la pila de subprocesos de SQL Server y otros asignadores de varias páginas. Una fórmula típica sería ((total system memory) – (memory for thread stack) – (OS memory requirements) – (memory for other applications) – (memory for multipage allocators)), donde la memoria de la pila de subprocesos = ((max worker threads) (stack size)). El tamaño de la pila es de 512 KB para sistemas x86, 2 MB para sistemas x64 y 4 MB para sistemas IA64, y puedes encontrar el valor de máximo de subprocesos de trabajo en la columna max_worker_count de sys.dm_os_sys_info.

Estas consideraciones también se aplican a los requisitos de memoria para que SQL Server se ejecute en una máquina virtual. Dado que SQL Server está diseñado para copiar en caché los datos del grupo de búferes, y normalmente usará la mayor cantidad de memoria posible, puede ser difícil determinar la cantidad ideal de RAM necesaria. Al reducir la memoria asignada a una instancia de SQL Server, finalmente llegarás a un punto en el que se intercambia la cobertura de memoria inferior para un mayor acceso de E/S de disco.

Para configurar la memoria de SQL Server en un entorno que se ha sobreaprovisionado, empieza por supervisar el entorno y las métricas de rendimiento actuales, incluida la duración prevista de la página SQL Server Buffer Manager y las lecturas de página/s y los valores de lecturas de disco/s de disco físico. Si el entorno tiene memoria excesiva, la duración prevista de la página aumentará en un valor de uno cada segundo sin ninguna disminución de la carga de trabajo, debido al almacenamiento en caché; el valor lecturas de página/s de SQL Server Buffer Manager será bajo después de que la memoria caché se incremente; y las lecturas de disco/s de disco físico también permanecerán bajas.

Una vez que comprendas la base de referencia del entorno, puedes reducir la memoria máxima del servidor en 1 GB y, después, ver cómo afecta a los contadores de rendimiento (después de que se reduzca el vaciado inicial de la memoria caché). Si las métricas siguen siendo aceptables, reduce en otro 1 GB y, luego, vuelve a supervisarlo, repitiendo según lo deseado hasta determinar una configuración ideal.

Para obtener más información, consulta Opciones de configuración de memoria del servidor.

Optimización de TempDB

El tamaño y la ubicación física de la base de datos tempdb pueden afectar al rendimiento de Operations Manager. Por ejemplo, si el tamaño definido para tempdb es demasiado pequeño, parte de la carga de procesamiento del sistema puede ocuparse con el crecimiento automático de tempdb hasta el tamaño necesario para admitir la carga de trabajo cada vez que se reinicia la instancia de SQL Server. Para lograr un rendimiento óptimo de tempdb, se recomienda la siguiente configuración para tempdb en un entorno de producción:

• Establece el modelo de recuperación de tempdb en SIMPLE. Este modelo reclama automáticamente el espacio de registro para mantener requisitos de espacio pequeños.
• Asigne espacio previamente para todos los archivos de tempdb estableciendo el tamaño de archivo en un valor lo suficientemente alto para acomodar la carga de trabajo habitual del entorno. Esto evita que tempdb se expanda con demasiada frecuencia, lo que puede afectar al rendimiento. La base de datos tempdb puede establecerse de modo que crezca automáticamente, pero solo con el fin de aumentar el espacio en disco para las excepciones no previstas.
• Crea tantos archivos como sea necesario para maximizar el ancho de banda de disco. El uso de varios archivos reduce la contención de almacenamiento de tempdb y produce una escalabilidad mejorada. Sin embargo, no crees demasiados archivos, ya que pueden reducir el rendimiento y aumentar la sobrecarga de administración. Como guía general, crea un archivo de datos para cada procesador lógico en el servidor (teniendo en cuenta cualquier configuración de máscara de afinidad) y, después, ajusta el número de archivos hacia arriba o hacia abajo según sea necesario. Como regla general, si el número de procesadores lógicos es menor o igual a 8, use el mismo número de archivos de datos que procesadores lógicos. Si el número de procesadores lógicos es superior a 8, utiliza 8 archivos de datos y, después, si la contención continúa, aumenta el número de archivos de datos en múltiplos de 4 (hasta el número de procesadores lógicos) hasta que la contención se reduzca a niveles aceptables, o bien, modifica el código o la carga de trabajo. Si la contención no se reduce, es posible que tengas que aumentar más el número de archivos de datos.
• Haz que cada archivo de datos tenga el mismo tamaño, lo que permite un rendimiento óptimo de relleno proporcional. El mismo dimensionamiento de los archivos de datos es crítico porque el algoritmo de relleno proporcional se basa en el tamaño de los archivos. Si los archivos de datos se crean con tamaños desiguales, el algoritmo de relleno proporcional intenta usar el archivo más grande para las asignaciones de GAM en lugar de distribuir las asignaciones entre todos los archivos, lo que anula el propósito de crear varios archivos de datos.
• Coloca la base de datos tempdb en un subsistema de E/S rápido mediante unidades de estado sólido para obtener el rendimiento más óptimo. Cree bandas en disco si hay muchos discos conectados directamente.
• Coloque la base de datos tempdb en discos diferentes de los que utilizan las bases de datos de usuario.

Para configurar tempdb, puedes ejecutar la consulta siguiente o modificar sus propiedades en Management Studio.

USE [tempdb]
GO
DBCC SHRINKFILE (N'tempdev' , 8)
GO
USE [master]
GO
ALTER DATABASE [tempdb] MODIFY FILE ( NAME = N'tempdev', NEWNAME = N'tempdb', SIZE = 2097152KB , FILEGROWTH = 512MB )
GO
ALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdb2', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\tempdb2.mdf' , SIZE = 2097152KB , FILEGROWTH = 512MB )
GO

Ejecuta la consulta T-SQL SELECT * from sys.sysprocesses para detectar la contención de asignación de páginas para la base de datos tempdb. En la salida de la tabla del sistema, el recurso de espera puede aparecer como "2:1:1" (página PFS) o "2:1:3" (página mapa de asignación global compartida). En función del grado de contención, esto también puede provocar que SQL Server no responda durante períodos cortos. Otro enfoque consiste en examinar las vistas de administración dinámica [sys.dm_exec_request o sys.dm_os_waiting_tasks]. Los resultados mostrarán que estas solicitudes o tareas están esperando recursos de tempdb y tienen valores similares como se resaltan anteriormente al ejecutar la consulta sys.sysprocesses.

Si las recomendaciones anteriores no reducen significativamente la contención de asignación y la contención está en páginas SGAM, implementa la marca de seguimiento -T1118 en los parámetros de inicio de SQL Server para que la marca de seguimiento permanezca en vigor incluso después de reciclar SQL Server. En esta marca de seguimiento, SQL Server asigna extensiones completas a cada objeto de base de datos, lo que elimina la contención en páginas SGAM.

Nota:

Esta marca de seguimiento afecta a todas las bases de datos de la instancia de SQL Server.

Grado de paralelismo máximo

La configuración predeterminada de SQL Server para implementaciones de tamaño pequeño a mediano de Operations Manager es adecuada para la mayoría de las necesidades. Sin embargo, cuando la carga de trabajo del grupo de administración se escala hacia arriba hacia un escenario de clase empresarial (normalmente más de 2000 sistemas administrados por agentes y una configuración de supervisión avanzada, que incluye la supervisión de nivel de servicio con transacciones sintéticas avanzadas, supervisión de dispositivos de red, multiplataforma, etc.), es necesario optimizar la configuración de SQL Server descrita en esta sección del documento. Una opción de configuración que no se ha analizado en las instrucciones anteriores es MAXDOP.

La opción de configuración de grado de paralelismo máximo de Microsoft SQL Server (MAXDOP) controla el número de procesadores que se usan para la ejecución de una consulta en un plan paralelo. Esta opción determina los recursos de subproceso y computación que se usan para los operadores de plan de consulta que realizan el trabajo en paralelo. Dependiendo de si SQL Server está configurado en un equipo con multiproceso simétrico (SMP), un equipo de acceso a memoria no uniforme (NUMA) o procesadores habilitados para hyperthreading, tendrás que configurar correctamente la opción de grado de paralelismo máximo.

Cuando SQL Server se ejecuta en un equipo con más de un microprocesador o CPU, detecta el mejor grado de paralelismo, es decir, el número de procesadores que se emplea para ejecutar una única instrucción en cada ejecución de planes en paralelo. De forma predeterminada, su valor para esta opción es 0, lo que permite a SQL Server determinar el grado de paralelismo máximo.

Los procedimientos almacenados y las consultas predefinidas en Operations Manager en relación con la base de datos operativa, de almacenamiento de datos e incluso de auditoría no incluyen la opción MAXDOP, ya que durante la instalación no hay forma de consultar dinámicamente cuántos procesadores se presentan al sistema operativo, ni intenta codificar el valor para esta configuración, lo que podría tener consecuencias negativas cuando se ejecuta la consulta.

Nota:

La opción de configuración grado de paralelismo máximo no limita el número de procesadores que usa SQL Server. Para configurar el número de procesadores que usa SQL Server, usa la opción de configuración de máscara de afinidad.

• Para los servidores que usan más de ocho procesadores, usa la siguiente configuración: MAXDOP=8
• Para los servidores que usan ocho o menos procesadores, usa la siguiente configuración: MAXDOP=0 a N

  Nota:

  En esta configuración, N representa el número de procesadores.