2022_06 捆绑包¶

复制组：对象类型仅限于非 Business Critical Edition 账户的数据库和共享¶

账户复制功能支持复制账户对象，包括用户、角色、数据库和共享。有关支持的对象类型的完整列表，请参阅 复制对象。复制组 可以包括任何或所有支持的对象类型。

此行为已更改，如下所示：

之前:

所有支持的账户复制对象类型都可包含在复制组中。

现在:

对于非 Business Critical Edition（或更高版本）账户，可添加到复制组的对象类型支持仅限于数据库和共享。

有关各版本功能支持的更多详细信息，请参阅账户复制 功能支持表。

故障安全存储：针对导致计费不足的极端情况进行错误修复¶

由于内部系统错误，某些永久表未按 故障安全 字节存储计费。具体来说，如果创建瞬态表作为永久表的克隆，并且随后删除永久表，Snowflake 不会为永久表的故障安全存储付费。

故障安全计费已更改如下：

之前:

某些永久表不为故障安全存储计费。

现在:

客户需为所有永久表的故障安全存储付费。

CREATE DATABASE 和 CREATE SCHEMA 命令： OR REPLACE 子句导致策略出现悬空引用¶

CREATE DATABASE 和 CREATE SCHEMA 命令的行为已更改如下：

之前:

Snowflake 允许在包含掩码策略或行访问策略的数据库或架构上执行 CREATE OR REPLACE DATABASE 和 CREATE OR REPLACE SCHEMA 命令，用于保护不同数据库或架构中的对象。例如：

• 名为 db1.s1.p1 的掩码策略保护名为 db2.s1.t1.c1 的列。

• 名为 db1.s1.p2 的行访问策略保护名为 db2.s1.t1 的表。

结果会产生悬空引用，导致对该列或对象的所有查询失败。

请注意，此行为也适用于 CLONE 语句，例如 CREATE OR REPLACE SCHEMA S1 CLONE S2;。

现在:

如果结果是受策略保护的对象上的悬空引用， CREATE OR REPLACE DATABASE 或 CREATE OR REPLACE SCHEMA 命令将失败。Snowflake 返回以下任一错误消息：

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

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

如果出现以上两种错误消息，请查询 Account Usage POLICY_REFERENCES 视图，使用角色取消设置掩码或行访问策略，然后重试 CREATE OR REPLACE 语句。

例如：

1. 查询视图：

   • 替换之前需要删除的 跨架构 策略引用：

     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

   • 替换之前需要删除的 跨数据库 策略引用：

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

     Copy

2. 取消设置策略：

   • 掩码策略：

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

     Copy

   • 行访问策略：

     alter table <table_name> drop all row access policies;
     

     Copy

3. 重试 CREATE OR REPLACE 命令。

请注意，对于 CLONE 操作，您应该在运行 CLONE 语句之前将策略对象存储在单独的数据库或架构中。

INFER_SCHEMA 函数：输出中新增 ORDER_ID 列¶

INFER_SCHEMA 函数的输出现在包括一个新的 ORDER_ID 列，用于指示暂存文件中的列顺序。

目前，当您使用从一组暂存文件导出的列定义创建表时（使用 CREATE TABLE ...USING TEMPLATE），表中的列顺序是随机的。虽然表列顺序对 Snowflake 来说并不重要，但当您比较文件列顺序和表列顺序时，这可能会造成混乱。INFER_SCHEMA 输出中的新 ORDER_ID 列可帮助您确保使用检测到的架构创建的表具有相同的列顺序。

您可以使用 INFER_SCHEMA 检索任何文件的架构，如以下示例所示。输出包含一个新列 ORDER_ID 并且单架构场景中按 ORDER_ID 自动排序：

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

Copy

此外，您可以使用从暂存文件中检测到的架构创个表，并按 ORDER_ID 对列进行排序，如以下示例所示：

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

请注意，按 ORDER_ID 对列排序仅适用于所有暂存文件共享一个架构的情况。如果暂存数据文件集包含具有共享列名的多个架构，则 ORDER_ID 列中表示的顺序可能与任何单个文件不匹配。

FUNCTIONS 视图 (Account Usage)：视图中的新列¶

Account Usage FUNCTIONS 视图的输出现在包括以下新列：