Partager via

Résoudre les problèmes de l’entrepôt

  • Article

S’applique à : entrepôt dans Microsoft Fabric

Cet article fournit des conseils sur la résolution des problèmes courants dans Warehouse dans Microsoft Fabric.

Erreurs de connexion temporaires

Une erreur temporaire s’explique par une cause sous-jacente qui se résout d’elle-même en peu de temps. Si une connexion à Warehouse fonctionnait correctement, mais qu’elle commence à échouer sans modification des autorisations utilisateur, de la stratégie de pare-feu et de la configuration réseau, effectuez les étapes suivantes avant de contacter le support :

  1. Vérifier le statut de Warehouse et vérifiez qu’il n’est pas suspendu.
  2. Ne réessayez pas immédiatement la commande ayant échoué. Au lieu de cela, attendez 5 à 10 minutes, établissez une nouvelle connexion, puis réessayez la commande. Occasionnellement, le système Azure réaffecte rapidement des ressources matérielles pour mieux équilibrer les différentes charges de travail. La plupart de ces événements de reconfiguration se terminent en moins de 60 secondes. Durant cette reconfiguration, vous pouvez rencontrer des problèmes de connexion à votre base de données. La connexion peut également échouer lorsque le service est redémarré automatiquement pour résoudre certains problèmes.
  3. Connectez-vous à l’aide d’une autre application et/ou à partir d’une autre machine.

Échec de la requête en raison d’un problème d’espace tempdb

Est tempdb une base de données système utilisée par le moteur pour divers besoins de stockage temporaire pendant l’exécution de la requête. Il n’est pas accessible ou configuré par les utilisateurs. Les requêtes peuvent échouer en raison d’un tempdb manque d’espace. Procédez comme suit pour réduire tempdb l’utilisation de l’espace :

  1. Reportez-vous à l’article sur les statistiques pour vérifier que les statistiques de colonne appropriées ont été créées sur toutes les tables.
  2. Vérifiez que toutes les statistiques de table sont mises à jour après des transactions DML volumineuses.
  3. Les requêtes avec des JOIN complexes, GROUP BY et ORDER BY et qui s’attendent à retourner un jeu de résultats volumineux utilisent plus tempdb d’espace dans l’exécution. Mettez à jour les requêtes pour réduire le nombre de colonnes GROUP BY et ORDER BY si possible.
  4. Réexécutez la requête lorsqu’aucune autre requête active n’est en cours d’exécution pour éviter les contraintes de ressources pendant l’exécution de la requête.

Le niveau de performance des requêtes semblent se dégrader au fil du temps

De nombreux facteurs peuvent affecter le niveau de performance d’une requête, tels que les modifications de la taille de la table, l’asymétrie des données, la concurrence de la charge de travail, les ressources disponibles, le réseau, etc. Le simple fait qu’une requête s’exécute plus lentement ne signifie pas nécessairement qu’il existe un problème de performances de requête. Effectuez les étapes suivantes pour examiner la requête cible :

  1. Repérez les différences entre tous les facteurs affectant le niveau de performance entre les bonnes exécutions et les mauvais niveaux de performance.
  2. Reportez-vous à l’article sur les statistiques pour vérifier que les statistiques de colonne appropriées ont été créées sur toutes les tables.
  3. Vérifiez que toutes les statistiques de table sont mises à jour après des transactions DML volumineuses.
  4. Vérifiez l’asymétrie des données dans les tables de base.
  5. Interrompre et reprendre le service. Ensuite, réexécutez la requête lorsqu’aucune autre requête active n’est en cours d’exécution. Vous pouvez surveiller la charge de travail de l’entrepôt à l’aide de DMV.

La requête échoue après une longue exécution. Aucune donnée n’est retournée au client.

Une instruction SELECT peut s’être terminée avec succès dans le back-end et échouer lors de la tentative de retour du jeu de résultats de la requête au client. Essayez les étapes ci-dessous pour isoler le problème :

  1. Utilisez différents outils clients pour réexécuter la même requête.
  2. Si l’étape 1 échoue, exécutez une commande CTAS avec l’instruction SELECT ayant échoué pour envoyer le résultat de la requête SELECT à une autre table du même entrepôt. L’utilisation de CTAS évite le renvoi du jeu de résultats de requête à l’ordinateur client. Si la commande CTAS se termine correctement et que la table cible est remplie, l’échec de la requête d’origine est probablement dû à des problèmes du client ou du front-end de l’entrepôt.

Informations à collecter avant de contacter le support Microsoft

  • Indiquez l’ID d’espace de travail d’Entrepôt.
  • Fournissez l’ID d’instruction et l’ID de requête distribuée. Ils sont retournés en tant que messages après l’exécution ou l’échec d’une requête.
  • Indiquez le texte exact du message d’erreur.
  • Indiquez l’heure à laquelle la requête se termine ou échoue.

Contenu connexe