Limites des tables dynamiques¶
Ce sujet décrit les limites générales et inter-fonctionnalités des tables dynamiques.
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 50 000 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 Autorisation par le biais d’un rôle primaire et de 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, elles doivent être recréées pour reprendre les 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.
Lorsque vous créez une table dynamique qui utilise un entrepôt nommé DEFAULT, vous devez utiliser des guillemets doubles autour du nom, à la suite des exigences de l’identificateur à guillemets doubles. Par exemple,
CREATE DYNAMIC TABLE ... WAREHOUSE = "DEFAULT"
. Pour plus d’informations sur la création de tables dynamiques, voir Créer des tables dynamiques.Les tables dynamiques ne prennent pas en charge les sources qui incluent les tables de répertoire, les tables externes, les flux et les vues matérialisées.
Vous ne pouvez pas créer de tables dynamiques lisant des vues qui interrogent d’autres tables dynamiques.
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 politiques d’agrégation et de projection ne peuvent pas être appliquées aux tables de base des tables dynamiques. Si une table de base est associée à des politiques d’agrégation ou de projection, la création de la table dynamique échouera.
Prise en charge de l’actualisation incrémentielle¶
Les tables dynamiques prennent en charge deux modes d’actualisation : incrémentielle et complète. Vous pouvez soit paramétrer le mode d’actualisation sur AUTO, soit le définir explicitement. Pour plus d’informations, voir Modes d’actualisation des tables dynamiques et Bonnes pratiques pour le choix des modes d’actualisation des tables dynamiques.
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 sur les tables sources utilisent la fonction CURRENT_ROLE ou IS_ROLE_IN_SESSION.
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é.