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 es accesible antes de iniciar 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 Instancia administrada o Amazon Relational Database Service (AWS RDS). Use una instancia de SQL Server instalada en una máquina Windows. La única excepción a esto se encuentra en el Instancia administrada SCOM de Azure Monitor, que usa Azure SQL MI y no es reconfigurable.

requisitos de SQL Server

Las siguientes versiones de SQL Server Enterprise & Standard Edition son compatibles con una instalación existente de la versión de System Center Operations Manager para hospedar la base de datos Reporting Server, Operational, Data Warehouse 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.
  • Use ODBC 17.3 o 17.10.6 y MSOLEDBSQL 18.2 o 18.7.2.

• Actualizaciones acumulativas y de SQL Server 2017 como se detalla aquí

Antes de actualizar SQL Server, consulte 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:
  • 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 & 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 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).

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 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 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 autenticación en modo mixto de SQL seguirá funcionando si ninguna cuenta local tiene el rol de db_owner. Se sabe que las cuentas locales con el rol de db_owner provocan 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

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 configuració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 va a diseñar una implementación distribuida que requerirá grupos de disponibilidad AlwaysOn 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 le 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
Hospedaje de bases de datos de Operations Manager en SQL Server	TCP 1433 *	Entrada	servidor de administración y consola web (para Application Advisor y Application Diagnostics)
servicio SQL Server Browser	UDP 1434	Entrada	servidor de administración
Conexión de administrador dedicada de SQL Server	TCP 1434	Entrada	servidor de administración
Puertos adicionales usados por SQL Server - Llamadas a procedimientos remotos 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
Agente de escucha de grupo de disponibilidad AlwaysOn de SQL Server	Puerto configurado por el 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, vea Configurar firewall de Windows para permitir el acceso a SQL Server.

Consideraciones sobre la capacidad y el 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 necesarios por Operations Manager para la supervisión diaria. El ajuste de tamaño y la configuración del servidor de bases de datos es fundamental 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 entra 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.
• Velocidad 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 importa 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, 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 is_broker_enabled campo es 1 (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 capacidad suficiente 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 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 del operador.

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 costo adicional suele equilibrarse con el costo reducido de procesar 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 generales de capacidad. Por lo general, los informes que consultan intervalos de fechas grandes o un gran número de objetos requieren recursos adicionales del sistema.

En función de estos factores, hay varias prácticas recomendadas 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 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.
• Considere la ubicació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 suelen 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 desea separar los datos y los registros de transacciones, debe colocar los registros de transacciones para la base de datos de Operations Manager en un volumen físico independiente y los spindles 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.
• Considere 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á 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 AlwaysOn de SQL Server o instancias de clúster de conmutación por error.

SQL Server Always On

Los grupos de disponibilidad AlwaysOn 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). 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, sql AlwaysOn se prefiere a través 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 temporales, se pueden hospedar en un grupo de disponibilidad AlwaysOn.

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 AlwaysOn en los nodos del clúster. A continuación, puede agregar la base de datos de SQL Server de Operations Manager como base de datos de disponibilidad.

• Obtenga más información sobre los requisitos previos de AlwaysOn.
• Obtenga más información sobre cómo configurar un WSFC para grupos de disponibilidad AlwaysOn.
• Obtenga 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 AlwaysOn, para habilitar la seguridad estricta de CLR, ejecute 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 agente 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 agente de escucha del grupo de disponibilidad alcanzarán un tiempo de espera de conexión.

El enfoque recomendado para solucionar esta limitación cuando haya 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 sola dirección IP activa en DNS.
2. Configure 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, para una recuperación y resolución más rápidas del nombre del clúster con la nueva dirección IP.

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 AlwaysOn con un nombre de agente de escucha, también debe realizar estos cambios de configuración en el agente de escucha. Para obtener 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 AlwaysOn

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 AlwaysOn o en clúster para alta disponibilidad, debe habilitar 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, consulte 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 las instrucciones de configuración recomendadas con el almacenamiento aprovisionado para la instancia de base de datos de SQL Server. Estos ejemplos son:

• Asignación insuficiente de spindles para los LUN para admitir los requisitos de E/S de Operations Manager.
• Hospedar 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 ajuste de tamaño, etc.
• Alineación incorrecta 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.
• Con vistas a 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 de 80 % de escrituras y 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úrese de que estas pruebas pueden lograr los requisitos de E/S con una latencia aceptable. Use 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 mediante 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 unidad de asignación 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 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 provocar errores de alineació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. Tenga 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.

Reserva de memoria

Nota:

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

No siempre es fácil identificar la cantidad correcta de memoria física y procesadores para asignar a SQL Server en compatibilidad con System Center Operations Manager (o para otras cargas de trabajo fuera de este producto). La calculadora de ajuste de tamaño proporcionada por el grupo de productos proporciona 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 le 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 dinámicamente en función de los recursos del sistema disponibles. La configuración predeterminada para la memoria mínima del servidor es 0 y la configuración predeterminada para la memoria máxima del servidor es de 2 147 483 647 MB.

Los problemas relacionados con el rendimiento y la memoria pueden surgir si no establece un valor adecuado para la memoria máxima del servidor. Muchos factores influyen en la cantidad de memoria que necesita 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 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 onda 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 el número máximo de memoria 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, supervise el contador Memoria\MBytes disponible en Windows para determinar si puede aumentar la memoria disponible para SQL Server. Windows indica que la memoria física disponible se está ejecutando bajo en 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 RAM de 256 GB o superior, probablemente querrá asegurarse de que no se ejecute por debajo de 1 GB.

Tenga en cuenta que estos cálculos suponen que desea que SQL Server pueda usar toda la memoria disponible, a menos que las 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 la pila es de 512 KB para sistemas x86, 2 MB para sistemas x64 y 4 MB para sistemas IA64, y puede 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 almacenar 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á a un punto en el que se intercambia la asignación 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, empiece por supervisar el entorno y las métricas de rendimiento actuales, incluida la esperanza de vida de la página del Administrador de búferes de SQL Server y las lecturas de páginas/s y los valores de lecturas por segundo del disco disco físico. Si el entorno tiene memoria excesiva, la esperanza de vida 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é; las lecturas de página del Administrador de búferes de SQL Server/s serán bajas después de que la memoria caché se incremente; y el disco de disco físico también permanecerá bajo.

Una vez que comprenda la línea de base del entorno, puede 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, reduzca en otros 1 GB y, a continuación, vuelva a supervisarlo, repitiendo según lo deseado hasta determinar una configuración ideal.

Para obtener más información, consulte 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 tomarse con tempdb de crecimiento automático al tamaño necesario para admitir la carga de trabajo cada vez que reinicie 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:

• Establezca el modelo de recuperación de tempdb en SIMPLE. Este modelo reclama automáticamente el espacio de registro para mantener pequeños requisitos de espacio.
• 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. Impide que tempdb se expanda con demasiada frecuencia, lo que puede afectar al rendimiento. La base de datos tempdb se puede establecer en crecimiento automático, pero se debe usar para aumentar el espacio en disco para excepciones no planeadas.
• Cree tantos archivos como sea necesario para maximizar el ancho de banda de disco. El uso de varios archivos reduce la contención de almacenamiento 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 guía general, cree un archivo de datos para cada procesador lógico en el servidor (teniendo en cuenta cualquier configuración de máscara de afinidad) y, a continuación, 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 ocho archivos de datos y, después, si continúa la contención, aumente el número de archivos de datos por múltiplos de 4 (hasta el número de procesadores lógicos) hasta que la contención se reduzca a niveles aceptables o realice cambios en la carga de trabajo o código. 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 el mismo tamaño, lo que permite un rendimiento óptimo de relleno proporcional. El tamaño igual de los archivos de datos es fundamental 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.
• Coloque 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, puede 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

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 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 aparezca sin responder 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, implemente 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 máximo de paralelismo

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 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 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 informáticos y de subproceso que se usan para los operadores del plan de consulta 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 de forma adecuada.

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 empleados para ejecutar una sola instrucción, para cada ejecución del plan paralelo. De forma predeterminada, su 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 forma de realizar la instalación para consultar dinámicamente cuántos procesadores se presentan al sistema operativo, ni intenta codificar de forma difícil 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 SQL Server. Para configurar el número de procesadores que usa SQL Server, use la opción de configuración de máscara de afinidad.

• Para los servidores que usan más de ocho procesadores, use la siguiente configuración: MAXDOP=8
• Para 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.