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 oferecer suporte ao banco de dados de auditoria operacional, data warehouse e 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 co-localizado no primeiro servidor de gerenciamento do grupo de gerenciamento.

Em uma implantação distribuída de média a grande escala, 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 está 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 SQL que tenha outros bancos de dados de aplicativos. Isso é para evitar possíveis problemas com E/S e outras restrições de recursos de hardware.

Importante

O Operations Manager não oferece suporte a instâncias PaaS (Platform as a Service) do SQL, incluindo produtos como o Azure SQL Managed Instance ou o Amazon Relational Database Service (AWS RDS). Use uma instância do SQL Server instalada em uma máquina Windows. A única exceção a isso está na Instância Gerenciada SCOM do Azure Monitor, que utiliza o Azure SQL MI e não é reconfigurável.

Requisitos do SQL Server

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

• SQL Server 2022

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

  Observação

  • O Operations Manager 2022 oferece suporte ao SQL 2019 com CU8 ou posterior; no entanto, ele não oferece 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 oferecem suporte a uma infraestrutura SCOM precisa 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, 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

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

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.
• O Servidor de Relatórios não tem suporte 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. 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 agrupamento do SQL Server

Os seguintes agrupamentos do SQL Server e do Windows são suportados pelo System Center Operations Manager.

Observação

Para evitar problemas de compatibilidade na comparação ou cópia de operações, recomendamos que você use o mesmo agrupamento 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 instalaçã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á Grupos de Disponibilidade 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 precisarão 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 no grupo de gerenciamento do Operations Manager se comuniquem com êxito.

Cenário	Porta	Direção	Função do Operations Manager
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 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 Operations Manager Reporting Server	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 do SQL Server, consulte 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 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 crítico para os negócios colete menos dados do que um agente que monitora um servidor que está executando uma instância do SQL Server com um grande número de bancos de dados.
• Taxa de alterações de espaço de instância. A atualização desses dados no banco de dados do Operations Manager é dispendiosa em relação à gravação de novos dados operacionais. Além disso, quando os dados de espaço da instância são alterados, os servidores de gerenciamento fazem consultas adicionais ao banco de dados do Operations Manager para calcular as alterações de configuração e grupo. A taxa de alterações de 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 SDK em execução simultaneamente. Cada console de Operações lê dados do banco de dados do Operations Manager. A consulta desses 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 no Modo de Exibição de Eventos, no Modo de Exibição de Estado, no Modo de Exibição de Alertas e no Modo de 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 AlwaysOn 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, execute estas etapas:

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 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

O System Center - Operations Manager insere dados no data warehouse de Relatórios quase em tempo real, é importante ter capacidade suficiente nesse servidor que ofereça 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 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 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 geralmente é balanceado 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ório 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 de dados geral através 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 escolha. 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, e a orientação que se aplica ao banco de dados do Operations Manager também se aplica 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 escolha 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 de 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 de 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 melhor desempenho de relatórios.

O banco de dados do 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 do SQL Server Always On oferecem 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 é preferido em relação ao cluster 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 (Cluster de Failover do Windows Server) para hospedar a réplica de disponibilidade e habilitar o Always On nos nós do cluster. Em seguida, você pode adicionar o banco de dados do 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 multi-rede

O Operations Manager não oferece 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 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 de 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ê implantou 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 TTL baixo para o registro DNS registrado.

Essas configurações permitem, durante o failover para um nó em uma sub-rede diferente, a recuperação e a 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 o 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 ouvinte de grupo de disponibilidade - SQL Server Always On

Execute os seguintes comandos do PowerShell no nó SQL que atualmente hospeda 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 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 Operations Manager Data Access 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 System Center Management pára 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 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 afunilamentos de desempenho geralmente são atribuídos a não seguir as diretrizes de configuração recomendadas com o armazenamento provisionado para a instância de banco de dados do SQL Server. Tais exemplos são:

• Alocação insuficiente de eixos para que os LUNs ofereçam suporte aos requisitos de E/S do Operations Manager.
• Hospedagem de 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 de partição de disco de volumes que hospedam os logs de transações do banco de dados, arquivos de banco de dados e TempDB.
• Ignorando a configuração básica do SQL Server, como o uso de AUTOGROW para arquivos de banco de dados e de log de transações, 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 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 a E/S devido à rigorosa atividade de leitura e gravação do banco de dados e ao processamento de 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 incorreta de subsistemas de E/S pode levar a um desempenho e operação insatisfatórios dos sistemas SQL Server e se torna perceptível no Operations Manager.

É importante testar o design do SQL Server executando o teste 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 atingir seus requisitos de E/S com uma latência aceitável. Use o Diskspd Utility para avaliar a capacidade de E/S do subsistema de armazenamento que oferece suporte ao SQL Server. O artigo de blog a seguir, criado por um membro da equipe do Servidor de Arquivos no grupo de produtos, fornece orientações e recomendações detalhadas 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 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. A falha em 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 listra. Ele 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. No entanto, esteja ciente 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 ofereça suporte a dados somente leitura em volumes compactados, ele não é recomendado.

Reservar memória

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 orientação com base na escala da carga de trabalho, mas suas recomendações são baseadas em testes realizados em um ambiente de laboratório que podem ou não estar alinhados 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 usada por seu processo. Por padrão, o SQL Server pode alterar seus requisitos de memória dinamicamente com base nos recursos do sistema disponíveis. 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 que você precisa 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 antivírus em tempo real. Se memória suficiente não estiver definida, o sistema operacional e o SQL serão paginados em disco. Isso pode fazer com que a E/S do 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 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 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á sendo baixa em 96 MB, portanto, idealmente, o contador não deve ser executado abaixo de cerca de 200-300 MB, para garantir que você tenha um buffer. Para servidores com 256 GB de RAM ou superior, você provavelmente vai querer 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 possa 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 de 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 em cache dados 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 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 SQL Server Buffer Manager e as leituras de página/s e os valores de leituras de 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 leitura/seg da página do Gerenciador de Buffer do SQL Server será baixo depois que o cache aumentar e as leituras de disco físico/s 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 de 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.

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 tempdb for muito pequeno, parte da carga de processamento do sistema poderá ser ocupada com tempdb de crescimento automático 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 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 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. Ele 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 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. 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 uma diretriz geral, crie um arquivo de dados para cada processador lógico no servidor (considerando quaisquer configurações de máscara de afinidade) e, em seguida, 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, em seguida, 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 ótimo desempenho de preenchimento proporcional. O dimensionamento igual de arquivos de dados é crítico porque o algoritmo de preenchimento proporcional é baseado no tamanho dos arquivos. Se os arquivos de dados são criados com tamanhos desiguais, o algoritmo de preenchimento proporcional tenta usar o maior arquivo mais para alocações GAM em vez de espalhar as alocações entre todos os arquivos, derrotando assim o propósito 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 melhor desempenho. 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 o 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 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 Visõ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 nas páginas do 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 do 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 aumenta para 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, entre plataformas 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 é o 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 estiver configurado em um computador SMP (multiprocessamento simétrico), um computador NUMA (acesso não uniforme à memória) ou processadores habilitados para hyperthreading, você precisará 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 predefinidas no Operations Manager em relação ao banco de dados operacional, 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.