Problèmes courants et solutions (bêta)

Bêta

La fonctionnalité Historique de l’activité des utilisateurs est actuellement en version bêta pour l’outil Analytics.


Consultez le tableau suivant pour connaître les étapes de dépannage et les résolutions des erreurs courantes ou des comportements inattendus que vous pouvez rencontrer pendant ou après la mise à niveau vers la dernière version de l’interface de ligne de commande de Analytics Cloud Connector.

Émettre

La cause

Solution

« Trop de fichiers ouverts (erreur système d’exploitation 24) » lors d’un chargement de table basé sur CDF

Pendant les longs remplissages de tables suivies CDF (Change Données Feed), le noyau natif Delta Sharing peut ouvrir plus de descripteurs de fichiers simultanément que le système d’exploitation ne le permet. Remarque : Cela affecte les environnements macOS où la limite par défaut est 256.

Augmentez la limite de fichiers ouverts avant de commencer l’exécution : ulimit -n 65536.

  • Shell macOS/Linux : Ajoutez cette commande à votre profil shell (~/.zshrc or ~/.bashrc) ou au script wrapper de votre planificateur.

  • Linux (systemd) : Définissez LimitNOFILE=65536 dans votre fichier d’unité systemd.

  • Fenêtres : Aucune action n’est nécessaire ; Les limites natives du système d’exploitation sont suffisantes.

La première exécution après la mise à niveau prend beaucoup plus de temps que d’habitude

Comportement attendu. Le pipeline traite votre volume de données de remblayage historique.

  • Surveillez les journaux de l’interface de ligne de commande du connecteur Analytics Cloud.

  • Les journaux de l’interface de ligne de commande du connecteur Analytics Cloud K au nombre de partitions de chargement ; observez ces nombres diminuer pour vérifier la progression du traitement.

La première exécution après la mise à niveau affiche moins de lignes historiques que prévu

Le filigrane de processing_log ligne n’a pas été effacé avant l’exécution, ce qui fait que l’interface de ligne de commande du connecteur Analytics Cloud ne charge que les partitions plus récentes que votre ancien filigrane.

Recherchez un filigrane existant en exécutant la requête suivante :

  • SELECT * FROM <YOUR_DB>.<YOUR_SCHEMA>.PROCESSING_LOG
    WHERE TABLE_NAME = 'user_activity';

Si une ligne de user_activity est renvoyée, supprimez-la de la table et réexécutez l’exécution de l’interface de ligne de commande pour forcer le remplissage historique.

Flocon de neige « mémoire insuffisante » ou taille de l’entrepôt trop petite

L’énorme volume de données historiques lors d’un remplissage historique dépasse votre configuration d’entrepôt à l’état stationnaire.

Augmentez temporairement l’échelle de votre entrepôt Snowflake pendant la durée du remblai. Par exemple, de X-Small à Medium ou Large. Échelle de réduction une fois terminé.

Défaillance partielle : certaines partitions ont été chargées, puis l’exécution a été corrigée

Coupures de réseau ou interruptions inattendues de l’exécution.

Réexécutez le script de l’interface de ligne de commande. Il analysera votre base de données de destination, identifiera les partitions quotidiennes qui ont atterri avec succès et reprendra exactement là où il s’est arrêté sans dupliquer les données.

Erreurs de « pied de page corrompu » ou de Parquet lors du chargement

Incompatibilité de version de Lot ou de dépendance, généralement causée par le mélange personnalisé delta-sharing locale ou des installations pyarrow.

Assurez-vous d’utiliser la version exacte de Python et requirements.txt fourni avec la nouvelle interface de ligne de commande. La meilleure résolution consiste à utiliser l’environnement virtuel groupé (tel que snowenv/).

Le projet s’est terminé avec un code différent de zéro, mais la plupart des tables ont réussi

Comportement attendu dans l’interface de ligne de commande du connecteur Analytics Cloud. Toute défaillance d’une table individuelle force désormais l’ensemble du wrapper à se fermer avec le code 1 afin que les planificateurs détectent avec précision les défaillances.

Examinez l’impression du résumé Transfer Results à la fin du journal pour isoler la table défectueuse :

  • Transfer Results:
    projects: Success (...)
    user_activity: Failed — <error>
    Job FAILED: 1 of N table(s) failed (user_activity). Exiting with code 1.

Résolvez le problème de cette table spécifique et réexécutez le projet. Les tables réussies passeront rapidement à l’avance.

Impossible de localiser la table processing_log

N/A

Le lieu dépend entièrement du type de connecteur que vous utilisez :

  • Flocon de neige : Situé dans la base de données et le schéma configurés dans votre fichier config.yaml (le même lieu que vos tables données).

  • SQL Server : Situé dans le schéma configuré dans votre fichier config.yaml.

  • Autres connecteurs : Situé à côté de vos fichiers de données dans la superficie de contrôle/métadonnées désignée utilisée par ce connecteur spécifique.

Remarque : S’il n’existe encore nulle part, l’interface de ligne de commande le générera automatiquement lors de votre première exécution réussie.

Voir aussi

Chargement des articles connexes...