Ansicht ACCESS_HISTORY¶

Spalten¶

In diesem Abschnitt gibt es drei Tabellen:

• Die erste Tabelle enthält ein Beispiel für jeden Spaltenwert.

• Die zweite Tabelle definiert die Spalten in der ACCESS_HISTORY-Ansicht.

• Die dritte Tabelle definiert die Felder im JSON-Array für die Spalten base_objects_accessed, direct_objects_accessed und objects_modified.

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

Die Felder im JSON-Array für die Spalten direct_objects_accessed, base_objects_accessed, objects_modified und policies_referenced werden im Folgenden beschrieben.

Die Felder für die Spalte object_modified_by_ddl werden im Folgenden beschrieben.

Für das Feld properties:

• Atomar: Genau Ein Wert pro Eigenschaft (z. B. comment hat genau einen Zeichenfolgenwert, die Eigenschaft enabled ist vom Typ Boolean und hat genau einen Wert).

• Zusammengesetzt: Die Eigenschaft ist mehrwertig (z. B. allowed_values für einen Tag, Maskierungsrichtlinie).

Zusammengesetzte Eigenschaften werden in einem JSON-Array erfasst. Wenn eine Tabelle beispielsweise eine einzelne Spalte mit dem Namen EMAIL enthält, wird die Spalte wie folgt erfasst:

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

subOperationType kann einen der folgenden Werte aufweisen:

• ADD gibt das Hinzufügen einer zusammengesetzten Eigenschaft an (z. B. Hinzufügen einer Spalte, Festlegen zulässiger Werte).

• DROP gibt das Entfernen einer zusammengesetzten Eigenschaft an.

• ALTER gibt das Ändern einer zusammengesetzten Eigenschaft an.

objectId gibt den Bezeichner für die Spalte oder das Objekt an, außer für zulässige Tag-Werte, die keinen Bezeichner haben.

Nutzungshinweise¶

Latenz und historische Daten:

• Die Ansicht enthält Daten ab dem 22. Februar 2021 an.

• Die Latenzzeit der Ansicht kann bis zu 180 Minuten (3 Stunden) betragen.

Vorgänger-Abfragen:

Die Spalten parent_query_id und root_query_id beginnen mit der Erfassung von Daten ab dem 15.-16. Januar 2024, je nachdem, wann Ihr Snowflake-Konto auf der Grundlage des auf „Standardmäßig aktiviert“ umgestellten Verhaltensänderungs-Bundles 2023_08 aktualisiert wurde. Dieses Datum ist notwendig, um zwischen den folgenden Datensätzen in der Ansicht zu unterscheiden:

• Abfragen, die ausgeführt wurden, bevor das Bundle standardmäßig aktiviert wurde.

• Abfragen, die ausgeführt wurden, nachdem das Feature standardmäßig aktiviert wurde, aber keinen Wert im Feld parent_query_id haben.

Allgemeine Hinweise:

• Um die Leistung zu erhöhen, können Sie die Abfragen nach der Spalte query_start_time filtern und engere Zeitbereiche auswählen. Beispielabfragen finden Sie unter Abfragen der ACCESS_HISTORY-Ansicht.

• Sichere Ansichten. Der Protokollsatz enthält die zugrunde liegende Basistabelle (d. h. base_objects_accessed) zum Generieren der Ansicht. Beispiele hierfür sind Abfragen auf andere Account Usage- und Organization Usage-Ansichten sowie Abfragen auf Basistabellen für Extraktions-, Transformations- und Ladeoperationen (d. h. ETL).

• Datensätze in der QUERY_HISTORY-Ansicht werden nicht immer in der ACCESS_HISTORY-Ansicht erfasst. Die Struktur der SQL-Anweisung bestimmt, ob Snowflake Datensätze in der ACCESS_HISTORY-Ansicht erfasst.

• Die Angabe der USING-Klausel bei der Abfrage dieser Ansicht kann dazu führen, dass im Feld direct_objects_accessed nicht referenzierte Spalten erfasst werden. Ersetzten Sie als Problemumgehung die USING-Klausel durch eine JOIN ... ON ...-Klausel. Weitere Informationen dazu finden Sie unter:

  • JOIN und USING (unter dem Referenzthema zu JOIN)

  • Bewegung sensibler Stagingbereichsdaten verfolgen (in der Beispielabfrage zum Zugriffsverlauf)

Hinweise zu Leseabfragen:

Diese Ansicht unterstützt Lese-Abfragen des folgenden Typs:

• SELECT, einschließlich CREATE TABLE … AS SELECT (d. h. CTAS).

  • Snowflake erfasst SELECT-Unterabfragen von CTAS-Operationen.

• CREATE TABLE … CLONE

  • Snowflake erfasst die Quelltabelle in einer CLONE-Operation.

• COPY INTO … TABLE

  • Snowflake protokolliert diese Abfrage nur dann, wenn die Tabelle in einer FROM-Klausel als Quelle angegeben wird.

• DML-Operationen, die Daten lesen (z. B. enthalten eine SELECT-Unterabfrage, geben bestimmte Spalten in WHERE oder JOIN an): INSERT … SELECT, UPDATE, DELETE und MERGE.

• UDFs und Tabellarische SQL-UDFs (UDTFs), wenn Tabellen innerhalb der Funktionen in Abfragen enthalten sind. Dies wird im Feld base_objects_accessed protokolliert.

  Weitere Informationen zu UDFs finden Sie in den Nutzungshinweise zu UDFs (unter diesem Thema).

Hinweise zu Schreiboperationen:

Diese Ansicht unterstützt Schreiboperationen des folgenden Typs:

• GET <interner_Stagingbereich>

• PUT <interner_Stagingbereich>

• DELETE

• TRUNCATE

• INSERT

  • INSERT INTO … FROM SELECT *

  • INSERT INTO TABLE … VALUES ()

• MERGE INTO … FROM SELECT *

• UPDATE

  • UPDATE TABLE … FROM SELECT * FROM …

  • UPDATE TABLE … WHERE …

• Anweisungen zum Laden von Daten:

  • COPY INTO TABLE FROM internalStage

  • COPY INTO TABLE FROM externalStage

  • COPY INTO TABLE FROM externalLocation

• Anweisungen zum Entladen von Daten:

  • 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

• Bei Schreiboperationen, die die Funktion CASE aufrufen, um die Spalten zu bestimmen, auf die zugegriffen werden soll (z. B. eine CTAS-Anweisung mit der Funktion CASE in der SELECT-Abfrage), werden alle Spalten, auf die in jedem CASE-Zweig verwiesen wird, in der Spalte base_objects_accessed, der Spalte direct_objects_accessed oder in beiden Spalten erfasst, je nachdem, wie die CTAS-Anweisung geschrieben ist.

Hinweise zu Datenfreigaben (Data Sharing):

Wenn ein Data Sharing-Anbieterkonto Objekte für Data Sharing-Verbraucherkonten über eine Freigabe freigibt, gilt Folgendes:

• Anbieterkonten: Die Abfragen und Protokolle zu den freigegebenen Objekten, die im Anbieterkonto ausgeführt werden, sind für Data Sharing-Verbraucherkonten nicht sichtbar.

• Verbraucherkonten: Die im Verbraucherkonto ausgeführten Abfragen auf der Datenfreigabe werden protokolliert und sind nur für das Verbraucherkonto sichtbar, nicht aber für das Data Sharing-Anbieterkonto.

  Wenn der Anbieter beispielsweise eine Tabelle und eine aus der Tabelle erstellte Ansicht für das Verbraucherkonto freigibt und eine Abfrage auf der freigegebenen Ansicht ausführt, erfasst Snowflake den Zugriff auf die freigegebene Ansicht in der Spalte base_objects_accessed. Anhand dieses Datensatzes, der die Werte columnName und objectName enthält, kann der Verbraucher erkennen, auf welches Objekt in seinem Konto zugegriffen wurde. Der Anbieter ist nun geschützt, da die zugrunde liegende Tabelle (über die Werte objectId und columnId) dem Verbraucher nicht offengelegt wird.

• Spaltenherkunft:

  Wenn ein Data-Sharing-Anbieter dem Data-Sharing-Verbraucher eine Ansicht zur Verfügung stellt, sind die Quellspalten der Ansicht für den Verbraucher nicht sichtbar, da die Spalten vom Data-Sharing-Anbieter stammen.

  Wenn der Data Sharing-Verbraucher Daten aus der freigegebenen Ansicht in eine Tabelle verschiebt, erfasst Snowflake die Ansichtsspalten nicht als baseSources der neu erstellten Tabelle.

• Bei freigegebenen UDFs und UDTFs:

  • Im Verbraucherkonto erfasst die lokale ACCESS_HISTORY-Ansicht die vom Anbieter freigegebene UDF/UDTF, wenn die freigegebene UDF/UDTF vom Verbraucher aufgerufen werden.

  • Im Anbieterkonto erfasst die lokale ACCESS_HISTORY-Ansicht die Nutzung einer freigegebenen UDF/UDTF durch den Anbieter. Benutzern im Verbraucherkonto wird nicht angezeigt, wie das Anbieterkonto die freigegebene UDF/UDTF verwendet.

• Für die Verfolgung von Richtlinienreferenzen:

  Die Spalte policies_referenced enthält Richtlinien, die für das Konto, das die Daten abfragt, lokal sind.

  Wenn ein Anbieter eine richtliniengeschützte Tabelle freigibt und ein Verbraucher auf diese Tabelle zugreift, kann der Verbraucher die vom Anbieter für die Tabelle oder deren Spalten festgelegte Richtlinie nicht sehen.

  Wenn ein Verbraucher aus dem freigegebenen Objekt eine Ansicht (v1) erstellt, dann eine Richtlinie für die Ansicht (v1) oder eine ihrer Spalten festlegt und nun ein Benutzer im Verbraucherkonto auf die geschützte Ansicht (v1) oder eine andere Ansicht (v2) zugreift, die aus der geschützten Ansicht (v1) erstellt wurde, enthält die Ansicht ACCESS_HISTORY im Verbraucherkonto die Richtlinie, die die Ansicht (v1) und deren Spalten schützt. Der Anbieter kann den Datensatz, der v1 entspricht, nicht sehen.

Hybridtabellen:

Für Abfragen mit kurzer Ausführungszeit, die ausschließlich auf Hybridtabellen angewendet werden, werden in der Ansicht QUERY_HISTORY, in QUERY_HISTORY und in der Ausgabe der QUERY_HISTORY-Tabellenfunktion keine Datensätze mehr generiert. Um solche Abfragen zu überwachen, verwenden Sie AGGREGATE_QUERY_HISTORY.

Um den Zugriffsverlauf auf solche Abfragen zu überwachen, verwenden Sie die Option AGGREGATE_ACCESS_HISTORY. Mit dieser Ansicht können Sie operative Workloads mit hohem Durchsatz für den Zugriffsverlauf leichter überwachen.

Anmerkungen zum Snowflake Native App Framework:

Einige Abfragen, die sich auf eine Snowflake Native App beziehen, sind ausgeblendet. Weitere Details dazu finden Sie unter In SQL-Befehlen und Ansichten ausgeblendete Informationen.

Hinweise zur Tag-basierten Maskierung:

Wenn ein Benutzer auf eine Tabelle oder Ansicht zugreift, die durch eine Tag-basierte Maskierungsrichtlinie geschützt ist, enthält die Spalte policies_referenced die Maskierungsrichtlinie, die über das Tag angewendet wird, wenn Snowflake die Maskierungsrichtlinie für die geschützte Spalte erzwingt.

In der Ansicht ACCESS_HISTORY werden keine Tag-Informationen erfasst.

Nutzungshinweise zu UDFs und gespeicherten Prozeduren:

Diese Hinweise gelten für externe Funktionen, UDFs und UDTFs für alle Sprachen, auch wenn diese Funktionen die Eigenschaft SECURE haben, sowie für gespeicherte Prozeduren mit Eigentümer- und Aufruferrechten:

Spaltendetails:

• Die Spalte direct_objects_accessed erfasst die ausdrückliche Nennung dieser Funktionen und Prozeduren in einer Abfrage.

  Snowflake erfasst in dieser Spalte keine verschachtelten UDFs (d. h. UDFs, die in der Definition einer anderen UDF genannt werden).

• Die Spalte base_objects_accessed erfasst externe Funktionen, freigegebene Funktionen, Nicht-SQL-UDFs und gespeicherte Prozeduren, die in einer Abfrage aufgerufen werden.

• Die objects_modified-Spalte erfasst Folgendes:

  • Die UDF/UDTF, wenn das Ergebnis des Aufrufs der Funktion das Ergebnis in eine andere Spalte kopiert.

  • UDF, UDTF und externe Funktion können in den Arrays für baseSources und directSources erfasst werden, je nachdem wie die Abfrage geschrieben ist.

Nicht unterstützt:

Diese Ansicht protokolliert nicht den Zugriff folgender Typen:

• Die von Snowflake bereitgestellten Tabellenfunktionen, Account Usage-Ansichten und Organization Usage-Ansichten.

• RESULT_SCAN zum Ermitteln vorheriger Ergebnisse.

• Ein Zugriffsverlaufsdatensatz wird erstellt, wenn DDL Operationen auf Sequenzen durchgeführt werden. Er wird nicht erstellt, wenn eine Sequenz in anderen Operationen verwendet wird, einschließlich der Erstellung neuer Werte.

• Zwischenansichten, auf die zwischen der Basistabelle und dem direkten Objekt zugegriffen wird.

  Betrachten Sie zum Beispiel eine Abfrage auf View_A mit der folgenden Objektstruktur: View_A » View_B » View_C » Base_Table.

  Die ACCESS_HISTORY-Ansicht erfasst die Abfrage auf Ansicht_A und auf die Basistabelle, aber nicht Ansicht_B und Ansicht_C.

• Operationen zum Aktualisieren der Streams

• Verschieben von Daten für Replikation

• Fehlgeschlagene Abfragen werden zwar in der Ansicht QUERY_HISTORY protokolliert, aber nicht in der Ansicht ACCESS_HISTORY.

Nutzungshinweise: Spaltenherkunft¶

Diese zusätzlichen Hinweise beziehen sich auf die Spaltenherkunft:

Unterstützte Operationen:

Die Spaltenherkunft verfolgt Details zu den folgenden SQL-Operationen:

• CREATE TABLE … AS SELECT (CTAS)

• CREATE TABLE … CLONE

• INSERT … SELECT …

• MERGE

• UPDATE mit zwei möglichen Varianten, z. B.:

  • Selbstupdate:

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

    Copy

  • Zwei-Tabellen-Update:

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

    Copy

• ALTER TABLE … RENAME TO

Abfragebedingungen:

• Query profile/plan

  Der von Snowflake geschriebene Abfrageplan bestimmt, ob die Ansicht ACCESS_HISTORY die Spaltenherkunft enthält oder nicht. Wenn eine Spalte als Teil des Abfrageplans ausgewertet werden muss, übernimmt Snowflake die Spalte selbst dann in die Ansicht ACCESS_HISTORY, wenn das Endergebnis des Abfrageplans darin besteht, dass die Spalte nicht im Endergebnis enthalten ist.

  Betrachten Sie beispielsweise die folgende INSERT-Anweisung mit einer WHERE-Klausel für einen bestimmten Spaltenwert:

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

  Copy

  Auch wenn die WHERE-Klausel den Wert FALSE ergibt, erfasst Snowflake die Spalte c2 als Quellspalte der Spalte c1. Die Spalte c3 ist weder für baseSources noch für directSources als Quellspalte aufgeführt.

• Maskierte Spalten:

  • Eine maskierte Spalte wird immer im Feld directSources aufgeführt.

  • Der Datensatz im Feld baseSources hängt von der Definition der Richtlinie ab. Beispiel:

    • Wenn in den Bedingungen der Maskierungsrichtlinie eine CASE-Funktion verwendet wird, werden im Feld baseSources alle Spalten erfasst, auf die in den CASE-Zweigen verwiesen wird.

    • Wenn in den Bedingungen der Maskierungsrichtlinie nur ein konstanter Wert angeben ist (z. B. *****), bleibt das Feld baseSources leer.

• UDFs:

  • Wenn eine Spalte als Argument an einen UDF übergeben und das Ergebnis in eine andere Spalte geschrieben wird, wird die als Argument übergebene Spalte im Feld directSources erfasst. Beispiel:

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

    Copy

    In diesem Beispiel erfasst Snowflake col2 im Feld directSources, weil die Spalte ein Argument der UDF mit dem Namen f ist.

  • Der Datensatz im Feld baseSources hängt von der UDF-Definition ab.

Ansichtsspalten:

Ansichtspalten gelten nicht als Quellspalten, sodass sie beim Kopieren von Daten aus einer Ansichtsspalte in eine Tabellenspalte nicht im Feld baseSources erfasst. Ansichtsspalten werden in diesem Fall im Feld directSources erfasst.

EXISTS-Unterabfrage:

Spalten, auf die in der Klausel der EXISTS-Unterabfrage verwiesen wird, gelten nicht als Quellspalten.

Nutzungshinweise: Spalte object_modified_by_ddl¶

• IF [ NOT ] EXISTS-Klausel: Die Spalte object_modified_by_ddl erfasst beim Erstellen oder Ändern eines Objekts nur CREATE oder REPLACE.

• Snowflake unterstützt die folgenden Objektdomänen:

  • Tabelle und externe Tabelle

  • Ansicht und materialisierte Ansicht

  • Schema

  • Datenbank

Die Spalte erfasst diese Änderungen anhand der folgenden SQL-Operationen. Die Operationen DROP und UNDROP gelten für Tabellen und Ansichten, nicht für Spalten.

CREATE OR REPLACE

ALTER ... { SET | UNSET }

ALTER ... ADD ROW ACCESS POLICY

ALTER ... DROP ROW ACCESS POLICY

ALTER ... DROP ALL ROW ACCESS POLICIES

DROP | UNDROP

Die folgende Tabelle fasst die Beziehung zwischen DDL-Operationen, unterstützten Domänen und den Eigenschaften der Snowflake-Datensätze zusammen.