Partilhar via

MSSQLSERVER_35267

  • Artigo

Aplica-se a: SQL Server

Detalhes

Atributo Valor
Nome do produto SQL Server
ID do evento 35267
Origem do Evento MSSQLSERVER
Componente SQLEngine
Nome simbólico HADR_DISCONNECTED_DB
Texto da mensagem Conexão de Grupos de Disponibilidade AlwaysOn com o banco de dados %S_MSG encerrada para %S_MSG banco de dados '%.*ls' na réplica de disponibilidade '%.*ls' com ID de Réplica: {%.8x-%.4x-%.4x-%.2x%.2x-%.2x%.2x%.2x%.2x%.2x%.2x}. Essa mensagem é apenas informativa. Não é necessária nenhuma ação do usuário.

Explicação

Essa mensagem ocorre quando uma réplica do grupo de disponibilidade perde sua conexão com as réplicas remotas no ponto de extremidade de espelhamento de banco de dados. Aqui estão exemplos de como você pode ver esse erro:

Always On Availability Groups connection with secondary database terminated for primary database 'ContosoDb' on the availability replica 'PRODSQL' with Replica ID: {xxxxxxxx-xxxx-xxxx-xxxxx-xxxxxxxxxxxx}. This is an informational message only. No user action is required.

Always On Availability Groups connection with primary database terminated for secondary database 'ContosoDb' on the availability replica 'PRODSQL' with Replica ID: {xxxxxxxx-xxxx-xxxx-xxxxx-xxxxxxxxxxxx}. This is an informational message only. No user action is required.

Como você pode ver, o erro pode aparecer na réplica primária, indicando que ela perdeu a comunicação com a réplica secundária ou vice-versa.

O erro 35267 geralmente é intermitente e pode se resolver no momento em que a causa subjacente se resolve. Por exemplo, um problema de rede intermitente pode se resolver sozinho e a conexão pode se restabelecer.

Em muitos casos, o nó remoto ao qual o nó local está tentando se conectar pode nem estar ciente da falha de conexão. Portanto, você pode ver esse erro gerado apenas em uma das réplicas, não em ambas.

Às vezes, o erro 35267 pode ocorrer junto com o erro 35206, que é gerado quando um período significativo decorreu sem uma conexão bem-sucedida (por exemplo, mais de 10 segundos).

A connection timeout has occurred on a previously established connection to availability replica 'PRODSQL' with id [xxxxxxxx-xxxx-xxxx-xxxxx-xxxxxxxxxxxx].  Either a networking or a firewall issue exists or the availability replica has transitioned to the resolving role.

Always On Availability Groups connection with primary database terminated for secondary database 'ContosoHRDb' on the availability replica 'PRODSQL' with Replica ID: {xxxxxxxx-xxxx-xxxx-xxxxx-xxxxxxxxxxxx}. This is an informational message only. No user action is required.
Always On Availability Groups connection with primary database terminated for secondary database 'ContosoFinDb' on the availability replica 'PRODSQL' with Replica ID: {xxxxxxxx-xxxx-xxxx-xxxxx-xxxxxxxxxxxx}. This is an informational message only. No user action is required.
Always On Availability Groups connection with primary database terminated for secondary database 'ContosoMktngDb' on the availability replica 'PRODSQL' with Replica ID: {xxxxxxxx-xxxx-xxxx-xxxxx-xxxxxxxxxxxx}. This is an informational message only. No user action is required.

O encerramento da conexão do AG com a réplica remota pode levar a vários problemas de réplica local. Por exemplo, se o AG usar o modo SYNCHRONOUS e a conexão for perdida, a réplica local poderá acabar aguardando a confirmação do remoto. Como resultado, o log de transações não é truncado e o log de transações fica sem espaço (erro MSSQLSERVER_9002) e depois fica indisponível (erro MSSQLSERVER_9001). Aqui está um exemplo de grupo de erros em que isso ocorreu. O motivo para o log de transações estar cheio é 'AVAILABILITY_REPLICA', o que significa que essa réplica está aguardando que a remota reconheça seus registros de log aplicados.

Error: 9002, Severity: 17, State: 9.
The transaction log for database 'ContosoAnalyticsDb' is full due to 'AVAILABILITY_REPLICA'.
Error: 3314, Severity: 21, State: 3.
During undoing of a logged operation in database 'ContosoAnalyticsDb' (page (1:32573799) if any), an error occurred at log record ID (7672713:36228:159). Typically, the specific failure is logged previously as an error in the operating system error log. Restore the database or file from a backup, or repair the database.
State information for database 'ContosoAnalyticsDb' - Hardened Lsn: '(7672713:38265:1)'    Commit LSN: '(7672712:1683087:46)'    Commit Time: 'JuN  10 2022  5:51AM'

Always On Availability Groups connection with secondary database terminated for primary database 'ContosoAnalyticsDb' on the availability replica 'SQL2019DB' with Replica ID: {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}. This is an informational message only. No user action is required.

Database ContosoAnalyticsDb was shutdown due to error 3314 in routine 'XdesRMReadWrite::RollbackToLsn'. Restart for non-snapshot databases will be attempted after all connections to the database are aborted.

Error during rollback. shutting down database (location: 1).
Error: 9001, Severity: 21, State: 5.
The log for database 'ContosoAnalyticsDb' is not available. Check the operating system error log for related error messages. Resolve any errors and restart the database.

Recovery of database 'ContosoAnalyticsDb' (6) is 0% complete (approximately 60177 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required.

Causa

  • Podem existir problemas de conexão de rede entre as réplicas primária e secundária
  • Problemas do SQL Server ou do sistema operacional nas réplicas primárias ou secundárias que fazem com que os threads não possam ser executados. Alguns exemplos:
    • Problemas do Agendador do SO SQL (agendadores sem rendimento ou com deadlock)
    • Pouca memória na máquina, levando ao corte do conjunto de trabalho de todos os processos no sistema, incluindo o SQL Server
    • Problemas no sistema operacional que fazem com que os processos parem de responder
  • Problemas de E/S lentos que causam longas esperas intermitentes na réplica primária ou secundária

Ação do usuário

As informações abaixo descrevem os cenários mais comuns, mas não são uma lista exaustiva de etapas de solução de problemas. As razões específicas para a ocorrência desse problema podem incluir uma longa lista de possibilidades.

Problemas de conexão

Para verificar se há problemas de conexão do SQL Server em que o erro é gerado para o SQL Server remoto, você pode considerar as seguintes etapas:

Etapa 1. Verifique se o ponto de extremidade no SQL Server remoto está ativo

Execute a consulta a seguir para descobrir o ponto de extremidade.

SELECT
 tep.name as EndPointName,
 sp.name As CreatedBy,
 tep.type_desc,
 tep.state_desc,
 tep.port
FROM
 sys.tcp_endpoints tep
INNER JOIN sys.server_principals sp ON tep.principal_id = sp.principal_id
WHERE tep.type = 4

Etapa 2. Testar a conectividade com o ponto de extremidade remoto

Use Test-NetConnection para validar a conectividade. Se o Endpoint estiver escutando e a conexão for bem-sucedida, procure o TcpTestSucceeded : True. Substitua ServerName ou IP_Address pelo SQL Server remoto e o número da porta pelo do ponto de extremidade de espelhamento de banco de dados.

Test-NetConnection -ComputerName <ServerName> -Port <port_number>
Test-NetConnection -ComputerName <IP_address> -Port <port_number>

Etapa 3. Coletar um rastreamento de rede

Erros de rede intermitentes geralmente são difíceis de rastrear, a menos que você capture um rastreamento de rede, que mostra redefinições de rede (pacotes descartados) ou problemas semelhantes. Para obter mais informações, consulte 0300 Problema de rede intermitente ou periódico

Problemas do agendador do SQL Server

Se os threads de trabalho do SQL Server estiverem enfrentando problemas do agendador por vários motivos, os threads que atendem às solicitações de entrada poderão parar de responder temporariamente enquanto durarem os problemas do agendador.

Etapa 4. Verificar se há problemas com o agendador no SQL Server

Um problema típico do agendador sem rendimento é registrado no log de erros do SQL Server após 70 segundos de estado sem rendimento. No entanto, o SQL Server verifica o estado dos agendadores com mais frequência do que isso e relata esses estados intermediários não produtivos em eventos estendidos. Se você descobrir problemas do agendador no nó remoto que correspondem à hora do erro 35267, concentre-se em resolvê-los primeiro. Veja como você pode verificar se há ocorrências de curta duração de problemas do agendador que não atingem o limite de 70 segundos, mas ocorrem por, digamos, 10 ou 20 segundos.

Usar o arquivo de evento estendido da Integridade do Sistema

  1. Localize o arquivo de evento estendido de Integridade do Sistema a partir do momento do evento.
  2. Clique duas vezes no system_health_0_xxxxxxxxxxxxxxxxxx.xel para abri-lo no SQL Server Management Studio (SSMS). Como alternativa, você pode usar sys.fn_xe_file_target_read_file para exibir ou importar o arquivo como uma tabela para facilitar a filtragem.
  3. Pesquise todas as ocorrências de scheduler_monitor_non_yielding_ring_buffer_recorded evento. Se você encontrar algum, isso é uma indicação de que o SQL Server detectou eventos do agendador sem rendimento e os está registrando. Esses eventos são registrados antes dos despejos de memória reais do agendador não yiedling e das entradas do log de erros, que ocorrem após 60 a 70 segundos de estado não produtivo. Em outras palavras, você pode usar o scheduler_monitor_non_yielding_ring_buffer_recorded para detectar problemas de agendador de curta duração que não são produtivos que não são registrados no log de erros, mas ainda ocorreram. Essas podem ser razões para a falta de conectividade intermitente ou de curta duração entre os nós AG.

Usar o log de diagnóstico

  1. Localize o Log de Diagnóstico no diretório \Log a partir do momento do evento (aplicável a sistemas de Cluster do Windows). O formato do nome do arquivo é assim SERVERNAME_MSSQLSERVER_SQLDIAG_x_xxxxxxxxxxxxxxxxxx.xel.

  2. Clique duas vezes para abrir o arquivo no SSMS (SQL Server Management Studio). Como alternativa, você pode usar sys.fn_xe_file_target_read_file para exibir ou importar o arquivo como uma tabela para facilitar a filtragem.

  3. Depois de aberto no SSMS, localize uma instância de component_health_result evento e clique com o botão direito do mouse no seguinte e escolha Mostrar Coluna na Tabela: componente, state_desc

  4. Em seguida, clique com o botão direito do mouse em cada coluna e escolha Filtrar por este valor para aplicar os seguintes filtros:

    • o component_health_result evento para ser o único exibido
    • component field='processamento de consulta'
    • <> state_desc 'limpo'.

  5. Em seguida, clique duas vezes na coluna de dados para abrir os dados XML e o valor de aparência trackingNonYieldingScheduler na primeira linha.

  6. Se o valor for diferente disso 0x0 , significa que o SQL Server detectou sinais iniciais de um agendador não produtivo e o relatou aqui.

    Aqui está um exemplo em que o SQL Server detectou uma condição de não rendimento com um endereço de agendador "0x4fedb840040":

     <queryProcessing maxWorkers="9600" workersCreated="2574" workersIdle="1883" tasksCompletedWithinInterval="175591" pendingTasks="3" ... trackingNonYieldingScheduler="0x4fedb840040">

Sistema operacional com pouca memória

Pode haver vários problemas no nível do sistema operacional (SO) que desencadeiam essa falta intermitente de resposta. Um comum é a memória baixa. No nó do AG remoto em que o problema suspeito está ocorrendo, execute as seguintes etapas:

Etapa 5. Verifique se há problemas de memória do sistema operacional que levam à paginação de memória do SQL Server para o disco

  1. Verifique o log de eventos do sistema Windows em busca de erros que indiquem pouca memória física ou virtual.

  2. Verifique se há o erro 17890 no log de erros do SQL Server ou no log de eventos do aplicativo do Windows para ver se a memória insuficiente no computador está levando ao corte do conjunto de trabalho de todos os processos no sistema, incluindo o SQL Server. O erro é semelhante a este:

    A significant part of SQL Server process memory has been paged out. This may result in a performance degradation. Duration: 0 seconds. Working set (KB): 3383250, committed (KB):    9112480, memory utilization: 37%.

    Para obter etapas detalhadas de disparo em T, consulte MSSQLSERVER_17890

Etapa 6. Configure a memória máxima do servidor e as páginas de bloqueio na memória corretamente

  1. Configure a Memória Máxima do Servidor do SQL Server para um valor que permita que o uso do sistema operacional e de outros processos tenha memória disponível. Um valor recomendado para definir a memória máxima do servidor do SQL Server como não mais do que 75% do tamanho da RAM no sistema. Para obter mais informações, consulte Opções de configuração de memória do servidor
  2. Habilite a opção Bloquear páginas na memória (Windows) para impedir a paginação massiva do cache de buffer do SQL Server.

E/S de disco lenta

Em alguns casos, a E/S excessivamente lenta pode fazer com que os threads do SQL Server parem de responder temporariamente, o que pode fazer com que a outra réplica do AG se desconecte.

Etapa 7. Resolva quaisquer problemas de E/S lenta

Se você encontrar erros que indiquem E/S lenta, solucione os motivos subjacentes para E/S lenta.

SQL Server has encountered 2 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [F:\TLOG\ContosoDb.ldf] in database id 9.  The OS file handle is 0x00000000000003BC.  The offset of the latest long I/O is: 0x0000003d26f600
SQL Server has encountered 2 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [F:\DATA\t38data\ContosoDb2.mdf] in database id 7.  The OS file handle is 0x000000000000118C.  The offset of the latest long I/O is: 0x00000000012000
SQL Server has encountered 1 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [F:\DATA\t38data\ContosoDb.mdf] in database id 9.  The OS file handle is 0x000000000000134C.  The offset of the latest long I/O is: 0x00000000012000

Always On Availability Groups connection with primary database terminated for secondary database 'ContosoDb2' on the availability replica 'SQLNODE1\INSTANCE19' with Replica ID: {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}. This is an informational message only. No user action is required.
Always On Availability Groups connection with primary database terminated for secondary database 'ContosoDb' on the availability replica 'SQLNODE1\INSTANCE19' with Replica ID: {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}. This is an informational message only. No user action is required.
  • Atualize todos os drivers de dispositivo e firmware ou execute outros diagnósticos associados ao seu subsistema de E/S
  • O acesso ao disco pode ser retardado por drivers de filtro, por exemplo, um programa antivírus. Para aumentar a velocidade de acesso, exclua os arquivos de dados do SQL Server das verificações de vírus ativas
  • Trabalhe com o fornecedor de hardware e o administrador do sistema para diagnosticar e resolver a causa da E/S lenta

Para obter instruções detalhadas, consulte Solucionar problemas de desempenho lento do SQL Server causado por problemas de E/S e MSSQLSERVER_833.