- Esquema:
Exibição ACCESS_HISTORY¶
Esta visualização de Account Usage pode ser usada para consultar o histórico de acesso dos objetos Snowflake (por exemplo, tabela, visualização, coluna) nos últimos 365 dias (1 ano).
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
eobjects_modified
.
Nome da coluna |
Exemplo |
---|---|
|
|
|
|
|
|
|
[
{
"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"
}
]
}
]
|
Nome da coluna |
Tipo de dados |
Descrição |
---|---|---|
|
TEXT |
Um identificador interno gerado pelo sistema para a instrução SQL. Este valor também é mencionado em Exibição QUERY_HISTORY. |
|
TIMESTAMP_LTZ |
A hora de início da instrução (fuso horário UTC). |
|
TEXT |
O usuário que emitiu a consulta. |
|
ARRAY |
Uma matriz JSON de objetos de dados, como funções definidas pelo usuário (ou seja UDFs e UDTFs), procedimentos armazenados, tabelas, visualizações e colunas nomeadas diretamente na consulta explicitamente ou por atalhos como o uso de um asterisco (ou seja, As colunas virtuais podem ser devolvidas neste campo. Para obter notas adicionais sobre UDFs, consulte as notas sobre UDF (neste tópico). |
|
ARRAY |
Uma matriz JSON de todos os objetos de dados básicos para executar uma consulta, incluindo colunas, funções externas, UDFs e procedimentos armazenados. Neste exemplo, os campos da primeira matriz especificam uma UDF. Estes mesmos campos na primeira matriz também especificam um procedimento armazenado, quando aplicável. Observe o seguinte:
|
|
ARRAY |
Uma matriz JSON que especifica os objetos que foram associados a uma operação de gravação na consulta. A matriz de procedimento armazenado e UDF é a mesma que foi mostrada anteriormente e aparece nas matrizes para Para obter notas adicionais sobre UDFs, consulte as notas sobre UDF (neste tópico). |
|
OBJECT |
Especifica a operação DDL em um banco de dados, esquema, tabela, exibição e coluna. Essas operações também incluem instruções que especificam uma política de acesso a linhas em uma tabela ou exibição, uma política de mascaramento em uma coluna e atualizações de tags (por exemplo, definir uma tag, alterar um valor de tag) no objeto ou coluna. |
|
ARRAY |
Especifica as informações sobre a política de mascaramento aplicada definida na coluna e a política de acesso a linhas aplicada na tabela, incluindo políticas definidas em objetos ou colunas intermediários. |
|
TEXT |
O ID de consulta do trabalho pai ou NULL se o trabalho não tiver um pai. |
|
TEXT |
O ID de consulta do trabalho mais importante na cadeia ou NULL se o trabalho não tiver um pai. |
Os campos na matriz JSON para as colunas direct_objects_accessed
, base_objects_accessed
, objects_modified
e policies_referenced
estão descritos abaixo.
Campo |
Tipo de dados |
Descrição |
---|---|---|
columnId |
NUMBER |
Uma coluna ID que é única dentro da conta. Este valor é idêntico ao columnID na visualização COLUMNS. |
columnName |
TEXT |
O nome da coluna acessada. Para as políticas, especifica a coluna na qual a política de mascaramento é definida. |
objetId |
NUMBER |
Um identificador do objeto, que é único dentro de uma determinada conta e domínio. Este número será correspondente ao seguinte: |
objectName |
TEXT |
O nome completo e qualificado do objeto que foi acessado. Se uma política de mascaramento for definida em uma coluna ou uma política de acesso a linhas for definida em uma tabela ou exibição, o valor se referirá ao nome totalmente qualificado da tabela ou exibição na qual a política de acesso a linhas é definida ou a tabela ou exibição que tem uma política de mascaramento definida em uma de suas colunas. Se um estágio foi acessado, este valor será o valor:
|
objectDomain |
TEXT |
Uma das seguintes opções: Observe que Para as políticas, especifica o domínio do objeto no qual a política de acesso a linhas é definida. |
local |
TEXT |
O URL do local externo quando o acesso aos dados é um local externo (por exemplo, |
stageKind |
TEXT |
Ao gravar em um estágio, uma das seguintes opções: |
baseSources |
TEXT |
As colunas que servem como colunas de origem para as colunas especificadas por |
directSources |
TEXT |
As colunas especificamente mencionadas na parte dos dados escrever da declaração SQL que serve como as colunas de origem na tabela de destino para a qual os dados são escritos. Estas colunas facilitam a linhagem de colunas. |
policyName |
TEXT |
O nome totalmente qualificado da política. |
policyId |
NUMBER |
Um identificador da política, que é único dentro de uma determinada conta e domínio. Este valor corresponde ao identificador de uma política de mascaramento no Exibição MASKING_POLICIES ou ao identificador de uma política de acesso a linhas no Exibição ROW_ACCESS_POLICIES |
policyKind |
TEXT |
MASKING_POLICY ou ROW_ACCESS_POLICY |
argumentoSignature |
TEXT |
O nome e o tipo de dados para cada argumento na UDF ou procedimento armazenado. |
dataType |
O tipo de dados do valor de retorno para uma UDF ou procedimento armazenado. Este valor ajuda a diferenciar duas ou mais UDFs com o mesmo nome, mas tipos de retorno diferentes. |
Os campos para a coluna object_modified_by_ddl
são descritos abaixo.
fieldName |
Tipo de dados |
Descrição |
---|---|---|
objectDomain |
TEXT |
O domínio do objeto definido ou modificado pela operação DDL, que inclui todos os objetos que podem ser marcados com tag e MASKING POLICY | ROW ACCESS POLICY | TAG. |
objetId |
NUMBER |
Um identificador do objeto, que é único dentro de uma determinada conta e domínio, definido e modificado pela operação DDL. |
objectName |
TEXT |
O nome totalmente qualificado do objeto definido ou modificado pela operação DDL. |
operationType |
TEXT |
A palavra-chave SQL que especifica a operação na tabela, exibição ou coluna: ALTER | CREATE | DROP | REPLACE | UNDROP |
properties |
ARRAY |
A matriz JSON que especifica as propriedades do objeto ou da coluna quando você cria, modifica, descarta ou desfaz o descarte do objeto ou da coluna. Existem dois tipos de propriedades: atômicas e compostas. |
Para o campo properties
:
Atômica: um valor por propriedade (por exemplo, um
comment
tem um único valor de cadeia de caracteres, a propriedadeenabled
é 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
eroot_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 comportamento2023_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
.
- 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 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 campodirect_objects_accessed
. Como alternativa, substitua a cláusulaUSING
por uma cláusulaJOIN ... 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 colunadirect_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 valorescolumnName
eobjectName
, 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 valoresobjectId
ecolumnId
) 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 av1
.
- 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
edirectSources
, 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.
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)
UPDATE, duas variações possíveis, por exemplo:
Autoatualização:
UPDATE mydb.s1.t1 SET col_1 = col_1 + 1;
Atualização de duas tabelas:
UPDATE mydb.s1.t1 FROM mydb.s2.t2 SET t1.col1 = t2.col1;
ALTER TABLE … RENAME TO
- Condições de consulta:
-
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;
Mesmo que a cláusula WHERE avalie como
FALSE
, Snowflake registra a colunac2
como uma coluna de origem para a colunac1
. A colunac3
não está listada como coluna de origem parabaseSources
oudirectSources
. 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 campobaseSources
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;
Neste exemplo, Snowflake registra
col2
no campodirectSources
porque a coluna é um argumento para o UDF chamadof
.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 campodirectSources
.- 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 colunaobject_modified_by_ddl
só registraCREATE
ouREPLACE
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.
Operação |
Domínio |
Propriedades |
Notas |
---|---|---|---|
CREATE [ OR REPLACE ] |
TABLE | EXTERNAL TABLE | VIEW | MATERIALIZED VIEW |
Nome da coluna, identificador da coluna. |
As operações CREATE DATABASE e CREATE SCHEMA não possuem propriedades registradas. |
CREATE |
TABLE … { AS SELECT | USING TEMPLATE | LIKE | CLONE } |
Nome da coluna, identificador da coluna. |
Snowflake registra a fonte de criação para as operações LIKE e CLONE. O Snowflake não registra a origem da criação quando o objeto de origem é de um compartilhamento ou com USING TEMPLATE. |
ALTER … RENAME TO ALTER TABLE … RENAME COLUMN |
TABLE | VIEW | MATERIALIZED VIEW | DATABASE | SCHEMA |
O novo nome do objeto ou coluna. |
|
ALTER … SWAP WITH |
TABLE | SCHEMA | DATABASE |
objectName, objectId, objectDomain |
Existem dois registros na exibição, um para cada destino de troca. Cada registro contém o mesmo valor de identificador de consulta. |
ALTER … { ADD | DROP } COLUMN |
TABLE |
Nome da coluna, identificador da coluna e o ADD ou DROP subOperationType. |
|
DROP |
TABLE | VIEW | MATERIALIZED VIEW | DATABASE | SCHEMA |
Snowflake não registra propriedades para essas operações. |
|
UNDROP |
TABLE | SCHEMA | DATABASE |
Snowflake não registra propriedades para essas operações. |