Considerações sobre design do SQL Server

O System Center Operations Manager requer acesso a uma instância de um servidor que executa o Microsoft SQL Server para dar suporte ao banco de dados operacional, de data warehouse e de auditoria do ACS. Os bancos de dados operacionais e de data warehouse são necessários e criados quando você implanta o primeiro servidor de gerenciamento em seu grupo de gerenciamento, enquanto o banco de dados ACS é criado quando você implanta um coletor ACS em seu grupo de gerenciamento.

Em um ambiente de laboratório ou implantação em pequena escala do Operations Manager, o SQL Server pode ser colocalizado no primeiro servidor de gerenciamento no grupo de gerenciamento.

Em uma implantação distribuída de escala média a empresarial, a instância do SQL Server deve estar localizada em um servidor autônomo dedicado ou em uma configuração de alta disponibilidade do SQL Server. Em ambos os casos, o SQL Server já deve existir e estar acessível antes de iniciar a instalação do primeiro servidor de gerenciamento ou coletor ACS.

Não recomendamos a utilização de bancos de dados do Operations Manager de uma instância do SQL que tenha outros bancos de dados de aplicativo. Isso é para evitar possíveis problemas com E/S e outras restrições de recursos de hardware.

Importante

O Operations Manager não dá suporte a instâncias de PaaS (Plataforma como Serviço) do SQL, incluindo produtos como a Instância Gerenciada de SQL do Azure ou o AWS RDS (Amazon Relational Database Service). Use uma instância do SQL Server instalada em um computador Windows. A única exceção a isso é na Instância Gerenciada do SCOM do Azure Monitor, que utiliza a MI do SQL do Azure e não é reconfigurável.

Requisitos do SQL Server

As seguintes versões do SQL Server Enterprise e Standard Edition têm suporte para uma instalação existente da versão do System Center Operations Manager para hospedar o Servidor de Relatórios, Operacional, Data Warehouse e banco de dados ACS:

• SQL Server 2022

• SQL Server 2019 com Atualização Cumulativa 8 (CU8) ou posterior, conforme detalhado aqui

  Observação

  • O Operations Manager 2022 dá suporte ao SQL 2019 com CU8 ou posterior; no entanto, ele não dá suporte ao SQL 2019 RTM.
  • Use ODBC 17.3 ou 17.10.6 e MSOLEDBSQL 18.2 ou 18.7.2.

• SQL Server 2017 e atualizações cumulativas, conforme detalhado aqui

Antes de atualizar o SQL Server, consulte informações de atualização para 2017 e informações de atualização para SQL 2019.

Observação

• Cada um dos seguintes componentes do SQL Server que dão suporte a uma infraestrutura SCOM deve estar na mesma versão principal do SQL Server:
  • Instâncias do mecanismo de banco de dados do SQL Server que hospedam qualquer um dos bancos de dados SCOM (ou seja, os bancos de dados OperationManager, OperationManagerDW e SSRS ReportServer e ReportServerTempDB).
  • Instância do SSRS (SQL Server Reporting Services).
• A configuração de agrupamento do SQL Server deve ser um dos tipos com suporte, conforme descrito na seção de configuração de agrupamento do SQL Server abaixo.
• A Pesquisa de Texto Completa do SQL Server é necessária para todas as instâncias do mecanismo de banco de dados do SQL Server que hospedam qualquer um dos bancos de dados SCOM.
• As opções de instalação do Windows Server 2016 (Server Core, Server with Desktop Experience e Nano Server) com suporte dos componentes de banco de dados do Operations Manager são baseadas em quais opções de instalação do Windows Server são suportadas pelo SQL Server.

Observação

Os Relatórios do System Center Operations Manager não podem ser instalados lado a lado com uma versão anterior da função de Relatório e devem ser instalados apenas no modo nativo (não há suporte para o modo integrado do SharePoint).

Considerações adicionais de hardware e software se aplicam ao seu planejamento de projeto:

• Recomendamos que você execute o SQL Server em computadores com o formato de arquivo NTFS.
• Deve haver pelo menos 1024 MB de espaço livre em disco para o banco de dados operacional e de data warehouse. Ele é imposto no momento da criação do banco de dados e provavelmente crescerá significativamente após a instalação.
• O .NET Framework 4 é necessário.
• O Operations Manager 2022 dá suporte ao .NET Framework 4.8.
• Não há suporte para o Reporting Server no Windows Server Core.

Para obter mais informações, consulte Requisitos de hardware e software para a instalação do SQL Server.

Observação

Embora o Operations Manager use apenas a autenticação do Windows durante a instalação, a configuração de Autenticação de Modo Misto do SQL ainda funcionará se nenhuma conta local tiver a função db_owner. Sabe-se que as contas locais com a função db_owner causam problemas com o System Center Operations Manager. Remova a função db_owner de todas as contas locais antes de instalar o produto e não adicione a função db_owner a nenhuma das contas locais após a instalação.

Configuração de agrupamento do SQL Server

Os agrupamentos do SQL Server e do Windows a seguir são compatíveis com o System Center Operations Manager.

Observação

Para evitar problemas de compatibilidade na comparação ou cópia de operações, recomendamos que você use a mesma ordenação para o banco de dados SQL e Operations Manager.

Ordenação do SQL Server

• SQL_Latin1_General_CP1_CI_AS

Ordenação do 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

Se sua instância do SQL Server não estiver configurada com um dos agrupamentos com suporte listados anteriormente, a execução de uma nova configuração da instalação do Operations Manager falhará. No entanto, uma atualização in-loco será concluída com êxito.

Configuração do firewall

O Operations Manager depende do SQL Server para hospedar seus bancos de dados e de uma plataforma de relatórios para analisar e apresentar dados operacionais históricos. As funções de servidor de gerenciamento, Operações e console Web precisam ser capazes de se comunicar com êxito com o SQL Server, e é importante entender o caminho de comunicação e as portas para configurar seu ambiente corretamente.

Se você estiver criando uma implantação distribuída que exigirá que os Grupos de Disponibilidade Always On do SQL forneçam funcionalidade de failover para os bancos de dados do Operations Manager, há definições de configuração de firewall adicionais que precisam ser incluídas em sua estratégia de segurança de firewall.

A tabela a seguir ajuda a identificar as portas de firewall exigidas pelo SQL Server que precisarão ser permitidas no mínimo para que as funções de servidor em seu grupo de gerenciamento do Operations Manager se comuniquem com êxito.

Cenário	Porta	Direção	Função do Gerente de Operações
SQL Server hospedando bancos de dados do Operations Manager	TCP 1433 *	Entrada	servidor de gerenciamento e console Web (para Application Advisor e Application Diagnostics)
Serviço Navegador do SQL Server	UDP 1434	Entrada	Management Server
Conexão de administrador dedicado do SQL Server	TCP 1434	Entrada	Management Server
Portas adicionais usadas pelo SQL Server - Chamadas de procedimento remoto da Microsoft (MS RPC) - Instrumentação de Gerenciamento do Windows (WMI) - Coordenador de Transações Distribuídas da Microsoft (MS DTC)	TCP 135	Entrada	Management Server
Ouvinte do Grupo de Disponibilidade Always On do SQL Server	Porta configurada pelo administrador	Entrada	Management Server
SQL Server Reporting Services hospedando o Servidor de Relatórios do Operations Manager	TCP 80 (padrão)/443 (SSL)	Entrada	servidor de gerenciamento e console de operações

* Embora a TCP 1433 seja a porta predefinida para a instância padrão do Mecanismo de Banco de Dados, quando você criar uma instância nomeada em um SQL Server autônomo ou implantar um grupo de disponibilidade Always On do SQL, uma porta personalizada deverá ser definida e documentada para referência a fim de que você configure os firewalls corretamente e insira essas informações durante a instalação.

Para obter uma visão geral mais detalhada dos requisitos de firewall para o SQL Server, consulte Configurar o Firewall do Windows para permitir o acesso ao SQL Server.

Considerações sobre capacidade e armazenamento

Banco de dados do Operations Manager

O banco de dados do Operations Manager é um banco de dados do SQL Server que contém todos os dados necessários para o Operations Manager para o monitoramento diário. O dimensionamento e a configuração do servidor de banco de dados são essenciais para o desempenho geral do grupo de gerenciamento. O recurso mais crítico usado pelo banco de dados do Operations Manager é o subsistema de armazenamento, mas a CPU e a RAM também são significativas.

Os fatores que influenciam a carga no banco de dados do Operations Manager incluem:

• Taxa de coleta de dados operacionais. Os dados operacionais consistem em todos os eventos, alertas, alterações de estado e dados de desempenho coletados pelos agentes. A maioria dos recursos usados pelo banco de dados do Operations Manager é usada para gravar esses dados no disco à medida que eles entram no sistema. A taxa de dados operacionais coletados tende a aumentar à medida que pacotes de gerenciamento adicionais são importados e agentes adicionais são adicionados. O tipo de computador que um agente está monitorando também é um fator importante usado para determinar a taxa geral de coleta de dados operacionais. Por exemplo, pode-se esperar que um agente que esteja monitorando um computador desktop comercialmente crítico colete menos dados do que um agente que monitora um servidor que esteja executando uma instância do SQL Server com um grande número de bancos de dados.
• A taxa de alterações no espaço de instância. Atualizar esses dados no banco de dados do Operations Manager é caro em relação à gravação de novos dados operacionais. Além disso, quando os dados do espaço da instância são alterados, os servidores de gerenciamento fazem consultas adicionais ao banco de dados do Operations Manager para calcular a configuração e as alterações de grupo. A taxa de alterações no espaço de instância aumenta à medida que você importa pacotes de gerenciamento adicionais para um grupo de gerenciamento. A adição de novos agentes a um grupo de gerenciamento também aumenta temporariamente a taxa de alterações no espaço da instância.
• Número de Consoles de Operações e outras conexões do SDK em execução simultaneamente. Cada console de Operações lê dados do banco de dados do Operations Manager. Consultar esses dados consome quantidades potencialmente grandes de recursos de E/S de armazenamento, tempo de CPU e RAM. Os consoles de operações que exibem grandes quantidades de dados operacionais na Exibição de Eventos, Exibição de Estado, Exibição de Alertas e Exibição de Dados de Desempenho tendem a causar a maior carga no banco de dados.

O banco de dados do Operations Manager é uma única fonte de falha para o grupo de gerenciamento, portanto, ele pode ser altamente disponibilizado usando configurações de failover com suporte, como Grupos de Disponibilidade Always On do SQL Server ou Instâncias de Cluster de Failover.

Você pode configurar e atualizar bancos de dados do Operations Manager com uma configuração Always-On do SQL existente sem a necessidade de alterações pós-configuração.

Habilitar o SQL Broker no banco de dados do Operations Manager

O System Center Operations Manager depende do SQL Server Service Broker para implementar todas as operações de tarefa. Se o SQL Server Service Broker estiver desabilitado, todas as operações de tarefa serão afetadas. O comportamento resultante pode variar de acordo com a tarefa iniciada. Portanto, é importante verificar o estado do SQL Server Service Broker sempre que um comportamento inesperado for observado em torno de uma tarefa no System Center Operations Manager.

Para habilitar o SQL Server Service Broker, siga estas etapas:

1. Execute a seguinte consulta SQL:

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

2. Pule esta etapa se o valor exibido no is_broker_enabled campo for 1 (um). Caso contrário, execute as seguintes consultas SQL:

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

Banco de dados do data warehouse do Operations Manager

System Center – Operations Manager insere dados no data warehouse de Relatórios quase em tempo real, é importante ter capacidade suficiente nesse servidor que dê suporte à gravação de todos os dados que estão sendo coletados no data warehouse de Relatórios. Assim como acontece com o banco de dados do Operations Manager, o recurso mais crítico no data warehouse de Relatórios é o subsistema de E/S de armazenamento. Na maioria dos sistemas, as cargas no data warehouse de Relatórios são semelhantes ao banco de dados do Operations Manager, mas podem variar. Além disso, a carga de trabalho colocada no data warehouse de Relatórios por meio de relatórios é diferente da carga colocada no banco de dados do Operations Manager pelo uso do console de Operações.

Os fatores que influenciam a carga no data warehouse de relatórios incluem:

• Taxa de coleta de dados operacionais. Para permitir relatórios mais eficientes, o data warehouse de relatórios calcula e armazena dados agregados, além de uma quantidade limitada de dados brutos. Fazer esse trabalho extra significa que a coleta de dados operacionais para o data warehouse de Relatórios pode ser um pouco mais cara do que para o banco de dados do Operations Manager. Esse custo adicional normalmente é equilibrado pelo custo reduzido de processamento de dados de descoberta pelo data warehouse de Relatórios versus o banco de dados do Operations Manager.
• Número de usuários de relatórios simultâneos ou geração de relatórios agendada. Como os relatórios frequentemente resumem grandes volumes de dados, cada usuário de relatório pode adicionar uma carga significativa no sistema. O número de relatórios executados simultaneamente e o tipo de relatórios que estão sendo executados afetam as necessidades gerais de capacidade. Geralmente, os relatórios que consultam grandes intervalos de datas ou um grande número de objetos exigem recursos adicionais do sistema.

Com base nesses fatores, há várias práticas recomendadas a serem consideradas ao dimensionar o data warehouse de relatórios:

• Escolha um subsistema de armazenamento apropriado. Como o data warehouse de Relatórios é parte integrante do fluxo geral de dados por meio do grupo de gerenciamento, é importante escolher um subsistema de armazenamento apropriado para o data warehouse de Relatórios. Assim como no banco de dados do Operations Manager, o RAID 0 + 1 geralmente é a melhor opção. Em geral, o subsistema de armazenamento do data warehouse de Relatórios deve ser semelhante ao subsistema de armazenamento do banco de dados do Operations Manager, e as diretrizes que se aplicam ao banco de dados do Operations Manager também se aplicam ao data warehouse de Relatórios.
• Considere o posicionamento apropriado de logs de dados versus logs de transações. Quanto ao banco de dados do Operations Manager, separar dados SQL e logs de transações geralmente é uma opção apropriada à medida que você aumenta o número de agentes. Se o banco de dados do Operations Manager e o data warehouse de Relatórios estiverem localizados no mesmo servidor e você quiser separar os logs de dados e transações, deverá colocar os logs de transações do banco de dados do Operations Manager em um volume físico e eixos de disco separados do data warehouse de Relatórios para receber qualquer benefício. Os arquivos de dados do banco de dados do Operations Manager e do data warehouse de Relatórios podem compartilhar o mesmo volume físico, desde que o volume forneça capacidade adequada e o desempenho de E/S do disco não afete negativamente a funcionalidade de monitoramento e relatório.
• Considere colocar o data warehouse de Relatórios em um servidor separado do banco de dados do Operations Manager. Embora as implantações de menor escala geralmente possam consolidar o banco de dados do Operations Manager e o data warehouse de Relatórios no mesmo servidor, é vantajoso separá-los à medida que você aumenta o número de agentes e o volume de dados operacionais de entrada. Quando o data warehouse de Relatórios e o Servidor de Relatórios estão em um servidor separado do banco de dados do Operations Manager, você obtém um melhor desempenho de relatórios.

O banco de dados de data warehouse do Operations Manager é uma única fonte de falha para o grupo de gerenciamento, portanto, ele pode ser altamente disponibilizado usando configurações de failover com suporte, como Grupos de Disponibilidade Always On do SQL Server ou Instâncias de Cluster de Failover.

AlwaysOn do SQL Server

Os grupos de disponibilidade Always On do SQL Server dão suporte a ambientes de failover para um conjunto discreto de bancos de dados de usuário (bancos de dados de disponibilidade). Cada conjunto de bancos de dados de disponibilidade é hospedado por uma réplica de disponibilidade.

Com o System Center 2016 e posterior – Operations Manager, o SQL Always On é preferível ao clustering de failover para fornecer alta disponibilidade para bancos de dados. Todos os bancos de dados, exceto a instalação do Reporting Services no modo nativo, que usa dois bancos de dados para separar o armazenamento de dados persistente dos requisitos de armazenamento temporário, podem ser hospedados em um Grupo de Disponibilidade AlwaysOn.

Com o Operations Manager 2022, você pode configurar e atualizar os bancos de dados do Operations Manager com uma configuração Always-On do SQL sem a necessidade de realizar alterações após a configuração.

Para configurar um grupo de disponibilidade, você precisará implantar um cluster WSFC (Clustering de Failover do Windows Server) para hospedar a réplica de disponibilidade e habilitar o Always On nos nós de cluster. Em seguida, você pode adicionar o banco de dados SQL Server do Operations Manager como um banco de dados de disponibilidade.

• Saiba mais sobre os pré-requisitos do Always On.
• Saiba mais sobre como configurar um WSFC para grupos de disponibilidade Always On.
• Saiba mais sobre como configurar um grupo de disponibilidade.

Observação

Depois de implantar o Operations Manager nos nós do SQL Server que participam do SQL Always On, para habilitar a segurança estrita do CLR, execute o script SQL em cada banco de dados do Operations Manager.

Cadeia de caracteres de várias sub-redes

O Operations Manager não dá suporte às palavras-chave da cadeia de conexão (MultiSubnetFailover=True). Como um grupo de disponibilidade tem um nome de ouvinte (conhecido como nome de rede ou Ponto de Acesso para Cliente no Gerenciador de Cluster do WSFC) dependendo de vários endereços IP de sub-redes diferentes, como quando você implanta em uma configuração de failover entre sites, as solicitações de conexão de cliente dos servidores de gerenciamento para o ouvinte do grupo de disponibilidade atingirão um tempo limite de conexão.

A abordagem recomendada para contornar essa limitação quando você implanta nós de servidor no grupo de disponibilidade em um ambiente de várias sub-redes é fazer o seguinte:

1. Defina o nome da rede do ouvinte do grupo de disponibilidade para registrar apenas um único endereço IP ativo no DNS.
2. Configure o cluster para usar um valor de TTL baixo para o registro DNS registrado.

Essas configurações permitem, ao fazer failover para um nó em uma sub-rede diferente, recuperação e resolução mais rápidas do nome do cluster com o novo endereço IP.

Execute os seguintes comandos do PowerShell em qualquer um dos nós SQL para modificar suas configurações:

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"

Se você estiver usando Always On com um nome de ouvinte, também deverá fazer essas alterações de configuração no ouvinte. Para obter mais informações sobre como configurar um ouvinte do grupo de disponibilidade, consulte a documentação aqui: Configurar o ouvinte do grupo de disponibilidade – SQL Server Always On

Execute os seguintes comandos do PowerShell no nó SQL que hospeda o ouvinte no momento para modificar suas configurações:

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>

Quando uma instância SQL clusterizada ou Always On é usada para alta disponibilidade, você deve habilitar o recurso de recuperação automática em seus servidores de gerenciamento para evitar a reinicialização do serviço de Acesso a Dados do Operations Manager sempre que ocorrer um failover entre nós. Para obter informações sobre como configurar isso, consulte o seguinte artigo da base de dados de conhecimento O serviço de Gerenciamento do System Center para de responder depois que uma instância do SQL Server fica offline.

Otimizando o SQL Server

Em geral, a experiência anterior de implantação com clientes mostra que os problemas de desempenho normalmente não são causados pela alta utilização de recursos (ou seja, processador ou memória) com o próprio SQL Server; em vez disso, está diretamente relacionado à configuração do subsistema de armazenamento. Os gargalos de desempenho geralmente são atribuídos ao não cumprimento das diretrizes de configuração recomendadas com o armazenamento provisionado para a instância de banco de dados do SQL Server. Esses exemplos são:

• Alocação insuficiente de eixos para os LUNs para dar suporte aos requisitos de E/S do Operations Manager.
• Hospedar logs de transações e arquivos de banco de dados no mesmo volume. Essas duas cargas de trabalho têm características diferentes de E/S e latência.
• A configuração do TempDB está incorreta em relação ao posicionamento, dimensionamento e assim por diante.
• Desalinhamento da partição de disco de volumes que hospedam os logs de transações do banco de dados, arquivos de banco de dados e TempDB.
• Ignorar a configuração básica do SQL Server, como usar AUTOGROW para arquivos de banco de dados e log de transações, configuração MAXDOP para paralelismo de consulta, criar vários arquivos de dados TempDB por núcleo de CPU e assim por diante.

A configuração de armazenamento é um dos componentes críticos para uma implantação do SQL Server para o Operations Manager. Os servidores de banco de dados tendem a ser fortemente vinculados à E/S devido à rigorosa atividade de leitura e gravação do banco de dados e ao processamento do log de transações. O padrão de comportamento de E/S do Operations Manager normalmente é de 80% de gravações e 20% de leituras. Como resultado, a configuração inadequada de subsistemas de E/S pode levar a um desempenho e operação insatisfatórios de sistemas SQL Server e se torna perceptível no Operations Manager.

É importante testar o design do SQL Server executando testes de taxa de transferência do subsistema de E/S antes de implantar o SQL Server. Certifique-se de que esses testes sejam capazes de atender aos requisitos de E/S com uma latência aceitável. Use o Utilitário Diskspd para avaliar a capacidade de E/S do subsistema de armazenamento que dá suporte ao SQL Server. O artigo de blog a seguir, de autoria de um membro da equipe do Servidor de Arquivos no grupo de produtos, fornece diretrizes e recomendações detalhadas sobre como executar testes de estresse usando essa ferramenta com algum código do PowerShell e capturando os resultados usando o PerfMon. Veja também o Auxiliar de Dimensionamento do Operations Manager para obter as diretrizes iniciais.

Tamanho da unidade de alocação NTFS

O alinhamento de volume, comumente chamado de alinhamento de setor, deve ser executado no sistema de arquivos (NTFS) sempre que um volume for criado em um dispositivo RAID. Não fazer isso pode levar a uma degradação significativa do desempenho e é mais comumente o resultado do desalinhamento da partição com os limites da unidade de faixa. Isso também pode levar ao desalinhamento do cache de hardware, resultando na utilização ineficiente do cache do array. Ao formatar a partição que será usada para arquivos de dados do SQL Server, é recomendável usar um tamanho de unidade de alocação de 64 KB (ou seja, 65.536 bytes) para dados, logs e tempdb. Lembre-se, no entanto, de que o uso de tamanhos de unidade de alocação maiores que 4 KB resulta na incapacidade de usar a compactação NTFS no volume. Embora o SQL Server dê suporte a dados somente leitura em volumes compactados, ele não é recomendado.

Memória de reserva

Observação

Muitas das informações nesta seção vêm de Jonathan Kehayias em sua postagem no blog Quanta memória meu SQL Server realmente precisa? (sqlskills.com).

Nem sempre é fácil identificar a quantidade certa de memória física e processadores a serem alocados para o SQL Server em suporte ao System Center Operations Manager (ou para outras cargas de trabalho fora deste produto). A calculadora de dimensionamento fornecida pelo grupo de produtos fornece diretrizes com base na escala de carga de trabalho, mas suas recomendações são baseadas em testes realizados em um ambiente de laboratório que pode ou não estar alinhado com sua carga de trabalho e configuração reais.

O SQL Server permite configurar a quantidade mínima e máxima de memória que será reservada e utilizada por seu processo. Por padrão, o SQL Server pode alterar seus requisitos de memória dinamicamente com base nos recursos disponíveis do sistema. A configuração padrão para memória mínima do servidor é 0 e a configuração padrão para memória máxima do servidor é 2.147.483.647 MB.

Problemas relacionados ao desempenho e à memória podem surgir se você não definir um valor apropriado para a memória máxima do servidor. Muitos fatores influenciam a quantidade de memória necessária para alocar ao SQL Server para garantir que o sistema operacional possa oferecer suporte a outros processos em execução nesse sistema, como a placa HBA, os agentes de gerenciamento e a verificação em tempo real do antivírus. Se memória suficiente não for definida, o sistema operacional e o SQL serão paginados para o disco. Isso pode fazer com que a E/S de disco aumente, diminuindo ainda mais o desempenho e criando um efeito cascata onde ele se torna perceptível no Operations Manager.

Recomendamos especificar pelo menos 4 GB de RAM para memória mínima do servidor. Isso deve ser feito para cada nó SQL que hospeda um dos bancos de dados do Operations Manager (operacional, data warehouse, ACS).

Para memória máxima do servidor, recomendamos que você reserve inicialmente um total de:

• 1 GB de RAM para o sistema operacional
• 1 GB de RAM por cada 4 GB de RAM instalada (até 16 GB de RAM)
• 1 GB de RAM por cada 8 GB de RAM instalada (acima de 16 GB de RAM)

Depois de definir esses valores, monitore o contador Memória\MBytes disponíveis no Windows para determinar se você pode aumentar a memória disponível para o SQL Server. O Windows sinaliza que a memória física disponível está acabando em 96 MB, portanto, o ideal é que o contador não seja inferior a cerca de 200 a 300 MB, para garantir que você tenha um buffer. Para servidores com 256 GB de RAM ou superior, você provavelmente desejará garantir que ele não seja executado abaixo de 1 GB.

Lembre-se de que esses cálculos pressupõem que você deseja que o SQL Server seja capaz de usar toda a memória disponível, a menos que você os modifique para levar em conta outros aplicativos. Considere os requisitos de memória específicos para seu sistema operacional, outros aplicativos, a pilha de threads do SQL Server e outros alocadores de várias páginas. Uma fórmula típica seria ((total system memory) – (memory for thread stack) – (OS memory requirements) – (memory for other applications) – (memory for multipage allocators)), onde a memória para pilha de threads = ((max worker threads) (stack size)). O tamanho da pilha é de 512 KB para sistemas x86, 2 MB para sistemas x64 e 4 MB para sistemas IA64, e você pode encontrar o valor para max worker threads na coluna max_worker_count de sys.dm_os_sys_info.

Essas considerações também se aplicam aos requisitos de memória para que o SQL Server seja executado em uma máquina virtual. Como o SQL Server foi projetado para armazenar dados em cache no pool de buffers e normalmente usará o máximo de memória possível, pode ser difícil determinar a quantidade ideal de RAM necessária. Ao reduzir a memória alocada para uma instância do SQL Server, você chegará a um ponto em que a alocação de memória mais baixa será trocada por um acesso de E/S de disco mais alto.

Para configurar a memória do SQL Server em um ambiente que foi provisionado em excesso, comece monitorando o ambiente e as métricas de desempenho atuais, incluindo a expectativa de vida da página do SQL Server Buffer Manager e as leituras de página/s e os valores de leituras de disco do disco físico/s. Se o ambiente tiver excesso de memória, a expectativa de vida da página aumentará em um valor de um a cada segundo, sem qualquer diminuição na carga de trabalho, devido ao cache; o valor de leituras de página/s do Gerenciador de Buffer do SQL Server será baixo depois que o cache for aumentado; e as leituras de disco/s do disco físico também permanecerão baixas.

Depois de entender a linha de base do ambiente, você pode reduzir a memória máxima do servidor em 1 GB e, em seguida, ver como isso afeta seus contadores de desempenho (depois que qualquer liberação inicial do cache diminuir). Se as métricas permanecerem aceitáveis, reduza em mais 1 GB e monitore novamente, repetindo conforme desejado até determinar uma configuração ideal.

Para obter mais informações, consulte Opções de configuração de memória do servidor.

Otimize o TempDB

O tamanho e o posicionamento físico do banco de dados tempdb podem afetar o desempenho do Operations Manager. Por exemplo, se o tamanho definido para tempdb for muito pequeno, parte da carga de processamento do sistema poderá ser ocupada com o crescimento automático de tempdb para o tamanho necessário para dar suporte à carga de trabalho sempre que você reiniciar a instância do SQL Server. Para obter o desempenho ideal do tempdb, recomendamos a seguinte configuração para o tempdb em um ambiente de produção:

• Defina o modelo de recuperação de tempdb como SIMPLE. Esse modelo recupera automaticamente o espaço de log para manter os requisitos de espaço pequenos.
• Aloque espaço antecipadamente para todos os arquivos do tempdb definindo o tamanho de arquivo com um valor grande o bastante para acomodar a carga de trabalho comum no ambiente. Isso impede que o tempdb se expanda com muita frequência, o que pode afetar o desempenho. O banco de dados tempdb pode ser definido para crescer automaticamente, mas isso deve ser usado para aumentar o espaço em disco para exceções não planejadas.
• Crie quantos arquivos forem necessários para maximizar a largura de banda do disco. O uso de vários arquivos reduz a contenção de armazenamento tempdb e produz escalabilidade aprimorada. No entanto, não crie muitos arquivos, pois isso pode reduzir o desempenho e aumentar a sobrecarga de gerenciamento. Como diretriz geral, crie um arquivo de dados para cada processador lógico no servidor (levando em conta as configurações de máscara de afinidade) e ajuste o número de arquivos para cima ou para baixo conforme necessário. Como regra geral, se o número de processadores lógicos for menor ou igual a 8, use o mesmo número de arquivos de dados que o de processadores lógicos. Se o número de processadores lógicos for maior que 8, use oito arquivos de dados e, se a contenção continuar, aumente o número de arquivos de dados em múltiplos de 4 (até o número de processadores lógicos) até que a contenção seja reduzida a níveis aceitáveis ou faça alterações na carga de trabalho/código. Se a contenção não for reduzida, talvez seja necessário aumentar mais o número de arquivos de dados.
• Faça com que cada arquivo de dados tenha o mesmo tamanho, permitindo um desempenho ideal de preenchimento proporcional. O dimensionamento igual dos arquivos de dados é crítico porque o algoritmo de preenchimento proporcional é baseado no tamanho dos arquivos. Se os arquivos de dados forem criados com tamanhos desiguais, o algoritmo de preenchimento proporcional tentará usar o maior arquivo mais para alocações do GAM em vez de espalhar as alocações entre todos os arquivos, anulando assim a finalidade de criar vários arquivos de dados.
• Coloque o banco de dados tempdb em um subsistema de E/S rápido usando unidades de estado sólido para obter o desempenho ideal. Use a distribuição de disco se houver muitos discos anexados diretamente.
• Coloque o banco de dados tempdb em discos diferentes dos usados por bancos de dados de usuários.

Para configurar tempdb, você pode executar a consulta a seguir ou modificar suas propriedades no 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

Execute a consulta SELECT * from sys.sysprocesses T-SQL para detectar a contenção de alocação de página para o banco de dados tempdb. Na saída da tabela do sistema, o recurso de espera pode aparecer como "2:1:1" (Página PFS) ou "2:1:3" (Página do Mapa de Alocação Global Compartilhada). Dependendo do grau de contenção, isso também pode fazer com que o SQL Server pareça não responder por curtos períodos. Outra abordagem é examinar as Exibições de Gerenciamento Dinâmico [sys.dm_exec_request ou sys.dm_os_waiting_tasks]. Os resultados mostrarão que essas solicitações ou tarefas estão aguardando recursos tempdb e têm valores semelhantes aos destacados anteriormente quando você executa a consulta sys.sysprocesses .

Se as recomendações anteriores não reduzirem significativamente a contenção de alocação e a contenção estiver em páginas SGAM, implemente o sinalizador de rastreamento -T1118 nos parâmetros de inicialização do SQL Server para que o sinalizador de rastreamento permaneça em vigor mesmo depois que o SQL Server for reciclado. Sob esse sinalizador de rastreamento, o SQL Server aloca extensões completas para cada objeto de banco de dados, eliminando assim a contenção em páginas SGAM.

Observação

Esse sinalizador de rastreamento afeta todos os bancos de dados na instância do SQL Server.

Grau máximo de paralelismo

A configuração padrão do SQL Server para implantações de pequeno a médio porte do Operations Manager é adequada para a maioria das necessidades. No entanto, quando a carga de trabalho do grupo de gerenciamento é dimensionada para cima em direção a um cenário de classe empresarial (normalmente 2.000+ sistemas gerenciados por agente e uma configuração de monitoramento avançada, que inclui monitoramento de nível de serviço com transações sintéticas avançadas, monitoramento de dispositivo de rede, plataforma cruzada e assim por diante), é necessário otimizar a configuração do SQL Server descrita nesta seção do documento. Uma opção de configuração que não foi discutida nas diretrizes anteriores é MAXDOP.

A opção de configuração MAXDOP (grau máximo de paralelismo) do Microsoft SQL Server controla o número de processadores usados para a execução de uma consulta em um plano paralelo. Essa opção determina os recursos de computação e thread usados para os operadores de plano de consulta que executam o trabalho em paralelo. Dependendo se o SQL Server está configurado em um computador SMP (multiprocessamento simétrico), em um computador NUMA (acesso não uniforme à memória) ou em processadores habilitados para hyperthreading, você precisa configurar a opção de grau máximo de paralelismo adequadamente.

Quando o SQL Server é executado em um computador com mais de um microprocessador ou CPU, ele detecta o melhor grau de paralelismo, ou seja, o número de processadores empregados para executar uma única instrução, para cada execução de plano paralelo. Por padrão, seu valor para essa opção é 0, o que permite que o SQL Server determine o grau máximo de paralelismo.

Os procedimentos armazenados e as consultas predefinidos no Operations Manager no que se refere ao banco de dados operacional, de data warehouse e até mesmo de auditoria não incluem a opção MAXDOP, pois não há como consultar dinamicamente quantos processadores são apresentados ao sistema operacional durante a instalação, nem tentar codificar o valor dessa configuração, o que pode ter consequências negativas quando a consulta é executada.

Observação

A opção de configuração de grau máximo de paralelismo não limita o número de processadores que o SQL Server usa. Para configurar o número de processadores que o SQL Server usa, use a opção de configuração de máscara de afinidade.

• Para servidores que usam mais de oito processadores, use a seguinte configuração: MAXDOP=8
• Para servidores que usam oito ou menos processadores, use a seguinte configuração: MAXDOP=0 a N

  Observação

  Nessa configuração, N representa o número de processadores.