Consideraciones de diseño de SQL Server

Para admitir las bases de datos operativa, de almacenamiento de datos y de auditoria de ACS, System Center Operations Manager requiere acceso a una instancia de un servidor con Microsoft SQL Server. Las bases de datos operativas y de almacenamiento de datos se requieren y se crean cuando implementa su primer servidor de administración en el grupo de administración, mientras que la base de datos de ACS se crea cuando implementa un recopilador de ACS en su grupo de administración.

En un entorno de laboratorio o en una implementación a pequeña escala de Operations Manager se puede colocalizar SQL Server en el primer servicio de administración en el grupo de administración.

En una implementación distribuida de mediana escala empresarial, se puede localizar la instancia de SQL Server en un servidor independiente dedicado o en una configuración de SQL Server de alta disponibilidad. En cualquier caso, SQL Server debe existir y ser accesible antes de empezar la instalación del primer servidor de administración o 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. 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). Use una instancia de SQL Server instalada en un equipo Windows. La única excepción a esto se encuentra en el Instancia administrada de SCOM de Azure Monitor, que utiliza Azure SQL MI y no es reconfigurable.

Requisitos de SQL Server

Se admiten las siguientes versiones de SQL Server Enterprise y de SQL Server Standard para una instalación existente de la versión de System Center Operations Manager para hospedar Reporting Server, Operational, Data Warehouse y bases de datos de ACS:

• SQL Server 2022

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

  Nota

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

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

Antes de actualizar SQL Server, consulte información de actualización para 2017 e información de actualización para 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:
  • SQL Server instancias del motor de base de datos que hospedan cualquiera de las bases de datos SCOM (es decir, OperationManager, OperationManagerDW y bases de datos de SSRS ReportServer & 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

Los informes de System Center Operations Manager no se pueden instalar de forma en paralelo con una versión anterior del rol Informes y deben instalarse solo en modo nativo (no se admite el modo integrado de SharePoint).

Al planear el diseño se deben tener en cuenta consideraciones adicionales de hardware y software:

• 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 configuración.
• Se requiere .NET Framework 4.
• .NET Framework 4.8 se admite desde Operations Manager 2022.
• Reporting Server no se admite en Windows Server Core.

Para obtener 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 de db_owner. Las cuentas locales con el rol db_owner se conocen para causar problemas con System Center Operations Manager. Quite el rol db_owner de todas las cuentas locales antes de instalar el producto y no agregue el rol db_owner a ninguna de las cuentas locales después de la instalación.

Configuración de intercalación de SQL Server

Las intercalaciones de SQL Server y Windows siguientes son compatibles con System Center Operations Manager.

Nota

Para evitar problemas de compatibilidad con las operaciones de comparación o copia, se recomienda utilizar la misma intercalación para SQL y Operations Manager DB.

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 configuración de Operations Manager. Sin embargo, una actualización en contexto se completará correctamente.

Configuración de firewall

Operations Manager depende de SQL Server para hospedar las bases de datos y una plataforma de informes para analizar y presentar los 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 va a diseñar una implementación distribuida que requerirá que LOS grupos de disponibilidad de SQL Always On proporcionen 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 le ayuda a identificar los puertos de firewall necesarios para SQL Server que se deben permitir como mínimo para que los roles de servidor en el grupo de administración de Operations Manager se puedan comunicar correctamente.

Escenario	Port	Direction	Rol de Operations Manager
SQL Server que hospeda bases de datos de Operations Manager	TCP 1433 *	Entrante	servidor de administración y consola web (para Application Advisor y Diagnóstico de aplicaciones)
Servicio SQL Server Browser	UDP 1434	Entrante	Servidor de administración
Conexión de administración dedicada de SQL Server	TCP 1434	Entrante	Servidor de administración
Otros puertos 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	Entrante	Servidor de administración
Escucha de grupo de disponibilidad de SQL Server Always On	Puerto configurado por el administrador	Entrante	Servidor de administración
SQL Server Reporting Services que hospeda el servidor de informes de Operations Manager	TCP 80 (predeterminado)/443 (SSL)	Entrante	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, vea Configure the Windows Firewall to Allow SQL Server Access (Configurar Firewall de Windows para permitir el acceso a SQL Server).

Consideraciones de capacidad y almacenamiento

Base de datos OperationsManager

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 ajuste y configuración del servidor de bases de datos es fundamental para el rendimiento general del grupo de administración. El recurso más importante que usa la base de datos de Operations Manager es el subsistema de almacenamiento, pero la CPU y RAM también son significativas.

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

• Frecuencia 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 llegan al sistema. La frecuencia de los datos operativos recopilados tiende a aumentar a medida que se importan los módulos de administración adicionales y se agregan los agentes adicionales. El tipo de equipo que supervisa un agente también es un factor importante que se usa al determinar la frecuencia global de recopilación de datos operativos. Por ejemplo, puede esperarse que un agente que supervisa un equipo de escritorio fundamental 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.
• Frecuencia de cambios de espacio de instancia. La actualización de estos datos en la base de datos de Operations Manager es costoso en comparación con el costo de escribir nuevos datos operativos. Además, cuando cambian los datos del espacio de instancia, los servidores de administración pueden hacer consultas adicionales a la base de datos de Operations Manager con el fin de calcular los cambios de configuración y de grupo. La frecuencia de cambios de espacio de instancia aumenta a medida que importa módulos de administración adicionales a un grupo de administración. Agregar nuevos agentes a un grupo de administración también aumenta temporalmente la frecuencia de cambios de espacio de instancia.
• Número de consolas de Operations Manager y otras conexiones de SDK que se ejecutan simultáneamente. Cada consola de operaciones lee los datos de la base de datos de Operations Manager. Consultar estos datos consume potencialmente grandes cantidades de almacenamiento de recursos de E/S, tiempo de CPU y RAM. La mayor carga de la base de datos la suelen provocar las consolas del operador que muestran grandes cantidades de datos operativos en la vista de eventos, vista de estado, vista de alertas y vista de datos de rendimiento.

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 que esté altamente disponible con configuraciones de conmutación por error admitidas, como los grupos de disponibilidad de SQL Server Always On o las 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 una 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, siga estos pasos:

1. Ejecute la siguiente consulta SQL:

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

2. Omita este paso si el valor que se muestra en el campo is_broker_enabled es is_broker_enabled (uno). De lo contrario, ejecute 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, es importante tener suficiente capacidad en este servidor que admita la escritura de todos los datos que se recopilan en el almacenamiento de datos de informes. Al igual que con la base de datos de Operations Manager, el recurso más importante 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 las de la base de datos de Operations Manager, pero pueden variar. Además, la carga de trabajo sobre el almacenamiento de datos de informes por informar es diferente de la carga sobre la base de datos de Operations Manager debida al uso de la consola del operador.

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

• Frecuencia de recopilación de datos operativos. Para permitir una generación de informes más eficaz, el almacenamiento de datos de informes calcula y almacena los datos agregados, además de una cantidad limitada de datos sin procesar. Este trabajo adicional implica que la recopilación de datos operativos para el almacenamiento de datos de informes puede ser ligeramente más costosa que la base de datos de Operations Manager. Este costo adicional normalmente se equilibra mediante la reducción del costo de procesamiento de los datos de detección por el almacenamiento de datos de informes frente a la base de datos de Operations Manager.
• Número de usuarios que informan simultáneamente o generación de informes programados. Dado que generalmente los informes resumen grandes volúmenes de datos, cada usuario que informa puede agregar una carga significativa en el sistema. Tanto el número de informes que se ejecutan simultáneamente como el tipo de informes que se va a ejecutar afectan a las necesidades de capacidad total. Por lo general, los informes que consultan grandes intervalos de fechas o grandes cantidades de objetos requieren recursos adicionales del sistema.

En base a estos factores, hay varios procedimientos recomendados que se deben tener en cuenta al cambiar el tamaño del almacenamiento de datos de informes:

• Elija un subsistema de almacenamiento adecuado. Dado que el almacenamiento de datos de informes es una parte integral del flujo de datos en el 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 debería 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.
• Considere cuál es la ubicación adecuada de los registros de datos frente a los registros de transacciones. Para la base de datos de Operations Manager, separar los registros de transacciones y de datos de SQL a medida que aumenta el número de agentes suele ser una opción adecuada. Si tanto la base de datos de Operations Manager como el almacenamiento de datos de informes están ubicados en el mismo servidor y quiere separar los datos y los registros de transacciones, debe poner los registros de transacciones de la base de datos de Operations Manager en un volumen físico y ejes de disco independientes del almacenamiento de datos de informes para obtener algún beneficio. 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 y cuando 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.
• Considere la posibilidad de ubicar el almacenamiento de datos de informes en un servidor independiente de la base de datos de Operations Manager. Aunque las implementaciones a menor escala a menudo pueden 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 almacén de datos de informes y el servidor de informes se encuentran en un servidor independiente de la base de datos de Operations Manager, se logra un mejor rendimiento en la elaboración de informes.

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

SQL Server Always On

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

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

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á implementar un clúster 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. Luego, puede agregar la base de datos de Operations Manager de SQL Server como una base de datos de disponibilidad.

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

Nota

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

Cadena de varias subredes

Operations Manager no admite las cadena de conexión palabras clave (MultiSubnetFailover=True). Las solicitudes de conexión de cliente desde los servidores de administración superarán el tiempo de espera de la conexión al agente de escucha del grupo de disponibilidad. Esto se debe a que un grupo de disponibilidad tiene un nombre de agente de escucha (conocido como nombre de red o punto de acceso de cliente en el administrador de clústeres de WSFC) que depende de varias direcciones IP de distintas subredes, como cuando se realiza una implementación en una configuración de conmutación por error entre sitios.

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

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

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

Ejecute 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 usa Always On con un nombre de agente de escucha, también debe realizar estos cambios de configuración en el agente de escucha. Para más información sobre cómo configurar un agente de escucha de grupo de disponibilidad, consulte la documentación aquí: Configuración del agente de escucha del grupo de disponibilidad: SQL Server Always On

Ejecute los siguientes comandos de PowerShell en el nodo SQL que hospeda actualmente el agente 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 en clúster o Always On para la alta disponibilidad, debe habilitar la característica de recuperación automática en los servidores de administración para evitar el reinicio del servicio Operations Manager Data Access cada vez que se produzca una conmutación por error entre los nodos. Para obtener información sobre cómo configurar esto, vea el siguiente artículo de Knowledge Base, The System Center Management service stops responding after an instance of SQL Server goes offline (El servicio de administración de System Center deja de responder después de que una instancia de SQL Server se quede sin conexión).

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 sí mismo; en su lugar, está directamente relacionado con la configuración del subsistema de almacenamiento. Los cuellos de botella de rendimiento a menudo se atribuyen a no seguir las siguientes instrucciones 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 que el LUN admita los requisitos de E/S de Operations Manager.
• Hospedaje en el mismo volumen de registros de transacciones y archivos de bases de datos. 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 ajuste de tamaño, etc.
• Desalineación de particiones de disco de los volúmenes que hospedan los registros de transacciones de la base de datos, los archivos de base de datos y TempDB.
• Con vistas a la configuración básica de SQL Server, como el uso de AUTOGROW para archivos de base de datos y de registro de transacciones, la configuración MAXDOP para el 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 fundamentales para la implementación de SQL Server para Operations Manager. Los servidores de base de datos suelen estar muy limitados en E/S debido a la actividad de lectura y escritura de la base de datos y el procesamiento de registro de transacciones rigurosos. El patrón de comportamiento de E/S de Operations Manager normalmente es de 80 % de escrituras y 20 % de lecturas. Como resultado, una configuración incorrecta de los subsistemas de E/S puede provocar un rendimiento y funcionamiento deficientes de los sistemas de SQL Server, algo notable en Operations Manager.

Es importante probar el diseño del SQL Server realizando pruebas de rendimiento del subsistema de E/S antes de implementar SQL Server. Asegúrese de que estas pruebas pueden lograr los requisitos de E/S con una latencia aceptable. Use la utilidad Diskspd para averiguar la capacidad de E/S del subsistema de almacenamiento compatible con 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 mediante esta herramienta con algún 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 de volumen, conocida comúnmente como la alineación de sectores, se debe realizar en el sistema de archivos (NTFS) cada vez que se cree un volumen en un dispositivo RAID. Si no lo hace, 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 franja. También puede ocasionar un error de alineación de caché del hardware, lo que provocará un uso poco eficaz de la caché de matriz. Al dar formato a la partición que se usará para SQL Server archivos de datos, se recomienda usar un tamaño de unidad de asignación de 64 KB (es decir, 65 536 bytes) para datos, registros y tempdb. Sin embargo, tenga en cuenta 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.

Reserva de memoria

Nota

Gran parte de la información de esta sección procede de la entrada de blog de Jonathan Kehayias ¿Cuánta memoria necesita realmente mi instancia de SQL Server? (sqlskills.com).

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

SQL Server le permite configurar la cantidad mínima y máxima de memoria que este proceso reservará y usará. De forma predeterminada, SQL Server puede cambiar de forma dinámica los requisitos de memoria, en base a los recursos del sistema disponibles. El valor de configuración predeterminado para Memoria de servidor mínima es 0 y para Memoria de servidor máxima es 2 147 483 647 MB.

Pueden surgir problemas relacionados con el rendimiento y la memoria si no se establece un valor adecuado para Memoria de servidor máxima. Muchos factores influyen en la cantidad de memoria que necesita asignar a SQL Server para asegurarse de que el sistema operativo puede 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 paginarán en el disco. Esto puede hacer que la E/S del disco aumente, lo que reduce aún más el rendimiento y crea un efecto dominó donde se hace perceptible en Operations Manager.

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

Para Memoria de servidor máxima, 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 que haya establecido estos valores, supervise el contador Memoria\MBytes disponibles de Windows para determinar si puede aumentar la memoria disponible para SQL Server. Windows indica que la memoria física disponible se está ejecutando a 96 MB, por lo que idealmente el contador no debe ejecutarse inferior a unos 200-300 MB, para asegurarse de que tiene un búfer. En el caso de los servidores con 256 GB de RAM o superior, probablemente querrá asegurarse de que no se ejecute por debajo de 1 GB.

Tenga en cuenta que estos cálculos asumen que desea que SQL Server pueda usar toda la memoria disponible, a menos que los modifique para tener en cuenta otras aplicaciones. Tenga en cuenta 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 pila es de 512 KB para sistemas x86, 2 MB para sistemas x64 y 4 MB para sistemas IA64. Además, puede encontrar el valor para el número 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. Puesto SQL Server está diseñado para almacenar en caché los datos del grupo de búferes y normalmente usará tanta memoria como sea posible, puede ser difícil determinar la cantidad ideal de RAM necesaria. Al reducir la memoria asignada a una instancia de SQL Server, al final llegará a un punto en el que se intercambiará la asignación de memoria inferior por un mayor acceso de E/S de disco.

Para configurar la memoria de SQL Server en un entorno que se ha aprovisionado en exceso, empiece por supervisar el entorno y las métricas de rendimiento actuales, incluidas la duración prevista de la página y las lecturas de página por segundo del administrador de búferes de SQL Server y los valores de lecturas de disco físico por segundo del disco físico. Si el entorno tiene un exceso de memoria, la duración prevista de la página aumentará en un valor de uno por segundo sin ninguna disminución en la carga de trabajo, debido al almacenamiento en caché; el valor de lecturas de página por segundo del administrador de búferes de SQL Server será bajo después de que la memoria caché se descontrole; por otra parte, las lecturas de disco físico por segundo del disco físico también permanecerán bajas.

Una vez que comprenda la línea base del entorno, puede reducir el valor de Memoria de servidor máxima en 1 GB y luego ver cómo afecta a los contadores de rendimiento (después de que se reduzca cualquier vaciado de caché inicial). Si las métricas sigue siendo aceptable, reduzca otro 1 GB y vuelva a supervisar, repitiendo el proceso según sea necesario hasta que determine una configuración ideal.

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

Optimizar 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 que se rellene con el crecimiento automático de tempdb hasta el tamaño necesario para admitir la carga de trabajo cada vez que se reinicie la instancia de SQL Server. Para conseguir un rendimiento óptimo, se recomienda la siguiente configuración para tempdb en un entorno de producción:

• Establezca el modelo de recuperación de tempdb en SIMPLE. Este modelo recupera automáticamente espacio de registro para mantener bajos los requisitos de espacio.
• Asigne espacio previamente para todos los archivos de tempdb estableciendo el tamaño del archivo en un valor lo suficientemente grande como para dar cabida a una carga de trabajo típica del entorno. Evita que tempdb se expanda con demasiada frecuencia, lo que puede afectar al rendimiento. Se puede establecer la base de datos tempdb en crecimiento automático, pero esto debería usarse para aumentar el espacio en disco para las excepciones imprevistas.
• Cree tantos archivos como sea necesario para maximizar el ancho de banda del disco. El uso de varios archivos reduce la contención de almacenamiento de tempdb y produce una escalabilidad mejorada. Sin embargo, no cree demasiados archivos, ya que puede reducir el rendimiento y aumentar la sobrecarga de administración. Como norma general, cree un archivo de datos para cada procesador lógico en el servidor (teniendo en cuenta los valores de máscara de afinidad) y, después, ajuste 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 mayor que 8, use 8 archivos de datos y después, si se mantiene la contención, aumente 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 y alcance niveles aceptables o realice cambios en el código o la carga de trabajo. Si la contención no se reduce, es posible que tenga que aumentar más el número de archivos de datos.
• Haga que cada archivo de datos sea del mismo tamaño, lo que permite un rendimiento de relleno proporcional óptimo. El tamaño uniforme de archivos de datos es importante porque el algoritmo de relleno proporcional se basa en el tamaño de los archivos. Si se crean archivos de datos con distintos tamaños, el algoritmo de relleno proporcional intenta usar el archivo más grande para las asignaciones de página GAM en lugar de distribuir las asignaciones entre todos los archivos, con lo que frustra el propósito de crear varios archivos de datos.
• Coloque la base de datos tempdb en un subsistema de E/S rápido con unidades de estado sólido para obtener un rendimiento óptimo. Cree bandas en disco si hay muchos discos conectados directamente.
• Coloque la base de datos tempdb en discos diferentes de los que usan las bases de datos de usuario.

Para configurar tempdb, puede ejecutar la siguiente consulta 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

Ejecute la consulta SELECT * from sys.sysprocesses T-SQL para detectar la contención de asignación de páginas para la base de datos tempdb. En la salida de tabla del sistema, el recurso de espera puede aparecer como "2:1:1" (página PFS) o "2:1:3" (página del mapa de asignación global compartida). Según el grado de contención, esto también podría hacer que SQL Server parezca no responder durante períodos cortos. Otro enfoque es 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 tempdb y tienen valores similares como se resaltaba 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 de SGAM, implemente la marca de seguimiento -T1118 en los parámetros de inicio para SQL Server para que la marca de seguimiento permanezca en vigor incluso después de reciclar SQL Server. Bajo esta marca de seguimiento, SQL Server asigna extensiones completas a cada objeto de base de datos, lo que elimina la contención en las páginas SGAM.

Nota

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

Grado máximo de paralelismo

La configuración predeterminada de SQL Server para implementaciones de Operations Manager de tamaño pequeño a mediano 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 que se describe en esta sección del documento. Una opción de configuración que no se ha analizado en la guía anterior es MAXDOP.

La opción de configuración del grado máximo de paralelismo 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 proceso y subproceso que se usan para los operadores de plan de consultas que realizan el trabajo en paralelo. Dependiendo de si SQL Server está configurado en un equipo de multiprocesamiento simétrico (SMP), un equipo de acceso a memoria no uniforme (NUMA) o procesadores habilitados para hyperthreading, tiene que configurar la opción grado máximo de paralelismo correctamente.

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 usados para ejecutar una única instrucción, para cada ejecución de planes paralelos. De forma predeterminada, el valor para esta opción es 0, lo que permite a SQL Server determinar el grado máximo de paralelismo.

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

Nota

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

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

  Nota

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