Partage via

MSSQLSERVER_35267

  • Article

S’applique à : SQL Server

Détails

Attribut Valeur
Nom du produit SQL Server
ID de l’événement 35 267
Source de l’événement MSSQLSERVER
Composant SQLEngine
Nom symbolique HADR_DISCONNECTED_DB
Texte du message Connexion aux groupes de disponibilité Always On avec %S_MSG base de données terminée pour %S_MSG base de données '%.*ls' sur le réplica de disponibilité '%.*ls' avec l’ID de réplica : {%.8x-%.4x-%.4x-%.2x%.2x%.2x}. Ce message est fourni uniquement à titre d'information. Aucune action de l'utilisateur n'est requise.

Explication

Ce message se produit lorsqu’un réplica de groupe de disponibilité perd sa connexion aux réplicas distants sur le point de terminaison de mise en miroir de bases de données. Voici des exemples de la façon dont vous pouvez voir cette erreur :

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.

Comme vous pouvez voir que l’erreur peut apparaître sur le réplica principal indiquant qu’elle a perdu la communication avec le réplica secondaire, ou inversement.

L’erreur 35267 est généralement intermittente et peut se résoudre le moment où la cause sous-jacente se résout elle-même. Par exemple, un problème de réseau intermittent peut se résoudre lui-même et la connexion peut se rétablir.

Dans de nombreux cas, le nœud distant auquel le nœud local tente de se connecter risque de ne pas connaître l’échec de connexion. Par conséquent, cette erreur peut s’afficher uniquement sur l’un des réplicas, et non sur les deux.

L’erreur 35267 peut parfois se produire avec l’erreur 35206, qui est déclenchée lorsqu’une période significative s’est écoulée sans connexion réussie (par exemple, plus de 10 secondes).

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.

L’arrêt de la connexion du groupe de disponibilité avec le réplica distant peut entraîner différents problèmes de réplica local. Par exemple, si le groupe de disponibilité utilise le mode SYNCHRONOUS et que la connexion est perdue, le réplica local peut se retrouver en attente de confirmation à partir de la connexion distante. Par conséquent, le journal des transactions n’est pas tronqué et le journal des transactions pour manquer d’espace (MSSQLSERVER_9002 d’erreur) et les versions ultérieures deviennent indisponibles (MSSQLSERVER_9001 d’erreur). Voici un exemple de groupe d’erreurs où cela s’est produit. La raison pour laquelle le journal des transactions est complet est « AVAILABILITY_REPLICA », ce qui signifie que ce réplica attend que le journal distant reconnaisse qu’il s’agit d’enregistrements de journal appliqués.

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.

Cause

  • Les problèmes de connexion réseau peuvent exister entre les réplicas principaux et secondaires
  • Problèmes de système d’exploitation ou sql Server sur les réplicas principaux ou secondaires, ce qui ne permet pas aux threads de s’exécuter. Exemples :
    • Problèmes liés au planificateur de système d’exploitation SQL (planificateurs de non-rendement ou de blocage)
    • Mémoire faible sur l’ordinateur, ce qui entraîne le découpage de jeu de travail de tous les processus sur le système, y compris SQL Server
    • Problèmes de système d’exploitation entraînant l’arrêt de la réponse des processus
  • Problèmes d’E/S lents qui provoquent des attentes longues intermittentes sur le réplica principal ou secondaire

Action utilisateur

Les informations ci-dessous décrivent les scénarios les plus courants, mais ne constituent pas une liste exhaustive des étapes de résolution des problèmes. Les raisons spécifiques de l’occurrence de ce problème peuvent inclure une longue liste de possibilités.

Problèmes de connexion

Pour rechercher les problèmes de connexion à partir de SQL Server où l’erreur est générée vers le serveur SQL Server distant, vous pouvez prendre en compte les étapes suivantes :

Étape 1. Vérifiez que le point de terminaison sur le serveur SQL Server distant est actif

Exécutez la requête suivante pour découvrir le point de terminaison

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

Étape 2. Tester la connectivité au point de terminaison distant

Utilisez Test-NetConnection pour valider la connectivité. Si le point de terminaison écoute et que la connexion réussit, recherchez le TcpTestSucceeded : True. Remplacez ServerName ou IP_Address par SQL Server distant et le numéro de port par celui du point de terminaison de mise en miroir de bases de données.

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

Étape 3. Collecte d'un suivi réseau

Les erreurs réseau intermittentes sont souvent difficiles à suivre, sauf si vous capturez une trace réseau, ce qui montre les réinitialisations réseau (paquets supprimés) ou des problèmes similaires. Pour plus d’informations, consultez 0300 Problème de réseau intermittent ou périodique

Problèmes liés au planificateur SQL Server

Si les threads de travail SQL Server sont en cours d’exécution dans des problèmes de planificateur pour différentes raisons, les threads qui serviceent les demandes entrantes peuvent cesser de répondre temporairement pendant que les problèmes du planificateur sont en dernier.

Étape 4. Rechercher les problèmes de planificateur sur SQL Server

Un problème de planificateur non-rendement classique est enregistré dans le journal des erreurs SQL Server après 70 secondes d’état non-rendement. Toutefois, SQL Server vérifie l’état des planificateurs plus fréquemment que celui-ci et signale ces états intermédiaires sans rendement dans les événements étendus. Si vous découvrez des problèmes de planificateur sur le nœud distant qui correspondent à l’heure de l’erreur 35267, concentrez-vous sur la résolution de ces problèmes en premier. Voici comment vérifier les occurrences à courte durée de vie des problèmes de planificateur qui n’atteignent pas le seuil de 70 secondes, mais se produisent pendant 10 ou 20 secondes.

Utiliser le fichier d’événements étendu System Health

  1. Recherchez le fichier d’événements étendu System Health à partir de l’heure de l’événement.
  2. Double-cliquez sur le system_health_0_xxxxxxxxxxxxxxxxxx.xel bouton pour l’ouvrir dans SQL Server Management Studio (SSMS). Vous pouvez également utiliser sys.fn_xe_file_target_read_file pour afficher ou importer le fichier en tant que table pour faciliter le filtrage.
  3. Recherchez les occurrences d’un événement scheduler_monitor_non_yielding_ring_buffer_recorded . Si vous le trouvez, il s’agit d’une indication indiquant que SQL Server a détecté des événements de planificateurs sans rendement et les enregistre. Ces événements sont enregistrés plus tôt que les vidages réels de mémoire du planificateur non-yiedling et les entrées du journal des erreurs, qui se produisent après 60 à 70 secondes d’état sans rendement. En d’autres termes, vous pouvez utiliser l’scheduler_monitor_non_yielding_ring_buffer_recorded pour détecter les problèmes de planificateurs de courte durée qui ne sont pas consignés dans le journal des erreurs, mais qui se sont toujours produits. Il peut s’agir de raisons de manque de connectivité intermittente ou de courte durée entre les nœuds du groupe de disponibilité.

Utiliser le journal des diagnostics

  1. Recherchez le journal des diagnostics dans le répertoire \Log à partir de l’heure de l’événement (applicable aux systèmes de cluster Windows). Le format de nom de fichier est semblable à ceci SERVERNAME_MSSQLSERVER_SQLDIAG_x_xxxxxxxxxxxxxxxxxx.xel.

  2. Double-cliquez pour ouvrir le fichier dans SQL Server Management Studio (SSMS). Vous pouvez également utiliser sys.fn_xe_file_target_read_file pour afficher ou importer le fichier en tant que table pour faciliter le filtrage.

  3. Une fois ouvert dans SSMS, recherchez une instance d’événement component_health_result et cliquez avec le bouton droit sur ce qui suit, puis choisissez Afficher la colonne dans la table : composant, state_desc

  4. Cliquez ensuite avec le bouton droit sur chaque colonne et choisissez Filtrer par cette valeur pour appliquer les filtres suivants :

    • l’événement component_health_result pour être le seul affiché
    • component field='query processing'
    • <> state_desc 'clean'.

  5. Double-cliquez ensuite sur la colonne de données pour ouvrir les données XML et rechercher trackingNonYieldingScheduler la valeur dans la première ligne.

  6. Si la valeur est différente de 0x0 celle-ci, SQL Server a détecté des signes précoces d’un planificateur sans rendement et de le signaler ici.

    Voici un exemple où SQL Server a détecté une condition sans rendement avec une adresse de planificateur « 0x4fedb840040 » :

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

Mémoire faible du système d’exploitation

Il peut y avoir différents problèmes au niveau du système d’exploitation qui déclenchent un tel manque de réponse intermittent. Une mémoire faible est courante. Sur le nœud de groupe de disponibilité distant où le problème suspect se produit, procédez comme suit :

Étape 5. Rechercher les problèmes de mémoire du système d’exploitation qui entraînent la pagination de la mémoire SQL Server sur le disque

  1. Vérifiez le journal des événements système Windows pour toutes les erreurs indiquant une mémoire physique ou virtuelle faible.

  2. Recherchez l’erreur 17890 dans le journal des erreurs SQL Server ou dans le journal des événements de l’application Windows pour voir si la mémoire faible sur l’ordinateur conduit à réduire le jeu de travail de tous les processus sur le système, y compris SQL Server. L’erreur ressemble à ceci :

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

    Pour obtenir des instructions détaillées sur le t-shooting, consultez MSSQLSERVER_17890

Étape 6. Configurer la mémoire maximale du serveur et verrouiller les pages en mémoire correctement

  1. Configurez la mémoire Max Server SQL Server sur une valeur qui permet au système d’exploitation et à d’autres processus d’utiliser la mémoire disponible. Valeur recommandée pour définir la mémoire maximale du serveur SQL Server sur plus de 75 % de la taille de ram sur le système. Pour plus d’informations, consultez les options de configuration de la mémoire du serveur
  2. Activez l’option Verrouiller les pages en mémoire (Windows) pour empêcher la pagination massive du cache de mémoire tampon SQL Server.

E/S de disque lent

Dans certains cas, des E/S excessivement lentes peuvent entraîner l’arrêt temporaire des threads SQL Server, ce qui peut entraîner la déconnexion de l’autre réplica de groupe de disponibilité.

Étape 7. Résoudre les problèmes d’E/S lents

Si vous rencontrez des erreurs qui indiquent des E/S lentes, résolvez les raisons sous-jacentes des E/S lentes.

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.
  • Mettez à jour tous les pilotes et microprogrammes de périphérique ou effectuez d’autres diagnostics associés à votre sous-système d’E/S
  • L’accès au disque peut être ralenti par les pilotes de filtre, par exemple, un programme antivirus. Pour augmenter la vitesse d’accès, excluez les fichiers de données SQL Server des analyses antivirus actives
  • Collaborez avec votre fournisseur de matériel et votre administrateur système pour diagnostiquer et résoudre la cause d’E/S lentes

Pour obtenir des instructions détaillées, consultez Résoudre les problèmes de performances lentes de SQL Server causés par des problèmes d’E/S et de MSSQLSERVER_833.