Considerações de design do SQL Server

O System Center Operations Manager depende do Microsoft SQL Server para dar suporte a seus bancos de dados operacionais, de data warehouse e de auditoria ACS. Esses bancos de dados são essenciais e são criados durante a implantação do primeiro servidor de gerenciamento ou 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 estar localizado no primeiro servidor de gestão do grupo de gerenciamento.

Em uma implantação distribuída de médio a nível 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 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 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 de SQL da plataforma como serviço (PaaS), incluindo produtos como a instância gerenciada SQL do Azure 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á dentro do Azure Monitor SCOM Managed Instance, 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 são suportadas 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 com a atualização cumulativa mínima CU11 ou posterior, conforme disponível aqui
• SQL Server 2019 com um mínimo de Atualização Cumulativa 8 (CU8) ou posterior disponível aqui
• SQL Server 2017 com a atualização mais recente, disponível aqui

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

Drivers do SQL Server

O OLE DB e ODBC SQL Server Drivers precisam ser instalados em todos os servidores de gerenciamento e no servidor do console Web, pois esses componentes interagem diretamente com os bancos de dados e esses drivers permitem acesso em nível de API ao SQL.

É recomendável utilizar uma conexão criptografada do SQL Server; ao fazer isso, você precisa instalar as versões mais recentes dos drivers SQL:

• Microsoft OLE DB Driver versão mais recente.
• Microsoft ODBC Driver versão mais recente.

Mais informações sobre como configurar a criptografia de conexão SQL podem ser encontradas aqui: Configurar o Mecanismo de Banco de Dados do SQL Server para criptografar conexões

Se não utilizando conexões SQL criptografadas, use versões anteriores dos drivers SQL que não impõem criptografia:

• Microsoft ODBC Driver versão 17.10.6.
• Microsoft OLE DB Driver versão 18.7.4.

Atualizações do SQL Server

Cada um dos seguintes componentes do SQL Server que dão suporte a uma infraestrutura do Operations Manager 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 do Operations Manager, incluindo:
  • Gerente de Operações
  • Gerente de Operações DW
  • Bancos de dados SSRS ReportServer e ReportServerTempDB
• Instância do SQL Server Reporting Services (SSRS).

Modo de autenticação do SQL Server

Por padrão, o SQL opera em uma configuração de autenticação de modo misto. No entanto, o Operations Manager utiliza apenas a autenticação do Windows para se comunicar com o SQL Server. Se deixada como padrão, a configuração de Autenticação do 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 Operations Manager.

É altamente recomendável remover a função db_owner de todas as contas locais antes de instalar o produto e não adicionar a função db_owner a nenhuma conta local após a instalação.

Outras considerações

Outras considerações de hardware e software se aplicam ao seu planejamento de projeto:

• Recomenda-se que a TI tenha discos SQL no formato de arquivo NTFS.
• Você deve ter pelo menos 1 GB de espaço livre em disco para o banco de dados operacional e de data warehouse, isso é imposto no momento da criação do banco de dados. Tenha presente que a utilização de disco das bases de dados aumentará significativamente após a instalação. Assegure-se de ter bastante espaço livre em disco além do requisito base.
• O .NET Framework 4 é necessário.
• O .NET Framework 4.8 é suportado pelo Operations Manager 2022.
• O Servidor de Relatórios não é suportado no Windows Server Core.
• A configuração de agrupamento do SQL Server deve ser um dos tipos com suporte, conforme descrito na seção: configuração de agrupamento do SQL Server.
• A Pesquisa de Texto Completo 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 do Operations Manager.
• As opções de instalação do Windows Server (Server Core, Server with Desktop Experience e Nano Server) suportadas pelos componentes de banco de dados do Operations Manager são baseadas nas opções de instalação suportadas pelo SQL Server.

Para obter mais informações, consulte a seção Requisitos de hardware & software na documentação de instalação e planejamento do SQL Server aqui: Planejar uma instalação do SQL Server

Configuração de agrupamento do SQL Server

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

Observação

Para evitar problemas de compatibilidade ao comparar ou copiar operações, recomendamos que você use o mesmo agrupamento para o banco de dados SQL e Operations Manager.

Intercalaçã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 (insensível a maiúsculas e minúsculas, sensível a acentos)
• 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 no local é 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 estiver projetando uma implantação distribuída usando Grupos de Disponibilidade Always On do SQL, 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 identifica as portas de firewall exigidas pelo SQL Server para que os servidores de gerenciamento se comuniquem com os bancos de dados:

Cenário	Porto	Direção	Função de 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	Servidor de gerenciamento
Conexão de administrador dedicado do SQL Server	TCP 1434 [en]	Entrada	Servidor de gerenciamento
Outras portas usadas pelo SQL Server - Chamadas de procedimento remoto da Microsoft (MS RPC) - Instrumentação de Gestão Windows (WMI) - Coordenador de Transações Distribuídas Microsoft (MS DTC)	TCP 135 [en]	Entrada	Servidor de gerenciamento
Ouvinte do Grupo de Disponibilidade Always On do SQL Server	Porta configurada pelo administrador	Entrada	Servidor de gerenciamento
SQL Server Reporting Services que hospeda o Operations Manager Reporting Server	TCP 80 (padrão)/443 (SSL)	Entrada	servidor de gerenciamento e console de operações

Observação

Embora o TCP 1433 seja a porta padrão para a instância padrão do Mecanismo de Banco de Dados, quando você cria uma instância nomeada em um SQL Server autônomo ou implanta um Grupo de Disponibilidade Always On do SQL, uma porta personalizada é definida e deve ser documentada para referência para que você configure corretamente seus firewalls 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 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 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 recolha de dados operacionais.
  • A taxa de coleta de dados operacionais é influenciada por fatores como o número de pacotes de gerenciamento importados, o número de agentes adicionados e o tipo de computador monitorado. Por exemplo, um agente que monitora um computador desktop crítico para os negócios coleta menos dados em comparação com um agente que monitora um servidor que executa o SQL Server com vários bancos de dados.
• Taxa de alterações no espaço da instância.
  • A atualização de dados existentes no banco de dados do Operations Manager consome muitos recursos em comparação com a gravação de novos dados operacionais. Além disso, quando há alterações nos dados de espaço da instância, os servidores de gerenciamento precisam fazer mais consultas ao banco de dados para calcular a configuração e agrupar as alterações. A taxa de alterações de espaço de instância aumenta ao importar novos pacotes de gerenciamento ou adicionar novos agentes ao grupo de gerenciamento.
• O número de Consoles de Operações e outras conexões SDK em execução simultânea também afeta a carga no banco de dados.
  • 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, Modo de Exibição de Estado, Modo de Exibição de Alertas e 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 é um único ponto de falha para o grupo de gestão, portanto, pode ser tornado altamente disponível usando configurações de failover suportadas, 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 de Always-On SQL existente sem qualquer 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 tarefas. 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 que é iniciada. Portanto, é importante verificar o estado do SQL Server Service Broker sempre que for observado um comportamento inesperado 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 para verificar se o broker já está habilitado, indicado por um resultado de 1 (um) no campo is_broker_enabled:

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

2. Se o valor exibido no campo is_broker_enabled for 0 (zero), execute a seguinte instrução SQL para ativar o corretor:

   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 Operations Manager Data Warehouse

Observação

O Operations Manager Data Warehouse também é conhecido como o banco de dados "Reporting Data Warehouse" ou apenas "Data Warehouse" em algumas documentações.

O System Center - Operations Manager insere dados no data warehouse quase em tempo real, é importante ter capacidade suficiente neste servidor que suporte a gravação de todos os dados que estão sendo coletados no data warehouse. Assim como no banco de dados do Operations Manager, o recurso mais crítico no data warehouse é o subsistema de E/S de armazenamento. Na maioria dos sistemas, as cargas no data warehouse são semelhantes ao banco de dados do Operations Manager, mas podem variar. Além disso, a carga de trabalho colocada no data warehouse por relatório é 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 incluem:

• Taxa de recolha de dados operacionais.
  • O data warehouse realiza cálculos e armazena dados agregados, juntamente com uma quantidade limitada de dados brutos, para permitir relatórios mais eficientes. Como resultado, o custo de coleta de dados operacionais para o data warehouse é ligeiramente maior em comparação com o banco de dados do Operations Manager. No entanto, esse custo é compensado pelo custo de processamento reduzido dos dados de descoberta no data warehouse em comparação com o banco de dados do Operations Manager.
• Número de usuários de relatórios simultâneos ou geração de relatórios agendada.
  • Cada usuário de relatório pode adicionar uma carga significativa ao sistema porque os relatórios frequentemente resumem grandes volumes de dados. As necessidades gerais de capacidade são influenciadas pelo número de relatórios executados simultaneamente e pelo tipo de relatórios que estão sendo executados. Relatórios que consultam grandes intervalos de datas ou grandes números de objetos exigem recursos extras do sistema.

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

• Escolha um subsistema de armazenamento apropriado.
  • Como o data warehouse é parte integrante do fluxo geral de dados através do grupo de gerenciamento, escolher um subsistema de armazenamento apropriado para o data warehouse é importante. Assim como no banco de dados do Operations Manager, RAID 0 + 1 geralmente é a melhor escolha. Em geral, o subsistema de armazenamento para o data warehouse 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.
• Considere o posicionamento apropriado de logs de dados em comparação com 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 a base de dados do gestor de operações e o data warehouse estiverem localizados no mesmo servidor e pretenderes separar os dados dos registos de transações, deves colocar os registos de transações da base de dados do gestor de operações em um volume físico e fusos de disco separados do data warehouse para obteres qualquer benefício. Os arquivos de dados do banco de dados e do data warehouse do Operations Manager 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órios.
• Considere colocar o data warehouse em um servidor separado do banco de dados do Operations Manager.
  • Embora implantações de menor escala geralmente possam consolidar o banco de dados e o data warehouse do Operations Manager 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 e o Reporting Server estão em um servidor separado do banco de dados do Operations Manager, você experimenta um melhor desempenho de relatórios.

O banco de dados do Operations Manager Data Warehouse é um único ponto de falha para o grupo de gerenciamento, por isso pode ser tornado altamente disponível utilizando configurações de failover suportadas, como Grupos de Disponibilidade Always On do SQL Server ou Instâncias de Cluster de Tolerância a Falhas.

SQL Server Sempre Ativo

Os grupos de disponibilidade Always On do SQL Server oferecem suporte a ambientes de failover para um conjunto discreto de bancos de dados de usuários (bancos de dados de disponibilidade). Cada conjunto de bases de dados de disponibilidade é hospedado em uma réplica de disponibilidade.

Com o System Center 2016 e versões posteriores do Operations Manager, o SQL Always On é preferido em relação aos clusters 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.

Para configurar um grupo de disponibilidade, implemente um cluster WSFC (Cluster de Failover do Windows Server) para hospedar a réplica de disponibilidade e ative a funcionalidade Always On nos nós do 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 configurar um grupo de disponibilidade.

Dica

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

Para configurar um grupo de disponibilidade, implemente um cluster WSFC (Cluster de Failover do Windows Server) para hospedar a réplica de disponibilidade e ative a funcionalidade Always On nos nós do 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 configurar um grupo de disponibilidade.

Observação

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

Cadeia de caracteres de várias sub-redes

O Operations Manager não suporta as palavras-chave da cadeia de conexão (MultiSubnetFailover=True). Como um grupo de disponibilidade possui um nome de ouvinte (conhecido como nome de rede ou Ponto de Acesso para Cliente no Gerenciador de Cluster WSFC) que depende de vários endereços IP de diferentes sub-redes, como quando se implementa em uma configuração de failover entre sites, as solicitações de conexão de cliente dos servidores de gestão para o ouvinte do grupo de disponibilidade poderão ultrapassar o tempo limite de conexão.

A abordagem recomendada para contornar essa limitação com nós de servidor de grupo de disponibilidade implantados em um ambiente de várias sub-redes é:

1. Defina o nome da rede do ouvinte do seu 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 uma recuperação e resolução mais rápidas do nome do cluster com o novo endereço IP ao efetuar transferência para um nó numa sub-rede diferente.

Execute os seguintes comandos do PowerShell em qualquer um dos nós SQL para modificar essas 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.

Os seguintes comandos do PowerShell podem ser executados 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 de Acesso a Dados do Operations Manager sempre que ocorrer um failover entre nós. Para obter informações de configuração, 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.

Otimizar o SQL Server

As experiências de suporte mostraram 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, o problema 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 discos para os LUNs suportarem os requisitos de I/O 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 de E/S e latência diferentes.
• 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 usar AUTOGROW para banco de dados e arquivos 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 do log de transações. O padrão de comportamento de E/S do Operations Manager consiste normalmente em 80% gravações e 20% leituras. Como resultado, a configuração inadequada de subsistemas de E/S pode levar a um desempenho e operação insatisfatórios dos sistemas SQL Server e torna-se percetí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 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 seguinte artigo do blog, de autoria de um membro da equipe do Servidor de Arquivos no grupo de produtos, fornece orientações detalhadas e recomendações sobre como realizar testes de esforço usando essa ferramenta - DiskSpd, PowerShell e desempenho de armazenamento: medindo IOPs, taxa de transferência e latência para discos locais e compartilhamentos de arquivos SMB.

Tamanho da unidade de alocação NTFS

O alinhamento de volume, comumente referido como alinhamento de setor, deve ser executado no sistema de arquivos (NTFS) sempre que um volume é 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. Isso também pode levar a um desalinhamento do cache de hardware, resultando em uma utilização ineficiente do cache do array.

Ao formatar a partição usada para arquivos de dados do SQL Server, a recomendação é usar um tamanho de unidade de alocação de 64 KB (ou seja, 65.536 bytes) para dados, logs e TempDB. Esteja ciente, no entanto, 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 apenas de leitura em volumes compactados, não é aconselhável.

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 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 orientação 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 que você configure a quantidade mínima e máxima de de memória que serão reservados e usados 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 a memória mínima do servidor é 0, e a configuração padrão para a 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 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, agentes de gerenciamento e verificação antivírus em tempo real. Se não estiver definida memória suficiente, o SO e o SQL serão transferidos 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 percetível no Operations Manager.

Recomendamos especificar pelo menos 4 GB de RAM para min de memória do servidor. Isso deve ser feito para cada instância SQL que hospeda um dos bancos de dados do Gestor de Operações (operacional, data warehouse, ACS).

Para a memória máxima do servidor , recomendamos que inicialmente reserve 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 Memória\MB disponíveis no Windows para determinar se pode aumentar a memória disponível para o SQL Server. O Windows sinaliza que a memória física disponível está a níveis baixos quando atinge 96 MB, portanto, idealmente, o contador não deve descer abaixo de cerca de 200-300 MB, para garantir um buffer. Para servidores com 256 GB de RAM ou superior, verifique se não está 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 o seu sistema operativo, outras aplicações, a pilha de threads do SQL Server e outros alocadores multipá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 memória é de 512 KB para sistemas x86, 2 MB para sistemas x64 e 4 MB para sistemas IA64, e pode-se 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 usa 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ê pode chegar a um ponto em que a alocação de memória mais baixa é trocada por um acesso de E/S de disco mais alto.

Para configurar a memória do SQL Server num ambiente que foi provisionado em excesso, comece por monitorizar o ambiente e as métricas de desempenho atuais, incluindo a expectativa de vida útil da página no SQL Server Buffer Manager , leituras de página por segundo e os valores de leituras de disco físico por segundo . Se o ambiente tiver excesso de memória, a expectativa de vida da página aumentará um segundo a cada segundo sem qualquer redução sob a carga de trabalho, devido ao cache; o valor de leituras/s de páginas do SQL Server Buffer Manager será baixo após o aumento do cache; e as leituras/s de disco físico também permanecerão baixas.

Depois de entender a linha de base do ambiente, você pode reduzir o máximo de memória 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, em seguida, 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 Server.

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 ocupada com o crescimento automático do 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 do TempDB como SIMPLE.
  • Este modelo recupera automaticamente espaço de log para manter os requisitos de espaço mínimos.
• Pré-aloque espaço para todos os arquivos TempDB definindo o tamanho do arquivo para um valor grande o suficiente para acomodar a carga de trabalho típica 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 configurado 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 do TempDB e melhora a escalabilidade. 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 (contabilizando todas as 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 os 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 ainda mais o número de ficheiros 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 forem criados com tamanhos desiguais, o algoritmo de preenchimento proporcional tenta usar mais o maior arquivo para alocações GAM, em vez de distribuir as alocações entre todos os arquivos, comprometendo assim o objetivo 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.
  • Utilize a fragmentação de disco se houver muitos discos ligados diretamente.
• Coloque o banco de dados TempDB em discos diferentes daqueles 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

Executar a consulta T-SQL SELECT * from sys.sysprocesses para detetar contenção na alocação de páginas para a base 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, essa configuração pode fazer com que o SQL Server pareça sem resposta 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 mostram que essas solicitações ou tarefas estão aguardando recursos do TempDB e têm valores semelhantes, conforme destacado 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 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 após a reinicialização do SQL Server. Com este sinalizador de rastreamento, o SQL Server atribui extensões completas a cada objeto na base de dados, assim eliminando 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

Dica

Para obter as práticas recomendadas e recomendações mais recentes da equipe do SQL Server, consulte a documentação aqui: Defina a opção de grau máximo de paralelismo para um desempenho ideal

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 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 dispositivos 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 não discutida na orientação anterior é MAXDOP.

A opção de configuração do grau máximo de paralelismo (MAXDOP) do Microsoft SQL Server controla o número de processadores usados para a execução de uma consulta em um plano paralelo. Esta opção determina os recursos de computação e thread que são usados para os operadores de plano de consulta que executam o trabalho em paralelo. Dependendo se o SQL Server está configurado em um computador de multiprocessamento simétrico (SMP), um computador NUMA (acesso não uniforme à memória) ou 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 deteta 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 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 durante a instalação consultar dinamicamente quantos processadores são apresentados ao sistema operacional, 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

  Dica

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

• Para servidores com NUMA configurado, o MAXDOP não deve exceder o número de CPUs atribuídas a cada nó NUMA.

• Para servidores com hyperthreading habilitado, o valor MAXDOP não deve exceder o número de processadores físicos.

• Para servidores que têm NUMA configurado e hiperprocessamento ativado, o valor MAXDOP não deve exceder o número de processadores físicos por nó NUMA.

Você pode monitorar o número de trabalhadores paralelos consultando select * from sys.dm_os_tasks.

Neste exemplo, a configuração de hardware do servidor era um HP Blade G6 com 24 processadores de núcleo e 196 GB de RAM. A instância que hospeda o banco de dados do Operations Manager tinha uma configuração MAXMEM de 64 GB. Depois de executar as otimizações sugeridas nesta seção, o desempenho melhorou. No entanto, ainda persistia um gargalo no paralelismo das consultas. Após testar diferentes valores, o melhor desempenho foi encontrado pela configuração MAXDOP=4.

Dimensionamento inicial do banco de dados

Tentar estimar o crescimento futuro dos bancos de dados do Operations Manager, especificamente os bancos de dados operacionais e de data warehouse, nos primeiros meses após a implantação não é um exercício simples. Embora o auxiliar de dimensionamento do Operations Manager seja razoável ao estimar o crescimento potencial com base na fórmula derivada pelo grupo de produtos a partir de seus testes no laboratório, ele não leva em conta vários fatores, que podem influenciar o crescimento a curto prazo versus longo prazo.

O tamanho inicial do banco de dados, conforme sugerido pelo Auxiliar de Dimensionamento, deve ser alocado a um tamanho previsto para reduzir a fragmentação e a sobrecarga correspondente, que pode ser especificada no momento da configuração para os bancos de dados Operacional e de Data Warehouse. Se durante a instalação não houver espaço de armazenamento suficiente disponível, os bancos de dados poderão ser expandidos posteriormente usando o SQL Management Studio e, em seguida, reindexados posteriormente para desfragmentar e otimizar adequadamente. Esta recomendação também se aplica à base de dados ACS.

O monitoramento proativo do crescimento do banco de dados operacional e de data warehouse deve ser realizado em um ciclo diário ou semanal. Isso é necessário para identificar surtos de crescimento inesperados e significativos e iniciar a solução de problemas para determinar a causalidade, seja por um bug em um fluxo de trabalho do pacote de gerenciamento (ou seja, regra de descoberta, regra de coleta de desempenho ou evento ou regra de monitor ou alerta) ou outro sintoma com um pacote de gerenciamento que não foi identificado durante a fase de teste e garantia de qualidade do processo de gerenciamento de versão.

Crescimento automático do banco de dados

Quando o tamanho do arquivo de bancos de dados reservados fica cheio, o SQL Server pode aumentar automaticamente o tamanho em uma porcentagem ou em um valor fixo. Além disso, um tamanho máximo de banco de dados pode ser configurado para evitar o preenchimento de todo o espaço disponível no disco. Por padrão, o banco de dados do Operations Manager não está configurado com o crescimento automático habilitado; apenas os bancos de dados Data Warehouse e ACS são.

Confie apenas no autocrescimento como uma contingência para um crescimento inesperado. O Autogrow introduz uma penalidade de desempenho que deve ser considerada ao lidar com um banco de dados altamente transacional. As penalidades de desempenho incluem:

• Se você não fornecer um incremento de crescimento apropriado, poderá ocorrer fragmentação do arquivo de log ou do banco de dados.
• Se você executar uma transação que requer mais espaço de log do que o disponível e o crescimento automático estiver habilitado para o log de transações desse banco de dados, o tempo que a transação levará para ser concluída incluirá o tempo que o log de transações levará para crescer no valor configurado.
• Se você executar uma transação grande que exija que o log cresça, outras transações que exijam uma gravação no log de transações também terão que esperar até que a operação de crescimento seja concluída.

Se as opções de crescimento automático e redução automática forem combinadas, isso pode criar sobrecarga desnecessária. Certifique-se de que os limites que acionam as operações de crescimento e redução não causem alterações frequentes de tamanho para cima e para baixo. Por exemplo, você pode executar uma transação que faz com que o log de transações cresça 100 MB no momento em que é confirmado; algum tempo depois disso, a redução automática é iniciada e reduz o log de transações em 100 MB. Em seguida, você executa a mesma transação e faz com que o log de transações cresça em 100 MB novamente. Nesse exemplo, você está criando sobrecarga desnecessária e potencialmente criando fragmentação do arquivo de log, o que pode afetar negativamente o desempenho.

Configure essas duas configurações com cuidado. A configuração específica realmente depende do seu ambiente. A recomendação geral é aumentar o tamanho do banco de dados em uma quantidade fixa, a fim de reduzir a fragmentação do disco. Veja, por exemplo, a figura a seguir, onde o banco de dados é configurado para crescer 1.024 MB cada vez que o crescimento automático é necessário.

Política de failover de cluster

O Cluster de Failover do Windows Server é uma plataforma de alta disponibilidade que monitoriza constantemente as conexões de rede e a saúde dos nós de um cluster. Se um nó não estiver acessível pela rede, será tomada uma ação de recuperação para restaurar e colocar aplicações e serviços online em outro nó no cluster. As configurações padrão prontas para uso são otimizadas para falhas em que há uma perda completa de um servidor, o que é considerado uma falha "difícil". Estes seriam cenários de falha irrecuperáveis, como a falha de hardware ou energia não redundante. Nessas situações, o servidor é perdido e o objetivo é que o Clustering de Failover detete rapidamente a perda do servidor e se recupere rapidamente em outro servidor no cluster. Para realizar essa recuperação rápida de falhas graves, as configurações padrão para monitoramento da integridade do cluster são bastante agressivas. No entanto, eles são totalmente configuráveis para permitir flexibilidade para vários cenários.

Essas configurações padrão oferecem o melhor comportamento para a maioria dos clientes; No entanto, como os clusters são esticados de centímetros a possivelmente quilômetros de distância, o cluster pode ficar exposto a mais componentes de rede potencialmente não confiáveis entre os nós. Outro fator é que a qualidade dos servidores comuns está constantemente a melhorar, e a resiliência aumentada através de componentes redundantes (como fontes de alimentação duplas, agrupamento de NIC e E/S de múltiplos caminhos) significa que o número de falhas de hardware não redundantes pode ser bastante raro. Como as falhas graves podem ser menos frequentes, alguns clientes podem querer ajustar o cluster para falhas transitórias, onde o cluster é mais resiliente a breves falhas de rede entre os nós. Ao aumentar os limites de falha padrão, você pode diminuir a sensibilidade a breves problemas de rede que duram um curto período de tempo.

É importante entender que não há uma resposta certa aqui, e a configuração otimizada pode variar de acordo com seus requisitos de negócios específicos e contratos de nível de serviço.

Virtualizando o SQL Server

Em ambientes virtuais, por motivos de desempenho, é recomendável armazenar o banco de dados operacional e o banco de dados do data warehouse em um armazenamento com conexão direta, e não em um disco virtual. Você pode usar o utilitário Operations Manager Sizing Helper lançado para o Operations Manager 2012 para estimar as IOPS necessárias e testar os discos de dados para verificar. O desempenho do armazenamento pode ser testado com o utilitário DiskSpd. Consulte também suporte à virtualização do Operations Manager para obter orientações adicionais sobre o ambiente virtualizado do Operations Manager.

Always On e modelo de recuperação

Embora não seja estritamente uma otimização, uma consideração importante em relação ao Always On Availability Group é o fato de que, por design, esse recurso requer que os bancos de dados sejam definidos no modelo de recuperação "Full". Ou seja, os logs de transações nunca são descartados até que seja realizado um backup completo ou apenas do log de transações. Por esse motivo, uma estratégia de backup não é opcional, mas uma parte obrigatória do design AlwaysOn para bancos de dados do Operations Manager. Caso contrário, com o tempo, os discos contendo logs de transações enchem-se.

Uma estratégia de backup deve levar em conta os detalhes do seu ambiente. Um agendamento de backup típico é fornecido na tabela a seguir.

Tipo de backup	Horário
Somente log de transações	A cada uma hora
Completo	Semanalmente, domingo às 3:00 AM

Otimizando os serviços de relatório do SQL Server

A instância do Reporting Services atua como um proxy para acesso a dados no banco de dados do Data Warehouse. Ele gera e exibe relatórios com base em modelos armazenados dentro dos pacotes de gerenciamento.

A função Relatório do Operations Manager não pode ser instalada lado a lado com uma versão anterior da função Relatório e deve ser instalada apenas no modo nativo (o modo integrado do SharePoint não é suportado).

Nos bastidores do Reporting Services, há uma instância do Banco de Dados do SQL Server que hospeda os bancos de dados ReportServer e ReportServerTempDB. Aplicam-se recomendações gerais relativas ao ajuste de desempenho desta instância.

Observação

No SQL Server Reporting Services (SSRS) 2017 versão 14.0.600.1274 e posterior, as configurações de segurança padrão não permitem carregamentos de extensões de recursos. Isso resulta em exceções de ResourceFileFormatNotAllowedException no Operations Manager durante a implementação de componentes de relatório.

Para corrigir isso:

1. Abra o SQL Server Management Studio.
2. Conecte-se à sua instância do Reporting Services.
3. Clique com o botão direito do mouse na instância do servidor na janela do Pesquisador de Objetos.
4. Selecione Propriedades.
5. Selecione Avançado na barra lateral esquerda.
6. Adicione *.* à lista de AllowedResourceExtensionsForUpload.

Como alternativa, você pode adicionar a lista completa de extensões de relatório do Operations Manager à lista de permissão no SSRS. A lista é descrita na "Resolução 2" aqui: relatórios do Operations Manager falham ao serem distribuídos

Próximos passos

Para entender como configurar o alojamento do armazém de dados (de relatórios) por trás de um firewall, consulte conectar o armazém de dados (de relatórios) através de um firewall.