ACCESS_HISTORY 视图¶

列¶

本部分包含执行以下操作的表：

• 为每列提供示例值。

• 提供视图中每列的描述。

• 为 base_objects_accessed、direct_objects_accessed 和 objects_modified 列的 JSON 数组中的每个字段提供描述。

• 为 object_modified_by_ddl 列的对象中的每个字段提供描述。

[
  {
    "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"
      }
    ]
  }
]

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

CREATE EXTERNAL LISTING my_listing SHARE my_share
  AS $$my_manifest$$

"manifest": {
  "value": "my_manifest"
},
"share": {
  "value": "my_share"
}

ALTER LISTING my_listing
  AS $$my_manifest$$

"manifest": {
  "value": "my_manifest"
}

ALTER LISTING my_listing
  ADD TARGETS $$my_targets_manifest$$;

"addTargets": {
  "value": "my_targets_manifest"
}

ALTER LISTING my_listing
  REMOVE TARGETS $$my_targets_manifest$$;

"removeTargets": {
  "value": "my_targets_manifest"
}

ALTER LISTING my_listing
  ADD VERSION V3
  FROM @listing_db.listing_schema.stage1;

"manifestStageLocation": {
  "value": "@listing_db.listing_schema.stage1"
},
"versionAlias": {
  "value": "V3"
}

CREATE SHARE my_share
  SECURE_OBJECTS_ONLY=FALSE;

"secureObjectsOnly": {
  "value": false
}

ALTER SHARE my_share
  SET ACCOUNTS = acc1, acc2;

"accountsToSet": {
  "value": [ "acc1", "acc2" ]
}

ALTER SHARE my_share
  ADD ACCOUNTS = acc1, acc2
  SHARE_RESTRICTIONS = false;

"accountsToAdd": {
 "value": [ "acc1", "acc2" ]
},
"shareRestrictions": {
  "value": false
}

ALTER SHARE my_share
  REMOVE ACCOUNTS = acc1, acc2;

"accountsToRemove": {
  "value": [ "acc1", "acc2" ]
}

使用说明¶

延迟和历史数据:

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

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

祖先查询:

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

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

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

一般注意事项:

• 为提高性能，请筛选对 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 字段中进行记录。

写入操作说明:

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

• 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 对应的记录。

混合表:

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

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

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,用于获得先前的结果。

• 对 序列 执行 DDL 操作时会生成访问历史记录。当序列用于任何其他操作（包括生成新值）时，则不会生成访问历史记录。

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

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

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

• 用于更新 Streams 的操作。

• 复制导致的数据移动。

• 失败的查询虽然已记录在 QUERY_HISTORY 视图中，但 不会 记录在 ACCESS_HISTORY 视图中。

使用说明：列沿袭¶

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

支持的操作:

列沿袭跟踪以下 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。

该列根据以下 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 记录的属性之间的关系。