Pacote 2022_02¶

Consultas de dados hierárquicos: os limites de iteração não são mais aplicados¶

Ao consultar dados hierárquicos, é possível usar CTEs recursivos ou o comando CONNECT BY para iterar sobre cada nível de hierarquia.

O limite do número de iterações, que antes era fixado em 100 (internamente pelo Snowflake), agora não é mais aplicado:

Anteriormente:

Se uma consulta ultrapassasse o número máximo de iterações (100), a consulta falhava com a seguinte mensagem de erro:

Recursion exceeded max iteration count (n)

onde n era o número máximo de iterações permitido.

O código de erro para este erro era 100189.

Atualmente:

Não há limite para o número de iterações realizadas.

Consultas que anteriormente falhavam com a mensagem de erro acima (em particular, consultas que resultam em loops infinitos) não falham mais e continuam funcionando até que a consulta seja bem-sucedida ou atinja o tempo limite, o que pode ser controlado através da definição do parâmetro STATEMENT_TIMEOUT_IN_SECONDS.

Para determinar se você teve consultas que excederam o número máximo de iterações antes da ativação da mudança, verifique a exibição QUERY_HISTORY para consultas que falharam com o código de erro 100189:

SELECT * FROM snowflake.account_usage.query_history WHERE error_code = 100189;

Copy

Com a mudança ativada, se essas mesmas consultas forem executadas, elas não falharão. Se ocorrer um loop infinito, a consulta não terminará prematuramente. Em vez disso, a consulta será realizada até ter sucesso ou até atingir o tempo limite (por exemplo, exceder o número de segundos definido no parâmetro STATEMENT_TIMEOUT_IN_SECONDS).

Consulte Solução de problemas de uma CTE recursiva para informações sobre como loops infinitos podem ocorrer, como identificá-los e como corrigi-los.

Time Travel: o parâmetro herdado DATA_RETENTION_TIME_IN_DAYS é conservado em tabelas transitórias¶

O comportamento das tabelas transitórias quando o parâmetro DATA_RETENTION_TIME_IN_DAYS é explicitamente definido para 0 (dias) para um objeto pai (conta, banco de dados ou esquema) mudou como segue:

Anteriormente:

As tabelas transitórias não herdavam a configuração do parâmetro DATA_RETENTION_TIME_IN_DAYS dos objetos pai quando o tempo de retenção de dados era de 0 dias. As tabelas transitórias eram criadas com um tempo de retenção de dados de 1 dia, independentemente do tempo de retenção de dados do objeto pai.

Atualmente:

As tabelas transitórias herdam o tempo de retenção de dados definido em um objeto pai (esquema, banco de dados, conta) se o DATA_RETENTION_TIME_IN_DAYS do objeto pai estiver definido como 0.

Para gerar uma lista de tabelas transitórias em uma conta em que pelo menos um de seus pais (esquema ou banco de dados) tenham DATA_RETENTION_TIME_IN_DAYS definido como 0, execute as instruções no exemplo a seguir. No entanto, observe o seguinte antes de executar as instruções:

• A lista inclui tabelas transitórias com o parâmetro DATA_RETENTION_TIME_IN_DAYS explicitamente definido para 1.

  Se DATA_RETENTION_TIME_IN_DAYS estiver definido para 0 no nível da conta, execute o conjunto de instruções no segundo exemplo abaixo para listar todas as tabelas transitórias com DATA_RETENTION_TIME_IN_DAYS definido para 1.

• Antes de remover a definição do parâmetro de qualquer tabela, recomendamos verificar se Time Travel deve ser desativado para essa tabela.

show tables in account;
set
  table_qid = (
    select
      last_query_id()
);

show schemas in account;
set
  schema_qid = (
    select
      last_query_id()
);

show databases in account;
set
  database_qid = (
    select
      last_query_id()
);

with table_v as (
    select
      "database_name" as database_name,
      "schema_name" as schema_name,
      "name" as table_name,
      "kind" = 'TRANSIENT' as is_transient,
      "retention_time" as table_retention_time
    from
      table(result_scan($table_qid))
  ),
  schema_v as (
    select
      "name" as schema_name,
      iff(
        try_to_number("retention_time") is null,
        0,
        try_to_number("retention_time")
      ) as schema_retention_time
    from
      table(result_scan($schema_qid))
  ),
  database_v as (
    select
      "name" as database_name,
      "retention_time" as database_retention_time
    from
      table(result_scan($database_qid))
  )
select
  *
from
  table_v
  left join schema_v using (schema_name)
  left join database_v using (database_name)
where
  is_transient
  and table_retention_time = 1
  and (
    schema_retention_time = 0
    or database_retention_time = 0
  );

Copy

Se DATA_RETENTION_TIME_IN_DAYS estiver definido como 0 no nível da conta, execute as seguintes instruções para listar todas as tabelas transitórias com DATA_RETENTION_TIME_IN_DAYS definido para 1:

-- Verify account level DATA_RETENTION_TIME_IN_DAYS setting is 0
show parameters like 'DATA_RETENTION_TIME_IN_DAYS' in account;

show tables in account;

select
  "database_name" as database_name,
  "schema_name" as schema_name,
  "name" as table_name,
  "kind" = 'TRANSIENT' as is_transient,
  "retention_time" as table_retention_time
from
  table(result_scan(last_query_id()))
where
  is_transient
  and table_retention_time = 1;

Copy

Para remover a definição do parâmetro DATA_RETENTION_TIME_IN_DAYS de uma tabela transitória existente, que permite herdar a definição do parâmetro de um objeto pai, use ALTER TABLE:

ALTER TABLE <table_name> UNSET DATA_RETENTION_TIME_IN_DAYS;

Copy

Para verificar o tempo de retenção de dados definido em uma tabela, use SHOW TABLES:

SHOW TABLES LIKE '<table_name>';

Copy

Comando SHOW ORGANIZATION ACCOUNTS: nova coluna¶

A seguinte coluna foi adicionada à saída do comando SHOW TAGS:

Comando SHOW PROCEDURES: a saída inclui tanto os procedimentos armazenados criados pelo usuário quanto os internos¶

Snowflake oferece suporte à criação de procedimentos armazenados como objetos no nível de esquema em qualquer banco de dados de uma conta. O comando SHOW PROCEDURES retorna informações sobre esses procedimentos armazenados criados pelo usuário.

Com a introdução da classificação de dados, Snowflake agora também fornece procedimentos armazenados internos que podem ser chamados como objetos globais, assim como as funções internas.

A saída do comando SHOW PROCEDURES mudou da seguinte forma para oferecer suporte aos procedimentos armazenados internos:

Anteriormente:

O comando retornava apenas procedimentos armazenados no banco de dados/esquema atual ou especificado (ou para a conta inteira).

Para visualizar os procedimentos armazenados internos fornecidos por Snowflake, você podia usar a palavra-chave BUILTIN no comando. Por exemplo:

SHOW BUILTIN PROCEDURES;

Copy

Entretanto, observe que Snowflake fornece apenas um procedimento armazenado interno, ASSOCIATE_SEMANTIC_CATEGORY_TAGS.

Atualmente:

A função retorna todos os procedimentos armazenados, incluindo tanto os procedimentos criados pelo usuário como os procedimentos armazenados internos.

Isso torna o comando SHOW PROCEDURES consistente com o comando SHOW FUNCTIONS.

A mudança não afeta as palavras-chave BUILTIN ou USER, que podem ser usadas para retornar explicitamente os procedimentos armazenados internos ou criados pelo usuário. Por exemplo:

SHOW BUILTIN PROCEDURES;

SHOW USER PROCEDURES;

Copy

Função SYSTEM$ESTIMATE_SEARCH_OPTIMIZATION_COSTS: mudanças na base de estimativa¶

SYSTEM$ESTIMATE_SEARCH_OPTIMIZATION_COSTS é uma função do sistema que você pode chamar para determinar os custos estimados para adicionar otimização de pesquisa a uma tabela.

Esta função mudou para usar uma pequena amostra como base para estimar os custos. Com esta mudança, a função informa estimativas de custos mais precisas. Entretanto, a mudança afeta o uso do warehouse e a saída da função, assim como pode afetar o desempenho da função, conforme descrito abaixo:

Anteriormente:

A função utilizava um modelo simples para estimar os custos. Em decorrência do fato de que a função utilizava um modelo simples para estimar os custos:

• Você não precisava ter um warehouse em uso ao chamar a função.

• Como a função não utilizava um warehouse, você não era cobrado pelo uso do warehouse desta função.

• A função era executada e retornada em segundos.

• Na saída JSON retornada, para os objetos nomeados BuildCosts e StorageCosts na matriz costPositions:

  • Não havia o campo comment.

  • O campo computationMethod era definido para "EstimatedUpperBound".

Atualmente:

A função agora retira uma pequena amostra de dados da tabela especificada, produz um caminho de acesso de busca temporário, analisa o custo do processo e extrapola os resultados para estimar o custo de toda a tabela. Em decorrência do fato de que a função usa amostragem para estimar os custos:

• Para chamar a função, você precisa ter um warehouse em uso. Se nenhum warehouse estiver em uso no momento, a função imprime a seguinte mensagem:

  No active warehouse selected in the current session.

  Selecione um warehouse ativo com o comando USE WAREHOUSE. Para executar esta função, você pode usar um warehouse X-Small. O tamanho do warehouse não afeta a velocidade e o desempenho desta função.

• Como a função utiliza um warehouse, agora você é cobrado pelo uso do warehouse desta função.

• A função leva mais tempo para executar e retornar resultados (entre 20 segundos e 10 minutos). Conforme observado acima, o uso de um warehouse de maior tamanho não resulta na execução mais rápida desta função.

• Na saída JSON retornada, para os objetos nomeados BuildCosts e StorageCosts na matriz costPositions:

  • O campo comment é definido para "estimated via sampling".

  • O campo computationMethod é definido para "Estimated".

Exibição LOGIN_HISTORY (Account Usage): nova coluna¶

A seguinte nova coluna foi adicionada à exibição ACCOUNT_USAGE.LOGIN_HISTORY:

Exibições QUERY_HISTORY (Account Usage): saída consistente com a função QUERY_HISTORY¶

Os valores dos bytes de transferência de dados de entrada e de saída são inconsistentes entre os seguintes elementos:

• Exibições ACCOUNT_USAGE.QUERY_HISTORY e READER_ACCOUNT_USAGE.QUERY_HISTORY

• Saída da função de tabela INFORMATION_SCHEMA.QUERY_HISTORY

As exibições Account Usage incluem bytes de transferência de dados de entrada e saída quando o valor da nuvem de transferência de dados (INBOUND_DATA_TRANSFER_CLOUD ou OUTBOUND_DATA_TRANSFER_CLOUD respectivamente) é nulo.

Estas exibições mudaram da seguinte forma:

Anteriormente:

As exibições QUERY_HISTORY em ACCOUNT_USAGE e READER_ACCOUNT_USAGE incluíam os seguintes elementos:

• A coluna INBOUND_DATA_TRANSFER_BYTES incluía bytes de transferência de dados quando o valor INBOUND_DATA_TRANSFER_CLOUD era nulo.

• A coluna OUTBOUND_DATA_TRANSFER_BYTES incluía bytes de transferência de dados quando o valor OUTBOUND_DATA_TRANSFER_CLOUD era nulo.

Atualmente:

As exibições agora são consistentes com a saída da função de tabela INFORMATION_SCHEMA.QUERY_HISTORY.

As colunas INBOUND_DATA_TRANSFER_BYTES e OUTBOUND_DATA_TRANSFER_BYTES não incluem bytes de transferências de arquivos quando o valor associado INBOUND_DATA_TRANSFER_CLOUD ou OUTBOUND_DATA_TRANSFER_CLOUD é nulo.

Comandos DESCRIBE STREAM/SHOW STREAM: novas colunas na saída¶

A saída dos comandos DESCRIBE STREAM e SHOW STREAMS agora inclui as seguintes colunas adicionais:

As novas colunas foram inseridas entre as colunas TABLE_NAME e TYPE existentes.

Tabelas de diretório: metadados atualizados automaticamente quando o estágio é criado¶

Quando você cria um estágio que inclui uma tabela de diretório, os metadados da tabela de diretório agora são automaticamente atualizados no mesmo instante apenas uma vez. A atualização dos metadados da tabela de diretório sincroniza os metadados com a lista atual de arquivos de dados no caminho especificado do estágio.

Anteriormente, para registrar os arquivos de dados existentes nos metadados da tabela de diretório, os usuários tinham que executar a instrução ALTER STAGE … REFRESH após a criação do estágio.

Essa melhoria foi implementada através do novo parâmetro REFRESH_ON_CREATE do comando CREATE STAGE. Quando REFRESH_ON_CREATE = TRUE (valor padrão), Snowflake atualiza automaticamente os metadados da tabela de diretório apenas uma vez quando o estágio é criado.