Bundle 2022_06¶

Groupes de réplication : types d’objets limités aux bases de données et aux partages pour les comptes qui ne sont pas de la Business Critical Edition¶

La fonction de réplication de compte prend en charge la réplication des objets de compte, notamment les utilisateurs, les rôles, les bases de données et les partages. Pour la liste complète des types d’objets pris en charge, voir Objets répliqués. Les groupes de réplication peuvent inclure tout ou partie des types d’objets pris en charge.

Le comportement a changé comme suit :

Précédemment

Tous les types d’objets de réplication de compte pris en charge peuvent être inclus dans un groupe de réplication.

Actuellement

La prise en charge des types d’objets pouvant être ajoutés à un groupe de réplication pour les comptes qui ne sont pas Business Critical Edition (ou supérieur) est limitée aux bases de données et aux partages.

Consultez le tableau de prise en charge des fonctionnalités de réplication de compte pour plus de détails sur la prise en charge des fonctionnalités par édition.

Stockage Fail-safe : correction d’un bogue pour les cas particuliers entraînant une sous-facturation¶

En raison d’une erreur interne du système, certaines tables permanentes n’ont pas été facturées pour le stockage d’octets Fail-safe. Plus précisément, si une table temporaire est créée en tant que clone d’une table permanente, et que la table permanente est ensuite détruite, Snowflake n’a pas facturé le stockage Fail-safe de la table permanente.

La facturation de Fail-safe a changé comme suit :

Précédemment

Certaines tables permanentes n’ont pas été facturées pour le stockage Fail-safe.

Actuellement

Les clients sont facturés pour le stockage Fail-safe de toutes les tables permanentes.

Commandes CREATE DATABASE et CREATE SCHEMA : une clause OR REPLACE entraîne des références pendantes pour les politiques¶

Le comportement des commandes CREATE DATABASE et CREATE SCHEMA a changé comme suit :

Précédemment

Snowflake a permis aux commandes CREATE OR REPLACE DATABASE et CREATE OR REPLACE SCHEMA de s’exécuter sur la base de données ou le schéma contenant une politique de masquage ou une politique d’accès aux lignes qui protègent un objet dans une base de données ou un schéma différent. Par exemple :

• Une politique de masquage nommée db1.s1.p1 protège une colonne nommée db2.s1.t1.c1.

• Une politique d’accès aux lignes nommée db1.s1.p2 protège une table nommée db2.s1.t1.

Le résultat était une référence pendante qui faisait échouer toutes les requêtes sur la colonne ou l’objet.

Notez que ce comportement s’applique également aux instructions CLONE telles que CREATE OR REPLACE SCHEMA S1 CLONE S2;.

Actuellement

La commande CREATE OR REPLACE DATABASE ou CREATE OR REPLACE SCHEMA échoue si le résultat est une référence pendante sur un objet protégé par une politique. Snowflake renvoie l’un des messages d’erreur suivants :

• Pour CREATE OR REPLACE DATABASE : Cannot drop database because: Policy '<db.schema.policy>' used by schema '<db.schema>' in another database

• Pour CREATE OR REPLACE SCHEMA : Cannot drop schema because: Policy '<db.schema.policy>' used by another schema '<db.schema>'

Si l’un des deux messages d’erreur apparaît, interrogez la vue Account Usage POLICY_REFERENCES, utilisez un rôle pour désactiver la politique de masquage ou d’accès aux lignes, puis réessayez l’instruction CREATE OR REPLACE.

Par exemple :

1. Interrogez la vue :

   • Références de politique inter-schémas qui doivent être supprimées avant le remplacement :

     select * from snowflake.account_usage.policy_references
     where policy_db=<policy_db> and
     policy_schema=<policy_schema_to_replace> and ref_schema_name != <policy_schema>;
     

     Copy

   • Références de politique inter-base de données qui doivent être supprimées avant le remplacement :

     select * from snowflake.account_usage.policy_references
     where policy_db=<policy_db_to_replace>’ and ref_database_name != <policy_db>;
     

     Copy

2. Désactiver les politiques :

   • Pour les politiques de masquage :

     alter table <table_name> modify column <col_name> unset masking policy;
     

     Copy

   • Pour les politiques d’accès aux lignes :

     alter table <table_name> drop all row access policies;
     

     Copy

3. Réessayer la commande CREATE OR REPLACE.

Notez que, avec les opérations CLONE, vous devez stocker les objets de politique dans une base de données ou un schéma distinct avant d’exécuter les instructions CLONE.

Fonction INFER_SCHEMA : nouvelle colonne ORDER_ID dans la sortie¶

La sortie de la fonction INFER_SCHEMA comprend maintenant une nouvelle colonne ORDER_ID qui indique l’ordre des colonnes dans les fichiers en zone de préparation.

Actuellement, lorsque vous créez une table avec les définitions de colonnes dérivées d’un ensemble de fichiers en zone de préparation (en utilisant CREATE TABLE … USING TEMPLATE), l’ordre des colonnes dans la table est aléatoire. Bien que l’ordre des colonnes de la table n’ait pas d’importance pour Snowflake, cela peut être source de confusion lorsque vous comparez l’ordre des colonnes du fichier à celui de la table. La nouvelle colonne ORDER_ID dans la sortie INFER_SCHEMA peut vous aider à vous assurer que les tables créées avec le schéma détecté ont le même ordre des colonnes.

Vous pouvez récupérer le schéma de n’importe quel fichier en utilisant INFER_SCHEMA, comme le montre l’exemple suivant. La sortie inclut une nouvelle colonne ORDER_ID et est triée par ORDER_ID automatiquement pour le scénario à schéma unique :

SELECT *
  FROM TABLE(
  INFER_SCHEMA(
  LOCATION=>'@***_****_STAGE/' , FILE_FORMAT=>'FFPARQUET'
  )
  );

Copy

De même, vous pouvez créer une table en utilisant le schéma détecté à partir de fichiers en zone de préparation et trier les colonnes par ORDER_ID, comme le montre l’exemple suivant :

CREATE OR REPLACE TABLE BIG_TABLE
  USING TEMPLATE (
  SELECT ARRAY_AGG(OBJECT_CONSTRUCT(*))
  WITHIN GROUP (ORDER BY ORDER_ID) // NEW
  FROM TABLE( INFER_SCHEMA(LOCATION=>'@***_****_STAGE/', FILE_FORMAT=>'FFPARQUET')
  )
  );

DESC TABLE BIG_TABLE;

Copy

Notez que le tri des colonnes par ORDER_ID ne s’applique que si tous les fichiers en zone de préparation partagent un même schéma. Si l’ensemble des fichiers de données mis à disposition comprend plusieurs schémas avec des noms de colonnes partagés, l’ordre représenté dans la colonne ORDER_ID peut ne pas correspondre à un seul fichier.

FUNCTIONS Vue (Account Usage) : nouvelles colonnes dans vue¶

La sortie de la vue Account Usage FUNCTIONS comprend maintenant les nouvelles colonnes suivantes :