ACCESS_HISTORY 视图¶

列¶

本部分有三个表：

• 第一个表提供每个列值的示例。

• 第二个表定义 ACCESS_HISTORY 视图中的列。

• 第三个表定义 base_objects_accessed、direct_objects_accessed 和 objects_modified 列的 JSON 数组中的字段。

[
  {
    "objectDomain": "FUNCTION",
    "objectName": "GOVERNANCE.FUNCTIONS.RETURN_SUM",
    "objectId": "2",
    "argumentSignature": "(NUM1 NUMBER, NUM2 NUMBER)",
    "dataType": "NUMBER(38,0)"
  },
  {
    "columns": [
      {
        "columnId": 68610,
        "columnName": "CONTENT"
      }
    ],
    "objectDomain": "Table",
    "objectId": 66564,
    "objectName": "GOVERNANCE.TABLES.T1"
  }
]

[
  {
    "objectDomain": "FUNCTION",
    "objectName": "GOVERNANCE.FUNCTIONS.RETURN_SUM",
    "objectId": "2",
    "argumentSignature": "(NUM1 NUMBER, NUM2 NUMBER)",
    "dataType": "NUMBER(38,0)"
  },
  {
    "columns": [
      {
        "columnId": 68610,
        "columnName": "CONTENT"
      }
    ],
    "objectDomain": "Table",
    "objectId": 66564,
    "objectName": "GOVERNANCE.TABLES.T1"
  }
]

[
  {
    "objectDomain": "STRING",
    "objectId":  NUMBER,
    "objectName": "STRING",
    "columns": [
      {
        "columnId": "NUMBER",
        "columnName": "STRING",
        "baseSources": [
          {
            "columnName": STRING,
            "objectDomain": "STRING",
            "objectId": NUMBER,
            "objectName": "STRING"
          }
        ],
        "directSources": [
          {
            "columnName": STRING,
            "objectDomain": "STRING",
            "objectId": NUMBER,
            "objectName": "STRING"
          }
        ]
      }
    ]
  },
  ...
]

{
  "objectDomain": STRING,
  "objectName": STRING,
  "objectId": NUMBER,
  "operationType": STRING,
  "properties": ARRAY
}

[
  {
    "columns": [
      {
        "columnId": 68610,
        "columnName": "SSN",
        "policies": [
          {
              "policyName": "governance.policies.ssn_mask",
              "policyId": 68811,
              "policyKind": "MASKING_POLICY"
          }
        ]
      }
    ],
    "objectDomain": "VIEW",
    "objectId": 66564,
    "objectName": "GOVERNANCE.VIEWS.V1",
    "policies": [
      {
        "policyName": "governance.policies.rap1",
        "policyId": 68813,
        "policyKind": "ROW_ACCESS_POLICY"
      }
    ]
  }
]

下面介绍 direct_objects_accessed、base_objects_accessed、objects_modified 和 policies_referenced 列的 JSON 数组中的字段。

下面介绍了 object_modified_by_ddl 列的字段。

对于 properties 字段：

• 原子性：每个属性有一个值（例如，comment 有一个字符串值，enabled 属性是布尔值，并且有一个值）。

• 复合性：每个属性有多个值（例如 allowed_values 适用于标签、掩码策略）。

复合属性以 JSON 数组记录。例如，如果表包含名为 EMAIL 的单个列，则该列记录如下：

columns: {
  "email": {
    objectId: {
      "value": 1
    },
    "subOperationType": "ADD"
  }
}

subOperationType 可以是以下其中一项：

• ADD 指定添加复合属性（例如，添加列、设置允许的值）。

• DROP 指定移除复合属性。

• ALTER 指定修改复合属性。

objectId 指定列或对象的标识符，但没有标识符的允许标签值除外。

使用说明¶

延迟和历史数据:

• 该视图显示从 2021 年 2 月 22 日起的数据。

• 视图的延迟时间最长可达 180 分钟（3 小时）。

祖先查询:

从 2024 年 1 月 15 日至 16 日开始，parent_query_id 和 root_query_id 列开始记录数据，具体取决于您的 Snowflake 账户基于 2023_08 行为变更捆绑包过渡到默认启用的更新时间。此日期是区分视图中的以下记录所必需的：

• 在捆绑包默认启用之前运行的查询。

• 在功能默认启用之后运行但 parent_query_id 中没有值的查询。

混合表:

专门针对混合表运行的短期查询将不再在 QUERY_HISTORY 视图、QUERY_HISTORY 或 QUERY_HISTORY 表函数的输出中生成记录。要监控此类查询，请使用 AGGREGATE_QUERY_HISTORY。

要监控此类查询的访问历史记录，请使用 AGGREGATE_ACCESS_HISTORY。通过此视图，您可以更轻松地监控访问历史记录的高吞吐量操作工作负载。

一般注意事项:

• 为提高性能，请筛选对 query_start_time 列的查询，并选择更窄的时间范围。有关示例查询，请参阅 查询 ACCESS_HISTORY 视图。

• 安全视图。日志记录包含用于生成视图的基础基表（即 base_objects_accessed）。示例包括对其他 Account Usage 和 Organization Usage 视图的查询，以及对用于提取、转换和加载（即 ETL）操作的基表的查询。

• QUERY_HISTORY 视图中的记录并不总是记录在 ACCESS_HISTORY 视图中。SQL 语句的结构决定 Snowflake 是否在 ACCESS_HISTORY 视图中记录一个条目。

• 在查询此视图时指定 USING 子句，这可能会导致在 direct_objects_accessed 字段中记录未引用的列。解决方法是将 USING 子句替换为 JOIN ... ON ... 子句。有关详细信息，请参阅：

  • JOIN 和 USING （JOIN 参考主题内容）

  • 跟踪敏感的暂存区数据移动 （访问历史记录查询示例内容）

读取查询说明:

该视图支持以下类型的 读取 查询：

• SELECT，包括 CREATE TABLE ...AS SELECT（即 CTAS）。

  • Snowflake 在 CTAS 操作中记录 SELECT 子查询。

• CREATE TABLE ... CLONE

  • Snowflake 在 CLONE 操作中记录源表。

• COPY INTO ... TABLE

  • 仅 当表在 FROM 子句中指定为源时，Snowflake 才会记录此查询。

• 读取数据的 DML 操作（例如，包含 SELECT 子查询、在 WHERE 或 JOIN 中指定某些列）：INSERT ... SELECT、UPDATE、DELETE 和 MERGE。

• UDFs 和 表格 SQL UDFs (UDTFs)，如果函数内的查询包含表。这在 base_objects_accessed 字段中进行记录。

  有关 UDFs 的更多详细信息，请参阅 UDF 说明 （本主题内容）。

写入操作说明:

此视图支持以下类型的 写入 操作：

• GET <internal_stage>

• PUT <internal_stage>

• DELETE

• TRUNCATE

• INSERT

  • INSERT INTO ...FROM SELECT *

  • INSERT INTO TABLE ... VALUES ()

• MERGE INTO ...FROM SELECT *

• UPDATE

  • UPDATE TABLE ...FROM SELECT * FROM ...

  • UPDATE TABLE ... WHERE ...

• 数据加载语句：

  • COPY INTO TABLE FROM internalStage

  • COPY INTO TABLE FROM externalStage

  • COPY INTO TABLE FROM externalLocation

• 数据卸载语句：

  • COPY INTO internalStage FROM TABLE

  • COPY INTO externalStage FROM TABLE

  • COPY INTO externalLocation FROM TABLE

• CREATE：

  • CREATE DATABASE ... CLONE

  • CREATE SCHEMA ... CLONE

  • CREATE TABLE ... CLONE

  • CREATE TABLE ...AS SELECT

• 对于调用 CASE 函数以确定要访问的列的写入操作（例如 SELECT 查询中采用 CASE 函数的 CTAS 语句），每个 CASE 分支中引用的所有列都记录于 base_objects_accessed 列、direct_objects_accessed 列或这两列，具体取决于 CTAS 语句的写入方式。

数据共享说明:

如果数据共享提供商账户通过共享，将对象共享给数据共享使用者账户：

• 提供商账户： 在提供商账户中执行的共享对象的查询和日志不对数据共享使用者账户可见。

• 使用者账户： 对使用者账户中的数据共享执行的查询会记录下来，并且仅对使用者账户可见，而对数据共享提供商账户不可见。

  例如，如果提供商向使用者账户共享一个表和根据此表构建的视图，并且发生对该共享视图的查询，则 Snowflake 会在 base_objects_accessed 列内记录对该共享视图的访问。此记录包含 columnName 和 objectName 值，可让使用者知道在其账户中访问了哪个对象，并且还保护了提供商，因为基础表（通过 objectId 和 columnId 标识）不会透露给使用者。

• 对于列沿袭：

  如果数据共享提供商向数据共享使用者提供视图，则该视图的源列对使用者不可见，因为这些列源自数据共享提供商。

  如果数据共享使用者将数据从共享视图移动到表，则 Snowflake 不会将视图列记录为新建表的 baseSources。

• 对于共享 UDFs 和 UDTFs：

  • 在使用者账户中，本地 ACCESS_HISTORY 视图记录 UDF/UDTF（在使用者调用共享 UDF/UDTF 时，由提供商共享）。

  • 在提供商账户中，本地 ACCESS_HISTORY 视图记录共享 UDF/UDTF 的提供商使用情况。使用者账户中的用户无法查看提供商账户如何使用共享 UDF/UDTF。

• 对于跟踪策略参考：

  policies_referenced 列包含数据查询账户的本地策略。

  如果提供商共享受策略保护的表，并且使用者访问此表，则使用者无法看到提供商对表或其列设置的策略。

  如果使用者从共享对象创建视图 (v1)，将策略设置为视图 (v1) 或其列，并且使用者账户中的用户访问受保护的视图 (v1) 或从受保护的视图 (v1) 创建的另一个视图 (v2)，则使用者账户中的 ACCESS_HISTORY 视图包含用于保护视图 (v1) 及其列的策略。提供商无法看到 v1 对应的记录。

Snowflake Native App Framework 说明:

一些与 Snowflake Native App 相关的查询被隐去了。有关详细信息，请参阅 从 SQL 命令和视图中隐去的信息。

基于标签的掩码说明:

如果用户访问受 基于标签的掩码策略 保护的表或视图，则当 Snowflake 对受保护的列强制实施掩码策略时，policies_referenced 列包含通过标签应用的掩码策略。

ACCESS_HISTORY 视图不记录任何标签信息。

UDFs 和存储过程说明:

这些说明适用于所有语言的外部函数、UDFs 和 UDTFs，包括当这些函数具有 SECURE 属性，以及具有所有者权限和调用方权限的存储过程时：

列详细信息：

• direct_objects_accessed 列记录查询中对这些函数和过程的显式提及。

  Snowflake 不记录此列中嵌套的 UDFs（即，在其他 UDF 的定义中提到的 UDF）。

• base_objects_accessed 列记录在查询中调用的外部函数、共享函数、非 SQL UDFs 和存储过程。

• objects_modified 列记录：

  • 调用函数的结果将结果复制到另一列时的 UDF/UDTF。

  • UDF、UDTF 和外部函数可以在 baseSources 和 directSources 的数组中记录，具体取决于查询的写入方式。

不支持:

此视图 不 记录以下类型的访问：

• Snowflake 提供的 表函数、Account Usage 视图和 Organization Usage 视图。

• RESULT_SCAN，用于获得先前的结果。

• 序列，包括生成新值。

• 在基表和直接对象之间访问的中间视图。

  例如，考虑使用以下对象结构对 View_A 执行的查询：View_A » View_B » View_C » Base_Table。

  ACCESS_HISTORY 视图记录对 View_A 和 Base_Table（不是 View_B 和 View_C）执行的查询。

• 用于更新流的操作。

• 复制导致的数据移动。

使用说明：列沿袭¶

这些附加说明与列沿袭有关：

支持的操作:

列沿袭跟踪以下 SQL 操作的详细信息：

• CREATE TABLE ...AS SELECT (CTAS)

• CREATE TABLE ...CLONE

• INSERT ... SELECT ...

• MERGE

• UPDATE，两种可能的变体，例如：

  • 自我更新：

    UPDATE mydb.s1.t1 SET col_1 = col_1 + 1;
    

    Copy

  • 两表更新：

    UPDATE mydb.s1.t1 FROM mydb.s2.t2 SET t1.col1 = t2.col1;
    

    Copy

• ALTER TABLE ...RENAME TO

查询条件:

• 查询配置文件/计划

  Snowflake 写入的查询计划确定 ACCESS_HISTORY 视图是否包含列沿袭。如果需要将列作为查询计划的一部分进行评估，则即使查询计划的最终结果表明该列未包含在最终结果中，Snowflake 也会在 ACCESS_HISTORY 视图中包含该列。

  例如，考虑以下 INSERT 语句，其中包含针对特定列值的 WHERE 子句：

  insert into a(c1)
  select c2
  from b
  where c3 > 1;
  

  Copy

  即使 WHERE 子句的计算结果为 FALSE，Snowflake 也会将 c2 列记录为 c1 列的源列。c3 列未列为 baseSources 或 directSources 的源列。

• 掩码列：

  • 掩码列始终在 directSources 字段中列出。

  • baseSources 字段中的记录取决于策略定义。例如：

    • 如果掩码策略条件使用 CASE 函数，则每个 CASE 分支中引用的所有列都在 baseSources 字段中记录。

    • 如果掩码策略条件仅指定一个常量值（例如 *****），则 baseSources 字段为空。

• UDFs：

  • 将一列作为实参传递给 UDF 并将结果写入另一列时，作为实参传递的列在 directSources 字段中记录。例如：

    insert into A(col1) select f(col2) from B;
    

    Copy

    在此示例中，Snowflake 在 directSources 字段中记录 col2，因为该列是针对名为 f 的 UDF 的实参。

  • baseSources 字段中的记录取决于 UDF 定义。

视图列：:

将视图列中的数据复制到表列时，视图列不被视为源列，并且不会在 baseSources 字段中列出。在本案例中，视图列在 directSources 字段中列出。

EXISTS 子查询:

EXISTS 子查询中引用的列不被视为源列。

使用说明：object_modified_by_ddl 列¶

• IF [ NOT ] EXISTS 子句：object_modified_by_ddl 列仅在创建或修改对象时记录 CREATE 或 REPLACE。

• Snowflake 支持以下对象域。

  • 表和外部表。

  • 视图和物化视图

  • 架构

  • 数据库。

该列根据以下 SQL 操作记录这些更改。DROP 和 UNDROP 操作适用于表和视图，而不是列。

CREATE OR REPLACE

ALTER ... { SET | UNSET }

ALTER ... ADD ROW ACCESS POLICY

ALTER ... DROP ROW ACCESS POLICY

ALTER ... DROP ALL ROW ACCESS POLICIES

DROP | UNDROP

下表总结了 DDL 操作、支持的域和 Snowflake 记录的属性之间的关系。