Limitations connues relatives aux tables dynamiques¶
Ce chapitre décrit les limitations des fonctions de table dynamique suivantes :
Limitations générales¶
Les limitations générales suivantes s’appliquent à l’utilisation des tables dynamiques :
Un seul compte peut contenir un maximum de 4 000 tables dynamiques.
Dans la définition d’une table dynamique :
Vous ne pouvez pas interroger plus de 100 tables.
Vous ne pouvez pas interroger plus de 100 tables dynamiques.
Vous ne pouvez pas tronquer les données d’une table dynamique.
Vous ne pouvez pas créer de table dynamique temporaire.
Lorsque vous utilisez une table dynamique pour intégrer des données partagées, la requête ne peut pas effectuer de sélection à partir d’une table dynamique partagée ou d’une vue sécurisée partagée faisant référence à une table dynamique en amont.
Vous ne pouvez pas utiliser de rôles secondaires avec les tables dynamiques, car les actualisations des tables dynamiques jouent le rôle de leur propriétaire. Pour plus d’informations, voir Modèle d’application avec rôle principal et rôles secondaires.
Vous ne pouvez pas définir le paramètre d’objet DATA_RETENTION_TIME_IN_DAYS dans vos tables sources sur zéro.
Vous ne pouvez pas utiliser de SQL dynamique (par exemple, des variables de session ou des variables non liées de blocs anonymes) dans la définition de la table dynamique.
Dans une définition de table dynamique, les blocs SELECT qui lisent depuis des fonctions de table définies par l’utilisateur (UDTF) doivent spécifier explicitement les colonnes et ne peuvent pas utiliser
*.Les tables dynamiques peuvent devenir obsolètes si elles ne sont pas actualisées dans la période MAX_DATA_EXTENSION_TIME_IN_DAYS des tables d’entrée. Une fois obsolètes, les tables dynamiques doivent être recréées pour la reprise des actualisations.
Les tables dynamiques ne prennent actuellement pas en charge le suivi dans Vue ACCESS_HISTORY. Cela signifie que les requêtes et les opérations effectuées sur les tables dynamiques ne sont pas capturées dans ACCESS_HISTORY de Snowflake à des fins d’audit ou de surveillance.
Types de données pris en charge¶
Les tables dynamiques prennent en charge tous les types de données SQL Snowflake pour les actualisations incrémentielles et complètes, à l’exception de ce qui suit :
Types de données structurés
Types de données géospatiales (actualisation complète uniquement)
Limitations des constructions de requête¶
Les constructions suivantes ne sont actuellement pas prises en charge dans la requête pour une table dynamique. Si vous les indiquez dans la requête, il se produit une erreur :
Des fonctions qui s’appuient sur CURRENT_USER. Les actualisations des tables dynamiques jouent le rôle de leur propriétaire avec un utilisateur SYSTEM spécial.
Des sources qui incluent des tables de répertoire, des tables externes, des flux et des vues matérialisées.
Vues sur des tables dynamiques ou d’autres objets non pris en charge.
Fonctions de table définies par l’utilisateur (UDTF) écrites en SQL.
Fonctions définies par l’utilisateur (UDF) écrites en SQL qui contiennent une sous-requête (par exemple, une instruction SELECT).
Les constructions PIVOT et UNPIVOT ne sont pas prises en charge dans le cadre d’une actualisation incrémentielle ou complète.
Les constructions SAMPLE / TABLESAMPLE ne sont pas prises en charge dans le cadre d’une actualisation incrémentielle ou complète d’une table dynamique.
Prise en charge des interactions inter-fonctionnalités¶
Les interactions inter-fonctionnalités suivantes ne sont pas prises en charge :
Utilisation du Query Acceleration Service (QAS) pour l’actualisation des tables dynamiques.
Masquage des politiques avec des rôles de base de données sur des tables partagées.
Les limitations suivantes s’appliquent aux interactions inter-fonctionnalités :
Les tables dynamiques et les tables de base qui se trouvent dans des groupes de basculement différents entraînent l’échec de la réplication.
Prise en charge de l’actualisation incrémentielle¶
Cette section décrit les expressions, les clauses et les fonctions qui ne sont actuellement pas prises en charge pour l”actualisation incrémentielle des tables dynamiques. Si une requête les utilise, le processus d’actualisation automatisé utilise une actualisation complète, ce qui peut consommer davantage de crédits. Voir Déterminer si une actualisation incrémentielle ou complète est utilisée.
Les fonctions non déterministes ne sont pas prises en charge avec les actualisations incrémentielles, mais certaines fonctions non déterministes sont prises en charge avec les actualisations complètes.
Lorsque vous créez une table dynamique, la valeur par défaut pour le mode d’actualisation est AUTO, ce qui permet de sélectionner une actualisation incrémentielle de la table dynamique. Si l’instruction CREATE DYNAMIC TABLE ne prend pas en charge l’actualisation incrémentielle, l’actualisation complète est automatiquement choisie comme mode d’actualisation.
Pour déterminer le mode d’actualisation le mieux adapté à votre cas d’utilisation, expérimentez les modes d’actualisation et les recommandations automatiques. Pour un comportement cohérent entre les versions de Snowflake, définissez explicitement le mode d’actualisation de toutes les tables dynamiques. Par exemple, si vous souhaitez que vos tables dynamiques soient actualisées uniquement de manière incrémentielle, vous devez définir explicitement le mode d’actualisation sur INCREMENTAL lors de leur création. Pour plus d’informations, voir Définir le mode d’actualisation pour toutes les tables dynamiques de production.
Pour vérifier le mode d’actualisation de vos tables dynamiques, consultez Afficher le mode d’actualisation de tables dynamiques.
Constructions, opérateurs et fonctions non pris en charge¶
Les tables dynamiques ne prennent actuellement pas en charge les actualisations incrémentielles d’un certain nombre de constructions, d’opérateurs et de fonctions. Si vous spécifiez les éléments suivants dans la requête, la table dynamique est mise à jour via une actualisation complète :
-
UNION, MINUS, EXCEPT, INTERSECT.
Utilisations suivantes de UNION [ ALL ] :
UNION ALL d’une table et de l’élément lui-même ou d’un clone de lui-même.
UNION ALL entre un GROUP BY ou DISTINCT et un autre GROUP BY ou DISTINCT.
Tous les opérateurs de sous-requête.
Les modèles de jointure externe (gauche, droite ou complète) :
Les jointures externes dans lesquelles les deux parties sont la même table.
Les jointures externes dans lesquelles les deux parties sont une sous-requête avec des clauses GROUP BY.
Les jointures externes avec des prédicats de non-égalité.
Les utilisations suivantes des fonctions de fenêtre :
Plusieurs fonctions de fenêtre dans la même définition de table dynamique, où les clauses PARTITION BY ne sont pas identiques ou apparaissent dans des blocs de requête distincts.
Utilisation des fonctions de fenêtre PERCENT_RANK, DENSE_RANK, RANK avec des cadres de fenêtre glissants.
Utilisation de ANY_VALUE, puisqu’il s’agit d’une fonction non déterministe.
Les utilisations suivantes de fonctions définies par l’utilisateur (UDF) :
UDFs et UDTFs écrites en Python, Java, Scala ou Javascript, et en spécifiant le paramètre VOLATILE.
SQL UDFs qui contiennent des sous-requêtes.
Jointures LATERAL, à l’exception de l’utilisation de LATERAL avec FLATTEN().
Vous ne pouvez pas sélectionner la colonne SEQ aplatie provenant d’une jointure latérale aplatie. Pour plus d’informations, voir Requêtes prises en charge dans le cadre de l’actualisation incrémentielle.
Limitations supplémentaires de l’actualisation incrémentielle¶
Politiques de masquage et d’accès aux lignes¶
Les politiques de masquage ou d’accès aux lignes sur une table dynamique n’affectent pas son mode d’actualisation. Cependant, les politiques appliquées aux tables sources peuvent affecter le mode d’actualisation :
L’actualisation incrémentielle est prise en charge si les politiques des tables sources utilisent la fonction CURRENT_ROLE.
L’actualisation incrémentielle n’est pas prise en charge si les politiques des tables sources utilisent d’autres fonctions, des vues INFORMATION_SCHEMA, ou interrogent une table (par exemple, une recherche de la table de mappage).
Réplication¶
Les tables dynamiques répliquées avec actualisation incrémentielle se réinitialisent après le basculement avant de pouvoir reprendre l’actualisation incrémentielle.
Pour plus d’informations, consultez Réplication et tables dynamiques.
Clonage¶
Les tables dynamiques incrémentielles clonées peuvent avoir besoin d’être réinitialisées lors de leur première actualisation après leur création.
Si une table dynamique est clonée à partir d’une autre table dynamique avec des tables de base supprimées, le clone sera suspendu et ne pourra pas être repris ou actualisé.