Exibição ACCESS_HISTORY¶

Colunas¶

Existem três tabelas nesta seção:

• A primeira tabela fornece um exemplo de cada valor de coluna.

• A segunda tabela define as colunas na exibição ACCESS_HISTORY.

• A terceira tabela define os campos na matriz JSON para as colunas base_objects_accessed, direct_objects_accessed e 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"
      }
    ]
  }
]

Os campos na matriz JSON para as colunas direct_objects_accessed, base_objects_accessed, objects_modified e policies_referenced estão descritos abaixo.

Os campos para a coluna object_modified_by_ddl são descritos abaixo.

Para o campo properties:

• Atômica: um valor por propriedade (por exemplo, um comment tem um único valor de cadeia de caracteres, a propriedade enabled é um booleano e tem um valor).

• Composta: a propriedade tem múltiplos valores (por exemplo allowed_values para uma tag, política de mascaramento).

As propriedades compostas são registradas em uma matriz JSON. Por exemplo, se uma tabela contiver uma única coluna chamada EMAIL, a coluna será registrada da seguinte forma:

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

O valor subOperationType pode ser um dos seguintes:

• ADD especifica a adição de uma propriedade composta (por exemplo, adicionar uma coluna, definir valores permitidos).

• DROP especifica a remoção de uma propriedade composta.

• ALTER especifica a modificação de uma propriedade composta.

O objectId especifica o identificador para a coluna ou objeto, exceto para valores de tag permitidos que não possuem um identificador.

Notas de uso¶

Latência e dados históricos:

• A visualização exibe dados a partir de 22 de fevereiro de 2021.

• A latência da visualização pode ser de até 180 minutos (3 horas).

Consultas antigas:

As colunas parent_query_id e root_query_id começam a registrar dados a partir de 15-16 de janeiro de 2024, dependendo de quando sua conta Snowflake foi atualizada com base na transição do pacote de mudança de comportamento 2023_08 para ativado por padrão. Esta data é necessária para distinguir entre os seguintes registros na exibição:

• Consultas executadas antes do pacote ser ativado por padrão.

• Consultas executadas depois que o recurso foi ativado por padrão, mas não têm um valor em parent_query_id.

Notas gerais:

• Para aumentar o desempenho, filtre as consultas na coluna query_start_time e escolha períodos mais curtos. Para amostras de consulta, consulte Consulta da exibição ACCESS_HISTORY.

• Visualizações seguras. O registro contém a tabela base subjacente (ou seja base_objects_accessed) para gerar a visualização. Exemplos incluem consultas em outras exibições do Account Usage e Organization Usage e consultas em tabelas base para operações de extração, transformação e carga (ou seja, ETL).

• Registros na exibição QUERY_HISTORY nem sempre são gravados na exibição ACCESS_HISTORY. A estrutura da instrução SQL determina se o Snowflake registra uma entrada na exibição ACCESS_HISTORY.

• Especificar a cláusula USING ao consultar esta exibição pode fazer com que colunas não referenciadas sejam registradas no campo direct_objects_accessed. Como alternativa, substitua a cláusula USING por uma cláusula JOIN ... ON .... Para obter mais detalhes, consulte:

  • JOIN e USING (no tópico de referência JOIN)

  • Rastreamento da movimentação de dados em estágios confidenciais (no exemplo de consulta ao histórico de acesso)

Leia as notas de consulta:

Esta exibição oferece suporte a consultas de leitura do seguinte tipo:

• SELECT incluindo CREATE TABLE … AS SELECT (como CTAS).

  • O Snowflake registra a subconsulta SELECT em uma operação CTAS.

• CREATE TABLE … CLONE

  • O Snowflake registra a tabela de origem em uma operação CLONE.

• COPY INTO … TABLE

  • O Snowflake registra esta consulta somente quando a tabela é especificada como a fonte em uma cláusula FROM.

• Operações DML que leem dados (por exemplo, contém uma subconsulta SELECT, especifica certas colunas em WHERE ou JOIN): INSERT … SELECT, UPDATE, DELETE e MERGE.

• UDFs e UDFs tabulares de SQL (UDTFs) se as tabelas estiverem incluídas nas consultas dentro das funções. Isso é registrado no campo base_objects_accessed.

  Para obter mais detalhes sobre UDFs, consulte as notas UDF (neste tópico).

Gravação de notas de operação:

Esta exibição oferece suporte às operações de gravação do seguinte tipo:

• GET <estágio_interno>

• PUT <estágio_interno>

• DELETE

• TRUNCATE

• INSERT

  • INSERT INTO … FROM SELECT *

  • INSERT INTO TABLE … VALUES ()

• MERGE INTO … FROM SELECT *

• UPDATE

  • UPDATE TABLE … FROM SELECT * FROM …

  • UPDATE TABLE … WHERE …

• Instruções de carregamento de dados:

  • COPY INTO TABLE FROM internalStage

  • COPY INTO TABLE FROM externalStage

  • COPY INTO TABLE FROM externalLocation

• Instruções de descarregamento de dados:

  • 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

• Para operações de escrita que chamam a função CASE para determinar as colunas a serem acessadas, como uma instrução CTAS com a função CASE na consulta SELECT, todas as colunas referenciadas em cada ramo CASE são registradas na coluna base_objects_accessed, na coluna direct_objects_accessed, ou em ambas as colunas dependendo de como a instrução CTAS é escrita.

Notas de compartilhamento de dados:

Se uma conta do provedor de Data Sharing compartilhar objetos com contas do consumidor de Data Sharing por um compartilhamento:

• Contas do provedor: As consultas e logs dos objetos compartilhados executados na conta do provedor não ficam visíveis para as contas de consumidor de Data Sharing.

• Contas de consumidor: As consultas de compartilhamento de dados executadas na conta do consumidor são registradas e ficam visíveis somente para a conta de consumidor, e não para a conta de provedor de Data Sharing.

  Por exemplo, se o provedor compartilha uma tabela e uma exibição construída a partir da tabela para a conta do consumidor, e há uma consulta sobre a exibição compartilhada, o Snowflake registra o acesso à exibição compartilhada na coluna base_objects_accessed. Esse registro, que inclui os valores columnName e objectName, permite que o consumidor saiba qual objeto foi acessado em sua conta e também protege o provedor porque a tabela subjacente (através dos valores objectId e columnId) não é revelada ao consumidor.

• Para linhagem de colunas:

  Se um provedor de Data Sharing disponibilizar uma exibição para o consumidor de Data Sharing, as colunas de origem da exibição não ficarão visíveis para o consumidor porque as colunas são originadas do provedor de Data Sharing.

  Se o consumidor do Data Sharing mover os dados da exibição compartilhada para uma tabela, Snowflake não registra as colunas de exibição como baseSources para a tabela recém-criada.

• Para compartilhar UDFs e UDTFs:

  • Na conta do consumidor, a exibição ACCESS_HISTORY local registra a UDF/UDTF que foi compartilhada pelo provedor quando a UDF/UDTF compartilhada é invocada pelo consumidor.

  • Na conta do provedor, a exibição ACCESS_HISTORY local registra o uso do provedor de uma UDF/UDTF compartilhada. Os usuários na conta do consumidor não podem ver como a conta do provedor utiliza a UDF/UDTF compartilhada.

• Para rastreamento de referências de políticas:

  A coluna policies_referenced contém políticas que são locais para a conta que consulta os dados.

  Se um provedor compartilhar uma tabela protegida por política e um consumidor acessar essa tabela, o consumidor não poderá ver a política que o provedor definiu na tabela ou suas colunas.

  Se um consumidor criar uma exibição (v1) do objeto compartilhado, definir uma política para a exibição (v1) ou suas colunas, e um usuário na conta do consumidor acessar a exibição protegida (v1) ou outra exibição (v2) criada a partir da exibição protegida (v1), a exibição ACCESS_HISTORY na conta do consumidor terá a política que protege a exibição (v1) e suas colunas. O provedor não pode ver o registro que corresponde a v1.

Tabelas híbridas:

Consultas de curta duração que operam exclusivamente em tabelas híbridas não gerarão mais um registro na exibição QUERY_HISTORY, em QUERY_HISTORY ou na saída da função de tabela QUERY_HISTORY. Para monitorar essas consultas, use AGGREGATE_QUERY_HISTORY.

Para monitorar o histórico de acesso para essas consultas, use AGGREGATE_ACCESS_HISTORY. Essa exibição permite monitorar mais facilmente cargas de trabalho operacionais de alto rendimento para histórico de acesso.

Notas do Snowflake Native App Framework:

Algumas consultas relacionadas ao Snowflake Native App são censuradas. Para obter mais detalhes, consulte Informações censuradas de comandos e exibições SQL.

Notas de mascaramento baseado em tags:

Se um usuário acessar uma tabela ou exibição protegida por uma política de mascaramento baseada em tags, a coluna policies_referenced terá a política de mascaramento aplicada pela tag quando o Snowflake aplica a política de mascaramento na coluna protegida.

A exibição ACCESS_HISTORY não registra nenhuma informação da tag.

UDFs e procedimentos armazenados:

Estas notas se aplicam às funções externas, UDFs e UDTFs para todas as linguagens, inclusive quando estas funções têm a propriedade SECURE, e procedimentos armazenados com direitos de proprietário e direitos de chamador:

Detalhes da coluna:

• A coluna direct_objects_accessed registra a menção explícita destas funções e procedimentos em uma consulta.

  O Snowflake não registra UDFs aninhadas (ou seja, uma UDF mencionada na definição de outra UDF) nesta coluna.

• A coluna base_objects_accessed registra funções externas, funções compartilhadas, UDFs não SQL, e procedimentos armazenados que são chamados em uma consulta.

• A coluna objects_modified registra:

  • A UDF/UDTF quando o resultado da chamada da função copia o resultado para outra coluna.

  • A UDF, UDTF e uma função externa podem ser registradas nas matrizes para baseSources e directSources, dependendo de como a consulta é escrita.

Sem suporte:

Esta visualização não registra os acessos dos seguintes tipos:

• Funções de tabela, exibições Account Usage e Uso da organização fornecidas pelo Snowflake.

• RESULT_SCAN para obter resultados prévios.

• Sequências, incluindo a geração de novos valores.

• Visualizações intermediárias acessadas entre a tabela base e o objeto direto.

  Por exemplo, considere uma consulta em View_A com a seguinte estrutura de objetos: View_A » View_B » View_C » Base_Table.

  A exibição ACCESS_HISTORY registra a consulta na Exibição_A e na Tabela_base, não na Exibição_B e Exibição_C.

• As operações para atualizar fluxos.

• Movimento de dados resultante da replicação.

• Consultas com falha, embora registradas na exibição QUERY_HISTORY, não serão registradas na exibição ACCESS_HISTORY.

Notas de uso: Linhagem de colunas¶

Estas notas adicionais dizem respeito à linhagem de colunas:

Operações com suporte:

Detalhes da linhagem de colunas para as seguintes operações SQL:

• CREATE TABLE … AS SELECT (CTAS)

• CREATE TABLE … CLONE

• INSERT … SELECT …

• MERGE

• UPDATE, duas variações possíveis, por exemplo:

  • Autoatualização:

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

    Copy

  • Atualização de duas tabelas:

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

    Copy

• ALTER TABLE … RENAME TO

Condições de consulta:

• Query profile/plan

  O plano de consulta que o Snowflake escreve determina se a exibição ACCESS_HISTORY contém a linhagem de colunas. Se uma coluna precisar ser avaliada como parte do plano de consulta, Snowflake contém a coluna na exibição ACCESS_HISTORY, mesmo se o resultado final do plano de consulta for que a coluna não está incluída no resultado final.

  Por exemplo, considere a seguinte instrução INSERT com uma cláusula WHERE para um determinado valor de coluna:

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

  Copy

  Mesmo que a cláusula WHERE avalie como FALSE, Snowflake registra a coluna c2 como uma coluna de origem para a coluna c1. A coluna c3 não está listada como coluna de origem para baseSources ou directSources.

• Colunas mascaradas:

  • A coluna mascarada é sempre listada no campo directSources.

  • O registro no campo baseSources depende da definição da política. Por exemplo:

    • Se as condições da política de mascaramento utilizarem uma função CASE, então todas as colunas referenciadas em cada uma das ramificações CASE são registradas no campo baseSources.

    • Se as condições da política de mascaramento especificarem apenas um valor constante (por exemplo, *****), então o campo baseSources estará vazio.

• UDFs:

  • Ao passar uma coluna como argumento para um UDF e escrever o resultado para outra coluna, a coluna que é passada como argumento é registrada no campo directSources. Por exemplo:

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

    Copy

    Neste exemplo, Snowflake registra col2 no campo directSources porque a coluna é um argumento para o UDF chamado f.

  • O registro no campo baseSources depende da definição do UDF.

Exibição de colunas:

As colunas de exibição não são consideradas colunas de origem e não são listadas no campo baseSources quando dados de uma coluna de exibição são copiados para uma coluna de tabela. As colunas de exibição neste caso estão listadas no campo directSources.

Subconsulta EXISTS:

As colunas que são referenciadas na cláusula de subconsulta EXISTS não são consideradas como colunas de origem.

Notas de uso: coluna object_modified_by_ddl¶

• Cláusulas IF [ NOT ] EXISTS: a coluna object_modified_by_ddl só registra CREATE ou REPLACE ao criar ou modificar um objeto.

• O Snowflake oferece suporte aos seguintes domínios de objeto.

  • Tabela e tabela externa.

  • Exibição e exibição materializada

  • Esquema

  • Banco de dados.

A coluna registra essas alterações com base nas seguintes operações SQL. As operações DROP e UNDROP se aplicam a tabelas e exibições, não a colunas.

CREATE OR REPLACE

ALTER ... { SET | UNSET }

ALTER ... ADD ROW ACCESS POLICY

ALTER ... DROP ROW ACCESS POLICY

ALTER ... DROP ALL ROW ACCESS POLICIES

DROP | UNDROP

A tabela a seguir resume a relação entre operações DDL, domínios suportados e as propriedades dos registros do Snowflake.