Utilisation des partages

Ce chapitre décrit les tâches associées à la création et à la configuration d’un compte de fournisseur de données, au partage des partages avec d’autres comptes (c’est-à-dire les comptes client) et à la maintenance continue des partages.

Vous devez utiliser le rôle ACCOUNTADMIN (ou un rôle ayant le privilège global CREATE SHARES) pour effectuer ces tâches. Pour plus de détails sur le privilège CREATE SHARES , voir Capacité des rôles non ACCOUNTADMIN à effectuer des tâches de partage de données.

La seule exception à cette règle est la préparation de vos objets (base de données, tables, etc.) à partager, qui peut être effectuée en utilisant n’importe quel rôle.

Dans ce chapitre :

Partage des données et comptes Business Critical

Si vous avez un compte Business Critical, veuillez noter les conditions suivantes pour partager des données avec d’autres comptes (c.-à-d. des comptes de consommateur) :

Fournisseur

Consommateur

Pris en charge

Activé

Remarques

Business Critical (avec HIPAA)

dans

Business Critical (avec HIPAA)

Les deux comptes HIPAA devraient avoir un BAA signé l’un avec l’autre.

Business Critical (avec HIPAA)

dans

Toutes les autres éditions

Snowflake ne permet pas aux comptes HIPAA de partager des données avec des comptes non HIPAA, même si l’autre compte est un compte Business Critical.

Business Critical

dans

Business Critical ou Business Critical (avec HIPAA)

Business Critical

dans

Toutes les autres éditions

Veuillez contacter Snowflake pour activer votre compte.

Pour toutes les autres éditions Snowflake :

  • VPS (Virtual Private Snowflake) ne prend pas en charge le partage de données sécurisé en raison des limitations actuelles contre le partage de données interrégionales.

  • Les éditions Enterprise et Standard prennent en charge le partage de données sécurisé avec les mises en garde habituelles.

Pour plus de détails, voir Considérations générales sur le partage de données et utilisation (dans ce chapitre).

Attention

Snowflake n’est pas responsable de s’assurer que les comptes HIPAA qui participent au partage de données ont un BAA signé entre eux. Ceci reste à la discrétion des comptes qui partagent des données. Notez que ne pas avoir un BAA signé peut avoir des conséquences sur la compliance HIPAA des deux comptes, en particulier pour le compte fournisseur.

En outre, si vous avez un compte Business Critical pour maintenir le niveau de protection des données attendu fourni par Business Critical, nous recommandons fortement de prendre en compte ce qui suit avant de demander à Snowflake d’activer le partage de données sécurisé avec des comptes non Business Critical :

  • Ne partagez pas de données sensibles avec des comptes non Business Critical.

  • Envisagez de créer un deuxième compte non Business Critical où vous stockerez des données moins sensibles et partagerez ces données avec des comptes non Business Critical.

  • Si vous utilisez Tri-Secret Secure avec votre compte Business Critical et que vous partagez des données avec d’autres comptes, Snowflake traite l’accès aux données à partir de ces comptes comme si l’accès se faisait à partir de votre propre compte. Plus précisément, donner accès au compte consommateur peut exiger que Snowflake accède à votre AWS KMS.

Il ne s’agit que de recommandations qui ne sont pas imposées par Snowflake. La décision de partager les données reste toujours à la discrétion du fournisseur de données, et Snowflake ne peut être tenu responsable des données qui sont partagées de façon inappropriée.

Interface Web pour les partages

Si vous avez le rôle ACCOUNTADMIN (ou si vous avez un rôle qui s’est vu accorder le privilège CREATE SHARES), vous pouvez utiliser la page Shares Shares tab dans l’interface Web Snowflake pour effectuer la plupart des tâches liées à la création et à la gestion des partages.

Shares page in Snowflake web interface

Les tâches que vous pouvez effectuer dépendent si le partage est Outbound ou Inbound.

Partages sortants (fournisseurs)

Les partages sortants sont créés par votre compte à des fins de partage de données avec des comptes de consommateur. Dans l’interface Web, vous pouvez exécuter les tâches suivantes pour les partages sortants :

  • Afficher les partages que vous avez créés ou pour lesquels vous avez des privilèges d’accès. L’information fournie comprend la base de données du partage et les comptes de consommateur (le cas échéant) qui ont été ajoutés au partage.

  • Créer un partage.

  • Ajouter des comptes de consommateur à un partage. Lorsque vous ajoutez des comptes, vous pouvez choisir d’ajouter des comptes complets ou des comptes de lecteur. Vous pouvez également choisir de créer un compte de lecteur à cet instant et de l’ajouter au partage.

  • Modifier un partage, y compris :

    • Voir les objets dans le partage.

    • Ajouter ou supprimer les tables et vues sécurisées au/du partage.

      Note

      L’interface Web ne prend actuellement pas en charge l’ajout ou la suppression de tables externes, de vues matérialisées sécurisées ou d’UDFs sécurisées aux/des partages. La gestion de ces objets dans les partages doit être effectuée à l’aide de SQL.

      Important

      Si vous prévoyez de partager en toute sécurité des données avec des consommateurs de données dans différentes régions ou plateformes Cloud, notez qu’actuellement, la réplication d’une base de données principale est bloquée si une ou plusieurs tables externes existent dans la base de données.

    • Révoquer l’accès au partage pour les comptes de consommateur individuels.

  • Détruire un partage, ce qui invalide immédiatement toutes les bases de données créées par les consommateurs pour le partage.

Partages entrants (consommateurs)

Les partages entrants sont partagés avec votre compte par des comptes de fournisseur. Dans l’interface Web, vous pouvez exécuter les tâches suivantes pour les partages entrants :

  • Afficher tous les partages des fournisseurs (dont ceux ayant fourni le partage et si une base de données a été créée à partir de celui-ci dans votre compte).

  • Création d’une base de données à partir d’un partage.

Une fois qu’une base de données a été créée pour un partage, toutes les autres tâches que vous effectuez sur la base de données (par exemple, détruire la base de données) sont effectuées depuis la page Databases Databases tab.

DDL pour les partages

Pour faciliter la création et la gestion des partages, Snowflake fournit l’ensemble suivant de commandes spéciales DDL :

En outre, les fournisseurs peuvent afficher, accorder ou révoquer l’accès aux objets de base de données d’un partage en utilisant le contrôle d’accès standard suivant DDL :

Considérations générales sur le partage de données et utilisation

Notez les détails d’utilisation importants suivants pour la création et la gestion des partages :

  • Vous pouvez partager des données entre régions et plates-formes Cloud. Pour plus d’informations, voir Partage sécurisé des données entre les régions et les plates-formes Cloud.

  • Un partage peut inclure des données provenant de plusieurs bases de données. Pour plus d’informations, voir Partage de données de plusieurs bases de données.

  • Pour des raisons de sécurité et de confidentialité des données, seules les vues sécurisées sont actuellement prises en charge dans les partages. Si une vue standard est ajoutée à un partage, Snowflake renvoie une erreur.

  • L’ajout de comptes à un partage rend le partage immédiatement disponible pour être consommé par les comptes.

  • Les lignes nouvelles et modifiées dans les tables d’un partage (ou dans les tables référencées par une vue dans un partage) sont immédiatement disponibles pour tous les consommateurs qui ont créé une base de données à partir du partage. Gardez cela à l’esprit lorsque vous mettez ces tables à jour.

  • Un nouvel objet créé dans une base de données dans un partage n’est pas automatiquement disponible aux consommateurs.

    Pour rendre l’objet disponible aux consommateurs, vous devez utiliser la commande GRANT <privilège> … TO SHARE pour ajouter explicitement l’objet au partage.

    Note

    Ceci s’applique également aux objets qui ont été détruits dans une base de données puis recréés avec le même nom dans la base de données. L’objet recréé est traité comme un nouvel objet et n’est donc pas accessible tant que l’objet n’a pas reçu explicitement les privilèges nécessaires dans le partage.

Préparation à la création d’un partage

Avant de créer un partage, Snowflake recommande d’identifier les objets Snowflake que vous prévoyez de partager :

  • Base de données

  • Tables

  • Tables externes

  • Vues sécurisées

  • Vues matérialisées sécurisées

  • UDFs sécurisées

Cela peut nécessiter des tâches administratives et de planification supplémentaires, en particulier si vous décidez de ne partager qu’un sous-ensemble de données dans l’une de vos tables.

Base de données et tables

Peu ou aucune préparation n’est nécessaire pour partager une base de données. De même, si vous choisissez de partager des tables entières dans une base de données, aucune préparation n’est nécessaire.

Toutefois, si vous décidez de filtrer les données dans une table (ou un ensemble de tables), soit en fonction de certaines conditions, soit par compte de consommateur, vous devrez créer une ou plusieurs vues sécurisées sur la ou les tables.

Permettre aux consommateurs de données de créer des flux de table sur des tables partagées

Note

La prise en charge des flux de table sur les tables partagées est fournie sous la forme d’une fonctionnalité en avant-première.

Pour que les consommateurs de données créent des flux sur des tables partagées, vous devez activer le suivi des modifications sur les tables. En outre, la période de conservation des données doit être prolongée pour les tables.

Activer le suivi des modifications

Actuellement, lorsque le premier flux d’une table locale est créé, une paire de colonnes masquées est ajoutée automatiquement à la table et commence à stocker les métadonnées de suivi des modifications. Cette modification n’est pas possible pour les tables partagées, car un consommateur d’un partage ne peut pas modifier la base de données source. Au lieu de cela, pour activer le suivi des modifications pour les tables destinées au partage, exécutez ALTER TABLE … CHANGE_TRACKING = TRUE sur chacune des tables.

Prolonger la période de conservation des données pour la table

Lorsqu’un flux sur une table locale n’est pas consommé régulièrement, Snowflake prolonge temporairement la période de conservation des données pour la table source afin d’éviter la désuétude. Si la période de conservation des données de la table est inférieure à 14 jours, alors en arrière-plan, elle est étendue à la valeur la plus petite liée au décalage transactionnel du flux ou à 14 jours (si la période de conservation des données pour la table est inférieure à 14 jours), quelle que soit l” édition Snowflake de votre compte. Lorsque le flux est consommé, la période de conservation étendue des données est réduite à la période par défaut de la table.

Un flux sur une table partagée ne prolonge pas la période de conservation des données pour la table. Pour spécifier manuellement une période de conservation des données plus longue pour une table partagée, définissez le paramètre DATA_RETENTION_TIME_IN_DAYS.

Les paramètres CHANGE_TRACKING et DATA_RETENTION_TIME_IN_DAYS peuvent être définis lors de la création d’une table (en utilisant CREATE TABLE) ou ultérieurement (en utilisant ALTER TABLE).

Objets sécurisés (vues, vues matérialisées et UDFs)

Pour assurer un contrôle strict de l’accès aux données d’une base de données partagée, nous recommandons d’utiliser des vues sécurisées, des vues sécurisées matérialisées et/ou des UDFs sécurisés. Par exemple, vous pouvez choisir de filtrer les données par date ou une autre condition, ou vous pouvez décider d’utiliser un seul partage pour partitionner les données partagées pour différents comptes de consommateur. Les objets sécurisés vous permettent de dicter le niveau de granularité que vous souhaitez appliquer à vos données, tout en assurant que les tables de base et la logique commerciale sont protégées de toute exposition.

Les objets sécurisés sont définis de la même manière que les objets standard, en utilisant les commandes correspondantes CREATE <objet> ou ALTER <objet>. Veuillez toutefois prendre note de ces informations d’utilisation importantes :

  • Les objets sécurisés qui référencent des tables par leur nom complet (c’est-à-dire <nom_bd>.<nom_schéma>.<nom_table>) peuvent être inclus dans un partage. Cependant, vous devez vous assurer que le nom de base de données référencé correspond à la base de données pour le partage.

  • N’incluez pas d’objets sécurisés utilisant les fonctions CURRENT_USER ou CURRENT_ROLE dans leur définition. Les valeurs contextuelles renvoyées par ces fonctions n’ont aucune importance pour les comptes de consommateur et provoquent l’échec de l’objet lorsqu’il est interrogé/utilisé.

  • Lors de la définition d’un objet sécurisé à partager avec les comptes de consommateur, une étape clé/essentielle supplémentaire à effectuer est de vérifier que l’objet est configuré correctement pour afficher uniquement les données que vous souhaitez afficher. Ceci est particulièrement important si vous souhaitez limiter l’accès aux données en fonction du compte avec lequel les données sont partagées.

    Pour faciliter cette validation, Snowflake fournit le paramètre de session SIMULATED_DATA_SHARING_CONSUMER.

    Pour le moment, le paramètre de session SIMULATED_DATA_SHARING_CONSUMER ne prend en charge que les vues sécurisées et les vues matérialisées sécurisées, mais ne prend pas en charge les UDFs sécurisés. Le réglage de ce paramètre dans une session vous permet de simuler l’interrogation d’une vue sécurisée en tant qu’utilisateur dans un compte de consommateur avec lequel vous souhaitez partager cette vue.

    Par exemple, pour un compte de consommateur nommé xy12345 :

    ALTER SESSION SET SIMULATED_DATA_SHARING_CONSUMER = xy12345;
    

Pour un exemple détaillé, voir Utilisation d’objets sécurisés pour contrôler l’accès aux données.

Création d’un partage à l’aide de SQL

Pour créer un partage à l’aide de SQL :

  1. Utilisez la commande CREATE SHARE pour créer un partage vide.

  2. Utilisez la commande GRANT <privilège> … TO SHARE pour ajouter une base de données au partage, puis accordez sélectivement l’accès à des objets de base de données spécifiques (schémas, tables et vues sécurisées) au partage.

  3. Utilisez la commande ALTER SHARE pour ajouter un ou plusieurs accès de compte au partage.

Note

Les étapes suivantes supposent qu’un compte fournisseur nommé prvdr1 partage des données avec deux comptes de consommateur nommés xy12345 et yz23456.

Étape 1 : Création d’un partage vide

L’exemple suivant crée un partage vide nommé sales_s :

CREATE SHARE sales_s;

Étape 2 : Attribution de privilèges pour une base de données et d’objets au partage

Pour inclure des objets dans le partage, accordez des privilèges sur chaque objet. Lorsque vous accordez des privilèges, accordez d’abord l’usage sur tout objet de conteneur avant d’accorder l’usage sur les objets dans le conteneur. Par exemple, autorisez l’utilisation sur une base de données avant d’accorder l’utilisation sur tout schéma inclus dans la base de données.

Note

Effectuez cette tâche avant d’ajouter des comptes au partage. Tenter d’ajouter un compte avant d’autoriser l’utilisation sur une base de données entraîne une erreur.

L’exemple suivant illustre l’octroi de privilèges sur les objets suivants au partage sales_s créé à l’étape précédente :

  • sales_db (base de données)

  • aggregates_eula (schéma)

  • aggregate_1 (table)

GRANT USAGE ON DATABASE sales_db TO SHARE sales_s;

GRANT USAGE ON SCHEMA sales_db.aggregates_eula TO SHARE sales_s;

GRANT SELECT ON TABLE sales_db.aggregates_eula.aggregate_1 TO SHARE sales_s;

Pour confirmer les contenus du partage :

SHOW GRANTS TO SHARE sales_s;

+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+
| created_on                    | privilege | granted_on | name                                 | granted_to | grantee_name   | grant_option | granted_by   |
|-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------|
| 2017-06-15 16:45:07.307 -0700 | USAGE     | DATABASE   | SALES_DB                             | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
| 2017-06-15 16:45:10.310 -0700 | USAGE     | SCHEMA     | SALES_DB.AGGREGATES_EULA             | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
| 2017-06-15 16:45:12.312 -0700 | SELECT    | TABLE      | SALES_DB.AGGREGATES_EULA.AGGREGATE_1 | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+

Cela permet de s’assurer que le partage est correctement configuré avant de le mettre à la disposition d’autres comptes pour le consommer.

Étape 3 : Ajout de comptes au partage

Attention

Si vous possédez un compte Business Critical et partagez des données avec des comptes de consommateurs :

  • Snowflake prend en charge le partage de données sensibles avec des comptes non Business Critical (désactivé par défaut), mais n’encourage pas à le faire.

  • Pour assurer la conformité aux exigences HIPAA, Snowflake n’autorise pas les comptes HIPAA à partager des données avec des comptes non HIPAA.

  • Si vous utilisez la protection des données Tri-Secret Secure, notez que Snowflake traite l’accès aux données à partir des comptes de consommateur comme si l’accès se faisait à partir de votre propre compte.

Pour plus d’informations sur ces recommandations et restrictions, voir Partage des données et comptes Business Critical.

L’exemple suivant ajoute deux comptes au partage sales_s :

ALTER SHARE sales_s ADD ACCOUNTS=xy12345, yz23456;

Les comptes xy12345 et yz23456 peuvent maintenant voir le partage et créer une base de données à partir de celui-ci.

Note

Lorsque vous ajoutez des comptes à un partage, si les comptes n’existent pas, la commande se termine avec succès, mais aucune mise à jour n’est effectuée sur le partage. Pour vous assurer que le partage est correctement mis à jour, assurez-vous que les comptes existent et que vous avez saisi les noms correctement.

Utilisez SHOW SHARES pour confirmer le partage. La sortie de la commande répertorie le partage sales_s. La colonne kind indique que le partage est OUTBOUND, ce qui signifie que ce partage partage une base de données avec d’autres comptes Snowflake. La colonne to répertorie tous les comptes auxquels le partage a été mis à disposition :

SHOW SHARES;

+-------------------------------+----------+-------------------------+-----------------------+------------------+--------------+----------------------------------------+
| created_on                    | kind     | name                    | database_name         | to               | owner        | comment                                |
|-------------------------------+----------+-------------------------+-----------------------+------------------+--------------+----------------------------------------|
| 2016-07-09 19:18:09.821 -0700 | INBOUND  | SFC_SAMPLES.SAMPLE_DATA | SNOWFLAKE_SAMPLE_DATA |                  |              | Sample data sets provided by Snowflake |
| 2017-06-15 17:02:29.625 -0700 | OUTBOUND | PRVDR1.SALES_S          | SALES_DB              | XY12345, YZ23456 | ACCOUNTADMIN |                                        |
+-------------------------------+----------+-------------------------+-----------------------+------------------+--------------+----------------------------------------+

Maintien des partages à l’aide de SQL

Affichage des consommateurs qui ont créé des bases de données à partir de partages

Pour voir les comptes qui ont créé des bases de données à partir d’un partage, utilisez la commande SHOW GRANTS OF SHARE . Ceci est différent de la liste des comptes renvoyée par SHOW SHARES :

  • SHOW SHARES répertorie tous les partages disponibles pour les comptes, ainsi que les comptes qui peuvent accéder à chaque partage.

  • SHOW GRANTS OF SHARE répertorie tous les comptes qui ont créé une base de données à partir du partage. Si aucun compte n’a créé de base de données à partir du partage, les résultats sont vides.

Par exemple, l’exemple suivant montre :

  • Deux actions, prvdr1.sales_s et prvdr1.sales_s2, ont été mises à disposition des comptes xy12345 et yz23456.

  • Le compte xy12345 a créé une base de données à partir du partage prvdr1.sales_s.

  • Aucun compte n’a créé de bases de données à partir du partage prvdr1.sales_s2.

SHOW SHARES;

+-------------------------------+----------+-------------------------+-----------------------+------------------+--------------+----------------------------------------+
| created_on                    | kind     | name                    | database_name         | to               | owner        | comment                                |
|-------------------------------+----------+-------------------------+-----------------------+------------------+--------------+----------------------------------------|
| 2016-07-09 19:18:09.821 -0700 | INBOUND  | SFC_SAMPLES.SAMPLE_DATA | SNOWFLAKE_SAMPLE_DATA |                  |              | Sample data sets provided by Snowflake |
| 2017-06-15 17:02:29.625 -0700 | OUTBOUND | PRVDR1.SALES_S          | SALES_DB              | XY12345, YZ23456 | ACCOUNTADMIN |                                        |
| 2017-06-15 17:02:29.625 -0700 | OUTBOUND | PRVDR1.SALES_S2         | SALES_DB              | XY12345, YZ23456 | ACCOUNTADMIN |                                        |
+-------------------------------+----------+-------------------------+-----------------------+------------------+--------------+----------------------------------------+

SHOW GRANTS OF SHARE sales_s;

+-------------------------------+----------------+------------+----------+
| created_on                    | share          | granted_to | account  |
|-------------------------------+----------------+------------+----------|
| 2017-06-15 18:00:03.803 -0700 | PRVDR1.SALES_S | ACCOUNT    | XY12345  |
+-------------------------------+----------------+------------+----------+

SHOW GRANTS OF SHARE sales_s2;

+------------+-------+------------+---------+
| created_on | share | granted_to | account |
|------------+-------+------------+---------|
+------------+-------+------------+---------+

Ajout d’objets à un partage

Vous pouvez ajouter des objets à un partage existant à tout moment en utilisant la commande GRANT <privilège> … TO SHARE. Tous les objets que vous ajoutez à un partage sont instantanément disponibles pour les comptes de consommateur qui ont créé des bases de données à partir du partage. Par exemple, si vous ajoutez une table à un partage, les utilisateurs des comptes de consommateur peuvent interroger les données de la table dès que la table est ajoutée au partage.

Note

  • Si le schéma de l’objet se trouve déjà dans le partage, il vous suffit d’ajouter l’objet.

  • Si le schéma de l’objet n’est pas déjà dans le partage, vous devez d’abord ajouter le schéma, puis l’objet.

L’exemple suivant ajoute une vue sécurisée nommée agg_secure dans le schéma aggregates_eula au partage sales_s :

SHOW GRANTS TO SHARE sales_s;

+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+
| created_on                    | privilege | granted_on | name                                 | granted_to | grantee_name   | grant_option | granted_by   |
|-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------|
| 2017-06-15 16:45:07.307 -0700 | USAGE     | DATABASE   | SALES_DB                             | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
| 2017-06-15 16:45:10.310 -0700 | USAGE     | SCHEMA     | SALES_DB.AGGREGATES_EULA             | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
| 2017-06-15 16:45:12.312 -0700 | SELECT    | TABLE      | SALES_DB.AGGREGATES_EULA.AGGREGATE_1 | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+

GRANT SELECT ON VIEW sales_db.aggregates_eula.agg_secure TO SHARE sales_s;

SHOW GRANTS TO SHARE sales_s;

+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+
| created_on                    | privilege | granted_on | name                                 | granted_to | grantee_name   | grant_option | granted_by   |
|-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------|
| 2017-06-15 16:45:07.307 -0700 | USAGE     | DATABASE   | SALES_DB                             | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
| 2017-06-15 16:45:10.310 -0700 | USAGE     | SCHEMA     | SALES_DB.AGGREGATES_EULA             | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
| 2017-06-15 16:45:12.312 -0700 | SELECT    | TABLE      | SALES_DB.AGGREGATES_EULA.AGGREGATE_1 | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
| 2017-06-17 12:33:15.310 -0700 | SELECT    | TABLE      | SALES_DB.AGGREGATES_EULA.AGG_SECURE  | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+

Suppression d’objets d’un partage

Vous pouvez supprimer des objets d’un partage existant à tout moment en utilisant la commande REVOKE <privilège> … FROM SHARE. Tous les objets que vous supprimez d’un partage sont instantanément indisponibles pour les comptes de consommateur qui ont créé des bases de données à partir du partage. Par exemple, si vous supprimez une table d’un partage, les utilisateurs des comptes de consommateur ne peuvent plus interroger les données de la table dès que la table est supprimée du partage.

L’exemple suivant supprime la vue sécurisée nommée agg_secure dans le schéma aggregates_eula du partage sales_s :

SHOW GRANTS TO SHARE sales_s;

+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+
| created_on                    | privilege | granted_on | name                                 | granted_to | grantee_name   | grant_option | granted_by   |
|-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------|
| 2017-06-15 16:45:07.307 -0700 | USAGE     | DATABASE   | SALES_DB                             | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
| 2017-06-15 16:45:10.310 -0700 | USAGE     | SCHEMA     | SALES_DB.AGGREGATES_EULA             | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
| 2017-06-15 16:45:12.312 -0700 | SELECT    | TABLE      | SALES_DB.AGGREGATES_EULA.AGGREGATE_1 | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
| 2017-06-17 12:33:15.310 -0700 | SELECT    | TABLE      | SALES_DB.AGGREGATES_EULA.AGG_SECURE  | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+

REVOKE SELECT ON VIEW sales_db.aggregates_eula.agg_secure FROM SHARE sales_s;

+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+
| created_on                    | privilege | granted_on | name                                 | granted_to | grantee_name   | grant_option | granted_by   |
|-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------|
| 2017-06-15 16:45:07.307 -0700 | USAGE     | DATABASE   | SALES_DB                             | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
| 2017-06-15 16:45:10.310 -0700 | USAGE     | SCHEMA     | SALES_DB.AGGREGATES_EULA             | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
| 2017-06-15 16:45:12.312 -0700 | SELECT    | TABLE      | SALES_DB.AGGREGATES_EULA.AGGREGATE_1 | SHARE      | PRVDR1.SALES_S | false        | ACCOUNTADMIN |
+-------------------------------+-----------+------------+--------------------------------------+------------+----------------+--------------+--------------+

Ajout de comptes à un partage

Vous pouvez ajouter des comptes à un partage existant à tout moment en utilisant la commande ALTER SHARE. Une fois qu’un compte est ajouté au partage, le partage est immédiatement « visible » pour le compte, et le compte peut créer une base de données à partir du partage et commencer à interroger les objets Snowflake dans la base de données.

Suppression de comptes d’un partage

Vous pouvez supprimer des comptes d’un partage existant à tout moment en utilisant la commande ALTER SHARE. La suppression d’un compte d’un partage invalide instantanément la base de données qu’ils ont créée à partir de ce partage. Toutes les requêtes et autres opérations que les utilisateurs du compte effectuent sur la base de données ne fonctionneront plus.

Vous supprimez un compte d’un partage en définissant une nouvelle liste de comptes pour le partage et en laissant le compte souhaité en dehors de la liste.

Après avoir supprimé un compte d’un partage, vous pouvez l’ajouter à nouveau au partage. Cependant, cela ne restaure pas la base de données créée précédemment à partir du partage. Une nouvelle base de données doit être créée à partir du partage.

Note

Avant de retirer un compte d’un partage, prenez en compte les conséquences en aval que cela aura sur le compte. Comme la base de données est instantanément invalidée, toutes les requêtes et autres opérations que les utilisateurs (dans le compte) effectuent sur la base de données cesseront de fonctionner, ce qui pourrait avoir un impact significatif sur les opérations commerciales du compte.

Destruction d’un partage

Vous pouvez détruire un partage à tout moment à l’aide de la commande DROP SHARE. Détruire un partage invalide instantanément toutes les bases de données créées par les comptes de consommateur à partir du partage. Toutes les requêtes et autres opérations effectuées sur ces bases de données ne fonctionneront plus.

Après avoir détruit un partage, vous pouvez le recréer avec le même nom. Cependant, cela ne restaure aucune des bases de données créées par les comptes de consommateur à partir du partage. Le partage recréé est traité comme un nouveau partage et tous les comptes de consommateur doivent créer une nouvelle base de données à partir du nouveau partage.

Note

Avant de détruire un partage, prenez en compte les conséquences en aval que cela aura sur les comptes de consommateur utilisant le partage.

À la place, vous pouvez envisager de supprimer des objets individuels du partage. Les objets supprimés peuvent être ajoutés de nouveau à un partage sans nécessiter de tâches supplémentaires de la part des comptes de consommateur.