Skip to main content

FAQ client sur les bases de données SQL Server

Cet article vous donne un aperçu de notre prise en charge pour Alteryx Server avec SQL géré par l'utilisateur comme couche de persistance, ainsi que des informations sur la migration de MongoDB vers SQL.

FAQ SQL

1. Quelles sont les versions de SQL prises en charge ?

Nous prenons officiellement en charge MSSQL Server 2019 et 2022.

2. Les versions SQL cloud sont-elles prises en charge ?

Les seules versions officiellement prises en charge sont MSSQL Server 2019 et 2022. Certaines versions SQL cloud peuvent fonctionner, mais ne sont pas prises en charge par Alteryx.

3. Quel est le niveau d'autorisation requis pour la configuration de SQL ?

L'utilisateur qui accède à la base de données SQL doit initialement disposer de privilèges d'administrateur pour créer et utiliser les bases de données requises par Alteryx Server. Une fois que SQL a été configurée et que toutes les migrations de MongoDB vers SQL (le cas échéant) ont été effectuées, ces privilèges peuvent être réduits. Cependant, l'utilisateur devra toujours disposer des autorisations pour lire, écrire, supprimer des enregistrements et créer ou supprimer des tables, mais les droits de création de bases de données complets ne seront plus nécessaires.

4. Existe-t-il une option SQL pour une option de base de données intégrée ?

Non. Pour le moment, nous proposons uniquement MSSQL comme option de base de données pour les bases de données gérées par l'utilisateur.

5. La base de données SQL prend-elle en charge les connexions SSL/TLS ?

Oui.

6. Prenez-vous en charge l'authentification SQL Kerberos ?

Oui.

7. Prenez-vous en charge l'authentification SQL WinAuth ?

Oui.

8. Le schéma a-t-il changé entre Mongo et SQL ?

Oui. De légères modifications ont été apportées au schéma avec la nouvelle base de données SQL. Si vous interrogez directement Mongo, vous devez vérifier vos requêtes et éventuellement les mettre à jour. Pour plus d'informations, consultez la page d'aide Référence de schéma de base de données SQL.

10. Un nouvel environnement FIPS peut-il être configuré à l'aide de SQL dans 2024.1 ?

Oui.

11. Puis-je ajouter ma base de données SQL Alteryx à un déploiement SQL existant ?

Oui, vous pouvez exécuter une instance SQL Server avec d'autres instances de base de données.

12. Y a-t-il une différence de performances entre Mongo et SQL ?

  • Les performances de SQL et de Mongo sont équivalentes dans la majorité des cas. Un ralentissement des performances est constaté uniquement pour les workflows dont l'exécution prend 5 secondes ou moins. Consultez le tableau ci-dessous pour connaître les temps de comparaison. Pour les workflows dont l'exécution prend plus de 5 secondes, les différences de performances sont négligeables.

  • Dans l'exemple le plus extrême, si un utilisateur exécute 60 workflows par minute qui prennent chacun 1 seconde, la différence de temps d'exécution passera de 1 minute dans Mongo à 1 minute 15 secondes dans SQL.

  • En fin de compte, la différence de performances dépend des workflows en cours d'exécution, mais comme le ralentissement ne se produit qu'avec les workflows à exécution rapide, la différence de 0,25 seconde n'entraîne pas de différence significative en termes de performances.

Temps d'exécution du workflow Mongo

Temps d'exécution du workflow SQL

5 secondes

5,25 secondes

1 seconde

1,25 seconde

FAQ sur la migration de MongoDB vers MSSQL

Pour vérifier l'intégralité des instructions de migration de MongoDB vers SQL, consultez le Guide de migration de MongoDB vers SQL. Veuillez consulter les instructions de migration complètes, car cette FAQ ne répond qu'aux questions principales.

1. Quelle version de Server puis-je mettre à niveau vers la version 2024.1 pour une migration complète (de Mongo vers SQL) ?

Server 2022.1+. Si vous utilisez une version antérieure à la version 2022.1, nous vous recommandons d'effectuer une mise à niveau vers la version 2022.1 - 2023.2 avant d'effectuer la mise à niveau vers la version 2024.1.

2. La migration de MongoDB vers MSSQL fonctionne-t-elle pour les bases de données Mongo intégrées et les bases de données Mongo (Enterprise ou Atlas) gérées par l'utilisateur ?

Oui.

3. La migration SQL fait-elle partie de la mise à niveau 2024.1 ?

Non, la migration SQL s'effectue via un workflow que vous pouvez exécuter après la mise à niveau vers la version 2024.1. Cela vous permet d'effectuer une mise à niveau vers la version 2024.1 et de faire vos tests initiaux avant de migrer vers SQL.

4. Où puis-je télécharger le workflow de migration SQL ?

Sur le portail des téléchargements Alteryx.

5. Dois-je migrer vers SQL dans la version 2024.1 ?

Non. Il s'agit d'une migration facultative. Si vous ne souhaitez pas migrer vers SQL dans la version 2024.1, vous pouvez migrer dans une version ultérieure.

6. Quelle taille de base de données recommandez-vous pour SQL lors de la migration ?

Nous recommandons que la taille de votre base de données SQL soit deux fois supérieure à celle de votre version MongoDB actuelle. En effet, Mongo compresse la taille de la base de données, ce qui ne se produit pas dans MSSQL.

7. Le service doit-il être désactivé pour que la migration s'exécute ?

Pour les tests, vous pouvez exécuter la migration lorsque le service est en cours d'exécution. Après les tests, supprimez tous les enregistrements (pas les tables) de la base de données SQL avant d'exécuter la migration finale. Pour la migration finale, arrêtez complètement le service. Tous les enregistrements seront déplacés.

8. La migration peut-elle être arrêtée avant la fin de la procédure ? Que se passe-t-il si la migration est interrompue ?

Oui. Si la migration est interrompue ou arrêtée avant la fin de la procédure, elle redémarrera là où elle s'est arrêtée et poursuivra le transfert des enregistrements. Cela ne s'applique que si le service reste désactivé et qu'aucune modification n'est apportée à la base de données pendant la période d'arrêt.

Si vous arrêtez la migration, que le service est démarré et que des modifications sont apportées à MongoDB, vous devrez effacer le contenu des tables SQL, pas les tables elles-mêmes, avant de relancer la migration.

9. Comment saurai-je que la migration s'est déroulée correctement ?

Vous verrez 0 erreur dans la fenêtre des résultats et les journaux afficheront tous les enregistrements transférés de MongoDB vers MSSQL.

10. Quelles erreurs courantes pourrais-je rencontrer lors de l'exécution de la migration ?

  • bcp_batch

    • Exemple de message d'erreur : MongoToSQL_Migration_Macro (829): Migrator (22): Record #17: BatchTransferProcess (574): Record #1: Tool #9: Unable to find address for bcp_batch”

    • Quand l'erreur se produit-elle ? Pendant la migration, l'erreur s'affiche dans la fenêtre Résultats.

    • Solution : assurez-vous que le bon pilote SQL est installé et configuré (ODBC SQL Driver 17).

  • Service Failed to Start After Migration

    • Exemple de message d'erreur (dans les journaux de service) : ERROR,1,AlteryxServerMigrator,migrationLogger,ExecuteServerSqlDbMigrations,Server SQL database migrations have failed: Exception has been thrown by the target of an invocation.

    • Quand l'erreur se produit-elle ?

      • Après la migration, l'erreur s'affichera dans \Alteryx\Service\alteryx-migration.csv.

      • Vous pouvez obtenir cette erreur si vous spécifiez un pilote de manière incorrecte dans la chaîne de connexion de l'interface utilisateur Server.

    • Solution :

      • AlteryxService doit démarrer au moins une fois avec MongoDB comme back-end AVANT de migrer les données vers MSSQL. Cela permet de s'assurer que le schéma MongoDB est correctement mis à jour.

      • Vérifiez vos chaînes de connexion. En particulier, assurez-vous de ne pas spécifier de pilote dans la chaîne de connexion de persistance de l'interface utilisateur Server. Pour plus d'informations, consultez la section Chaînes de connexion avancée de la base de données SQL.

  • String to Number Conversion Failure

    • Exemple de message d'erreur : Error: MongoToSQL_Migration_Macro (829): Migrator (22): Record #54: BatchTransferProcess (574): Record #1: Tool #2: Error SQLFetch: [Simba][Support] (50090) Conversion from string to number failed with value ''[Simba][Support] (50090) Conversion from string to number failed with value ''[Simba][Support] (50090) Conversion from string to number failed with value ''

    • Quand l'erreur se produit-elle ? Pendant la migration, l'erreur s'affiche dans la fenêtre Résultats.

    • Solution : AlteryxService doit démarrer au moins une fois avec MongoDB comme back-end AVANT de migrer les données vers MSSQL. Cela permet de s'assurer que le schéma MongoDB est correctement mis à jour.

  • AlteryxGallery.alteryx_Server.table_Name

    • Exemple de message d'erreur : Error: MongoToSQL_Migration_Macro (829): Tool #46: Error opening "SELECT COUNT(DISTINCT Primary_Key) AS Count_distinct FROM AlteryxGallery.alteryx_server.Table_Name": No Columns Returned.

    • Quand l'erreur se produit-elle ? Pendant la migration, l'erreur s'affiche dans la fenêtre Résultats.

    • Solution :

      • Assurez-vous que le schéma MongoDB est PUBLIÉ sur MongoDB lors de la configuration du pilote Simba.

      • Assurez-vous de définir la source d'authentification appropriée lors de la création des informations d'identification DCM pour chaque connexion. Pour accéder à la zone de texte Source d'authentification, développez la section Paramètres avancés sous les entrées nom d'utilisateur et mot de passe lors de la création de vos informations d'identification.

        Si vous utilisez MongoDB intégrée, deux informations d'identification distinctes sont nécessaires : l'une utilisant la base de données AlteryxService et l'autre utilisant la base de données AlteryxGallery pour la source d'authentification. Pour plus d'informations, consultez le Guide de migration de Mongo vers SQL.

  • Unauthorized Command during MongoDB Schema Setup

    • Exemple de message d'erreur : [Simba][MongoDBODBC] (110) Error from MongoDB Client: not authorized on test to execute command { insert: "DatabaseMetadata_SchemaMap", ordered: true, $db: "test", lsid: { id: UUID("9819f76d-486b-4722-a4f1-f8398cd9a4ae") } } (Error Code: 13)

    • Quand l'erreur se produit-elle ? Lors de la tentative de publication du schéma MongoDB pendant la configuration du pilote Simba.

    • Solution : assurez-vous que la base de données d'authentification est définie sur la base de données cible. Lors de la création de l'entrée DSN pour Alteryx Gallery, définissez alors la base de données d'authentification sur AlteryxGallery, et non sur admin.

11. Que dois-je faire si la migration échoue et comment en serai-je informé ?

Le workflow génère des erreurs lors d'un échec. Si cela se produit, signalez l'erreur à partir de la fenêtre Résultats et envoyez les captures d'écran et les fichiers journaux créés pendant l'exécution à votre équipe d'assistance.

Si la migration échoue, vous pouvez redémarrer AlteryxService et continuer à utiliser votre MongoDB. À ce stade, Mongo est toujours entièrement connecté et fonctionnel, vous n'avez rien de plus à faire pour continuer à utiliser Mongo en cas d'échec de la migration.

12. Que se passe-t-il si je souhaite revenir à l'utilisation de MongoDB après la migration ?

Si vous avez effectué une sauvegarde de votre fichier RuntimeSettings.xml avant la migration, vous pouvez le remplacer par votre fichier RuntimeSettings.xml actuel (effectuer des sauvegardes de ces deux fichiers peut vous aider). Toutefois, toutes les modifications apportées à Server lors de votre connexion à SQL ne seront pas répercutées après le retour à MongoDB.

13. La migration SQL apportera-t-elle des modifications à l'ancienne version de MongoDB ?

Non. Les données restent inchangées. Toutefois, 1 collection est créée afin de stocker le schéma pour le pilote ODBC Simba MongoDB.

14. Puis-je migrer une version FIPS de Server vers SQL ?

La migration de MongoDB vers SQL n'est pas prise en charge actuellement pour les environnements FIPS. Toutefois, de nouveaux environnements FIPS peuvent être configurés à l'aide de MSSQL géré par l'utilisateur.