Travailler avec des vues matérialisées¶

Avantages des vues matérialisées¶

La mise en œuvre de vues matérialisées par Snowflake offre un certain nombre de caractéristiques uniques :

• Les vues matérialisées peuvent améliorer les performances des requêtes utilisant les mêmes résultats de sous-requête à plusieurs reprises.

• Les vues matérialisées sont gérées de manière automatique et transparente par Snowflake. Un service en tâche de fond met à jour la vue matérialisée une fois que les modifications ont été apportées à la table de base. Cela est plus efficace et moins sujet aux erreurs que de conserver manuellement l’équivalent d’une vue matérialisée au niveau de l’application.

• Les données accessibles via les vues matérialisées sont toujours actuelles, quelle que soit la quantité de DML effectuée sur la table de base. Si une requête est exécutée avant que la vue matérialisée ne soit mise à jour, Snowflake met à jour la vue matérialisée ou utilise les parties mises à jour de la vue matérialisée et récupère toutes les nouvelles données requises à partir de la table de base.

Décider quand créer une vue matérialisée ou une vue normale¶

En général, lorsque vous décidez de créer une vue matérialisée ou normale, utilisez les critères suivants :

• Créez une vue matérialisée lorsque toutes les conditions suivantes sont réunies :

  • Les résultats de la requête de la vue ne changent pas souvent. Cela signifie presque toujours que la table sous-jacente/de base pour la vue ne change pas souvent, ou du moins que le sous-ensemble de lignes de la table de base utilisé dans la vue matérialisée ne change pas souvent.

  • Les résultats de la vue sont souvent utilisés (généralement plus souvent par rapport à la fréquence de changement des résultats).

  • La requête consomme beaucoup de ressources. En règle générale, cela signifie que la requête utilise beaucoup de temps de traitement ou de crédits, mais cela peut également signifier que la requête utilise beaucoup d’espace de stockage pour les résultats intermédiaires.

• Créez une vue normale lorsque certaines des conditions suivantes sont réunies :

  • Les résultats de la vue changent souvent.

  • Les résultats ne sont pas utilisés souvent (par rapport à la vitesse à laquelle les résultats changent).

  • La requête n’utilise pas beaucoup de ressources, il n’est donc pas coûteux de la réexécuter.

Ces critères ne sont que des indications. Une vue matérialisée peut présenter des avantages même si elle n’est pas utilisée souvent - en particulier si les résultats changent moins souvent que l’utilisation de la vue.

De plus, vous devez prendre en compte d’autres facteurs pour décider d’utiliser une vue normale ou une vue matérialisée.

Par exemple, le coût de stockage de la vue matérialisée est un facteur ; si les résultats ne sont pas utilisés très souvent (même s’ils sont utilisés plus souvent par rapport à leur fréquence de changement), les coûts de stockage supplémentaires risquent de ne pas valoir le gain de performances.

Comparaison avec des tables, des vues standard et des résultats mis en cache¶

Les vues matérialisées ressemblent aux tables à certains égards et aux vues ordinaires (c’est-à-dire non matérialisées) à d’autres égards. En outre, les vues matérialisées présentent certaines similitudes avec les résultats mis en cache, notamment parce qu’elles permettent de stocker les résultats des requêtes pour une utilisation ultérieure.

Cette section décrit certaines des similitudes et des différences entre ces objets dans des domaines spécifiques, notamment :

• Performances de la requête.

• Sécurité de la requête.

• Réduction de la complexité de la logique de requête.

• Clustering de données (lié aux performances de la requête).

• Frais de stockage et de maintenance.

Snowflake met en cache les résultats de la requête pendant une courte période après son exécution. Dans certaines situations, si la même requête est réexécutée, et si aucun élément n’a été modifié dans les tables auxquelles la requête accède, Snowflake peut simplement renvoyer les mêmes résultats sans réexécuter la requête. C’est la forme de réutilisation la plus rapide et la plus efficace, mais aussi la moins flexible. Pour plus de détails, voir Utilisation de résultats de requête persistants.

Les vues matérialisées et les résultats de requête en cache offrent des avantages en termes de performances de requête :

• Les vues matérialisées sont plus souples, mais généralement plus lentes que les résultats mis en cache.

• Les vues matérialisées sont plus rapides que les tables en raison de leur « cache » (c’est-à-dire les résultats de la requête pour la vue) ; en outre, si les données ont changé, elles peuvent utiliser leur « cache » pour les données qui n’ont pas changé et utiliser la table de base pour toutes les données qui ont été modifiées.

Les vues ordinaires ne mettent pas les données en cache et ne peuvent donc pas améliorer les performances grâce à la mise en cache. Cependant, dans certains cas, les vues aident Snowflake à générer un plan de requête plus efficace. Cependant, les vues matérialisées et les vues standard renforcent la sécurité des données en permettant à celles-ci d’être exposées ou masquées au niveau des lignes ou des colonnes.

Le tableau suivant indique les principales similitudes et différences entre les tables, les vues standard, les résultats de requête en cache et les vues matérialisées :

Exemples de cas d’utilisation pour les vues matérialisées¶

Cette section décrit certains scénarios d’utilisation générale qui fournissent également un aperçu conceptuel des vues matérialisées :

• Supposons que vous exécutiez chaque jour une requête Q comprenant une sous-requête S. Si S consomme beaucoup de ressources et interroge des données qui ne changent qu’une fois par semaine, vous pouvez améliorer les performances de la requête externe Q en exécutant S et en mettant en cache les résultats dans une table nommée CT :

  • Vous ne mettriez à jour la table qu’une fois par semaine.

  • Le reste du temps, lorsque vous exécutez Q, les résultats de la sous-requête de S sont référencés dans la table.

  Cela fonctionnerait bien tant que les résultats de la sous-requête S changeraient de manière prévisible (par exemple, à la même heure chaque semaine).

  Toutefois, si les résultats de S changent de manière imprévisible, la mise en cache des résultats dans une table est risquée. Parfois, votre requête principale Q renverra des résultats obsolètes si les résultats de la sous-requête S sont obsolètes (et donc les résultats de la table CT mise en cache ne sont plus à jour).

  Idéalement, vous auriez besoin d’un type de cache spécial pour des résultats qui changent rarement, mais pour lesquels le moment du changement est imprévisible. En l’envisageant sous un autre angle, vous souhaitez forcer la sous-requête S à être réexécutée (et votre table CT en cache à être mise à jour) si nécessaire.

  Une vue matérialisée implémente une approximation du meilleur des deux mondes. Vous définissez une requête pour votre vue matérialisée et les résultats de celle-ci sont mis en cache (comme s’ils étaient stockés dans une table interne), mais Snowflake met à jour le cache lorsque la table sur laquelle la vue matérialisée est définie est mise à jour. Ainsi, vos résultats de sous-requête sont facilement disponibles pour des performances rapides.

• Comme exemple moins abstrait, supposons que vous dirigiez une petite succursale d’une grande pharmacie et que votre succursale stocke des centaines de médicaments sur un total de dizaines de milliers de médicaments approuvés par FDA.

  Supposons également que vous disposiez d’une liste complète de tous les médicaments que chacun de vos clients prend, et que presque tous ces clients ne commandent que des médicaments en stock (les commandes spéciales sont rares).

  Dans ce cas de figure, vous pouvez créer une vue matérialisée répertoriant uniquement les interactions entre les médicaments que vous avez en stock. Lorsqu’un client commande un médicament qu’il n’a jamais utilisé auparavant, si ce dernier et tous les autres médicaments qu’il prend sont couverts par votre vue matérialisée, vous n’avez pas besoin de consulter la totalité de la base de données FDA pour connaître les interactions médicamenteuses. Vous pouvez simplement vérifier la vue matérialisée afin que la recherche soit plus rapide.

• Vous pouvez utiliser une vue matérialisée par elle-même ou dans une jointure.

  En reprenant l’exemple de la pharmacie, supposons que vous disposiez d’une table répertoriant tous les médicaments que chacun de vos clients prend ; vous pouvez associer cette table à la vue matérialisée des interactions médicamenteuses pour déterminer lequel des médicaments actuels du client pourrait interagir avec le nouveau médicament.

  Vous pourriez utiliser une jointure externe pour vous assurer de répertorier tous les médicaments du client, qu’ils soient ou non dans votre vue matérialisée. Si la jointure externe indique que l’un des médicaments actuels ne figure pas dans la vue matérialisée, vous pouvez réexécuter la requête sur la table complète des interactions médicamenteuses.

Comment l’optimiseur de requêtes utilise les vues matérialisées¶

Vous n’avez pas besoin de spécifier une vue matérialisée dans une instruction SQL pour que la vue soit utilisée. L’optimiseur de requêtes peut réécrire automatiquement les requêtes sur la table de base ou sur des vues ordinaires pour utiliser la vue matérialisée à la place.

Par exemple, supposons qu’une vue matérialisée contienne toutes les lignes et colonnes nécessaires à une requête sur une table de base. L’optimiseur peut décider de réécrire la requête pour utiliser la vue matérialisée, plutôt que la table de base. Cela peut considérablement accélérer une requête, en particulier si la table de base contient une grande quantité de données historiques.

Comme autre exemple, dans une jointure multi-table, l’optimiseur peut décider d’utiliser une vue matérialisée au lieu d’une table pour l’une des tables de la jointure.

Une vue matérialisée peut également être utilisée comme source de données pour une sous-requête.

Lorsque l’optimiseur choisit d’utiliser implicitement une vue matérialisée, la vue matérialisée est répertoriée dans le plan EXPLAIN ou le profil de requête au lieu de la table de base. Vous pouvez utiliser ces informations pour expérimenter et comprendre quelles requêtes peuvent bénéficier des vues matérialisées existantes.

Commandes DDL pour les vues matérialisées¶

Les vues matérialisées sont des objets de base de données de première classe. Snowflake fournit les commandes DDL suivantes pour créer et gérer les vues matérialisées :

• CREATE MATERIALIZED VIEW

• ALTER MATERIALIZED VIEW

• DROP MATERIALIZED VIEW

• DESCRIBE MATERIALIZED VIEW

• SHOW MATERIALIZED VIEWS

Opérations DML sur des vues matérialisées¶

Snowflake n’autorise pas le DML standard (par exemple INSERT, UPDATE, DELETE) sur les vues matérialisées. Snowflake ne permet pas aux utilisateurs de tronquer les vues matérialisées.

Pour plus de détails, voir Travailler avec des vues matérialisées : limites (dans ce chapitre).

Privilèges de contrôle d’accès¶

Il existe trois types de privilèges liés aux vues matérialisées :

• Privilèges sur le schéma contenant la vue matérialisée.

• Privilèges directs sur la vue matérialisée elle-même.

• Privilèges sur les objets de base de données (par exemple, les tables) auxquels la vue matérialisée accède.

Vous pouvez utiliser les commandes standard pour octroyer et révoquer des privilèges sur des vues matérialisées :

• GRANT <privilèges>

• REVOKE <privilèges>

GRANT CREATE MATERIALIZED VIEW ON SCHEMA <schema_name> TO ROLE <role_name>;

Vues matérialisées sécurisées¶

Les vues matérialisées peuvent être des vues sécurisées.

La plupart des informations sur les vues sécurisées s’appliquent aux vues matérialisées sécurisées. Il existe quelques cas où les vues matérialisées sécurisées sont différentes des vues sécurisées non matérialisées. Les différences sont les suivantes :

• La commande pour savoir si une vue est sécurisée.

  • Pour les vues non matérialisées, vérifiez la colonne IS_SECURE dans le résultat de la commande SHOW VIEWS.

  • Pour les vues matérialisées, consultez la colonne IS_SECURE dans le résultat de la commande SHOW MATERIALIZED VIEWS.

Pour plus d’informations sur les vues sécurisées, voir Utilisation de vues sécurisées.

La syntaxe permettant de créer des vues matérialisées sécurisées est documentée à l’adresse CREATE MATERIALIZED VIEW.

Planification de la création d’une vue matérialisée¶

Lorsque vous décidez de créer une vue matérialisée, envisagez de faire une analyse pour déterminer quelle est l’exigence d’une telle vue :

1. Examinez les filtres, les projections et les agrégations de requêtes fréquentes ou coûteuses.

2. Utilisez le profil de requête et la commande EXPLAIN pour voir si les vues matérialisées existantes sont déjà utilisées par la fonction de réécriture automatique des requêtes. Vous constaterez peut-être que vous n’avez pas besoin de créer de nouvelles vues matérialisées s’il existe des vues existantes qui correspondent bien aux requêtes.

3. Avant d’ajouter des vues matérialisées, enregistrez les coûts et les performances actuels de la requête afin de pouvoir évaluer la différence après avoir créé la nouvelle vue matérialisée.

4. Si vous trouvez des requêtes avec des filtres très sélectifs qui ne bénéficient pas du clustering de la table, une vue matérialisée contenant les mêmes filtres peut aider les requêtes à éviter d’analyser beaucoup de données.

   De même, si vous trouvez des requêtes qui utilisent l’agrégation, ou qui contiennent des expressions qui sont très coûteuses à évaluer (par exemple, des appels de fonction coûteux ou des opérations coûteuses sur des données semi-structurées), alors une vue matérialisée qui utilise la ou les mêmes expressions ou agrégation(s) peut offrir un avantage.

5. Exécutez la commande EXPLAIN sur les requêtes d’origine, ou exécutez les requêtes et vérifiez le profil de requête pour voir si la nouvelle vue matérialisée est utilisée.

6. Surveillez la requête combinée et les coûts de vue matérialisée et évaluez si les performances ou les avantages en termes de coûts justifient le coût de maintenance de la vue matérialisée.

   Examinez également les coûts de requête de la table de base. Dans les cas où l’optimiseur peut réécrire la requête pour utiliser une vue matérialisée, la compilation de requête peut consommer plus de temps et de ressources. (L’optimiseur a un plus grand nombre de possibilités à considérer.)

7. N’oubliez pas que vous pouvez toujours référencer directement les vues matérialisées si cela simplifie vos requêtes ou si vous savez qu’une vue matérialisée vous donnera de meilleures performances. Cependant, dans la plupart des cas, vous pouvez simplement interroger la table de base et la fonction de réécriture automatique des requêtes le fera pour vous.

Création d’une vue matérialisée¶

Utilisez la commande CREATE MATERIALIZED VIEW pour créer une vue matérialisée. Pour voir un exemple, voir Exemple de base : Création d’une vue matérialisée (dans ce chapitre).

Lorsque vous créez une vue matérialisée, notez les points suivants :

• Gestion des noms de colonnes non autorisés dans les vues matérialisées

• Référence à la table de base

• Spécification de filtres pour l’optimisation des requêtes

CREATE OR REPLACE MATERIALIZED VIEW mv AS
  SELECT SYSTEM$ALPHA AS col1, ...

Limitations relatives à la création de vues matérialisées¶

Les limitations suivantes s’appliquent à la création de vues matérialisées :

• Une vue matérialisée ne peut interroger qu’une seule table.

• Les jointures, y compris les jointures automatiques, ne sont pas prises en charge.

• Une vue matérialisée ne peut pas interroger :

  • Une vue matérialisée.

  • Une vue non matérialisée.

  • Une fonction de table définie par l’utilisateur (UDTF).

• Une vue matérialisée ne peut pas inclure :

  • des UDFs (cette limitation s’applique à tous les types de fonctions définies par l’utilisateur, y compris les fonctions externes).

  • des fonctions de fenêtrage.

  • Des clauses HAVING.

  • Des clauses ORDER BY.

  • Des clauses LIMIT.

  • De clés GROUP BY qui ne figurent pas dans la liste SELECT. Toutes les clés GROUP BY d’une vue matérialisée doivent faire partie de la liste SELECT.

  • GROUP BY GROUPING SETS.

  • GROUP BY ROLLUP.

  • GROUP BY CUBE.

  • Imbrication de sous-requêtes dans une vue matérialisée.

  • Les opérateurs d’ensemble MINUS, EXCEPT ou INTERSECT.

• De nombreuses fonctions d’agrégation ne sont pas autorisées dans une définition de vue matérialisée.

  • Les fonctions d’agrégation prises en charge dans les vues matérialisées sont les suivantes :

    • APPROX_COUNT_DISTINCT (HLL).

    • AVG (sauf en cas d’utilisation dans PIVOT).

    • BITAND_AGG.

    • BITOR_AGG.

    • BITXOR_AGG.

    • COUNT.

    • COUNT_IF.

    • MAX.

    • MIN.

    • STDDEV, STDDEV_SAMP.

    • STDDEV_POP.

    • SUM.

    • VARIANCE (VARIANCE_SAMP, VAR_SAMP).

    • VARIANCE_POP (VAR_POP).

    Les autres fonctions d’agrégation ne sont pas prises en charge dans les vues matérialisées.

  Note

  Les fonctions d’agrégation autorisées dans les vues matérialisées présentent encore certaines restrictions :

  • Les fonctions d’agrégation ne peuvent pas être imbriquées.

  • Les fonctions d’agrégation utilisées dans des expressions complexes (par exemple (sum(salary)/10)) ne peuvent être utilisées qu’au niveau le plus extérieur d’une requête, pas dans une sous-requête ou une vue en ligne.

    Par exemple, ce qui suit est autorisé :

    create materialized view mv1 as
        select
            sum(x) + 100
          from t;
    

    Copy

    Ce qui suit n’est pas autorisé :

    create materialized view mv2 as
        select
            y + 10
          from (
            select
              sum(x) as y
            from t
          );
    

    Copy

  • DISTINCT ne peut pas être combiné avec des fonctions d’agrégation.

  • Dans une vue matérialisée, les fonctions d’agrégation AVG, COUNT, COUNT_IF, MIN, MAX et SUM peuvent être utilisées en tant que fonctions d’agrégation, mais pas en tant que fonctions de fenêtre. Dans une vue matérialisée, ces fonctions ne peuvent pas être utilisées avec la clause OVER :

    OVER ( [ PARTITION BY <expr1> ] [ ORDER BY <expr2> ] )
    

    Copy

  • Si une fonction d’agrégation est dans une sous-requête, la vue matérialisée ne peut pas créer d’expression au-dessus des colonnes agrégées de cette sous-requête. Par exemple, considérons la définition de vue matérialisée suivante :

    create or replace materialized view mv1 as
        select c1 + 10 as c1new, c2
            from (select sum(c1) as c1, c2 from t group by c2);
    

    Copy

    L’expression « c1 + 10 » est une expression placée au-dessus d’une fonction d’agrégation dans une sous-requête et provoque donc un message d’erreur.

    Notez que même un opérateur d’égalité compte comme une expression, ce qui signifie que les expressions CASE utilisant des colonnes représentant des fonctions d’agrégation dans une sous-requête sont également interdites.

    Pour contourner cette limitation, créez une vue matérialisée sans l’expression, puis créez une vue non matérialisée incluant l’expression, par exemple :

    create or replace materialized view mv1 as
        select c1, c2
            from (select sum(c1) as c1, c2 from t group by c2);
    
    create or replace view expr_v1 as
        select c1 + 10 as c1new, c2
            from (select c1, c2 from mv1);
    

    Copy

• Les fonctions utilisées dans une vue matérialisée doivent être déterministes. Par exemple, l’utilisation de CURRENT_TIME ou CURRENT_TIMESTAMP n’est pas autorisée.

• Une vue matérialisée ne doit pas être définie à l’aide d’une fonction qui produit des résultats différents pour différents réglages de paramètres, tels que le paramètre au niveau de la session TIMESTAMP_TYPE_MAPPING.

  Par exemple, supposons qu’une vue est définie comme suit :

  create materialized view bad_example (ts1) as
      select to_timestamp(n) from t1;
  

  Copy

  Le type de données de la valeur de retour de TO_TIMESTAMP(n) dépend du paramètre TIMESTAMP_TYPE_MAPPING, donc le contenu de la vue matérialisée dépend de la valeur de TIMESTAMP_TYPE_MAPPING au moment de la création de la vue.

  Lorsqu’une vue matérialisée est créée, l’expression définissant chacune de ses colonnes est évaluée et stockée. Si une définition de colonne dépend d’une variable de session particulière et que la variable de session change, l’expression n’est pas réévaluée et la vue matérialisée n’est pas mise à jour. Si la vue matérialisée dépend d’une valeur particulière d’une variable de session et si la valeur de la variable de session a changé, les requêtes sur la vue matérialisée échouent.

  Pour éviter ce problème, forcez l’expression à une valeur qui ne dépend d’aucune variable de session. L’exemple ci-dessous convertit la sortie en un type de données particulier, indépendamment du paramètre TIMESTAMP_TYPE_MAPPING :

  create materialized view good_example (ts1) as
      select to_timestamp(n)::TIMESTAMP_NTZ from t1;
  

  Copy

  Ce problème est spécifique aux vues matérialisées. Les vues non matérialisées génèrent leur sortie de manière dynamique en fonction des paramètres actuels, de sorte que les résultats ne puissent pas être périmés.

• Dans la définition d’une vue matérialisée, la sélection de la colonne SEQ à partir de la sortie de la fonction FLATTEN n’est pas prise en charge.

  Il n’est pas garanti que les valeurs de la colonne SEQ soient ordonnées de quelque manière que ce soit lorsqu’elles sont sélectionnées à partir d’une vue matérialisée. Si vous sélectionnez cette colonne dans la définition de la vue matérialisée, la sortie peut être indéterminée.

• Les vues matérialisées ne peuvent pas être créées en utilisant la fonction Time Travel.

Exemple de base : Création d’une vue matérialisée¶

Cette section contient un exemple de base de création et d’utilisation d’une vue matérialisée :

CREATE OR REPLACE MATERIALIZED VIEW mv1 AS
  SELECT My_ResourceIntensive_Function(binary_col) FROM table1;

SELECT * FROM mv1;

Copy

Des exemples plus détaillés sont fournis dans Exemples (dans cette rubrique).

Présentation du mode de maintenance des vues matérialisées¶

Une fois que vous avez créé une vue matérialisée, un processus en arrière-plan conserve automatiquement les données dans la vue matérialisée. Remarques :

• La maintenance des vues matérialisées est effectuée par un processus en tâche de fond, et le calendrier est optimisé en fonction de la charge de travail sur la table de base et la vue matérialisée.

  • Ce processus met à jour la vue matérialisée avec les modifications apportées par les opérations DML à la table de base (insertions, mises à jour et suppressions).

    En outre, le clustering sur la table de base peut également entraîner les actualisations d’une vue matérialisée. Reportez-vous à Meilleures pratiques pour le clustering des vues matérialisées et de leurs tables de base.

  • Lorsque des lignes sont insérées dans la table de base, le processus effectue une opération d”« actualisation » pour insérer les nouvelles lignes dans la vue matérialisée.

  • Lorsque des lignes sont supprimées dans la table de base, le processus effectue une opération de « compactage » sur la vue matérialisée, en supprimant ces lignes de la vue matérialisée.

• Pour connaître la dernière fois qu’une vue matérialisée a été actualisée, exécutez la commande SHOW MATERIALIZED VIEWS.

  Vérifiez les colonnes REFRESHED_ON et BEHIND_BY dans la sortie :

  • Les colonnes REFRESHED_ON et COMPACTED_ON indiquent l’horodatage de la dernière opération DML sur la table de base qui a été traitée par les opérations d’actualisation et de compactage, respectivement.

  • La colonne BEHIND_BY indique le temps de retard des mises à jour de la vue matérialisée par rapport aux mises à jour de la table de base.

• Si la maintenance prend du retard, les requêtes risquent de s’exécuter plus lentement que si les vues étaient à jour, mais les résultats seront toujours à jour.

  Si des micro-partitions de la vue matérialisée sont obsolètes, Snowflake ignore ces partitions et recherche des données dans la table de base.

• Si le processus d’arrière-plan rencontre certaines erreurs de l’utilisateur (par exemple, la requête pour la vue aboutit à une erreur de « division par zéro »), le processus invalide la vue matérialisée.

  La requête d’une vue matérialisée non valide entraîne une erreur. Le message d’erreur comprend la raison pour laquelle la vue matérialisée a été invalidée. Par exemple :

  Failure during expansion of view 'MY_MV':
    SQL compilation error: Materialized View MY_MV is invalid.
    Invalidation reason: Division by zero
  

  Si cela se produit, résolvez le problème décrit dans le message d’erreur (par exemple, supprimez les lignes qui introduisent l’erreur « division par zéro ») et reprenez la vue matérialisée à l’aide de la commande ALTER MATERIALIZED VIEW… RESUME.

Suspension et reprise de la maintenance d’une vue matérialisée¶

Si vous devez suspendre la maintenance et l’utilisation d’une vue matérialisée, exécutez la commande ALTER MATERIALIZED VIEW avec le paramètre SUSPEND :

ALTER MATERIALIZED VIEW <name> SUSPEND

Si vous suspendez la maintenance d’une vue, vous ne pouvez pas interroger celle-ci avant de la reprendre.

Pour reprendre la maintenance et l’utilisation d’une vue matérialisée, exécutez la commande ALTER MATERIALIZED VIEW avec le paramètre RESUME :

ALTER MATERIALIZED VIEW <name> RESUME

Pour un exemple, voir Suspension des mises à jour d’une vue matérialisée.

Affichage d’informations sur les vues matérialisées¶

La commande et la vue suivantes fournissent des informations sur les vues matérialisées :

• La commande SHOW VIEWS renvoie des informations sur les vues matérialisées et ordinaires.

• La vue INFORMATION_SCHEMA.TABLES présente des vues matérialisées. La colonne TABLE_TYPE indique « MATERIALIZED VIEW ». La colonne IS_INSERTABLE est toujours « NO », car vous ne pouvez pas effectuer d’insertion directement dans une vue matérialisée.

  Note

  La vue INFORMATION_SCHEMA.VIEWS n’affiche pas de vues matérialisées. Les vues matérialisées sont indiquées par INFORMATION_SCHEMA.TABLES.

Travailler avec des vues matérialisées : limites¶

Les limites suivantes s’appliquent à l’utilisation de vues matérialisées :

• Pour vous assurer que les vues matérialisées restent cohérentes avec la table de base sur laquelle elles sont définies, vous ne pouvez pas effectuer la plupart des opérations DML sur une vue matérialisée elle-même. Par exemple, vous ne pouvez pas insérer de lignes directement dans une vue matérialisée (bien que vous puissiez bien sûr insérer des lignes dans la table de base). Les opérations interdites DML incluent :

  • COPY

  • DELETE

  • INSERT

  • MERGE

  • UPDATE

  La troncation d’une vue matérialisée n’est pas prise en charge.

• Vous ne pouvez pas cloner directement une vue matérialisée à l’aide de la commande CREATE MATERIALIZED VIEW ... CLONE.... Toutefois, si vous clonez un schéma ou une base de données contenant une vue matérialisée, la vue matérialisée sera clonée et incluse dans le nouveau schéma ou la nouvelle base de données.

• Snowflake ne prend pas en charge l’utilisation de la fonction Time Travel pour interroger des vues matérialisées à un point dans le passé (par exemple, en utilisant la clause AT lors de l’interrogation d’une vue matérialisée).

  Cependant, vous pouvez utiliser Time Travel pour cloner une base de données ou un schéma contenant une vue matérialisée à un point dans le passé. Pour plus de détails, voir Vues matérialisées et Time Travel.

• Les vues matérialisées ne sont pas surveillées par Snowflake Utilisation de moniteurs de ressources.

Effets des modifications apportées aux tables de base sur les vues matérialisées¶

Les sections suivantes expliquent comment les vues matérialisées sont affectées par les modifications apportées aux tables de base.

• Ajout de colonnes à la table de base

• Modification ou suppression de colonnes dans la table de base

• Renommer ou remplacer la table de base

• Suppression de la table de base

Vues matérialisées dans les schémas et bases de données clonés¶

Si vous clonez un schéma ou une base de données contenant une vue matérialisée, la vue matérialisée est clonée.

Si vous clonez simultanément la vue matérialisée et la table de base correspondante (dans la même opération CREATE SCHEMA ... CLONE ou CREATE DATABASE ... CLONE), la vue matérialisée clonée se réfère à la table de base clonée.

Si vous clonez la vue matérialisée sans cloner la table de base (par exemple, si la table se trouve dans Database1.Schema1 et la vue dans Database1.Schema2 et que vous clonez uniquement Schema2 plutôt que l’intégralité de Database1), la vue clonée fera référence à la table de base d’origine.

Estimation et contrôle des coûts¶

Il n’existe aucun outil permettant d’estimer les coûts de maintenance des vues matérialisées. En général, les coûts sont proportionnels aux facteurs suivants :

• Le nombre de vues matérialisées créées sur chaque table de base et la quantité de données modifiées dans chacune des vues matérialisées lorsque la table de base change. Toute modification des micro-partitions dans la table de base nécessite une éventuelle maintenance de la vue matérialisée, que ces modifications soient dues à un reclustering ou à des instructions DML exécutées sur la table de base.

• Nombre de ces vues matérialisées qui sont mises en cluster. Le maintien du clustering (d’une table ou d’une vue matérialisée) augmente les coûts.

  Si une vue matérialisée est mise en cluster différemment de la table de base, le nombre de micropartitions modifiées dans la vue matérialisée peut être sensiblement plus grand que le nombre de micropartitions modifiées dans la table de base.

  Par exemple, considérons le cas où la table de base est modifiée en grande partie par l’insertion (ajout) de données et n’est pas mise en cluster, la table de base est alors en grande partie dans l’ordre dans lequel les lignes ont été insérées dans la table. Imaginez que la vue matérialisée est mise en cluster par une colonne indépendante, par exemple, le code postal. Si 100 nouvelles lignes sont ajoutées à la table de base, celles-ci peuvent entrer dans une ou deux nouvelles micropartitions, sans toucher aux autres micropartitions de la table de base. Mais ces 100 lignes peuvent nécessiter une réécriture de 100 micropartitions dans la vue matérialisée en cluster.

  Comme autre exemple, considérez les suppressions. La suppression des lignes les plus anciennes dans une table de base non clusterisée peut supprimer uniquement les micropartitions les plus anciennes, mais peut nécessiter des modifications d’un nombre beaucoup plus élevé de micropartitions dans une vue matérialisée qui n’est pas mise en cluster par âge.

  (Pour plus d’informations sur le clustering des vues matérialisées, voir : Vues matérialisées et clustering.)

Vous pouvez contrôler le coût de maintenance des vues matérialisées en choisissant avec soin le nombre de vues à créer, les tables sur lesquelles les créer, et la définition de chaque vue (y compris le nombre de lignes et de colonnes dans cette vue).

Vous pouvez également contrôler les coûts en suspendant ou en reprenant la vue matérialisée. Cependant, suspendre la maintenance ne fait généralement que différer les coûts au lieu de les réduire. Plus la maintenance est différée, plus il y a de maintenance à faire.

Voir aussi Meilleures pratiques pour la gestion des vues matérialisées.

Affichage des coûts¶

Vous pouvez afficher les coûts de facturation pour la gestion des vues matérialisées à l’aide de Snowsight, de l”Classic Console, ou de SQL :

Snowsight:

En tant qu’utilisateur disposant des privilèges adéquats, sélectionnez Admin » Usage.

Classic Console:

En tant qu’administrateur de compte, sélectionnez Account » Billing & Usage.

Les coûts de crédit sont suivis dans un entrepôt virtuel géré par Snowflake nommé MATERIALIZED_VIEW_MAINTENANCE.

SQL:

Interrogez l’un des éléments suivants :

• la fonction de table MATERIALIZED_VIEW_REFRESH_HISTORY (dans Schéma d’information de Snowflake).

  Par exemple :

  SELECT * FROM TABLE(INFORMATION_SCHEMA.MATERIALIZED_VIEW_REFRESH_HISTORY());
  

  Copy

• la vue Vue MATERIALIZED_VIEW_REFRESH_HISTORY (dans Account Usage).

  Les requêtes suivantes peuvent être exécutées sur la vue MATERIALIZED_VIEW_REFRESH_HISTORY :

  Requête : historique des coûts en vues matérialisées (par jour, par objet).

  Cette requête fournit une liste complète des vues matérialisées et le volume de crédits consommés via le service au cours des 30 derniers jours, ventilés par jour. Toute irrégularité dans la consommation de crédit ou une consommation constamment élevée sont des signaux d’alerte qui entraînent la nécessité d’une investigation plus profonde.

  SELECT TO_DATE(start_time) AS date,
    database_name,
    schema_name,
    table_name,
    SUM(credits_used) AS credits_used
  FROM snowflake.account_usage.materialized_view_refresh_history
  WHERE start_time >= DATEADD(month,-1,CURRENT_TIMESTAMP())
  GROUP BY 1,2,3,4
  ORDER BY 5 DESC;
  

  Copy

  Requête : historique des vues matérialisées et moyenne sur un mois

  Cette requête montre les crédits quotidiens moyens consommés par les vues matérialisées regroupées par semaine au cours de la dernière année. Elle peut aider à identifier les anomalies dans les moyennes quotidiennes sur l’année, ce qui vous permet d’enquêter sur les pics ou les changements inattendus dans la consommation.

  WITH credits_by_day AS (
    SELECT TO_DATE(start_time) AS date,
      SUM(credits_used) AS credits_used
    FROM snowflake.account_usage.materialized_view_refresh_history
    WHERE start_time >= DATEADD(year,-1,CURRENT_TIMESTAMP())
    GROUP BY 1
    ORDER BY 2 DESC
  )
  
  SELECT DATE_TRUNC('week',date),
    AVG(credits_used) AS avg_daily_credits
  FROM credits_by_day
  GROUP BY 1
  ORDER BY 1;
  

  Copy

Meilleures pratiques pour la création de vues matérialisées¶

• La plupart des vues matérialisées doivent produire l’un des résultats suivants :

  • Filtrer les données. Vous pouvez le faire de cette manière :

    • Filtrer les lignes, par exemple en définissant la vue matérialisée afin que seules les données très récentes soient incluses. Dans certaines applications, les meilleures données à stocker sont les données anormales. Par exemple, si vous surveillez la pression dans un pipeline pour estimer le risque de défaillance des canalisations, vous pouvez stocker toutes les données de pression dans la table de base et ne stocker que les mesures de pression anormalement élevées dans la vue matérialisée. De même, si vous surveillez le trafic réseau, votre table de base peut stocker toutes les informations de surveillance, tandis que votre vue matérialisée ne stocke que des informations inhabituelles et suspectes (par exemple, à partir d’adresses IP connues pour lancer des attaques par déni de service (DOS).

    • Filtrer des colonnes, par exemple en sélectionnant des colonnes spécifiques plutôt que « SELECT * … ». Utiliser SELECT * ... pour définir une vue matérialisée est généralement coûteux. Cela peut également conduire à des erreurs futures ; si des colonnes sont ajoutées ultérieurement à la table de base (par exemple : ALTER TABLE ... ADD COLUMN ...), la vue matérialisée n’intègre pas automatiquement la ou les nouvelles colonnes.

  • Effectuer des opérations exigeantes en ressources et stocker les résultats de sorte que les opérations exigeantes en ressources ne soient plus aussi fréquentes.

• Vous pouvez créer plusieurs vues matérialisées pour la même table de base. Par exemple, vous pouvez créer une vue matérialisée contenant uniquement les données les plus récentes et une autre vue matérialisée stockant des données inhabituelles. Vous pouvez ensuite créer une vue non matérialisée qui joint les deux tables et affiche des données récentes qui correspondent à des données historiques inhabituelles afin de pouvoir détecter rapidement des situations inhabituelles telles qu’une attaque de type DOS (par déni de service) en cours de montée en puissance.

  Snowflake recommande les vues matérialisées pour des données inhabituelles uniquement lorsque :

  • La table de base n’est pas mise en cluster ou les colonnes contenant les données inhabituelles ne font pas déjà partie de la clé de clustering de la table de base.

  • Les données sont assez inhabituelles pour qu’elles soient faciles à isoler, mais pas si inhabituelles qu’elles sont rarement utilisées. (Si les données sont rarement utilisées, le coût de maintenance de la vue matérialisée l’emportera probablement sur les avantages en termes de performances et d’économies de coûts résultant de la possibilité d’y accéder rapidement lors de leur utilisation.)

Meilleures pratiques pour la gestion des vues matérialisées¶

• Snowflake recommande le traitement par lots DML de la table de base :

  • DELETE : si les tables stockent des données pour la période la plus récente (par exemple, le jour, la semaine ou le mois le plus récent), lorsque vous ajustez votre table de base en supprimant les anciennes données, les modifications apportées à la table de base sont propagées à la vue matérialisée. Selon la manière dont les données sont distribuées sur les micro-partitions, cela pourrait vous amener à payer davantage pour les mises à jour en arrière-plan des vues matérialisées. Dans certains cas, vous pourrez peut-être réduire les coûts en effectuant des suppressions moins fréquemment (par exemple, tous les jours plutôt que toutes les heures, ou toutes les heures plutôt que toutes les 10 minutes).

    Si vous n’avez pas besoin de conserver une quantité spécifique de données anciennes, essayez de trouver le meilleur équilibre entre coût et fonctionnalité.

  • INSERT, UPDATE, et MERGE : le traitement par lots de ces types d’instructions DML sur la table de base peut réduire les coûts de maintenance des vues matérialisées.

Meilleures pratiques pour le clustering des vues matérialisées et de leurs tables de base¶

• Si vous créez une vue matérialisée sur une table de base et si l’accès aux vues matérialisées est fréquent et si l’accès à la table de base est peu fréquent, il est généralement plus efficace d’éviter le clustering de la table de base.

  Si vous créez une vue matérialisée sur une table en cluster, envisagez de supprimer tout clustering sur la table de base, car toute modification du clustering de la table de base nécessitera éventuellement une actualisation de la vue matérialisée, ce qui s’ajoute aux coûts de maintenance de la vue matérialisée.

• Le clustering des vues matérialisées, en particulier des vues matérialisées sur des tables de base qui changent fréquemment, augmente les coûts. Ne regroupez pas plus de vues matérialisées en cluster que nécessaire.

• Presque toutes les informations sur les tables de clustering s’appliquent également au clustering des vues matérialisées. Pour plus d’informations sur le clustering des tables, voir Stratégies de sélection des clés de clustering.

Vue matérialisée simple¶

Ce premier exemple illustre une vue matérialisée simple et une requête simple sur la vue.

Créez la table et chargez les données, puis créez la vue :

CREATE TABLE inventory (product_ID INTEGER, wholesale_price FLOAT,
  description VARCHAR);
    
CREATE OR REPLACE MATERIALIZED VIEW mv1 AS
  SELECT product_ID, wholesale_price FROM inventory;

INSERT INTO inventory (product_ID, wholesale_price, description) VALUES 
    (1, 1.00, 'cog');

Copy

Sélectionnez des données à partir de la vue :

SELECT product_ID, wholesale_price FROM mv1;
+------------+-----------------+
| PRODUCT_ID | WHOLESALE_PRICE |
|------------+-----------------|
|          1 |               1 |
+------------+-----------------+

Copy

Association d’une vue matérialisée¶

Vous pouvez associer une vue matérialisée à une table ou à une autre vue. Cet exemple s’appuie sur l’exemple précédent en créant une table supplémentaire, puis une vue non matérialisée montrant les bénéfices en reliant la vue matérialisée à une table :

CREATE TABLE sales (product_ID INTEGER, quantity INTEGER, price FLOAT);

INSERT INTO sales (product_ID, quantity, price) VALUES 
   (1,  1, 1.99);

CREATE or replace VIEW profits AS
  SELECT m.product_ID, SUM(IFNULL(s.quantity, 0)) AS quantity,
      SUM(IFNULL(quantity * (s.price - m.wholesale_price), 0)) AS profit
    FROM mv1 AS m LEFT OUTER JOIN sales AS s ON s.product_ID = m.product_ID
    GROUP BY m.product_ID;

Copy

Sélectionnez des données à partir de la vue :

SELECT * FROM profits;
+------------+----------+--------+
| PRODUCT_ID | QUANTITY | PROFIT |
|------------+----------+--------|
|          1 |        1 |   0.99 |
+------------+----------+--------+

Copy

Suspension des mises à jour d’une vue matérialisée¶

L’exemple suivant suspend temporairement l’utilisation (et la maintenance) de la vue matérialisée mv1 et indique que les requêtes sur cette vue génèrent un message d’erreur lorsque la vue matérialisée est suspendue :

ALTER MATERIALIZED VIEW mv1 SUSPEND;
    
INSERT INTO inventory (product_ID, wholesale_price, description) VALUES 
    (2, 2.00, 'sprocket');

INSERT INTO sales (product_ID, quantity, price) VALUES 
   (2, 10, 2.99),
   (2,  1, 2.99);

Copy

Sélectionnez des données dans la vue matérialisée :

SELECT * FROM profits ORDER BY product_ID;

Copy

Sortie :

002037 (42601): SQL compilation error:
Failure during expansion of view 'PROFITS': SQL compilation error:
Failure during expansion of view 'MV1': SQL compilation error: Materialized View MV1 is invalid.

Copy

Reprise :

ALTER MATERIALIZED VIEW mv1 RESUME;

Copy

Sélectionnez des données dans la vue matérialisée :

SELECT * FROM profits ORDER BY product_ID;
+------------+----------+--------+
| PRODUCT_ID | QUANTITY | PROFIT |
|------------+----------+--------|
|          1 |        1 |   0.99 |
|          2 |       11 |  10.89 |
+------------+----------+--------+

Copy

Clustering d’une vue matérialisée¶

Cet exemple crée une vue matérialisée pour une mise en cluster plus tard :

Ces instructions créent deux tables qui suivent les informations sur les segments d’un pipeline (par exemple, pour le gaz naturel).

Les segments les plus susceptibles d’échouer dans un avenir proche sont souvent les segments les plus anciens, ou constitués de matériaux facilement corrodables, ou ayant connu des périodes de pression anormalement élevée. Dans cet exemple, nous suivons l’ancienneté de chaque tuyau, la pression et les matériaux (fer, cuivre, PVC plastique, etc.).

CREATE TABLE pipeline_segments (
    segment_ID BIGINT,
    material VARCHAR, -- e.g. copper, cast iron, PVC.
    installation_year DATE,  -- older pipes are more likely to be corroded.
    rated_pressure FLOAT  -- maximum recommended pressure at installation time.
    );
    
INSERT INTO pipeline_segments 
    (segment_ID, material, installation_year, rated_pressure)
  VALUES
    (1, 'PVC', '1994-01-01'::DATE, 60),
    (2, 'cast iron', '1950-01-01'::DATE, 120)
    ;

CREATE TABLE pipeline_pressures (
    segment_ID BIGINT,
    pressure_psi FLOAT,  -- pressure in Pounds per Square Inch
    measurement_timestamp TIMESTAMP
    );
INSERT INTO pipeline_pressures 
   (segment_ID, pressure_psi, measurement_timestamp) 
  VALUES
    (2, 10, '2018-09-01 00:01:00'),
    (2, 95, '2018-09-01 00:02:00')
    ;

Copy

Les segments de pipeline ne changent pas très souvent et les segments de pipeline les plus anciens sont ceux qui risquent le plus de tomber en panne. Créez donc une vue matérialisée des segments les plus anciens.

CREATE MATERIALIZED VIEW vulnerable_pipes 
  (segment_ID, installation_year, rated_pressure) 
  AS
    SELECT segment_ID, installation_year, rated_pressure
        FROM pipeline_segments 
        WHERE material = 'cast iron' AND installation_year < '1980'::DATE;

Copy

Vous pouvez ajouter un cluster ou modifier la clé de cluster. Par exemple, pour effectuer un cluster sur installation_year :

ALTER MATERIALIZED VIEW vulnerable_pipes CLUSTER BY (installation_year);

Copy

Les nouvelles mesures de pression arrivant fréquemment, peut-être toutes les 10 secondes, il serait donc coûteux de conserver une vue matérialisée sur les mesures de pression. Par conséquent, même si la performance (récupération rapide) des données de pression récentes est importante, la table pipeline_pressures démarre sans vue matérialisée.

Si les performances sont trop lentes, vous pouvez créer une vue matérialisée contenant uniquement les données de pression récentes ou uniquement des données relatives à des événements anormaux sous haute pression.

Créez une vue (non matérialisée) qui combine les informations de la vue matérialisée et de la table pipeline_pressures :

CREATE VIEW high_risk AS
    SELECT seg.segment_ID, installation_year, measurement_timestamp::DATE AS measurement_date, 
         DATEDIFF('YEAR', installation_year::DATE, measurement_timestamp::DATE) AS age, 
         rated_pressure - age AS safe_pressure, pressure_psi AS actual_pressure
       FROM vulnerable_pipes AS seg INNER JOIN pipeline_pressures AS psi 
           ON psi.segment_ID = seg.segment_ID
       WHERE pressure_psi > safe_pressure
       ;

Copy

Maintenant, listez les segments de pipeline à haut risque :

SELECT * FROM high_risk;
+------------+-------------------+------------------+-----+---------------+-----------------+
| SEGMENT_ID | INSTALLATION_YEAR | MEASUREMENT_DATE | AGE | SAFE_PRESSURE | ACTUAL_PRESSURE |
|------------+-------------------+------------------+-----+---------------+-----------------|
|          2 | 1950-01-01        | 2018-09-01       |  68 |            52 |              95 |
+------------+-------------------+------------------+-----+---------------+-----------------+

Copy

Cela montre que le segment de pipeline avec segment_id = 2, constitué d’un matériau corrodant, est ancien. Ce segment n’a jamais connu de pression supérieure à la pression nominale maximale au moment de son installation, mais en raison du potentiel de corrosion, sa « limite de sécurité » a diminué avec le temps et la pression la plus élevée qu’il a subie est supérieure à la pression recommandée pour un tuyau aussi ancien que celui-ci au moment de la mesure de la pression.

Création d’une vue matérialisée sur des données partagées¶

Vous pouvez créer une vue matérialisée sur des données partagées.

Compte1 :

create or replace table db1.schema1.table1(c1 int);
create or replace share sh1;
grant usage on database db1 to share sh1;
alter share sh1 add accounts = account2;
grant usage on schema db1.schema1 to share sh1;
grant select on table db1.schema1.table1 to share sh1;

Compte2 :

create or replace database dbshared from share account1.sh1;
create or replace materialized view mv1 as select * from dbshared.schema1.table1 where c1 >= 50;

Partage d’une vue matérialisée¶

Vous pouvez utiliser la fonctionnalité de partage de données de Snowflake pour partager une vue matérialisée.

Pour plus d’informations sur le partage de données, voir Aperçu du partage de données sur Snowflake.

Erreur de compilation : Failure during expansion of view '<nom>': SQL compilation error: Materialized View <nom> is invalid.¶

Causes possibles:

• La vue matérialisée a été suspendue. Pour plus d’informations sur la suspension et la reprise des vues, voir ALTER MATERIALIZED VIEW.

• Une modification de la table de base de la vue matérialisée a invalidé la vue matérialisée. Par exemple, cette erreur est renvoyée si :

  • La table de base est détruite.

  • Une colonne de la table de base a été supprimée.

• Le processus d’arrière-plan a rencontré une erreur d’un type spécifique (par exemple, une erreur de « division par zéro ») et n’a pas réussi à actualiser la vue matérialisée.

Solutions possibles:

• Si la vue a été suspendue :

  • Envisagez de reprendre la vue en exécutant ALTER MATERIALIZED VIEW RESUME.

  • Envisagez d’exécuter la requête sur la table de base. Cependant, cela risque de consommer plus de crédits et de prendre plus de temps que d’exécuter la requête sur la vue matérialisée.

• Si la table de base a été modifiée ou détruite :

  • Si la table de base a été détruite, alors détruisez la vue matérialisée.

  • Si la table de base a été modifiée (par exemple, si une colonne référencée par la vue a été détruite), et si la vue matérialisée est encore utile avec la nouvelle version de la table, il faut envisager de détruire et de recréer la vue matérialisée en utilisant les colonnes qui restent dans la table de base.

  • Si aucune autre cause du message d’erreur n’est apparente, envisagez de détruire et de recréer la vue matérialisée.

  • Envisagez d’exécuter la requête sur la table de base. Cependant, cela risque de consommer plus de crédits et de prendre plus de temps que d’exécuter la requête sur la vue matérialisée.

• Si le processus d’arrière-plan n’a pas réussi à actualiser la vue matérialisée en raison d’une erreur, le message d’erreur doit inclure des détails sur la raison pour laquelle la vue matérialisée a été invalidée. Par exemple :

  Failure during expansion of view 'MY_MV':
    SQL compilation error: Materialized View MY_MV is invalid.
    Invalidation reason: Division by zero
  

Si cela se produit, résolvez le problème décrit dans le message d’erreur et reprenez la vue matérialisée à l’aide de la commande ALTER MATERIALIZED VIEW… RESUME.

La commande SHOW MATERIALIZED VIEWS affiche les vues matérialisées non mises à jour¶

Cause possible:

Une cause possible est l’échec de l’actualisation, car l’instruction SELECT dans la définition de la vue a échoué.

L’actualisation étant effectuée en arrière-plan, vous ne verrez pas de message d’erreur au moment de la tentative d’actualisation. Au lieu de cela, vous verrez le message d’erreur lorsque vous interrogez la vue matérialisée ou lorsque vous exécutez SHOW MATERIALIZED VIEWS.

Solution possible:

Si la colonne invalid est true, vérifiez dans la colonne invalid_reason la raison pour laquelle la vue a été invalidée.

Dans certains cas, vous pourriez peut-être résoudre le problème en exécutant manuellement l’instruction SELECT dans la définition de la vue matérialisée ou en exécutant une instruction SELECT plus simple (moins coûteuse) sur la table référencée dans la définition de la vue matérialisée.

Si vous ne connaissez pas la définition exacte de la vue matérialisée, vous pouvez la retrouver dans le résultat de SHOW MATERIALIZED VIEWS ou en utilisant la fonction GET_DDL.