Considerações de design do SQL Server

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

Em um ambiente de laboratório ou em uma implantação de pequena escala do Operations Manager, o SQL Server pode ser localizado junto ao 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 você iniciar a instalação do primeiro servidor de gerenciamento ou do coletor ACS.

Não recomendamos a utilização de bancos de dados do Operations Manager de uma Instância SQL que tenha outros bancos de dados de aplicativos. Isso serve 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 o 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 está no SCOM do Azure Monitor Instância Gerenciada, que utiliza SQL do Azure MI e não é reconfigurável.

Requisitos do SQL Server

As seguintes versões do SQL Server Enterprise e da Edição Standard têm suporte para uma instalação existente da versão do System Center Operations Manager para hospedar o servidor de relatórios, o banco de dados operacional, o Data Warehouse e o 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 o ODBC 17.3 ou posterior e o MSOLEDBSQL 18.2 ou posterior.

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

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

Observação

• Cada um dos seguintes componentes do SQL Server que dão suporte uma infraestrutura SCOM devem estar na mesma versão principal do SQL Server:
  • SQL Server instâncias do mecanismo de banco de dados que hospedam qualquer um dos bancos de dados SCOM (ou seja, Os bancos de dados OperationManager, OperationManagerDW e SSRS ReportServer & 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

O System Center Operations Manager Reporting não pode ser instalado lado a lado com uma versão anterior da função Reporting e deve ser instalado somente no modo nativo (não há suporte para o modo integrado do SharePoint).

Considerações adicionais de hardware e de software aplicáveis ao planejamento de design:

• Recomendamos executar o SQL Server em computadores com o formato de arquivo NTFS.
• Deve haver pelo menos 1.024 MB de espaço em disco livre para os bancos de dados operacional e de data warehouse. Ele é imposto no momento da criação do banco de dados e provavelmente aumentará 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 Servidor de Relatórios no Windows Server Core.

Para saber mais, confira Requisitos de hardware e software para a instalação do SQL Server.

Observação

Embora o Operations Manager use apenas autenticação do Windows durante a instalação, a configuração autenticação de modo misto do SQL ainda funcionará se nenhuma conta local tiver a função db_owner. As contas locais com a função db_owner são conhecidas por causar 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 ordenação do SQL Server

As ordenações 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 na cópia de operações, recomendamos que você use a mesma ordenação para a BD do Operations Manager e SQL.

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 de SQL Server não estiver configurada com uma das ordenações com suporte listadas anteriormente, a execução de uma nova configuraçã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 os bancos de dados e uma plataforma de relatórios para analisar e apresentar os dados operacionais históricos. O servidor de gerenciamento, as operações e as funções de console Web precisam ser capazes de se comunicar com êxito com SQL Server e é importante entender o caminho de comunicação e as portas para configurar seu ambiente corretamente.

Se você estiver projetando uma implantação distribuída que exigirá grupos de disponibilidade do SQL Always On para fornecer funcionalidade de failover para os bancos de dados do Operations Manager, haverá 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 disponibilizadas para, pelo menos, as funções de servidor no grupo de gerenciamento do Operations Manager para uma comunicação com êxito.

Cenário	Porta	Direction	Função do Operations Manager
SQL Server hospedando bancos de dados do Operations Manager	TCP 1433 *	Entrada	servidor de gerenciamento e console Web (para o Application Advisor e o Application Diagnostics)
Serviço SQL Server Browser	UDP 1434	Entrada	Management Server
Conexão de administrador dedicada do SQL Server	TCP 1434	Entrada	Management Server
Portas adicionais usadas pelo SQL Server – MS RPC (Chamadas de procedimento remoto da Microsoft) – WMI (Instrumentação de Gerenciamento do Windows) – MS DTC (Coordenador de Transações Distribuídas da Microsoft)	TCP 135	Entrada	Management Server
Ouvinte do Grupo de Disponibilidade AlwaysOn 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 mais detalhada dos requisitos de firewall para o SQL Server, consulte Configure the Windows Firewall to Allow SQL Server Access (Configurar o Firewall do Windows para permitir 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 ao Operations Manager para o monitoramento cotidiano. O dimensionamento e a configuração do servidor de banco de dados são críticos 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.

Entre os fatores que influenciam a carga no banco de dados do Operations Manager estão:

• A taxa de coleta de dados operacionais. Os dados operacionais incluem todos os eventos, os alertas, as alterações de estado e os 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 assim que entram no sistema. A taxa dos dados operacionais coletados tende a aumentar à medida que outros pacotes de gerenciamento são importados e outros agentes são adicionados. O tipo de computador que um agente monitora também é um fator importante usado para determinar a taxa geral de coleta de dados operacionais. Por exemplo, espera-se que um agente monitorando um computador desktop crítico para os negócios colete menos dados que um agente monitorando um servidor que executa uma instância do SQL Server com um grande número de bancos de dados.
• A taxa de alterações de espaço de instâncias. Atualizar dados no banco de dados do Operations Manager é caro no que diz respeito à gravação de novos dados operacionais. Além disso, quando os dados de espaço de instâncias são alterados, os servidores de gerenciamento fazem consultas adicionais ao banco de dados do Operations Manager para computar as alterações nas configurações e nos grupos. A taxa de alterações de espaço de instâncias aumenta à medida que pacotes de gerenciamento adicionais são importados 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 de espaço de instâncias.
• O número de Consoles de Operações e de outras conexões de SDK em execução simultânea. Todo Console de Operações lê dados do banco de dados do Operations Manager. Consultar esses dados consome potencialmente uma grande quantidade de recursos de E/S de armazenamento, de tempo de CPU e de RAM. Os Consoles de Operações que exibem grandes quantidades de dados operacionais nas Exibições de Eventos, de Estado, de Alertas e de Dados de Desempenho tendem a gerar a maior carga no banco de dados.

O banco de dados do Operations Manager é uma fonte única de falha para o grupo de gerenciamento, portanto, é possível deixá-lo altamente disponível usando as configurações de failover com suporte, como os Grupos de Disponibilidade AlwaysOn ou as Instâncias de Cluster de Failover do SQL Server.

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 marcar o estado do SQL Server Service Broker sempre que um comportamento inesperado é observado em torno de uma tarefa no System Center Operations Manager.

Siga estas etapas para habilitar o SQL Server Service Broker:

1. Execute a seguinte consulta SQL:

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

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

   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

O 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 no 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 às do banco de dados do Operations Manager, mas elas 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 por meio do uso do Console de Operações.

Entre os fatores que influenciam a carga no data warehouse de relatórios estão:

• A taxa de coleta de dados operacionais. Para permitir relatórios mais eficientes, o data warehouse de relatórios calcula e armazena os dados agregados, bem como uma quantidade limitada de dados brutos. Realizar esse trabalho adicional significa que a coleta de dados operacionais para o data warehouse de relatórios pode ser um pouco mais cara em comparação com o banco de dados do Operations Manager. Esse custo adicional normalmente é equilibrado pelo custo reduzido do processamento de dados de descoberta realizado pelo data warehouse de relatórios em comparação com o banco de dados do Operations Manager.
• O número de usuários simultâneos de relatórios ou a geração de relatórios agendados. Uma vez que os relatórios normalmente resumem grandes volumes de dados, cada usuário de relatórios pode adicionar uma carga significativa no sistema. Tanto o número de relatórios executados simultaneamente quanto os tipos de relatórios executados afetam as necessidades de capacidade total. Normalmente, os relatórios que consultam grandes intervalos de datas ou um grande número de objetos requerem 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 que passa pelo grupo de gerenciamento, escolher um subsistema de armazenamento apropriado para o data warehouse de relatórios é importante. Como ocorre com o banco de dados do Operations Manager, o RAID 0 + 1 normalmente é a melhor opção. Em geral, o subsistema de armazenamento para o data warehouse de relatórios deve ser semelhante ao subsistema de armazenamento para o banco de dados do Operations Manager, sendo que as diretrizes aplicáveis ao banco de dados do Operations Manager também são aplicáveis ao data warehouse de relatórios.
• Considere o posicionamento adequado dos logs de dados em relação aos logs de transações. Quanto ao banco de dados do Operations Manager, a separação entre os logs de transações e os logs de dados do SQL é muitas vezes uma opção apropriada ao aumentar o número de agentes. Se tanto o banco de dados do Operations Manager quanto o data warehouse de relatórios estiverem localizados no mesmo servidor e você desejar separar os logs de transações dos logs de dados, será preciso colocar os logs de transações do banco de dados do Operations Manager em volumes físicos e eixos de discos separados dos usados para o data warehouse de relatórios para que você aproveite os benefícios. 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 de disco não afete negativamente a funcionalidade de monitoramento e relatório.
• Considere posicionar o data warehouse de relatórios em um servidor separado do banco de dados do Operations Manager. Embora implantações de menor escala possam geralmente 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ê tem um melhor desempenho de relatórios.

O banco de dados de data warehouse do Operations Manager é uma fonte única de falha para o grupo de gerenciamento, portanto, é possível deixá-lo altamente disponível usando as configurações de failover com suporte, como os Grupos de Disponibilidade AlwaysOn ou as Instâncias de Cluster de Failover do SQL Server.

AlwaysOn do SQL Server

Os Grupos de Disponibilidade AlwaysOn do SQL Server dão suporte a ambientes de failover para um conjunto discreto de bancos de dados do 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 – Operations Manager e versões posteriores, é preferível usar o Always On do SQL em vez do clustering de failover para fornecer alta disponibilidade para os bancos de dados. Exceto a instalação do Reporting Services em modo nativo, a qual usa dois bancos de dados para separar o armazenamento de dados persistentes dos requisitos de armazenamento temporário, todos os bancos de dados 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 o réplica de disponibilidade e habilitar Always On nos nós de cluster. Em seguida, você poderá adicionar o banco de dados do SQL Server do Operations Manager como um banco de dados de disponibilidade.

• Saiba mais sobre Always On pré-requisitos.
• 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 do SQL em cada banco de dados do Operations Manager.

Cadeia de caracteres de várias sub-redes

O Operations Manager não dá suporte ao cadeia de conexão palavras-chave (MultiSubnetFailover=True). Uma vez que o grupo de disponibilidade tem um nome de ouvinte (conhecido como o nome da rede ou como o Ponto de Acesso do Cliente no Gerenciador de Cluster WSFC) que depende 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 provenientes dos servidores de gerenciamento para o ouvinte do grupo de disponibilidade atingirão um tempo limite da 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 de 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 TTL baixo para o registro DNS registrado.

Estas configurações permitem uma recuperação mais rápida e a resolução do nome do cluster com o novo endereço IP no momento que o failover para um nó em uma sub-rede diferente é realizado.

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 de 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 atualmente o ouvinte 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 um cluster ou uma instância SQL Always On é usada para alta disponibilidade, você deverá habilitar o recurso de recuperação automática nos servidores de gerenciamento para evitar a reinicialização de serviço de Acesso a Dados do Operations Manager sempre que ocorrer um failover entre os nós. Para obter informações sobre como configurar isso, consulte o artigo da base de dados 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 de implantação anterior com os 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 SQL Server em si; em vez disso, está diretamente relacionado à configuração do subsistema de armazenamento. Gargalos de desempenho são normalmente atribuídos à não observação das diretrizes de configuração recomendadas para o armazenamento provisionado da instância do Banco de Dados do SQL Server. Entre os exemplos estão:

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

A configuração do armazenamento é um dos componentes críticos da implantação do SQL Server para o Operations Manager. Os servidores de banco de dados tendem a ser altamente associados à E/S devido às atividades rigorosas de leitura e de gravação do banco de dados e ao processamento dos logs de transações. Normalmente, o padrão do comportamento de E/S do Operations Manager é de 80% para gravações e 20% para leituras. Como resultado, a configuração incorreta dos subsistemas de E/S pode causar operação e desempenho insatisfatórios dos sistemas SQL Server, o que fica perceptível no Operations Manager.

É importante testar o design SQL Server executando testes de taxa de transferência do subsistema de E/S antes de implantar SQL Server. Verifique se esses testes são capazes de atingir seus 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 compatível com o SQL Server. O artigo do blog a seguir, criado por um membro da equipe do Servidor de Arquivos no grupo de produtos, fornece diretrizes detalhadas e recomendações sobre como executar testes de estresse usando essa ferramenta com algum código do PowerShell e capturar 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 do NTFS

O alinhamento de volume, conhecido como alinhamento de setor, deve ser executado no NTFS (sistema de arquivos NTFS) sempre que um volume é criado em um dispositivo RAID. A falha ao fazer isso pode levar a uma degradação significativa do desempenho e geralmente é o resultado de desalinhamento de partição com limites de unidade de distribuição. Isso também pode ocasionar o desalinhamento do cache do hardware, resultando em utilização ineficiente do cache da matriz. Ao formatar a partição que será usada para SQL Server arquivos de dados, é recomendável que você use um tamanho de unidade de alocação de 64 KB (ou seja, 65.536 bytes) para dados, logs e tempdb. No entanto, lembre-se de que o uso de tamanhos de unidade de alocação superiores a 4 KB resulta na incapacidade de usar a compactação NTFS no volume. Embora SQL Server dê suporte a dados somente leitura em volumes compactados, não é recomendável.

Reservar memória

Observação

Grande parte das informações nesta seção vem de Jonathan Kehayias em sua postagem no blog De 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 para alocar 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 executados em um ambiente de laboratório que pode ou não se alinhar à sua carga de trabalho e configuração reais.

O SQL Server permite a configuração da quantidade mínima e máxima de memória que será reservada e usada pelo processo. Por padrão, o SQL Server pode alterar os requisitos de memória de maneira dinâmica com base nos recursos disponíveis do sistema. A configuração padrão de memória mínima do servidor é 0 e a configuração padrão de memória máxima do servidor é 2.147.483.647 MB.

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

É recomendável 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 e ACS).

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

• 1 GB de RAM para o SO
• 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 de contador Memory\Available MBytes no Windows para determinar se é possível aumentar a memória disponível para o SQL Server. O Windows sinaliza que a memória física disponível está sendo baixa em 96 MB, portanto, o ideal é que o contador não seja executado abaixo de 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.

Tenha em mente que esses cálculos presumem que você queira que o SQL Server seja capaz de usar toda a memória disponível, a menos que você modifique-os 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)), em que a memória da 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 máximo de threads de trabalho na coluna max_worker_count do sys.dm_os_sys_info.

Essas considerações também se aplicam aos requisitos de memória para o SQL Server para ser executado em uma máquina virtual. Como o SQL Server é 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ê acabará alcançando um ponto em que a alocação de memória inferior é negociada para maior acesso de E/S de disco.

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 Gerenciador de Buffers do SQL Server e os valores leituras de página/s e leituras de disco/s do Disco Físico. Se o ambiente tiver memória em excesso, a expectativa de vida da página aumentará em um valor de um por segundo sem nenhuma 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 aumentar; o valor de leituras de disco/s do Disco Físico também permanecerá baixo.

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

Para saber mais, confira Opções de configuração de memória do servidor.

Otimizar 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 o tempdb for muito pequeno, parte da carga de processamento do sistema poderá ser elevada com o crescimento automático do tempdb até o tamanho necessário para dar suporte à carga de trabalho toda vez 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 do tempdb como SIMPLE. Esse modelo recupera automaticamente o espaço de log para manter os requisitos de espaço pequenos.
• Aloque antecipadamente espaço para todos os arquivos do tempdb definindo o tamanho do arquivo com um valor grande o suficiente para acomodar a carga de trabalho típica no ambiente. Isso evita que o tempdb seja expandido com muita frequência, o que pode afetar o desempenho. O banco de dados tempdb pode ser definido para crescimento automático, 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. Usar vários arquivos reduz a contenção do armazenamento do tempdb e gera uma escalabilidade consideravelmente melhor. 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 (considerando as configurações de máscara de afinidade) e ajuste o número de arquivos para mais ou para menos 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 do que oito, use oito arquivos de dados e se a contenção persistir, aumente o número de arquivos de dados em múltiplos de 4 (até chegar ao número de processadores lógicos) até que a contenção seja reduzida a um nível aceitável 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.
• Torne cada arquivo de dados do mesmo tamanho, permitindo o desempenho ideal de preenchimento proporcional. Dimensionar igualmente os arquivos de dados é crítico, uma vez que o algoritmo de preenchimento proporcional é baseado no tamanho dos arquivos. Se os arquivos de dados forem criados com tamanhos diferentes, o algoritmo de preenchimento proporcional tentará usar o maior arquivo mais para alocações GAM em vez de difundir as alocações entre todos os arquivos, anulando, com isso, 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 por discos se existirem muitos discos anexados diretamente.
• Coloque o banco de dados tempdb em discos diferentes dos que são usados pelos bancos de dados do usuário.

Para configurar o tempdb, você pode executar a seguinte consulta ou modificar as propriedades dele 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 de tabela do sistema, o recurso de espera pode aparecer como "2:1:1" (página PFS) ou "2:1:3" (página SGAM). Dependendo do grau de contenção, isso também pode fazer com que o SQL Server pareça estar sem resposta 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 conforme realçado 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 nas páginas do SGAM, implemente o sinalizador de rastreamento -T1118 nos parâmetros de inicialização para SQL Server para que o sinalizador de rastreamento permaneça em vigor mesmo depois que SQL Server for reciclado. Nesse sinalizador de rastreamento, o SQL Server aloca extensões completas para cada objeto de banco de dados, o que elimina a contenção nas 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 mais de 2.000 sistemas gerenciados por agente e uma configuração avançada de monitoramento, que inclui o monitoramento em nível de serviço com transações sintéticas avançadas, monitoramento de dispositivos de rede, multiplataforma e assim por diante) é necessário otimizar a configuração de 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 de thread usados para os operadores de plano de consulta que executam o trabalho em paralelo. Dependendo se SQL Server está configurado em um computador SMP (multiprocessamento simétrico), um computador NUMA (acesso à memória) não uniforme ou processadores habilitados para hiperthreading, 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, o valor para essa opção é 0, o que permite ao SQL Server determinar o grau máximo de paralelismo.

Os procedimentos armazenados e as consultas predefinidos no Operations Manager relacionados ao banco de dados operacional, data warehouse e até mesmo auditoria não incluem a opção MAXDOP, pois não há como durante a instalação consultar dinamicamente quantos processadores são apresentados ao sistema operacional, nem tenta 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 os 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 para N

  Observação

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