Considerações de Conceção do SQL Server

O System Center Operations Manager requer acesso a uma instância de um servidor com o Microsoft SQL Server para suportar a base de dados de auditoria operacional, armazém de dados e ACS. As bases de dados operacional e do armazém de dados são necessárias e criadas quando implementa o primeiro servidor de gestão no grupo de gestão, enquanto que a base de dados ACS é criada quando implementa um recoletor ACS no seu grupo de gestão.

Num ambiente de laboratório ou implementação de pequena escala do Operations Manager, o SQL Server pode ser colocalizado no primeiro servidor de gestão no grupo de gestão.

Numa implementação distribuída empresarial de média dimensão, a instância do SQL Server deve estar localizada num servidor autónomo dedicado ou numa configuração SQL Server de elevada disponibilidade. Em qualquer um dos casos, o SQL Server já deve existir e estar acessível antes de começar a instalação do primeiro servidor de gestão ou recolector ACS.

Não recomendamos a utilização de bases de dados do Operations Manager a partir de uma Instância do SQL que tenha outras bases de dados de aplicações. Isto serve para evitar potenciais problemas com a E/S e outras restrições de recursos de hardware.

Importante

O Operations Manager não suporta instâncias de Plataforma como Serviço (PaaS) do SQL, incluindo produtos como o Azure SQL Managed Instance ou o Amazon Relational Database Service (AWS RDS). Utilize uma instância de SQL Server instalada num computador Windows. A única exceção é na Instância Gerida do SCOM do Azure Monitor, que utiliza SQL do Azure 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 alojar o Servidor de Relatórios, Operacional, Data Warehouse e base de dados ACS:

• SQL Server 2022

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

  Nota

  • O Operations Manager 2022 suporta o SQL 2019 com CU8 ou posterior; No entanto, não suporta o SQL 2019 RTM.
  • Utilize o ODBC 17.3 ou posterior e o MSOLEDBSQL 18.2 ou posterior.

• SQL Server 2017 e Atualizações Cumulativos conforme detalhado aqui

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

Nota

• Cada um dos seguintes componentes SQL Server que suportam uma infraestrutura do SCOM têm de estar na mesma SQL Server versão principal:
  • SQL Server instâncias do motor de base de dados que alojam qualquer uma das bases de dados SCOM (ou seja, as bases de dados OperationManager, OperationManagerDW e SSRS ReportServer & ReportServerTempDB).
  • SQL Server Reporting Services (SSRS).
• A definição de agrupamento SQL Server tem de ser um dos tipos suportados, conforme descrito na secção definição de agrupamento SQL Server abaixo.
• SQL Server a Pesquisa em Texto Completo é necessária para todas as instâncias do motor de base de dados SQL Server que alojam qualquer uma das bases de dados SCOM.
• As opções de instalação do Windows Server 2016 (Server Core, Server com Experiência de Utilização do Computador e Servidor Nano) suportadas pelos componentes da base de dados do Operations Manager baseiam-se nas opções de instalação do Windows Server suportadas pelo SQL Server.

Nota

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 têm de ser instalados apenas no modo nativo (o modo integrado do SharePoint não é suportado).

Considerações de hardware e software adicionais aplicáveis ao planeamento da estrutura:

• Recomendamos que execute SQL Server em computadores com o formato de ficheiro NTFS.
• Tem de existir, pelo menos, 1024 MB de espaço livre em disco para a base de dados operacional e do armazém de dados. É imposta no momento da criação da base de dados e provavelmente irá aumentar significativamente após a configuração.
• É necessário o .NET Framework 4.
• .NET Framework 4.8 é suportado pelo Operations Manager 2022.
• O Servidor de Relatórios não é suportado no Windows Server Core.

Para obter mais informações, veja Requisitos de Hardware e Software para Instalar SQL Server.

Nota

Embora o Operations Manager utilize apenas a autenticação do Windows durante a instalação, a definição Autenticação do Modo Misto do SQL continuará a 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.

Definição do agrupamento do SQL Server

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

Nota

Para evitar problemas de compatibilidade nas operações de comparação ou cópia, recomendamos que utilize o mesmo agrupamento para a BD do SQL e do Operations Manager.

Agrupamento do SQL Server

• SQL_Latin1_General_CP1_CI_AS

Agrupamento 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 a instância SQL Server não estiver configurada com um dos agrupamentos suportados listados anteriormente, a execução de uma nova configuração da configuração do Operations Manager falhará. No entanto, uma atualização no local será concluída com êxito.

Configuração da firewall

O Operations Manager depende do SQL Server para alojar as bases de dados e uma plataforma de relatórios para analisar e apresentar dados operacionais históricos. As funções de servidor de gestão, Operações e consola Web precisam de conseguir comunicar com êxito com SQL Server e é importante compreender o caminho de comunicação e as portas para configurar corretamente o seu ambiente.

Se estiver a conceber uma implementação distribuída que irá exigir que os Grupos de Disponibilidade AlwaysOn do SQL forneçam funcionalidades de ativação pós-falha para as bases de dados do Operations Manager, existem definições de configuração de firewall adicionais que têm de ser incluídas na estratégia de segurança da firewall.

A tabela seguinte ajuda-o a identificar as portas de firewall exigidas pelo SQL Server que terá de permitir para que as funções de servidor no grupo de gestão do Operations Manager comuniquem com êxito.

Scenario	Porta	Direção	Função do Operations Manager
do SQL Server aloja as bases de dados do Operations Manager	TCP 1433 *	Entrada	entrada e consola Web (para Application Advisor e ao Application Diagnostics)
Serviço SQL Server Browser	UDP 1434	Entrada	Servidor de Management
Ligação de Administração Dedicada do SQL Server	TCP 1434	Entrada	Servidor de Management
Portas adicionais utilizadas pelo SQL Server - Chamadas de procedimento remoto da Microsoft (MS RPC) - Windows Management Instrumentation (WMI) - Coordenador de Transações Distribuídas da Microsoft (MS DTC)	TCP 135	Entrada	Servidor de Management
Serviço de Escuta do Grupo de Disponibilidade Always On do SQL Server	Porta configurada pelo administrador	Entrada	Servidor de Management
SQL Server Reporting Services aloja o Servidor de Relatórios do Operations Manager	TCP 80 (predefinição)/443 (SSL)	Entrada	e consola de operações

* Embora o TCP 1433 seja a porta padrão para a instância predefinida do Motor de Base de Dados, quando cria uma instância nomeada num SQL Server autónomo ou implementou um Grupo de Disponibilidade AlwaysOn do SQL, será definida uma porta personalizada e deverá ser documentada para referência para que configure corretamente as firewalls e introduza estas informações durante a configuração.

Para obter uma descrição geral mais detalhada dos requisitos de firewall para SQL Server, veja Configurar a Firewall do Windows para Permitir SQL Server Access.

Considerações sobre capacidade e armazenamento

Base de dados do Operations Manager

A base de dados do Operations Manager é uma base de dados do SQL Server que contém todos os dados de que o Operations Manager necessita para a monitorização de rotina. O dimensionamento e a configuração do servidor da base de dados são críticos para o desempenho global do grupo de gestão. O recurso mais crítico utilizado pela base de dados do Operations Manager é o subsistema de armazenamento, mas a CPU e a RAM também são importantes.

Os fatores que influenciam a carga na base de dados do Operations Manager incluem:

• Frequência de recolha de dados operacionais. Os dados operacionais são compostos por todos os eventos, alertas, alterações de estado e dados de desempenho recolhidos pelos agentes. A maior parte dos recursos utilizados pela base de dados do Operations Manager é utilizada para escrever dados no disco à medida que entram no sistema. A frequência de recolha de dados operacionais tende a aumentar à medida que pacotes de gestão adicionais são importados e agentes adicionais são adicionados. O tipo do computador que um agente monitoriza também é um fator importante utilizado na determinação da frequência de recolha de dados operacionais. Por exemplo, espera-se que um agente que monitoriza um computador de secretária crítico para a empresa recolha menos dados que um agente que monitoriza um servidor que está a executar uma instância do SQL Server com um grande número de bases de dados.
• Frequência de alterações de espaço de instância. A atualização destes dados na base de dados do Operations Manager é relativamente dispendiosa em comparação com a escrita de novos dados operacionais. Adicionalmente, quando os dados de espaço de instância mudam, os servidores de gestão efetuam consultas adicionais na base de dados do Operations Manager para calcular as alterações de configuração e de grupo. A frequência de alterações de espaço de instância aumenta à medida que importa pacotes de gestão adicionais para um grupo de gestão. Adicionar novos agentes a um grupo de gestão também aumenta temporariamente a frequência de alterações de espaço de instância.
• Número de consolas de operações e outras ligações de SDK executadas em simultâneo. Cada consola de operações lê os dados a partir da base de dados do Operations Manager. Potencialmente, consultar estes dados consome grandes quantidades de recursos de E/S de armazenamento, tempo de CPU e RAM. As consolas de operações que apresentam grandes quantidades de dados operacionais na Vista Eventos, Vista Estado, Vista Alertas e Vista Dados de Desempenho tendem a criar as cargas maiores na base de dados.

A base de dados do Operations Manager é uma origem única da falha para o grupo de gestão, pelo que pode ficar altamente disponível através da utilização de configurações de ativação pós-falha, como, por exemplo, Grupos de Disponibilidade Always On ou Instâncias de Cluster de Ativação Pós-falha.

Pode configurar e atualizar bases de dados do Operations Manager com uma configuração do SQL Always-On existente sem qualquer necessidade de alterações pós-configuração.

Ativar o SQL Broker na base 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 SQL Server Service Broker estiver desativado, todas as operações de tarefas serão afetadas. O comportamento resultante pode variar de acordo com a tarefa iniciada. Por conseguinte, é importante verificar o estado do SQL Server Service Broker sempre que se observar um comportamento inesperado em torno de uma tarefa no System Center Operations Manager.

Para ativar SQL Server Service Broker, siga estes passos:

1. Execute a seguinte consulta do SQL:

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

2. Ignore este passo se o valor apresentado no is_broker_enabled campo for 1 (um). Se não for o caso, execute as seguintes consultas do SQL:

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

Base de dados do armazém de dados do Operations Manager

O System Center - Operations Manager insere dados no armazém de dados de Relatórios quase em tempo real, é importante ter capacidade suficiente neste servidor que suporte a escrita de todos os dados que estão a ser recolhidos no armazém de dados de Relatórios. Tal como acontece com a base de dados do Operations Manager, o recurso mais crítico do armazém de dados de Relatórios é o subsistema de E/S de armazenamento. Na maioria dos sistemas, os carregamentos no armazém de dados de Relatórios são semelhantes à base de dados do Operations Manager, mas podem variar. Além disso, a carga de trabalho do armazém de dados de Relatórios por relatório é diferente da carga da base de dados do Operations Manager por utilização da consola de operações.

Os fatores que influenciam a carga no armazém de dados de Relatórios incluem:

• Frequência de recolha de dados operacionais. Para tornar os relatórios mais eficientes, o armazém de dados de Relatórios calcula e armazena os dados agregados bem como uma quantidade limitada de dados não processados. A execução deste trabalho adicional implica que a recolha de dados operacionais para o armazém de dados de Relatórios pode ser ligeiramente mais dispendiosa do que na base de dados do Operations Manager. Normalmente, este custo adicional é equilibrado pelo custo reduzido do processamento de dados de deteção no armazém de dados de Relatórios em comparação com a base de dados do Operations Manager.
• Número de utilizadores de relatórios em simultâneo ou geração de relatórios agendados. Como os relatórios resumem frequentemente grandes volumes de dados, cada utilizador de relatórios pode adicionar uma carga significativa ao sistema. O número de relatórios executados em simultâneo e o tipo de relatório executado afetam as necessidades de capacidade geral. Geralmente, os relatórios que consultam grandes intervalos de dados ou um grande número de objetos necessitam de recursos de sistema adicionais.

Com base nestes fatores, existem várias práticas recomendadas a considerar ao dimensionar o armazém de dados de Relatórios:

• Escolha um subsistema de armazenamento adequado. Uma vez que o armazém de dados de Relatórios é uma parte integrante do fluxo de dados geral através do grupo de gestão, é importante escolher um subsistema de armazenamento adequado para o armazém de dados de Relatórios. Tal como acontece na base de dados do Operations Manager, o RAID 0 + 1 é frequentemente a melhor escolha. Em geral, o subsistema de armazenamento para o armazém de dados de Relatórios deverá ser semelhante ao do subsistema de armazenamento da base de dados do Operations Manager e as orientações aplicáveis à base de dados do Operations Manager também se aplicam ao armazém de dados de Relatórios.
• Considere uma localização adequada dos registos de dados vs registos de transações. Quanto à base de dados do Operations Manager, separar os dados SQL e os registos de transações é, muitas vezes, uma escolha adequada à medida que aumenta verticalmente o número de agentes. Se a base de dados do Operations Manager e o armazém de dados de Relatórios estiverem localizados no mesmo servidor e pretende separar os registos de dados e de transações, tem de colocar os registos de transações da base de dados do Operations Manager num volume físico e spindle de disco separados do armazém de dados de Relatórios para beneficiar das vantagens inerentes. Os ficheiros de dados da base de dados do Operations Manager e do armazém de dados de Relatórios podem partilhar o mesmo volume físico, desde que o volume forneça uma capacidade adequada e o desempenho de E/S do disco não afete negativamente a funcionalidade de monitorização e relatórios.
• Considere colocar o armazém de dados de Relatórios num servidor separado da base de dados do Operations Manager. Embora as implementações em menor escala possam muitas vezes consolidar a base de dados do Operations Manager e o armazém de dados de Relatórios no mesmo servidor, é vantajoso separá-las à medida que aumenta verticalmente o número de agentes e o volume de dados operacionais recebidos. Quando o armazém de dados de Relatórios e o Servidor de Relatórios estão num servidor separado da base de dados do Operations Manager, terá um melhor desempenho de relatórios.

A base de dados do armazém de dados do Operations Manager é uma origem única da falha para o grupo de gestão, pelo que pode ficar altamente disponível através da utilização de configurações de ativação pós-falha, como, por exemplo, Grupos de Disponibilidade Always On ou Instâncias de Cluster de Ativação Pós-falha.

SQL Server AlwaysOn

Os grupos de disponibilidade Always On do SQL Server suportam ambientes de ativação pós-falha para um conjunto discreto de bases de dados do utilizador (bases de dados de disponibilidade). Cada conjunto de bases de dados de disponibilidade está alojado por uma réplica de disponibilidade.

Com o System Center 2016 e posterior – Operations Manager, o SQL AlwaysOn é preferido sobre o clustering de ativação pós-falha para fornecer elevada disponibilidade para bases de dados. Todas as bases de dados, exceto a instalação dos Reporting Services em modo nativo que utiliza duas bases de dados para separar o armazenamento de dados persistente do armazenamento de dados temporário, podem ser alojadas num Grupo de Disponibilidade AlwaysOn.

Com o Operations Manager 2022, pode configurar e atualizar bases de dados do Operations Manager com uma configuração de Always-On SQL existente sem necessidade de alterações pós-configuração.

Para configurar um grupo de disponibilidade, terá de implementar um cluster de Clustering de Ativação Pós-falha do Windows Server (WSFC) para alojar a réplica de disponibilidade e ativar o AlwaysOn nos nós do cluster. Em seguida, pode adicionar a base de dados SQL Server do Operations Manager como uma base de dados de disponibilidade.

• Saiba mais sobre os pré-requisitos alwayson.
• Saiba mais sobre como configurar um WSFC para grupos de disponibilidade AlwaysOn.
• Saiba mais sobre como configurar um grupo de disponibilidade.

Nota

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

Cadeia multisubnet

O Operations Manager não suporta as palavras-chave cadeia de ligação (MultiSubnetFailover=True). Uma vez que um grupo de disponibilidade tem um nome de serviço de escuta (conhecido como nome de rede ou Ponto de Acesso de Cliente no Gestor de Clusters do WSFC), dependendo de vários endereços IP de sub-redes diferentes, como quando implementa numa configuração de ativação pós-falha entre sites, os pedidos de ligação de cliente de servidores de gestão para o serviço de escuta do grupo de disponibilidade atingirão um tempo limite de ligação.

A abordagem recomendada para contornar esta limitação quando implementar nós de servidor no grupo de disponibilidade num ambiente de várias sub-redes é fazer o seguinte:

1. Defina o nome de rede do serviço de escuta do grupo de disponibilidade para registar apenas um único endereço IP ativo no DNS.
2. Configure o cluster para utilizar um valor TTL baixo para o registo DNS registado.

Estas definições permitem, quando a ativação pós-falha para um nó numa sub-rede diferente, para uma recuperação e resolução mais rápidas do nome do cluster com o novo endereço IP.

Execute os seguintes comandos do PowerShell em qualquer um dos nós SQL para modificar as definiçõ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 estiver a utilizar o AlwaysOn com um nome de serviço de escuta, também deve fazer estas alterações de configuração no serviço de escuta. Para obter mais informações sobre como configurar um serviço de escuta do grupo de disponibilidade, veja a documentação aqui: Configurar o serviço de escuta do grupo de disponibilidade - SQL Server AlwaysOn

Execute os seguintes comandos do PowerShell no nó SQL que atualmente aloja o serviço de escuta para modificar as definiçõ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 do SQL AlwaysOn ou em cluster é utilizada para elevada disponibilidade, deve ativar a funcionalidade de recuperação automática nos servidores de gestão para evitar que o serviço de Acesso a Dados do Operations Manager reinicie sempre que ocorrer uma ativação pós-falha entre nós. Para obter informações sobre como configurar esta opção, veja o seguinte artigo KB O serviço de Gestão do System Center deixa de responder após uma instância de SQL Server ficar offline.

Otimizar o SQL SERVER

Em geral, a experiência de implementação anterior com os clientes mostra que os problemas de desempenho normalmente não são causados pela utilização elevada de recursos (ou seja, processador ou memória) com SQL Server em si; em vez disso, está diretamente relacionado com a configuração do subsistema de armazenamento. Os estrangulamentos de desempenho são normalmente atribuídos a não seguir as orientações de configuração recomendadas com o armazenamento aprovisionado para a instância da base de dados SQL Server. Estes exemplos são:

• Alocação insuficiente de spindles para os LUNs suportarem os requisitos de E/S do Operations Manager.
• Alojamento de registos de transações e ficheiros de base de dados no mesmo volume. Estas duas cargas de trabalho têm características de E/S e latência diferentes.
• A configuração da TempDB está incorreta no que diz respeito ao posicionamento, ao dimensionamento, etc.
• Desalinhamento da partição do disco de volumes que alojam os registos de transações da base de dados, ficheiros de base de dados e TempDB.
• Ignorando a configuração de SQL Server básica, como a utilização do AUTOGROW para ficheiros de registo de bases de dados e transações, a definição MAXDOP para paralelismo de consultas, a criação de múltiplos ficheiros de dados TempDB por núcleo da CPU, etc.

A configuração do armazenamento é um dos componentes críticos da implementação do SQL Server para o Operations Manager. Os servidores de bases de dados tendem a estar demasiado dependentes da E/S devido à rigorosa atividade de leitura e escrita, e ao processamento do registo de transações. O padrão de comportamento de E/S do Operations Manager é normalmente 80% de escritas e 20% de leituras. Como resultado, uma configuração inadequada de subsistemas de E/S pode levar a um fraco desempenho e funcionamento de sistemas SQL Server e torna-se perceptível no Operations Manager.

É importante testar a estrutura do SQL Server ao realizar testes de débito do subsistema de E/S antes de implementar SQL Server. Certifique-se de que estes testes conseguem alcançar os seus requisitos de E/S com uma latência aceitável. Utilize o Utilitário Diskspd para avaliar a capacidade de E/S do subsistema de armazenamento que suporta SQL Server. O seguinte artigo de blogue, criado por um membro da equipa do Servidor de Ficheiros no grupo de produtos, fornece orientações detalhadas e recomendações sobre como realizar testes de stress com esta ferramenta com algum código do PowerShell e capturar os resultados com o PerfMon. Também pode consultar o Auxiliar de Dimensionamento do Operations Manager para obter orientações iniciais.

Tamanho da unidade de alocação NTFS

O alinhamento de volume, frequentemente referido como alinhamento do setor, deve ser efetuado no sistema de ficheiros (NTFS) sempre que um volume for criado num dispositivo RAID. Se não o fizer, pode levar a uma degradação significativa do desempenho e é normalmente o resultado de um desalinhamento de partições com limites de unidades de riscas. Também pode levar a um desalinhamento da cache de hardware, o que resulta numa utilização ineficiente da cache de matriz. Ao formatar a partição que será utilizada para SQL Server ficheiros de dados, recomenda-se que utilize um tamanho de unidade de alocação de 64 KB (ou seja, 65 536 bytes) para dados, registos e tempdb. Tenha em atenção, no entanto, que a utilização de tamanhos de unidades de alocação superiores a 4 KB resulta na incapacidade de utilizar a compressão NTFS no volume. Embora SQL Server suporte dados só de leitura em volumes comprimidos, não é recomendado.

Memória de reserva

Nota

Grande parte da informação nesta secção vem de Jonathan Kehayias na sua publicação de blogue De que quantidade de memória é que a minha SQL Server realmente precisa? (sqlskills.com).

Nem sempre é fácil identificar a quantidade certa de memória física e processadores a alocar para SQL Server de suporte do System Center Operations Manager (ou para outras cargas de trabalho fora deste produto). A calculadora de dimensionamento fornecida pelo grupo de produtos fornece orientações com base no dimensionamento da carga de trabalho, mas as respetivas recomendações baseiam-se em testes realizados num ambiente de laboratório que pode ou não estar alinhado com a carga de trabalho e a configuração reais.

SQL Server permite-lhe configurar a quantidade mínima e máxima de memória que será reservada e utilizada pelo respetivo processo. Por predefinição, o SQL Server pode alterar os requisitos de memória dinamicamente com base nos recursos de sistema disponíveis. A predefinição para memória mínima do servidor é 0 e a predefinição para a memória máxima do servidor é de 2.147 483 647 MB.

Podem surgir problemas relacionados com o desempenho e a memória se não definir um valor adequado para a memória máxima do servidor. Muitos fatores influenciam a quantidade de memória que precisa de alocar a SQL Server para garantir que o sistema operativo pode suportar outros processos em execução nesse sistema, como o cartão HBA, agentes de gestão e análise antivírus em tempo real. Se não estiver definida memória suficiente, o SO e o SQL serão apresentados em disco. Isto pode fazer com que a E/S do disco aumente, diminua ainda mais o desempenho e crie um efeito de ondulação onde se torna perceptível no Operations Manager.

Recomendamos que especifique, pelo menos, 4 GB de RAM para memória mínima do servidor. Isto deve ser feito para cada nó SQL que aloja uma das bases de dados do Operations Manager (operacional, armazém de dados, ACS).

Para a memória máxima do servidor, recomendamos que 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 RAM de 8 GB instalada (acima de 16 GB de RAM)

Depois de definir estes valores, monitorize o contador Memory\Available MBytes no Windows para determinar se pode aumentar a memória disponível para SQL Server. O Windows sinaliza que a memória física disponível está a ficar fraca a 96 MB, pelo que, idealmente, o contador não deve ser executado abaixo de cerca de 200 a 300 MB, para garantir que tem uma memória intermédia. Para servidores com RAM de 256 GB ou superior, é provável que queira garantir que não é executado com menos de 1 GB.

Tenha em atenção que estes cálculos partem do princípio de que pretende que SQL Server possa utilizar toda a memória disponível, a menos que os modifique para ter em conta outras aplicações. Considere os requisitos de memória específicos para o SO, outras aplicações, a pilha de threads 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 pode encontrar o valor para threads de trabalho máximos na coluna max_worker_count de sys.dm_os_sys_info.

Estas considerações também se aplicam aos requisitos de memória para SQL Server executar numa máquina virtual. Uma vez que SQL Server foi concebido para colocar dados em cache no conjunto de memória intermédia e, normalmente, utilizará 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 a uma instância de SQL Server, irá eventualmente chegar a um ponto em que a atribuição de memória mais baixa é trocada por um acesso de E/S de disco mais elevado.

Para configurar SQL Server memória num ambiente que tenha sido sobreaprovisionado, comece por monitorizar o ambiente e as métricas de desempenho atuais, incluindo a esperança de vida da página do Gestor de Memória Intermédia SQL Server e as leituras/seg de página e os valores de leitura/seg do disco do Disco Físico. Se o ambiente tiver memória em excesso, a esperança de vida na página aumentará um valor de um segundo sem qualquer diminuição na carga de trabalho, devido à colocação em cache; O valor de leitura/seg da página do Gestor de Memória Intermédia SQL Server será baixo após o aumento da cache e o disco do Disco Físico também permanecerá baixo.

Assim que compreender a linha de base do ambiente, pode reduzir a memória máxima do servidor em 1 GB e, em seguida, ver como isso afeta os contadores de desempenho (depois de qualquer cache inicial diminuir). Se as métricas se mantiverem aceitáveis, reduza em mais 1 GB e, em seguida, monitorize novamente, repetindo conforme pretendido até determinar uma configuração ideal.

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

Otimizar TempDB

O tamanho e a localização física da base de dados tempdb podem afetar o desempenho do Operations Manager. Por exemplo, se o tamanho definido para tempdb for demasiado pequeno, parte da carga de processamento do sistema pode ser aumentada com o aumento automático de tempdb para o tamanho necessário ao suporte da carga de trabalho sempre que reiniciar a instância do SQL Server. Para obter o desempenho ótimo de tempdb, recomenda-se a seguinte configuração de tempdb num ambiente de produção:

• Defina o modelo de recuperação de tempdb como SIMPLE. Este modelo recupera automaticamente espaço de registo para limitar os requisitos de espaço.
• Pré-atribua espaço a todos os ficheiros tempdb definindo o tamanho do ficheiro para um valor suficientemente grande para acomodar a carga de trabalho típica no ambiente. Impede que a tempdb se expanda com demasiada frequência, o que pode afetar o desempenho. A base de dados tempdb pode ser definida com aumento automático, mas tal deverá ser utilizado para aumentar o espaço em disco para exceções não planeadas.
• Crie tantos ficheiros quanto necessários para maximizar a largura de banda do disco. A utilização de vários ficheiros reduz a contenção do armazenamento tempdb e gera uma escalabilidade melhorada. No entanto, não crie demasiados ficheiros, pois pode reduzir o desempenho e aumentar a sobrecarga de gestão. Como orientação geral, crie um ficheiro de dados para cada processador lógico no servidor (representando qualquer definição de máscara de afinidade) e, em seguida, ajuste o número de ficheiros para cima ou para baixo conforme necessário. Regra geral, se o número de processadores lógicos for menor ou igual a 8, utilize o mesmo número de ficheiros de dados. Se o número de processadores lógicos for superior a 8, utilize oito ficheiros de dados e, em seguida, se a contenção continuar, aumente o número de ficheiros de dados em múltiplos de 4 (até ao número de processadores lógicos) até que a contenção seja reduzida para níveis aceitáveis ou faça alterações à carga de trabalho/código. Se a contenção não for reduzida, poderá ter de aumentar mais o número de ficheiros de dados.
• Faça com que cada ficheiro de dados seja do mesmo tamanho, o que permite um desempenho ideal de preenchimento proporcional. O dimensionamento igual de ficheiros de dados é crítico uma vez que o algoritmo de preenchimento proporcional se baseia no tamanho dos ficheiros. Se os ficheiros de dados forem criados com tamanhos desiguais, o algoritmo de preenchimento proporcional tenta utilizar o ficheiro maior para alocações GAM em vez distribuir as alocações entre todos os ficheiros, tornando obsoleta a criação de vários ficheiros de dados.
• Coloque a base de dados tempdb num subsistema de E/S rápido com unidades de estado sólido para obter o melhor desempenho. Utilize a repartição de disco se existirem muitos discos ligados diretamente.
• Coloque a base de dados tempdb em discos diferentes dos utilizados pelas bases de dados do utilizador.

Para configurar tempdb, pode executar a seguinte consulta ou modificar as 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 detetar a contenção de 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 de Mapa de Alocação Global Partilhada). Consoante o grau de contenção, o SQL Server poderá deixar de reagir durante curtos períodos de tempo. Outra alternativa é examinar as Vistas Gestão Dinâmica [sys.dm_exec_request ou sys.dm_os_waiting_tasks]. Os resultados mostrarão que estes pedidos ou tarefas estão à espera de recursos tempdb e têm valores semelhantes aos realçados anteriormente quando executa a consulta sys.sysprocesses .

Se as recomendações anteriores não reduzirem significativamente a contenção da alocação e a contenção estiver nas páginas SGAM, implemente o sinalizador de rastreio -T1118 nos parâmetros de Arranque para SQL Server para que o sinalizador de rastreio permaneça em vigor mesmo depois de SQL Server ser reciclado. Neste sinalizador de rastreio, o SQL Server aloca extensões completas a cada objeto de base de dados, eliminando assim a contenção nas páginas SGAM.

Nota

Este sinalizador de rastreio afeta todas as bases de dados na instância do SQL Server.

Grau máximo de paralelismo

A configuração predefinida do SQL Server para implementações de pequena e média dimensão do Operations Manager é adequada para a maioria das necessidades. No entanto, quando a carga de trabalho do grupo de gestão aumenta para um cenário de classe empresarial (normalmente, mais de 2000 sistemas geridos por agentes e uma configuração de monitorização avançada, que inclui monitorização ao nível do serviço com transações sintéticas avançadas, monitorização de dispositivos de rede, entre plataformas, etc.) é necessário otimizar a configuração de SQL Server descritos nesta secção do documento. Uma opção de configuração que não foi abordada na documentação de orientação anterior é MAXDOP.

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

Quando o SQL Server é executado num computador com mais de um microprocessador ou CPU, deteta o melhor grau de paralelismo, ou seja, o número de processadores empregues para executarem uma instrução única para cada execução do plano paralelo. Por predefinição, o valor desta opção é 0 para que o SQL Server determine o grau máximo de paralelismo.

Os procedimentos armazenados e as consultas predefinidas no Operations Manager, uma vez que se relacionam com a base de dados operacional, de armazém de dados e até de auditoria, não incluem a opção MAXDOP, uma vez que não existe nenhuma forma durante a instalação de consultar dinamicamente quantos processadores são apresentados ao sistema operativo, nem tenta codificar o valor para esta definição, o que pode ter consequências negativas quando a consulta é executada.

Nota

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

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

  Nota

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