Solucionar problemas Always On failover de Grupos de Disponibilidade

Observação

Para automatizar a análise manual descrita neste artigo, consulte Usar AGDiag para diagnosticar eventos de integridade do grupo de disponibilidade.

Este artigo fornece etapas de solução de problemas para ajudá-lo a determinar por que seu grupo de disponibilidade falhou.

Sintomas e efeitos de Always On problema de saúde ou failover

Always On implementa um monitoramento robusto de integridade por meio de diferentes mecanismos para garantir a integridade da instância do Microsoft SQL Server que hospeda o réplica primário, o cluster subjacente e a integridade do sistema. A carga de trabalho de produção é interrompida momentaneamente quando um cluster do Windows ou Always On problema de integridade é identificado.

Quando uma condição de integridade é detectada, a sequência de eventos a seguir geralmente ocorre. Ao longo dessa solução de problemas, os eventos de integridade são mencionados em referência aos seguintes eventos:

• Réplicas de grupo de disponibilidade e bancos de dados fazem a transição da função primária para a resolução da função.

• Os bancos de dados de grupo de disponibilidade fazem a transição para offline e não estão mais acessíveis.

• O Cluster do Windows marca o recurso clusterizado do grupo de disponibilidade como falha.

• O Cluster do Windows tenta colocar a função do grupo de disponibilidade novamente online (no réplica de parceiro de failover original ou automático).

• A função de grupo de disponibilidade estará online com êxito se for detectada como saudável por Always On e pelo monitoramento de integridade do Cluster do Windows.

Se for bem-sucedido, as réplicas e bancos de dados do grupo de disponibilidade serão transferidos para a função primária e os bancos de dados do grupo de disponibilidade ficarão online e estarão acessíveis pelo aplicativo.

Os aplicativos não podem acessar os bancos de dados do grupo de disponibilidade

Quando uma condição de integridade é detectada, o grupo de disponibilidade réplica e bancos de dados fazem a transição para a função Resolvendo e os bancos de dados do grupo de disponibilidade são retirados offline. Depois que o réplica estiver online na função primária (no servidor de réplica original ou no servidor réplica do parceiro de failover), o réplica e bancos de dados novamente fazem a transição para online. Enquanto as réplica e bancos de dados estão resolvendo e estão offline, todos os aplicativos que tentam acessar esses bancos de dados de grupo de disponibilidade falham e geram uma mensagem "Erro 983": Unable to access availability database.... Esse erro também será registrado no log de erros do Microsoft SQL Server se SQL Server estiver configurado para registrar tentativas de logon com falha:

Logon Error: 983, Severity: 14, State: 1.

Logon Unable to access availability database '<databasename>' because the database replica is not in the PRIMARY or SECONDARY role. Connections to an availability database is permitted only when the database replica is in the PRIMARY or SECONDARY role. Try the operation again later.

O período durante o qual o grupo de disponibilidade está na função Resolvendo antes de voltar a funcionar na função primária normalmente dura apenas alguns segundos ou até menos de um segundo.

Identificar e diagnosticar Always On eventos de integridade ou failover do grupo de disponibilidade

1. Identificar Always On tendências de integridade

Você pode investigar uma única Always On evento de integridade ou pode haver uma tendência recente ou contínua de problemas de integridade que estão interrompendo intermitentemente a produção. As perguntas a seguir podem ajudá-lo a reduzir e correlacionar as alterações recentes em seu ambiente de produção que podem estar relacionadas a esses problemas de integridade:

• Quando a tendência de eventos de integridade de Always On ou cluster começou?
• Os eventos de integridade ocorrem em um determinado dia?
• Os eventos de integridade ocorrem em uma determinada hora do dia?
• Os eventos de integridade ocorrem em um determinado dia ou semana do mês?

Se você detectar uma tendência, marcar a manutenção agendada no sistema (o sistema host em um ambiente virtual), lotes ETL e outros trabalhos que possam se correlacionar com esses eventos de integridade. Se o sistema for uma máquina virtual, investigue o sistema host para obter alterações que possivelmente foram introduzidas no momento das interrupções.

Considere cargas de trabalho de produção ad hoc ocupadas que podem se correlacionar com a hora dos problemas de integridade (por exemplo, quando os usuários fazem logon pela primeira vez no sistema ou depois que os usuários retornam do almoço).

Observação

Este é um bom momento para considerar um plano para coletar dados de desempenho ao longo da semana e do mês. Para entender melhor quando o sistema está mais movimentado, você pode medir contadores de monitor de desempenho do Windows, como Processor Information::% Processor Time, Memory::Available MBytese MSSQLServer:SQL Statistics::Batch Requests/sec.

2. Examine o log de cluster

O log do Cluster do Windows é o log mais abrangente a ser usado para identificar o tipo de evento de integridade de Always On ou cluster e também a condição de integridade detectada que causou o evento. Para gerar e abrir o log de cluster, siga estas etapas:

Use Windows PowerShell para gerar o log do Cluster do Windows no nó de cluster que hospeda o réplica primário no momento do evento de integridade. Por exemplo, execute o seguinte cmdlet em uma janela do PowerShell elevada usando 'sql19agn1' como o nome do servidor baseado em SQL Server:

get-clusterlog -Node sql19agn1 -UseLocalTime     

Observação

Por padrão, o arquivo de log é criado em %WINDIR%\cluster\reports.

3. Localize o evento de integridade no log de cluster

Always On usa vários mecanismos de monitoramento de integridade para monitorar a integridade do grupo de disponibilidade. Além de um evento de integridade do Cluster do Windows (no qual o Cluster do Windows detecta um problema de integridade entre os nós de cluster), Always On tem quatro tipos diferentes de verificações de integridade:

• O serviço SQL Server não está em execução
• Um tempo limite de concessão SQL Server
• Uma SQL Server marcar tempo limite de integridade
• Um SQL Server problema de integridade interna

Você pode localizar qualquer um desses Always On eventos de integridade específicos pesquisando o log de cluster para a cadeia de caracteres, [hadrag] Resource Alive result 0. Essa cadeia de caracteres é salva no log de cluster quando qualquer um desses eventos é detectado. Por exemplo:

00001334.00002ef4::2019/06/24-18:24:36.153 ERR [RES] SQL Server Availability Group : [hadrag] Resource Alive result 0.

Você pode usar uma ferramenta para encontrar todos os eventos de integridade no log de cluster para que você possa gerar um relatório de resumo de Always On problemas de integridade. Isso pode ser útil para identificar tendências cronológicas e determinar se um determinado tipo de Always On condição de saúde é recorrente. A captura de tela a seguir mostra como usar um editor de texto (NotePad++, nesse caso) para localizar todas as linhas no log de cluster que contêm a [hadrag] Resource Alive result 0 cadeia de caracteres:

Determinar o tipo de problema de integridade que desencadeou o failover

Para determinar o tipo de problemas de integridade que você encontra no log de cluster do réplica primário, compare-os com os problemas descritos nas próximas seções.

Evento de integridade do cluster

O Cluster do Microsoft Windows monitora a integridade dos servidores membros no cluster. Se um problema de integridade for detectado, um servidor membro do cluster poderá ser removido do cluster. Além disso, os recursos de cluster (incluindo a função de grupo de disponibilidade hospedada no servidor membro do cluster removido) serão movidos para o parceiro de failover do grupo de disponibilidade réplica se ele estiver configurado para failover automático.

Sintomas de eventos de integridade do cluster

Aqui está um exemplo de um evento de integridade de cluster no log de cluster. Para encontrá-lo, você pode pesquisar Lost quorum ou Cluster service has terminated porque pode estar presente durante a alteração ou failover da função do grupo de disponibilidade.

00000fe4.00001628::2022/12/15-14:26:02.654 WARN [QUORUM] Node 1: Lost quorum (1)
00000fe4.00001628::2022/12/15-14:26:02.654 WARN [QUORUM] Node 1: goingAway: 0, core.IsServiceShutdown: 0
00000fe4.00001628::2022/12/15-14:26:02.654 WARN lost quorum (status = 5925)
00000fe4.00001628::2022/12/15-14:26:02.654 INFO [NETFT] Cluster Service preterminate succeeded.
00000fe4.00001628::2022/12/15-14:26:02.654 WARN lost quorum (status = 5925), executing OnStop
00000fe4.00001628::2022/12/15-14:26:02.654 INFO [DM]: Shutting down, so unloading the cluster database.
00000fe4.00001628::2022/12/15-14:26:02.654 INFO [DM] Shutting down, so unloading the cluster database (waitForLock: false).
000019cc.000019d0::2022/12/15-14:26:02.654 WARN [RHS] Cluster service has terminated. Cluster.Service.Running.Event got signaled.

Outra maneira de identificar esse evento é pesquisar o log de eventos do sistema Windows:

Critical SQL19AGN1.CSSSQL 1135 Microsoft-Windows-FailoverClusterin Node Mgr NT AUTHORITY\SYSTEM Cluster node 'SQL19AGN2' was removed from the active failover cluster membership. The Cluster service on this node may have stopped. This could also be due to the node having lost communication with other active nodes in the failover cluster. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapters on this node. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.
Critical SQL19AGN1.CSSSQL 1177 Microsoft-Windows-FailoverClusterin Quorum Manager NT AUTHORITY\SYSTEM The Cluster service is shutting down because quorum was lost. This could be due to the loss of network connectivity between some or all nodes in the cluster, or a failover of the witness disk. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapter. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.

Diagnosticar um evento de integridade de cluster

Os erros no log de eventos do Windows (Eventos 1135 e 1177) sugerem que a conectividade de rede é uma causa do evento. Essa é a razão mais comum pela qual um problema de integridade de cluster é detectado. O exemplo a seguir mostra que outros servidores membros do cluster não conseguiram se comunicar com esse servidor que hospeda o grupo de disponibilidade principal réplica e que esse problema desencadeou a remoção do nó de cluster do cluster:

00000fe4.00001edc::2022/12/14-22:44:36.870 INFO [NODE] Node 1: New join with n3: stage: 'Attempt Initial Connection' status (10060) reason: 'Failed to connect to remote endpoint <endpoint address>'
00000fe4.00001620::2022/12/15-14:26:02.050 INFO [IM] got event: Remote endpoint <endpoint address> unreachable from <endpoint address>
00000fe4.00001620::2022/12/15-14:26:02.050 WARN [NDP] All routes for route (virtual) local <local address> to remote <remote address> are down
00000fe4.0000179c::2022/12/15-14:26:02.053 WARN [NODE] Node 1: Connection to Node 2 is broken. Reason GracefulClose(1226)' because of 'channel to remote endpoint <endpoint address> is closed'

Você pode pesquisar no log de cluster para obter evidências de uma falha de conexão com o nó. No local no log de cluster em que você encontrou Lost quorum, pesquise para trás em busca de cadeias de caracteres como Failed to connect to remote endpoint, unreachablee is broken.

Resolver um evento de integridade de cluster

Verifique se o monitoramento de integridade do cluster é apropriado para o ambiente do host. Para obter mais informações sobre SQL Server Always On grupos de disponibilidade hospedados no Microsoft Azure, confira Visão geral do Cluster de Failover do Windows Server – SQL Server em VMs do Azure.

Se for necessário, considere entrar em contato com o suporte de alta disponibilidade do Microsoft Windows para abrir um incidente de suporte.

SQL Server serviço caiu: um evento de integridade Always On

Always On monitoramento de integridade pode detectar se o serviço de SQL Server que hospeda a réplica primária do grupo de disponibilidade não está mais em execução.

Sintomas de desligamento do serviço SQL Server

Aqui está um exemplo do relatório de log de cluster para a função de grupo de disponibilidade 'ag' que indica uma falha porque QueryServiceStatusEx retornou uma ID 0do processo :

00001898.0000185c::2023/02/27-13:27:41.121 ERR [RES] SQL Server Availability Group <ag>: [hadrag] QueryServiceStatusEx returned a process id 0
00001898.0000185c::2023/02/27-13:27:41.121 ERR [RES] SQL Server Availability Group <ag>: [hadrag] SQL server service is not alive
00001898.0000185c::2023/02/27-13:27:41.121 ERR [RES] SQL Server Availability Group <ag>: [hadrag] Resource Alive result 0.
00001898.0000185c::2023/02/27-13:27:41.121 WARN [RHS] Resource ag IsAlive has indicated failure.

Diagnosticar e resolve eventos de desligamento do Serviço SQL

Verifique o log de eventos do sistema Windows e SQL Server log de erros para obter um desligamento inesperado SQL Server.

Se SQL Server for desligado por um desligamento do sistema ou por um desligamento administrativo, você verá a seguinte entrada no log de erros do SQL Server:

2023-03-10 09:38:46.73 spid9s SQL Server está terminando em resposta a uma solicitação 'stop' do Service Control Manager. Essa é apenas uma mensagem informativa. Não é necessária nenhuma ação do usuário.

O log de eventos do sistema Windows mostraria a seguinte entrada de erro:

Informações 3/10/2023 9:41:06 Am Service Control Manager 7036 None O serviço de SQL Server (MSSQLSERVER) entrou no estado interrompido.

O log de eventos do sistema Windows mostra a seguinte entrada de erro se SQL Server for desligado inesperadamente:

Erro 3/10/2023 8:37:46 Am Service Control Manager 7034 None The SQL Server (MSSQLSERVER) serviço encerrado inesperadamente. Ele fez isso 1 vez.s.

Verifique o final do log de erros SQL Server em busca de pistas. Se o log de erros terminar abruptamente, isso significa que ele foi desligado à força. Por exemplo, se SQL Server foi encerrado usando o Gerenciador de Tarefas, o relatório de erro SQL Server não revelará nenhuma informação sobre problemas internos que possam ter causado o desligamento do processo.

Se um SQL Server problema de integridade interna fez com que SQL Server terminasse inesperadamente, pode haver pistas de uma possível exceção fatal (incluindo um diagnóstico de arquivo de despejo sendo gerado) no final do log de erros do SQL. Examine as pistas e tome as medidas necessárias. Se você encontrar um arquivo de despejo, considere abrir contato com o suporte do Microsoft SQL Server e fornecer o log de erros SQL Server e despejar conteúdo do arquivo para uma investigação mais aprofundada.

Tempo limite de concessão: um evento de integridade Always On

Always On usa um mecanismo de "concessão" para monitorar a integridade do computador no qual o SQL Server está instalado. O tempo limite de concessão padrão é de 20 segundos.

Sintomas de Always On eventos de tempo limite de concessão

Aqui está uma saída de exemplo de um tempo limite de concessão Always On do log de cluster. Você pode pesquisar essas cadeias de caracteres para localizar um tempo limite de concessão no log do cluster.

00001a0c.00001c5c::2023/01/04-15:36:54.762 ERR [RES] SQL Server Availability Group : [hadrag] Availability Group lease is no longer valid 
00001a0c.00001c5c::2023/01/04-15:36:54.762 ERR [RES] SQL Server Availability Group : [hadrag] Resource Alive result 0. 
00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] Lease timeout detected, logging perf counter data collected so far
00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] Date/Time, Processor time(%), Available memory(bytes), Avg disk read(secs), Avg disk write(secs)
00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:35:57.0, 98.068572, 509227008.000000, 0.000395, 0.000350 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:7.0, 12.314941, 451817472.000000, 0.000278, 0.000266 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:17.0, 17.270742, 416096256.000000, 0.000376, 0.000292 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:27.0, 38.399895, 416301056.000000, 0.000446, 0.000304 00001a0c.00001c5c::2023/01/04-15:36:54.762 WARN [RES] SQL Server Availability Group: [hadrag] 1/4/2023 15:36:37.0, 100.000000, 417517568.000000, 0.001292, 0.000666

Para obter mais informações sobre o tempo limite de concessão, consulte a seção Mecanismo de Concessão em Mecânica e diretrizes de concessão, cluster e tempo limite de marcar de integridade para grupos de disponibilidade Always On.

Diagnosticar e resolve Always On eventos de tempo limite de concessão

Há dois problemas main que podem disparar um tempo limite de concessão:

• SQL Server diagnóstico de arquivo de despejo: quando SQL Server detecta determinados eventos de integridade interna, como uma violação de acesso, uma declaração ou um impasse do agendador, ele gera um arquivo de despejo de diagnóstico (.mdmp) na pasta SQL Server \LOG.

• Um problema de desempenho em todo o sistema: um tempo limite de concessão não indica necessariamente um problema de integridade SQL Server. Em vez disso, pode indicar um problema de integridade em todo o sistema que também afeta a integridade do servidor baseado em SQL Server. Para obter etapas mais detalhadas de solução de problemas, consulte MSSQLSERVER_19407.

1. SQL Server diagnóstico de arquivo de despejo

SQL Server pode detectar um problema de integridade interna, como uma violação de acesso, declaração ou agendadores em impasse. Nessa situação, o programa gera um mini arquivo de despejo (.mdmp) na pasta SQL Server \LOG do processo de SQL Server para diagnóstico. O processo SQL Server é congelado por vários segundos enquanto o mini arquivo de despejo é gravado em disco. Durante esse tempo, todos os threads dentro do processo de SQL Server estão em um estado congelado. Isso inclui o thread de concessão monitorado por Always On monitoramento de integridade. Portanto, Always On pode detectar um tempo limite de concessão.

**Dump thread - spid = 0, EC = 0x0000000000000000
***Stack Dump being sent to C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\LOG\SQLDump0001.txt
* *******************************************************************************
*
* BEGIN STACK DUMP:
*   11/02/14 21:21:10 spid 1920
*
* Deadlocked Schedulers
*
* *******************************************************************************
* -------------------------------------------------------------------------------
* Short Stack Dump
Stack Signature for the dump is 0x00000000000002BA
Error: 19407, Severity: 16, State: 1.
The lease between availability group 'ag' and the Windows Server Failover Cluster has expired. A connectivity issue occurred between the instance of SQL Server and the Windows Server Failover Cluster. To determine whether the availability group is failing over correctly, check the corresponding availability group resource in the Windows Server Failover Cluster.

Para resolve esse problema, o diagnóstico do arquivo de despejo deve ser investigado pela causa raiz. Considere entrar em contato com a Microsoft SQL Server suporte para fornecer o log de erros SQL Server e despejar conteúdo do arquivo para uma investigação mais aprofundada.

2. Alto uso da CPU ou outro problema de desempenho do sistema

Um tempo limite de concessão indica um problema de desempenho que afeta todo o sistema, incluindo SQL Server. Para diagnosticar o problema do sistema, Always On integridade diagnóstico relata dados do monitor de desempenho no log do cluster e inclui o evento de tempo limite de concessão. Os dados de desempenho abrangem aproximadamente 50 segundos que antecedem o evento de tempo limite de concessão, relatórios sobre utilização da CPU, memória gratuita e latência de disco.

Aqui está um exemplo dos dados de desempenho relatados que mostram um tempo limite de concessão no log de cluster. Nesta saída de exemplo, alta utilização geral da CPU que pode estar relacionada ao tempo limite de concessão.

00000f90.000015c0::2020/08/07-14:16:41.378 WARN [RES] SQL Server Availability Group: [hadrag] Lease timeout detected, logging perf counter data collected so far
00000f90.000015c0::2020/08/07-14:16:41.382 WARN [RES] SQL Server Availability Group: [hadrag] Date/Time, Processor time(%), Available memory(bytes), Avg disk read(secs), Avg disk write(secs)
00000f90.000015c0::2020/08/07-14:16:41.431 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:20.0, 83.266073, 31700828160.000000, 0.018094, 0.015752
00000f90.000015c0::2020/08/07-14:16:41.431 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:30.0, 93.653224, 31697063936.000000, 0.038590, 0.026897
00000f90.000015c0::2020/08/07-14:16:41.431 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:40.0, 94.270691, 31696265216.000000, 0.166000, 0.038962
00000f90.000015c0::2020/08/07-14:16:41.434 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:15:50.0, 90.272016, 31695409152.000000, 0.215141, 0.106084
00000f90.000015c0::2020/08/07-14:16:41.434 WARN [RES] SQL Server Availability Group: [hadrag] 8/7/2020 14:16:1.0, 99.991336, 31695892480.000000, 0.046983, 0.035440

Se os dados de desempenho mostrarem alta utilização da CPU, uma baixa condição de memória ou alta latência de disco no momento de um tempo limite de concessão, comece a coletar Monitor de Desempenho dados para o dia inteiro no réplica primário para investigar esses sintomas. Ao capturar dados do monitor de desempenho por um período mais longo, você pode identificar melhor os valores de linha de base e de pico para esses recursos e monitorar as alterações nesses recursos quando ocorrer um tempo limite de concessão. Ao coletar esses dados, considere se há determinadas cargas de trabalho agendadas ou ad hoc em SQL Server que se correlacionam com a hora desses problemas de recurso e eventos de integridade.

Você também deve capturar contadores que relatam o mesmo uso de recursos do sistema, incluindo o seguinte:

• Processor Information::% Processor Time
• Memory::Available MBytes
• Logical Disk::Avg. Disk sec/Read
• Logical Disk::Avg. Disk sec/Write
• Logical Disk::Avg. Disk Read Queue Length
• Logical Disk::Avg. Disk Write Queue Length
• MSSQLServer:SQL Statistics::Batch Requests/sec

Tempo limite de marcar de integridade: um evento de integridade Always On

Quando um grupo de disponibilidade réplica faz a transição para a função primária, Always On monitoramento de integridade estabelece uma conexão ODBC local com a instância SQL Server. Embora Always On esteja conectado e monitorando, se SQL Server não responder pela conexão ODBC no período definido para a integridade do grupo de disponibilidade marcar tempo limite (o padrão é de 30 segundos), um evento de marcar tempo limite é disparado. Nessa situação, o grupo de disponibilidade faz a transição da função primária para a função Resolvendo e inicia o failover, se estiver configurado para fazer isso.

Para obter mais informações sobre a integridade marcar tempo limite, consulte a seção "Operação de tempo limite marcar de integridade" em Mecânica e diretrizes de concessão, cluster e tempo limite de marcar de integridade para grupos de disponibilidade Always On.

Aqui está um tempo limite de marcar de integridade Always On conforme relatado no log do cluster:

0000211c.00002d70::2021/02/24-02:50:01.890 WARN [RES] SQL Server Availability Group: [hadrag] Failed to retrieve data column. Return code -1
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, diagnostics heartbeat is lost
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <AG>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <AG>: [hadrag] Resource Alive result 0.
0000211c.00002594::2021/02/24-02:50:02.453 WARN [RHS] Resource AG IsAlive has indicated failure.
00001278.00002ed8::2021/02/24-02:50:02.453 INFO [RCM] HandleMonitorReply: FAILURENOTIFICATION for 'AG', gen(0) result 1/0.

Diagnosticar e resolve Always On evento de tempo limite marcar saúde

A seção a seguir ajuda você a revisar os logs de SQL Server para eventos de "migalhas de pão" que você pode encontrar e que se correlacionam com Always On integridade marcar tempo limite detectados e relatados. Os logs revisados aqui incluem o log de cluster (em que o tempo limite de marcar de integridade é confirmado), os system_health logs de eventos estendidos e SQL Server logs de erro (ambos encontrados na pasta \LOG SQL Server) e no log de eventos do sistema Windows. Use esses e outros logs para procurar eventos correlacionados que possam ajudá-lo a escopo da causa da integridade marcar tempo limite.

1. Verifique se há eventos de agendador não produtivos

O Always On integridade marcar tempo limite é frequentemente causado por eventos "não produtivos" em SQL Server. Quando SQL Server detectar que um thread não rendeu em um agendador, ele informará que ocorreu um evento agendador não produtivo. Se você vir outras tarefas no mesmo agendador que não estão recebendo tempo de CPU, este será o principal sinal de um agendador que não está rendendo. Esse comportamento pode causar uma execução atrasada dessas tarefas e cargas de trabalho de "fome" atribuídas a um determinado agendador de tempo de CPU.

Para marcar para eventos de agendador que não produzem, siga estas etapas:

1. Verifique o SQL Server system_health logs de eventos estendidos para determinar se um evento agendador não produtivo de algum tipo foi relatado na hora do Always On marcar evento de tempo limite. Os eventos não produtivos que você pode encontrar incluem o seguinte:

   • scheduler_monitor_non_yielding_ring_buffer_recorded
   • scheduler_monitor_non_yielding_iocp_ring_buffer_recorded
   • scheduler_monitor_stalled_dispatcher_ring_buffer_recorded
   • scheduler_monitor_non_yielding_rm_ring_buffer_recorded

2. Abra os logs de eventos estendidos SQL Server integridade do sistema no réplica primário até o momento da suspeita de integridade marcar tempo limite.

3. Em SQL Server Management Studio (SSMS), vá para Arquivo > Aberto e selecione Mesclar Arquivos de Eventos Estendidos.

4. Selecione o botão Adicionar.

5. Na caixa de diálogo Abrir Arquivo, navegue até os arquivos no diretório \LOG SQL Server.

6. Pressione e segure Control e selecione os arquivos cujos nomes começam com system_health_xxx.xel.

7. Selecione Abrir>OK.

8. Filtrar os resultados. Clique com o botão direito do mouse em um evento na coluna nome e selecione Filtrar por esse Valor.

   

9. Defina um filtro para classificar linhas nas quais os valores na coluna de nome contêm yield, conforme mostrado na captura de tela a seguir. Isso retorna todos os tipos de eventos não produtivos que podem ter sido registrados nos system_health logs.

   

10. Compare os carimbos de data/hora para ver se havia eventos não produtivos no momento da integridade marcar tempo limite. Veja a integridade marcar tempo limite, conforme relatado no log do cluster:

    0000211c.00002594::2021/02/24-21:50:02.452 ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, diagnostics heartbeat is lost 0000211c.00002594::2021/02/24-21:50:02.452 ERR [RES] SQL Server Availability Group < SQL19AGN1>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel 0000211c.00002594::2021/02/24-21:50:02.452 ERR [RES] SQL Server Availability Group < SQL19AGN1: [hadrag] Resource Alive result 0.
    

    Você pode ver que houve eventos não produtivos que ocorreram no momento da integridade marcar tempo limite.

    

Se eventos não produtivos forem detectados, marcar a causa do evento não produtivo. Considere entrar em contato com a equipe de suporte do SQL Server para investigar os eventos não produtivos.

2. Verifique o log de erros SQL Server

Verifique o log de erros SQL Server para correlacionar eventos no momento da marcar tempo limite de integridade. Esses eventos podem fornecer "migalhas de pão" que sugerem etapas adicionais para escopo da causa raiz da integridade marcar tempo limite.

Por exemplo, a entrada de log a seguir mostra que uma integridade marcar tempo limite ocorreu no log do cluster:

0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, diagnostics heartbeat is lost 
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <SQL19AGN1>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel 
0000211c.00002594::2021/02/24-02:50:02.452 ERR [RES] SQL Server Availability Group <SQL19AGN1>: [hadrag] Resource Alive result 0.

No log de erros SQL Server, em segundos do tempo limite de marcar de integridade, SQL Server relata que detectou latência de E/S grave:

2021-02-23 20:49:54.64 spid12s SQL Server has encountered 1 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\DATA\agdb_log.ldf] in database id 12. The OS file handle is 0x0000000000001594. The offset of the latest long I/O is: 0x000030435b0000. The duration of the long I/O is: 26728 ms.

Examine o log de eventos do sistema para obter possíveis pistas do sistema que possam estar relacionadas à integridade marcar evento de tempo limite. Ao examinar o log de eventos do sistema Windows, você pode encontrar um problema de E/S relatado ao mesmo tempo para a mesma integridade marcar tempo limite:

02/23/2021,08:50:16 PM,Warning,SQL19AGN1.CSSSQL.local.local,<...>,"Reset to device, \Device\<device ID>, was issued."
02/23/2021,08:50:16 PM,Warning,SQL19AGN1.CSSSQL.local.local,<...>,"The IO operation at logical block address <block address> for Disk 6 (PDO name: \Device\<device ID>) was retried."

SQL Server integridade: um evento de integridade Always On

Always On monitora diferentes tipos de eventos de integridade SQL Server. Embora hospede um réplica primário do grupo de disponibilidade, SQL Server executa sp_server_diagnostics continuamente os relatórios sobre SQL Server integridade usando componentes diferentes. Quando algum problema de integridade é detectado, sp_server_diagnostics relata um erro para esse componente específico e envia os resultados de volta para o processo de detecção de integridade Always On. Quando um erro é relatado, a função Grupo de Disponibilidade mostra o estado com falha e o possível failover se o grupo de disponibilidade estiver configurado para fazer isso.

Sintomas de eventos de integridade Always On SQL Server

Aqui está um exemplo de um problema de integridade SQL Server conforme relatado no sp_server_diagnostics log do cluster. SQL Server relata um estado de "erro" no componente do sistema para Always On monitoramento de integridade e o grupo de disponibilidade "contoso-ag" é transferido para um estado com falha.

Observação

Um problema de integridade SQL Server gera um relatório semelhante ao da integridade marcar tempo limite. Ambos os eventos de integridade relatam Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel. A distinção para um evento de integridade SQL Server é que ele relata que o componente SQL Server mudou de "aviso" para "erro".

INFO [RES] SQL Server Availability Group: [hadrag] SQL Server component 'system' health state has been changed from 'warning' to 'error' at 2019-06-20 15:05:52.330
ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, the state of system component is error
ERR [RES] SQL Server Availability Group <contoso-ag>: [hadrag] Availability Group is not healthy with given HealthCheckTimeout and FailureConditionLevel
ERR [RES] SQL Server Availability Group <contoso-ag>: [hadrag] Resource Alive result 0.
ERR [RES] SQL Server Availability Group: [hadrag] Failure detected, the state of system component is error
WARN [RHS] Resource contoso-ag IsAlive has indicated failure.
INFO [RCM] HandleMonitorReply: FAILURENOTIFICATION for 'contoso-ag', gen(0) result 1/0.

Diagnosticar e resolve SQL Server eventos de integridade

O tipo de problema de saúde relatado pelo SQL Server integridade deve ditar a direção da análise de causa raiz.

Por padrão, quando você implanta um grupo de disponibilidade, o FAILURE_CONDITION_LEVEL é definido como três. Isso ativa o monitoramento de alguns, mas não todos os perfis de integridade SQL Server. No nível padrão, Always On dispara um evento de integridade quando SQL Server produz muitos arquivos de despejo, uma violação de acesso à gravação ou um spinlock órfão. A configuração do grupo de disponibilidade até o nível quatro ou cinco expandirá os tipos de SQL Server problemas de integridade monitorados. Para obter mais informações sobre os monitores de Always On de integridade SQL Server, consulte Configurar uma política de failover automático flexível para um grupo de disponibilidade – SQL Server Always On.

Para identificar o Always On problema de integridade específico, siga estas etapas:

1. Abra os logs de eventos estendidos de diagnóstico de cluster SQL Server no réplica primário até o momento da suspeita de SQL Server evento de integridade.

2. No SSMS, vá para Abrir Arquivos> e selecione Mesclar Arquivos de Eventos Estendidos.

3. Selecione Adicionar.

4. Na caixa de diálogo Abrir Arquivo, navegue até os arquivos no diretório \LOG SQL Server.

5. Pressione Controle, selecione os arquivos cujos nomes correspondem <servername>_<instance>_SQLDIAG_xxx.xele selecione Abrir>OK.

   

   Você verá uma nova janela com tabbed no SSMS que inclui os eventos estendidos, conforme mostrado na captura de tela a seguir.

6. Para investigar um problema de integridade SQL Server, localize o component_health_result cujo state_desc valor é error. Aqui está um exemplo de um evento de componente do sistema que relatou um erro de volta ao monitoramento de integridade Always On:

   

7. Clique duas vezes na coluna de dados no painel inferior. Isso abre os dados detalhados do componente em um novo painel de janela SSMS para revisão. Veja como são os dados do componente do sistema:

   

   Observe que os dados 'totalDumprequests=186' indicam que houve muitos eventos de diagnóstico de arquivo de despejo gerados neste SQL Server. Essa é a razão pela qual o componente do sistema relatou um estado de erro. Quando Always On monitoramento de integridade recebe esse estado de erro, ele dispara um evento de integridade do grupo de disponibilidade. Você também pode verificar se nenhuma violação de acesso de gravação ou spinlocks órfãos foram detectados dos dados fornecidos nos dados do componente do sistema.

   Se for necessário, entre em contato com SQL Server suporte para abrir um incidente de suporte para obter mais assistência para encontrar a causa raiz desses problemas internos de SQL Server integridade.