2022_02 捆绑包¶

分层数据查询：不再强制执行迭代限制¶

查询分层数据时，可以使用 递归 CTEs 或 CONNECT BY 命令 迭代访问层次结构的每个级别。

此前的迭代次数限制设置为 100 次（由 Snowflake 内部设置），现在不再强制执行：

之前:

如果查询超过最大迭代次数（100 次），则查询失败，并且系统会显示以下错误消息：

Recursion exceeded max iteration count (n)

其中 n 是允许的最大迭代次数。

此错误的错误代码为 100189。

现在:

执行的迭代次数没有限制。

此前会出现上述错误消息的查询（特别是导致无限循环的查询）不会再失败并将继续运行，直到查询成功或超时为止，这可以通过设置 STATEMENT_TIMEOUT_IN_SECONDS 参数来控制。

要确定在启用变更之前是否有超过最大迭代次数的查询，请检查 QUERY_HISTORY 视图中是否存在错误代码为 100189 的失败查询：

SELECT * FROM snowflake.account_usage.query_history WHERE error_code = 100189;

Copy

启用变更后，如果执行了这些相同的查询，这些查询将不会失败。如果发生无限循环，查询不会提前终止。相反，查询将一直运行，直到其成功或超时（例如，超过 STATEMENT_TIMEOUT_IN_SECONDS 参数中设置的秒数）。

有关无限循环如何发生、如何识别无限循环以及如何纠正无限循环的信息，请参阅 对递归 CTE 进行故障排除。

Time Travel：瞬态表中保留继承的 DATA_RETENTION_TIME_IN_DAYS 参数¶

当父对象（账户、数据库或架构）的 DATA_RETENTION_TIME_IN_DAYS 参数显式设置为 0 （天）时，瞬态表 的行为已更改，如下所示：

之前:

当数据保留时间为 0 天时，瞬态表不会从父对象中继承 DATA_RETENTION_TIME_IN_DAYS 参数设置。创建的瞬态表的数据保留时间为 1 天，与父对象的数据保留时间无关。

现在:

如果将父对象（架构、数据库、账户）的 DATA_RETENTION_TIME_IN_DAYS 设置为 0，则瞬态表将继承父对象上设置的数据保留时间。

要在账户中生成瞬态表列表，且其中至少一个父表（架构或数据库）的 DATA_RETENTION_TIME_IN_DAYS 设置为 0，请执行以下示例中的语句。但是，在执行语句之前，请注意以下事项：

• 该列表包括 DATA_RETENTION_TIME_IN_DAYS 参数 显式 设置为 1 的瞬态表。

  在 账户级别 中，如果将 DATA_RETENTION_TIME_IN_DAYS 设置为 0 ，则执行下面第二个示例中的语句集以列出所有将 DATA_RETENTION_TIME_IN_DAYS 设置为 1 的瞬态表。

• 在取消设置任何表的参数之前，我们建议您验证是否应为该表禁用 Time Travel 函数。

show tables in account;
set
  table_qid = (
    select
      last_query_id()
);

show schemas in account;
set
  schema_qid = (
    select
      last_query_id()
);

show databases in account;
set
  database_qid = (
    select
      last_query_id()
);

with table_v as (
    select
      "database_name" as database_name,
      "schema_name" as schema_name,
      "name" as table_name,
      "kind" = 'TRANSIENT' as is_transient,
      "retention_time" as table_retention_time
    from
      table(result_scan($table_qid))
  ),
  schema_v as (
    select
      "name" as schema_name,
      iff(
        try_to_number("retention_time") is null,
        0,
        try_to_number("retention_time")
      ) as schema_retention_time
    from
      table(result_scan($schema_qid))
  ),
  database_v as (
    select
      "name" as database_name,
      "retention_time" as database_retention_time
    from
      table(result_scan($database_qid))
  )
select
  *
from
  table_v
  left join schema_v using (schema_name)
  left join database_v using (database_name)
where
  is_transient
  and table_retention_time = 1
  and (
    schema_retention_time = 0
    or database_retention_time = 0
  );

Copy

在 账户级别 中，如果将 DATA_RETENTION_TIME_IN_DAYS 设置为 0 ，则执行以下语句以列出所有将 DATA_RETENTION_TIME_IN_DAYS 设置为 1 的瞬态表：

-- Verify account level DATA_RETENTION_TIME_IN_DAYS setting is 0
show parameters like 'DATA_RETENTION_TIME_IN_DAYS' in account;

show tables in account;

select
  "database_name" as database_name,
  "schema_name" as schema_name,
  "name" as table_name,
  "kind" = 'TRANSIENT' as is_transient,
  "retention_time" as table_retention_time
from
  table(result_scan(last_query_id()))
where
  is_transient
  and table_retention_time = 1;

Copy

要取消设置现有瞬态表中的 DATA_RETENTION_TIME_IN_DAYS 参数，以允许它从父对象中继承参数设置，请使用 ALTER TABLE：

ALTER TABLE <table_name> UNSET DATA_RETENTION_TIME_IN_DAYS;

Copy

要验证在表上设置的数据保留时间，请使用 SHOW TABLES：

SHOW TABLES LIKE '<table_name>';

Copy

SHOW ORGANIZATION ACCOUNTS 命令：新列¶

以下列已添加到 SHOW TAGS 命令的输出中：

SHOW PROCEDURES 命令：输出包括用户创建的存储过程和内置存储过程¶

Snowflake 支持在账户的任何数据库中将存储过程创建为架构级对象。SHOW PROCEDURES 命令会返回有关这些用户创建的存储过程的信息。

随着 数据分类 的引入，Snowflake 现在还提供了可作为全局对象调用的内置存储过程，类似于内置函数。

为支持内置存储过程， SHOW PROCEDURES 命令的输出已做出如下更改：

之前:

该命令仅返回当前或指定的数据库/架构（或整个账户）中用户创建的存储过程。

要查看 Snowflake 提供的内置存储过程，可以在命令中使用 BUILTIN 关键字。例如：

SHOW BUILTIN PROCEDURES;

Copy

但是，请注意，Snowflake 仅提供单个内置存储过程， ASSOCIATE_SEMANTIC_CATEGORY_TAGS。

现在:

该函数返回所有存储过程，包括用户创建的存储过程和内置存储过程。

这会使 SHOW PROCEDURES 命令与 SHOW FUNCTIONS 命令一致。

此更改不会影响 BUILTIN 或 USER 关键字，这些关键字可用于显式返回内置或用户创建的存储过程。例如：

SHOW BUILTIN PROCEDURES;

SHOW USER PROCEDURES;

Copy

SYSTEM$ESTIMATE_SEARCH_OPTIMIZATION_COSTS 函数：更改估算基础¶

SYSTEM$ESTIMATE_SEARCH_OPTIMIZATION_COSTS 是一个系统函数，通过调用该函数，您可以确定向表添加 搜索优化 的估算成本。

该函数已更改为使用小样本作为估算成本的基础。通过此更改，该函数报告的成本估算更加准确。但是，此更改会影响函数的仓库使用和输出，并可能影响函数的性能，如下所述：

之前:

该函数使用简单的模型来估算成本。因为该函数使用简单的模型来估算成本：

• 调用该函数时，无需使用仓库。

• 由于该函数未使用仓库，因此您无需为此函数使用仓库付费。

• 函数在数秒内执行并返回。

• 在返回的 JSON 输出中，对于 costPositions 数组中名为 BuildCosts 和 StorageCosts 的对象：

  • 没有 comment 字段。

  • computationMethod 字段设置为 "EstimatedUpperBound"。

现在:

现在，该函数现在从指定表中采用一小部分数据样本，生成临时搜索访问路径，分析该过程的成本，并推断结果以估计整个表的成本。由于该函数使用采样来估算成本：

• 要调用该函数，需要有一个正在使用的仓库。如果当前没有正在使用的仓库，该函数将打印以下消息：

  No active warehouse selected in the current session.

  使用 USE WAREHOUSE 命令选择活动仓库。要执行此函数，您可以使用 X- 小仓库。仓库大小对此函数的速度和性能没有影响。

• 由于该函数使用仓库，因此现在需要为此函数使用仓库付费。

• 该函数需要更长的时间来执行和返回结果（大约在 20 秒到 10 分钟之间）。如上所述，更大规模的仓库并不会加快此函数的执行速度。

• 在返回的 JSON 输出中，对于 costPositions 数组中名为 BuildCosts 和 StorageCosts 的对象：

  • 将 comment 字段设置为 "estimated via sampling"。

  • 将 computationMethod 字段设置为 "Estimated"。

LOGIN_HISTORY 视图 (Account Usage)：新列¶

以下新列已添加到 ACCOUNT_USAGE.LOGIN_HISTORY 视图中：

QUERY_HISTORY 视图 (Account Usage)：输出与 QUERY_HISTORY 函数一致¶

入站和出站数据传输字节的值在以下各项之间不一致：

• ACCOUNT_USAGE.QUERY_HISTORY 和 READER_ACCOUNT_USAGE.QUERY_HISTORY 视图

• INFORMATION_SCHEMA.QUERY_HISTORY 表函数输出

当数据传输云值（分别为 INBOUND_DATA_TRANSFER_CLOUD 或 OUTBOUND_DATA_TRANSFER_CLOUD 时）为 Null 时，Account Usage 视图包括入站和出站数据传输字节。

这些视图已做出如下更改：

之前:

ACCOUNT_USAGE 和 READER_ACCOUNT_USAGE 中的 QUERY_HISTORY 视图包括以下内容：

• 当 INBOUND_DATA_TRANSFER_BYTES 值为 Null 时， INBOUND_DATA_TRANSFER_CLOUD 列包含数据传输字节。

• 当 OUTBOUND_DATA_TRANSFER_BYTES 值为 Null 时， OUTBOUND_DATA_TRANSFER_CLOUD 列包含数据传输字节。

现在:

现在，视图与 INFORMATION_SCHEMA.QUERY_HISTORY 表函数的输出一致。

当 INBOUND_DATA_TRANSFER_CLOUD 或 OUTBOUND_DATA_TRANSFER_CLOUD 值为 Null 时， INBOUND_DATA_TRANSFER_BYTES 和 OUTBOUND_DATA_TRANSFER_BYTES 列不包括来自文件传输的字节。

DESCRIBE STREAM / SHOW STREAM 命令：输出中的新列¶

DESCRIBE STREAM 和 SHOW STREAMS 命令的输出现在包括以下新列：

新列已插入到现有 TABLE_NAME 列和 TYPE 列之间。

目录表：创建暂存区时自动刷新一次元数据¶

现在，创建包含目录表的暂存区时，目录表元数据会立即自动刷新一次。刷新目录表元数据会将元数据与指定暂存区路径中的当前数据文件列表同步。

此前，为了在目录表元数据中注册现有数据文件，用户必须在创建暂存区后执行 ALTER STAGE ...REFRESH 语句。

这一改进是通过为 CREATE STAGE 命令新增 REFRESH_ON_CREATE 参数实现的。当 REFRESH_ON_CREATE = TRUE（默认值）时，Snowflake 会在创建暂存区时自动刷新一次目录表元数据。