Résoudre les erreurs tempdb sur un pool SQL dédié

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 déplacements de données (par exemple, les déplacements aléatoires, les déplacements de découpage), les tris, les chargements, les dépassements de mémoire et d’autres opérations. En outre, 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 consommation importante de l’espace tempdb peut entraîner l’échec des requêtes d’autres utilisateurs et l’escalade pour empêcher l’établissement de nouvelles connexions.

Que faire si je ne parviens 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’impossibilité de créer une connexion consiste à suspendreet reprendre, ou à mettre à l’échelle le pool SQL dédié. Cette action met fin aux transactions utilisateur à l’issue de ce problème et recrée la base de données tempdb lors du redémarrage du service.

Note: Veillez à accorder au service plus de temps pour annuler toutes les transactions en cours d’exécution, car les opérations de mise en pause et de mise à l’échelle peuvent prendre plus de temps que d’habitude 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

Veillez à identifier 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 framework ETL ou l’audit de vos instructions de pool SQL dédiées. Dans la plupart des cas, pas toujours, la requête la plus longue exécutée pendant la période pendant laquelle le problème s’est produit est la cause des erreurs de manque d’espace tempdb. Exécutez la requête suivante pour obtenir la liste des requêtes de longue durée :

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 éviter que le problème ne se reproduise. Le tableau suivant présente les atténuations pour les causes les plus courantes des erreurs complètes tempdb :

Cause	Description	Limitation des risques
Plan distribué médiocre	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 des tables pertinentes et assurez-vous qu’elles sont conservées selon une planification régulière.
Mauvaise intégrité de l’index columnstore cluster (CCI)	Il consomme l’espace tempdb en raison de dépassements de mémoire.	Régénérez les interfaces réseau réseau et assurez-vous qu’elles sont gérées selon une planification régulière.
Transactions volumineuses	Un grand volume d’instructions ou INSERT SELECT remplit la base de données tempdb pendant les opérations de CREATE TABLE AS SELECT (CTAS) déplacement des données.	Divisez votre CTAS instruction ou INSERT SELECT en plusieurs transactions plus petites.
Allocation de mémoire insuffisante	Les requêtes avec une mémoire allouée insuffisante (via une classe de ressources ou un groupe de charge de travail) peuvent se propager dans tempdb.	Exécutez vos requêtes avec une classe de ressources plus grande ou un groupe de charge de travail avec plus de ressources.
Requêtes de table externe de l’utilisateur final	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-y les requêtes utilisateur.
Ressources globales insuffisantes	Vous constaterez peut-être que votre pool SQL dédié est proche de sa capacité tempdb maximale pendant une activité élevée.	Envisagez de mettre à l’échelle 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 n’émet jamais de COMMIT ou ROLLBACK.
• Jeux IMPLICIT_TRANSACTION = ON (en particulier pour les clients et outils JDBC qui utilisent les fonctionnalités de validation automatique).

É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 status « Inactif ». Exécutez la requête suivante pour 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 voyez quelles connexions persistent 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 ou les 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 toutes les sessions potentiellement problématiques.

Ressources

• Interrogez le sys.dm_pdw_errors DMV pour rechercher des erreurs.