FAQ sur le connecteur SQL Server

Cette page répond aux questions fréquemment posées sur le connecteur SQL Server dans Databricks Lakeflow Connect.

Questions fréquentes (FAQ) sur le connecteur général géré

Les réponses aux QUESTIONS sur les connecteurs managés s’appliquent à tous les connecteurs managés dans Lakeflow Connect. Poursuivez la lecture pour les questions fréquentes (FAQ) spécifiques au connecteur.

Si le pipeline échoue, l’ingestion reprend-t-elle sans perte de données ?

Oui. Databricks effectue le suivi de ce que le connecteur a extrait de la source et appliqué dans la destination. En cas de problème, Databricks pourra reprendre au même endroit à condition que les journaux de logs restent accessibles sur la base de données source. Cette méthode peut être affectée si les journaux sont supprimés avant que le pipeline ne s'exécute pendant la période de rétention, ce qui nécessite une actualisation complète des tables cibles.

Le connecteur capture-t-il des fuseaux horaires pour les colonnes de date et d’heure ?

Non. La date et l’heure sont ingérées au format UTC.

Puis-je personnaliser l'horaire de la passerelle d’ingestion ?

Remarque : la passerelle d’ingestion doit s’exécuter en mode continu pour éviter la suppression des modifications en raison de la rétention du journal. Si des modifications ont été supprimées, une actualisation complète est requise pour toutes les tables.

Comment le connecteur gère-t-il une table sans clé primaire ?

Le connecteur traite toutes les colonnes, sauf les objets volumineux, comme une clé primaire regroupée. S’il existe des lignes en double dans la table source, ces lignes sont ingérées en tant que ligne unique dans la table de destination.

À quelle fréquence puis-je planifier l’exécution du pipeline d’ingestion ?

Il n’existe aucune limite quant à la fréquence de planification de l'exécution du pipeline d’ingestion. Toutefois, Databricks recommande au moins 5 minutes entre les intervalles, car le démarrage du calcul serverless prend un certain temps. Databricks ne prend pas en charge l’exécution du pipeline d’ingestion en mode continu.

Pourquoi ne vois-je pas toutes les lignes de ma base de données dans l’exécution initiale du pipeline ?

La passerelle d’ingestion extrait les données historiques et du CDC dès qu’elle commence à s’exécuter. Le pipeline d’ingestion peut s’exécuter avant l’extraction de toutes ces données, ce qui entraîne une application partielle des données dans des tables cibles. Pour que toutes les données soient extraites et appliquées aux tables cibles, il peut être nécessaire d'effectuer plusieurs exécutions du pipeline d’ingestion.

Ma passerelle d’ingestion prend beaucoup de temps à démarrer. Comment puis-je le corriger ?

Les passerelles s’exécutent sur le calcul classique et provisionnent une machine virtuelle sur chaque démarrage. Si le démarrage prend plus de quelques minutes, tenez compte des éléments suivants :

• Basculez vers le canal de pipeline actuel. Il s’agit du correctif le plus courant. Les builds de canal en préversion ont des temps de démarrage plus longs. Vous pouvez le modifier dans l’interface utilisateur (dans les paramètres avancés du pipeline sous Canal), le fichier de ressources groupé ou la spécification du pipeline.
• Ne redémarrez pas la passerelle entre les exécutions d’ingestion. La passerelle est conçue pour fonctionner en permanence. Lors de chaque arrêt et redémarrage, la machine virtuelle est réapprovisionnée, ce qui risque de conduire à la perte des journaux de modification si la source les tronque pendant que la passerelle est hors service.

Si la passerelle est bloquée dans un état de démarrage pendant 15 minutes ou plus, créez un ticket d'assistance.

Cela s’applique uniquement aux passerelles. Les pipelines d’ingestion s’exécutent sur le calcul sans serveur et démarrent rapidement.

Puis-je procéder à l'ingestion à partir d'une réplica en lecture ou d'une instance secondaire ?

Non. La prise en charge est limitée aux instances SQL Server principales. Cela est dû au fait que le suivi des modifications et la capture de données modifiées ne sont pas pris en charge sur les réplicas en lecture ou les instances secondaires.