MSSQLSERVER_35267

Article
03/18/2023

S’applique à :SQL Server

Détails

Attribut	Valeur
Nom du produit	SQL Server
ID de l’événement	35267
Source de l’événement	MSSQLSERVER
Composant	SQLEngine
Nom symbolique	HADR_DISCONNECTED_DB
Texte du message	Always On connexion des groupes de disponibilité avec %S_MSG base de données arrêtée pour %S_MSG base de données '%.ls' sur le réplica de disponibilité '%.ls' avec l’ID de réplica : {%.8x-%.4x-%.2x-%.2x%.2x%.2x%.2x%.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 le voir, l’erreur peut apparaître sur le réplica principal indiquant qu’il a perdu la communication avec le réplica secondaire, ou inversement.

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

Dans de nombreux cas, le nœud distant auquel le nœud local tente de se connecter peut même ne pas être conscient de l’échec de la connexion. Par conséquent, vous ne pouvez voir cette erreur que 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 importante 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 divers 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 finir par attendre la confirmation de la part du distant. Par conséquent, le journal des transactions n’est pas tronqué et le journal des transactions doit manquer d’espace (erreur 9002) et versions ultérieures pour devenir indisponible (erreur 9001). Voici un exemple de groupe d’erreurs où cela s’est produit. Notez que la raison pour laquelle le journal des transactions est plein est « AVAILABILITY_REPLICA », ce qui signifie que ce réplica attend que le réplica distant reconnaisse qu’il a appliqué des enregistrements de journal.

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

Des problèmes de connexion réseau peuvent exister entre les réplicas principaux et secondaires
SQL Server ou des problèmes de système d’exploitation sur les réplicas principaux ou secondaires, ce qui entraîne l’impossibilité d’exécuter les threads. Voici quelques exemples :
- Problèmes du planificateur de système d’exploitation SQL (planificateurs sans rendement ou interblocage)
- Mémoire insuffisante sur l’ordinateur, ce qui entraîne la suppression des ensembles 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 de longues attentes intermittentes sur le réplica principal ou secondaire

Action requise

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 vérifier les problèmes de connexion à partir de l’SQL Server où l’erreur est générée sur le SQL Server distant, vous pouvez envisager les étapes suivantes :

Étape 1. Vérifiez que le point de terminaison sur le 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 est à l’écoute et que la connexion réussit, recherchez le TcpTestSucceeded : True. Remplacez ServerName ou IP_Address par le 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 à localiser, sauf si vous capturez une trace réseau, qui montre des réinitialisations réseau (paquets supprimés) ou des problèmes similaires. Pour plus d’informations, consultez Problème réseau intermittent ou périodique 0300

SQL Server problèmes liés au planificateur

Si les threads de travail SQL Server rencontrent des problèmes de planificateur pour différentes raisons, les threads qui prennent en charge les demandes entrantes peuvent cesser de répondre temporairement pendant que les problèmes du planificateur durent.

Étape 4. Recherchez les problèmes du planificateur sur SQL Server

Un problème classique de planificateur sans rendement est enregistré dans SQL Server journal des erreurs après 70 secondes d’état de non-rendement. Toutefois, SQL Server vérifie l’état des planificateurs plus fréquemment que cela 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 d’abord sur la résolution de ces problèmes. Voici comment vous pouvez vérifier les occurrences de courte durée de problèmes de planificateur qui n’atteignent pas le seuil de 70 secondes, mais qui se produisent pendant 10 ou 20 secondes.

Utiliser le fichier d’événements étendu d’intégrité du système

Recherchez le fichier d’événements étendu d’intégrité du système à partir de l’heure de l’événement.
Double-cliquez sur pour l’ouvrir system_health_0_xxxxxxxxxxxxxxxxxx.xel 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.
Recherchez toutes les occurrences de scheduler_monitor_non_yielding_ring_buffer_recorded événement. Si vous en trouvez, cela indique que SQL Server détecté des événements de planificateur sans rendement et les enregistre. Ces événements sont enregistrés avant les vidages de mémoire du planificateur et les entrées de journal des erreurs qui se produisent après 60 à 70 secondes d’état de non-rendement. En d’autres termes, vous pouvez utiliser le scheduler_monitor_non_yielding_ring_buffer_recorded pour détecter les problèmes de planification à courte durée qui ne sont pas enregistrés dans le journal des erreurs, mais qui se sont toujours produits. Il peut s’agir de raisons d’un manque de connectivité intermittent ou de courte durée entre les nœuds du groupe de disponibilité.

Utiliser le journal des événements ÉTENDU SQLDIAG

Recherchez le journal des événements étendus SQLDIAG 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 à celui-ci SERVERNAME_MSSQLSERVER_SQLDIAG_x_xxxxxxxxxxxxxxxxxx.xel.
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.
Une fois ouvert dans SSMS, recherchez une instance de component_health_result événement, cliquez avec le bouton droit sur les éléments suivants, puis choisissez Afficher la colonne dans la table : composant, state_desc
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 être le seul affiché
- champ de composant ='traitement des requêtes'
- <> state_desc 'propre'.
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.
Si la valeur est différente de 0x0 cela signifie SQL Server a détecté des signes précoces d’un planificateur sans rendement et l’a signalé ici.

Voici un exemple où SQL Server a détecté une condition de non-rendement avec une adresse de planificateur « 0x4fedb840040 » :
```
 <queryProcessing maxWorkers="9600" workersCreated="2574" workersIdle="1883" tasksCompletedWithinInterval="175591" pendingTasks="3" ... trackingNonYieldingScheduler="0x4fedb840040">
```

Mémoire insuffisante du système d’exploitation

Il peut y avoir différents problèmes au niveau du système d’exploitation (OS) qui déclenchent un tel manque de réponse intermittent. La mémoire insuffisante est l’une des plus courantes. 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 conduisent à SQL Server pagination de mémoire sur le disque

Vérifiez dans le journal des événements système Windows toute erreur indiquant une mémoire physique ou virtuelle faible.
Recherchez l’erreur 17890 dans le journal des erreurs SQL Server ou dans le journal des événements des applications Windows pour voir si la mémoire insuffisante sur l’ordinateur entraîne la suppression de tous les processus sur le système, y compris les SQL Server. L’erreur se présente comme suit :
```
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 plus d’informations sur les étapes de tir, consultez MSSQLSERVER_17890

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

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

E/S de disque lentes

Dans certains cas, la lenteur excessive des E/S peut entraîner l’arrêt temporaire des threads SQL Server, ce qui peut entraîner la déconnexion de l’autre réplica du 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 de la lenteur des E/S.

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.

Mettre à jour tous les pilotes et microprogrammes de périphérique ou effectuer d’autres diagnostics associés à votre sous-système d’E/S
L’accès au disque peut être ralenti par des 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 de la lenteur des E/S

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

Partager via