ACCESS_HISTORY ビュー¶

列¶

このセクションには3つのテーブルがあります。

• 最初のテーブルは、各列の値の例を示しています。

• 2番目のテーブルは、 ACCESS_HISTORY ビューの列を定義します。

• 3番目のテーブルは、 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 フィールドの場合は、

• アトミック: プロパティごとに1つの値（例: comment は1つの文字列値を持ち、 enabled プロパティはブール値であり、1つの値を持ちます）。

• 複合: プロパティに複数の値（例: タグの allowed_values、マスキングポリシー）。

複合プロパティは JSON 配列に記録されます。たとえば、テーブルに EMAIL という名前の列が1つある場合、その列は以下のように記録されます。

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

subOperationType の値は、次のいずれかになります。

• ADD は、複合プロパティの追加を指定します（例: 列を追加、許容値を設定）。

• DROP は、複合プロパティの削除を指定します。

• ALTER は、複合プロパティの変更を指定します。

objectId は、識別子を持たないタグ値を除いて、列またはオブジェクトの識別子を指定します。

使用上の注意¶

遅延と履歴データ:

• ビューには、2021年2月22日から始まるデータが表示されます。

• ビューの待機時間は最大180分（3時間）です。

先祖クエリ:

parent_query_id 列と root_query_id 列は、 2023_08 動作変更バンドルがデフォルトで有効に移行したことに基づいて、Snowflakeアカウントが更新された時期に応じて、2024年1月15～16日からデータの記録を開始します。この日付は、ビュー内の次の記録を区別するために必要です。

• バンドルがデフォルトで有効になる前に実行されたクエリ。

• この機能がデフォルトで有効になった後に実行されたクエリで、 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ビューや組織の使用状況ビューに対するクエリや、抽出、変換、およびロード（つまり、 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

  • Snowflakeは、テーブルが FROM 句でソースとして指定されている場合に 限り、このクエリをログに記録します。

• DML データを読み取る操作（例: SELECT サブクエリを含み、 WHERE または JOIN の特定の列を指定）: INSERT ... SELECT、 UPDATE、 DELETE、および MERGE。

• 関数内のクエリにテーブルが含まれている場合は、 UDFs および 表形式 SQL UDFs （UDTFs）。これは base_objects_accessed フィールドでログに記録されます。

  UDFs の詳細については、 UDF のメモ （このトピック内）をご参照ください。

書き込み操作のメモ:

このビューは、次の型の 書き込み 操作をサポートします。

• GET <内部ステージ>

• PUT <内部ステージ>

• 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 ステートメントなど）では、 CTAS ステートメントの記述方法に応じて、すべての CASE 分岐で参照されるすべての列が、 base_objects_accessed 列、 direct_objects_accessed 列、または両方の列で記録されます。

データ共有のメモ:

データ共有のプロバイダーアカウントが、共有を介してデータ共有のコンシューマーアカウントにオブジェクトを共有する場合、

• プロバイダーアカウント: プロバイダーアカウントで実行された共有オブジェクトに対するクエリとログは、データ共有のコンシューマーアカウントには表示されません。

• コンシューマーアカウント: コンシューマーアカウントで実行されたデータ共有に対するクエリは、ログに記録されてコンシューマーアカウントにのみ表示され、データ共有のプロバイダーアカウントには表示されません。

  たとえば、プロバイダーがテーブルとテーブルから構築されたビューをコンシューマーアカウントに共有し、共有ビューにクエリがある場合、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 ビュー、 組織の使用状況 ビュー。

• 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 には2つの可能なバリエーションがあります。たとえば、

  • 自己更新:

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

    Copy

  • 2つのテーブルの更新:

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

    Copy

• ALTER TABLE...RENAME TO

クエリ条件:

• クエリプロファイル/プラン

  Snowflakeが書き込むクエリプランは、 ACCESS_HISTORY ビューに列系統を含めるかどうかを決定します。クエリプランの一部として列を評価する必要がある場合、クエリプランの最終結果として列が最終結果に含まれていない場合でも、Snowflakeは ACCESS_HISTORY ビューに列を含めます。

  たとえば、特定の列値に対する WHERE 句を含む次の INSERT ステートメントについて考えます。

  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

    この例では、列が f という名前の UDF の引数であるため、Snowflakeは directSources フィールドに col2 を記録します。

  • 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が記録するプロパティの間の関係をまとめたものです。