Partager via

Résoudre les problèmes liés aux erreurs tempdb sur un pool SQL dédié

  • Article

S’applique à : Azure Synapse Analytics

Sur un pool SQL dédié, la base de données tempdb est utilisée pour les tables temporaires et l’espace intermédiaire pour les mouvements de données (par exemple : déplacement aléatoires, déplacement de découpage), tris, charges, déversements de mémoire et autres opérations. De plus, une transaction non validée dans une session qui interagit avec la base de données tempdb empêche le journal de vider toutes les autres sessions, ce qui entraîne le remplissage des fichiers journaux. Étant donné que la base de données tempdb est une ressource partagée, une grande consommation de l’espace tempdb peut entraîner l’échec des requêtes d’autres utilisateurs et peut augmenter pour empêcher l’établissement de nouvelles connexions.

Que faire si je ne peux pas me connecter au pool SQL dédié ?

Si vous n’avez aucune connexion existante pour identifier les connexions ou requêtes problématiques, la seule méthode permettant de résoudre l’incapacité de créer une connexion consiste à suspendre et reprendre, ou à mettre à l’échelle le pool SQL dédié. Cette action met fin aux transactions utilisateur qui ont conduit à ce problème et recréent la base de données tempdb lors du redémarrage du service.

Remarque : Veillez à accorder au service un délai supplémentaire pour annuler toutes les transactions en cours d’exécution, car les opérations de pause et de mise à l’échelle peuvent prendre plus de temps que normalement dans ce scénario.

Résoudre les problèmes liés aux fichiers de données tempdb complets

Étape 1 : Identifier la requête qui remplit la base de données tempdb

Vérifiez que vous identifiez la requête qui remplit la base de données tempdb pendant l’exécution de la requête, sauf si vous avez implémenté un composant de journalisation dans votre infrastructure ETL ou l’audit de vos instructions de pool SQL dédiées. Dans la plupart des cas, pas toujours, la requête en cours d’exécution la plus longue exécutée pendant le délai dans lequel le problème s’est produit est la cause des erreurs d’espace hors tempdb. Exécutez la requête suivante pour obtenir la liste des requêtes longues :

SELECT TOP 5 *
FROM sys.dm_pdw_exec_requests
WHERE status = 'running'
ORDER BY total_elapsed_time desc;

Une fois que vous avez une requête raisonnablement suspecte, essayez l’une des options suivantes :

  • Tuez l’instruction.
  • Essayez d’empêcher toute autre charge de travail de consommer davantage l’espace tempdb afin que l’exécuteur long puisse se terminer.

Étape 2 : Empêcher la périodicité

Une fois que vous avez identifié et pris des mesures contre la requête responsable, envisagez d’implémenter des atténuations pour empêcher le problème de se reproduire. Le tableau suivant présente les atténuations pour les causes les plus courantes des erreurs complètes tempdb :

Cause Description Limitation des risques
Mauvaise maintenance du plan distribué Le plan distribué généré pour une requête donnée peut introduire par inadvertance un déplacement de données à haute fréquence en raison de statistiques de table mal gérées. Mettez à jour les statistiques pour les tables pertinentes et assurez-vous qu’elles sont conservées selon une planification régulière.
Index columnstore cluster non sain Il consomme l’espace tempdb en raison de déversements de mémoire. Régénérez les interfaces de contrôle d’accès et assurez-vous qu’elles sont conservées selon une planification régulière.
Transactions volumineuses Un grand volume d’instructions remplit la base de CREATE TABLE AS SELECT (CTAS) INSERT SELECT données tempdb pendant les opérations de déplacement des données. Divisez votre instruction CTAS ou INSERT SELECT en plusieurs transactions plus petites.
Allocation de mémoire insuffisante Les requêtes avec une mémoire insuffisante allouée (par le biais d’une classe de ressources ou d’un groupe de charge de travail) peuvent se répandre dans tempdb. Exécutez vos requêtes avec une classe de ressource plus grande ou un groupe de charges de travail comprenant davantage de ressources.
Requêtes d’utilisateur final sur des tables externes Les requêtes sur des tables externes ne sont pas optimales pour les requêtes de l’utilisateur final, car le moteur doit lire l’intégralité du fichier tempdb avant de traiter les données. Chargez les données dans une table permanente, puis dirigez les requêtes utilisateur vers cette table.
Ressources globales insuffisantes Vous pouvez constater que votre pool SQL dédié est proche de sa capacité tempdb maximale pendant une activité élevée. Envisagez de monter en puissance votre pool SQL dédié en combinaison avec l’une des atténuations ci-dessus.

Résoudre les problèmes liés aux fichiers journaux des transactions tempdb complets

Le journal des transactions tempdb se remplit généralement uniquement lorsqu’un client/utilisateur :

  • Ouvre une transaction explicite, mais ne émet jamais un COMMIT ou ROLLBACK.
  • Définit IMPLICIT_TRANSACTION = ON (en particulier pour les clients et les outils JDBC qui utilisent des fonctionnalités AutoCommit).

Étape 1 : Identifier les transactions ouvertes

Les connexions problématiques peuvent provenir de clients qui ont une transaction ouverte, mais qui se trouvent dans un état « Inactif ». Exécutez la requête suivante pour vous aider à identifier ce scénario :

SELECT *
FROM sys.dm_pdw_exec_sessions
WHERE is_transactional = 1
AND status = 'Idle';

Remarque : Toutes les connexions retournées à la suite de cette requête ne sont pas nécessairement problématiques. Exécutez la requête au moins deux fois avec plus de 15 minutes entre les exécutions et vérifiez les connexions persistantes dans cet état.

Étape 2 : Atténuer et empêcher le problème

Après avoir identifié les clients qui détiennent des transactions ouvertes, collaborez avec les utilisateurs pour modifier l’une ou l’autre des deux :

  • Configuration du pilote (par exemple : paramètre JDBC AutoCommit sur off, qui définit IMPLICIT_TRANSACTIONS = ON)
  • Comportements de requête ad hoc (par exemple : exécution BEGIN TRAN incorrecte sans/COMMITROLLBACK )

Vous pouvez également envisager de créer un processus automatisé pour détecter régulièrement ce scénario et tuer les sessions potentiellement problématiques.

Ressources