Considerações sobre clonagem

Este tópico fornece considerações importantes ao clonar objetos no Snowflake, particularmente bancos de dados, esquemas e tabelas não temporárias. Fatores tais como transações DDL e DML (sobre o objeto de origem), Time Travel e períodos de retenção de dados podem afetar o clone do objeto.

Neste tópico:

Privilégios de controle de acesso para objetos clonados

Se o objeto de origem for um banco de dados ou esquema, o clone herda todos os privilégios concedidos sobre os clones de todos os objetos filhos contidos no objeto de origem:

  • Para bancos de dados, os objetos contidos incluem esquemas, tabelas, exibições, etc.

  • Para esquemas, os objetos contidos incluem tabelas, exibições, etc.

Observe que o próprio clone do contêiner (banco de dados ou esquema) não herda os privilégios concedidos sobre o contêiner de origem.

Instruções CREATE <objeto> … CLONE para a maioria dos objetos não copiam concessões sobre o objeto de origem para o clone do objeto. Entretanto, comandos CREATE <objeto> que oferecem suporte à cláusula COPY GRANTS (por exemplo, CREATE TABLE, CREATE VIEW) permitem, opcionalmente, copiar concessões para clones de objetos. Por exemplo, a sintaxe do comando CREATE TABLE … CLONE oferece suporte ao parâmetro COPY GRANTS. Quando o parâmetro COPY GRANTS é especificado em uma instrução CREATE TABLE, a operação de criação copia todos os privilégios, exceto OWNERSHIP, da tabela de origem para a nova tabela. O mesmo comportamento é verdadeiro para outros comandos CREATE que oferecem suporte à cláusula COPY GRANTS.

Em todos os outros casos, você deve conceder os privilégios necessários ao clone recém-criado (usando GRANT <privilégios>).

Clonagem e objetos Snowflake

Esta seção descreve considerações especiais de clonagem com relação a objetos específicos do Snowflake.

Clonagem e parâmetros de objetos

Os objetos clonados herdam os parâmetros do objeto que foram definidos no objeto de origem quando esse objeto foi clonado. Se um parâmetro de objeto puder ser definido em contêineres de objeto (isto é, conta, banco de dados, esquema) e não estiver explicitamente definido no objeto de origem, um clone de objeto herda o valor padrão do parâmetro ou o valor substituído no nível inferior. Para obter mais informações sobre parâmetros de objetos, consulte Parâmetros.

Clonagem e sequências padrão

Em uma tabela, uma coluna pode fazer referência a uma sequência que gera valores padrão. Quando uma tabela é clonada, a tabela clonada faz referência à origem ou à sequência clonada:

  • Se o banco de dados ou esquema contendo tanto a tabela quanto a sequência for clonado, a tabela clonada faz referência à sequência clonada.

  • Caso contrário, a tabela clonada faz referência à sequência de origem.

    Por exemplo, se a sequência for definida em um banco de dados ou esquema diferente, a tabela clonada faz referência à sequência de origem. Ou se você clonar apenas a própria tabela, a tabela clonada faz referência à sequência de origem.

    Se você não quiser que a nova tabela continue usando a sequência de origem, execute o seguinte comando:

    ALTER TABLE <table_name> ALTER COLUMN <column_name> SET DEFAULT <new_sequence>.nextval;
    
    Copy

Clonagem e restrições de chave estrangeira

Uma tabela pode ter uma restrição de chave estrangeira que faz referência a uma tabela que inclui a chave primária. Quando uma tabela com uma restrição de chave estrangeira é clonada, a tabela clonada faz referência à origem ou à tabela clonada que inclui a chave primária:

  • Se o banco de dados ou esquema contendo ambas as tabelas for clonado, a tabela clonada com a chave estrangeira faz referência à chave primária na outra tabela clonada.

  • Se as tabelas estiverem em bancos de dados ou esquemas separados, a tabela clonada faz referência à chave primária na tabela de origem.

Clonagem e chaves de clustering

Uma tabela pode ter um subconjunto de colunas designado como chave de clustering para colocalizar linhas similares na mesma micropartição. Quando uma tabela com uma chave de clustering é clonada, a nova tabela é criada com uma chave de clustering. Por padrão, Clustering automático é suspenso para a nova tabela. Para retomar o clustering automático para a nova tabela, execute o seguinte comando:

ALTER TABLE <name> RESUME RECLUSTER
Copy

Clonagem e estágios

Estágios nomeados externos individuais podem ser clonados. Um estágio externo faz referência a um bucket ou contêiner no armazenamento em nuvem externo; a clonagem de um estágio externo não tem impacto sobre o armazenamento em nuvem referenciado.

Os estágios internos (ou seja, Snowflake) nomeados não podem ser clonados.

Ao clonar um banco de dados ou esquema:

  • Os estágios externos nomeados que estavam presentes na origem quando a operação de clonagem começou são clonados.

  • Tabelas são clonadas, o que significa que o estágio interno associado a cada tabela também é clonado. Quaisquer arquivos de dados que estavam presentes em um estágio de tabela no banco de dados ou esquema de origem não são copiados para o clone (ou seja, os estágios da tabela clonada estão vazios).

  • Estágios internos nomeados não são clonados.

Clonagem e canais

Quando um banco de dados ou esquema é clonado, quaisquer canais no contêiner de origem que fazem referência a um estágio interno (ou seja, Snowflake) não são clonados.

Entretanto, quaisquer canais que façam referência a um estágio externo são clonados. Isto inclui quaisquer objetos de canal onde o parâmetro INTEGRATION está definido. Este parâmetro aponta para uma integração de notificação para habilitar a ingestão automática do Snowpipe ao carregar dados de arquivos no Google Cloud Storage ou no armazenamento de blob do Microsoft Azure.

Quando um arquivo de dados é criado em um local de estágio (por exemplo, contêiner de armazenamento de blob), uma cópia da notificação é enviada para cada canal que corresponda ao local do estágio. Isto resulta no seguinte comportamento:

  • Se uma tabela estiver totalmente qualificada na instrução COPY na definição do canal (na forma de db_name.schema_name.table_name ou schema_name.table_name), então o Snowpipe carrega dados duplicados na tabela de origem (ou seja, database.schema.table na instrução COPY) para cada canal.

  • Se uma tabela não estiver totalmente qualificada na definição do canal, então o Snowpipe carrega os dados na tabela (por exemplo, mytable) na origem e nos bancos de dados/esquemas clonados.

O estado padrão de um clone de canal é o seguinte:

  • Quando AUTO_INGEST = FALSE, um canal clonado é pausado por padrão.

  • Quando AUTO_INGEST = TRUE, um canal clonado é definido como o estado STOPPED_CLONED. Nesse estado, os canais não acumulam notificações de evento como resultado de arquivos preparados recentemente. Quando um canal é explicitamente retomado, ele só processa arquivos de dados acionados como resultado de novas notificações de eventos.

Um clone de canal em qualquer estado pode ser retomado executando uma instrução ALTER PIPE … RESUME.

Clonagem e fluxos

Atualmente, quando um banco de dados ou esquema que contém tabelas de origem e fluxos de origem é clonado, quaisquer registros não consumidos nos fluxos (no clone) ficam inacessíveis. Este comportamento é consistente com o Time Travel para tabelas. Se uma tabela for clonada, os dados históricos para o clone da tabela começam no momento/ponto em que o clone foi criado.

Clonagem e tarefas

Quando um banco de dados ou esquema que contém tarefas é clonado, as tarefas no clone são suspensas por padrão. As tarefas podem ser retomadas individualmente (usando ALTER TASK … RESUME).

Clonagem e objetos de governança

Políticas de mascaramento e acesso a linhas:

A abordagem a seguir ajuda a proteger os dados dos usuários com o privilégio SELECT na tabela ou exibição ao acessar um objeto clonado.

  • A clonagem de um objeto individual de política não é permitida.

  • A clonagem de um esquema resulta na clonagem de todas as políticas dentro do esquema.

  • Uma tabela clonada é mapeada para as mesmas políticas que a tabela de origem. Em outras palavras, se uma política for definida em uma tabela base ou suas colunas, a política será anexada à tabela clonada ou a suas colunas.

    • Quando uma tabela é clonada no contexto da clonagem de seu esquema principal, se a tabela de origem tiver uma referência a uma política no mesmo esquema principal (ou seja, uma referência local), a tabela clonada terá uma referência à política clonada.

    • Se a tabela de origem se referir a uma política em um esquema diferente (ou seja, uma referência estrangeira), então a tabela clonada manterá a referência estrangeira.

Para obter mais informações, consulte CREATE <objeto> … CLONE.

Consulte também:

Tags:

  • Associações de tags no objeto de origem (por exemplo, tabela) são mantidas nos objetos clonados.

  • Para um banco de dados ou esquema:

    As tags armazenadas no banco de dados ou esquema também são clonadas.

    Quando um banco de dados ou esquema é clonado, as tags contidas no esquema ou banco de dados também são clonadas.

    Se existir uma tabela ou exibição no esquema de origem/banco de dados e houver referências a tags no mesmo esquema ou banco de dados, a tabela ou exibição clonada será mapeada para a tag clonada correspondente (no esquema/banco de dados de destino) em vez da tag no esquema ou banco de dados de origem.

Políticas de mascaramento baseadas em tags:

Para uma política de mascaramento baseada em tags em que a tag é armazenada em um esquema diferente da política de mascaramento e da tabela, a clonagem do esquema contendo a política de mascaramento e tabela resulta na tabela clonada sendo protegida pela política de mascaramento no esquema de origem, não no esquema clonado.

No entanto, para uma política de mascaramento baseada em tags em que a tag, a política de mascaramento e a tabela existem no esquema, a clonagem do esquema resulta na proteção da tabela pela política de mascaramento no esquema clonado, não no esquema de origem.

Se a tabela for clonada ou movida para um esquema ou banco de dados diferente e tiver sido originalmente protegida por uma política de mascaramento baseada em tags definida no esquema ou banco de dados, a tabela não será protegida pela política de mascaramento baseada em tags definida no esquema ou banco de dados de origem. A tabela é protegida pela política de mascaramento baseada em tags definida no esquema ou banco de dados de destino, se houver uma política de mascaramento baseada em tags definida no esquema ou banco de dados de destino.

Impacto de DDL na clonagem

A clonagem é rápida, mas não instantânea, particularmente para objetos grandes (por exemplo, tabelas). Como tal, se as instruções DDL forem executadas em objetos de origem (por exemplo, renomeando tabelas em um esquema) enquanto a operação de clonagem estiver em andamento, as mudanças podem não ser representadas no clone. Isto porque as instruções DDL são atômicas e não fazem parte de transações com múltiplas instruções.

Além disso, o Snowflake não registra quais nomes de objetos estavam presentes quando a operação de clonagem começou e quais nomes mudaram. Como tal, as instruções DDL que renomeiam (ou descartam e recriam) objetos filhos de origem competem com qualquer operação de clonagem em andamento e podem causar conflitos de nome.

No exemplo a seguir, a tabela t_sales é descartada e outra tabela é alterada e recebe o mesmo nome que a tabela descartada enquanto o banco de dados pai está sendo clonado, produzindo um erro:

CREATE OR REPLACE DATABASE staging_sales CLONE sales;

DROP TABLE sales.public.t_sales;

ALTER TABLE sales.public.t_sales_20170522 RENAME TO sales.public.t_sales;

002002 (42710): None: SQL compilation error: Object 'T_SALES' already exists.
Copy

Dica

Para evitar conflitos na resolução de nomes durante uma operação de clonagem, sugerimos que se abstenha de renomear objetos com um nome usado anteriormente por um objeto descartado até que a clonagem seja concluída.

Impacto de DML e retenção de dados na clonagem

O parâmetro DATA_RETENTION_TIME_IN_DAYS especifica o número de dias em que o Snowflake retém dados históricos para realizar ações de Time Travel em um objeto. Como os dados retidos para o Time Travel incorrem em custos de armazenamento no nível da tabela, alguns usuários definem este parâmetro como 0 para algumas tabelas, desativando efetivamente a retenção de dados para estas tabelas (ou seja, quando o valor é definido como 0, os dados do Time Travel retidos para transações DML são limpos, incorrendo em custos de armazenamento adicionais insignificantes).

As operações de clonagem requerem tempo para serem concluídas, particularmente para tabelas grandes. Durante este período, as transações DML podem alterar os dados em uma tabela de origem. Posteriormente, o Snowflake tenta clonar os dados da tabela como ela existia quando a operação começou. Entretanto, se os dados são limpos para transações DML que ocorrem durante a clonagem (porque o tempo de retenção da tabela é 0), os dados não estão disponíveis para completar a operação, produzindo um erro semelhante ao seguinte:

ProgrammingError occured: "000707 (02000): None: Data is not available." with query id None
Copy

Dica

Como alternativa, recomendamos uma das seguintes práticas recomendadas ao clonar um objeto:

  • Abster-se, se possível, de executar transações DML sobre o objeto de origem (ou qualquer um de seus filhos) até após a conclusão da operação de clonagem.

  • Se isso não for possível, antes de iniciar a clonagem, defina DATA_RETENTION_TIME_IN_DAYS=1 para todas as tabelas do esquema (ou banco de dados, se estiver clonando um banco de dados inteiro). Uma vez concluída a operação, lembre-se de redefinir o valor do parâmetro de volta para 0 para aquelas tabelas na origem, se desejado.

    Você também pode definir o valor para 0 para as tabelas clonadas (se planeja fazer mudanças de DML nas tabelas clonadas e não deseja incorrer em custos adicionais de armazenamento para o Time Travel nas tabelas).

Clonagem usando Time Travel (apenas bancos de dados, esquemas, tabelas e fluxos)

Esta seção fornece informações a serem consideradas ao usar o Time Travel para clonar objetos em um momento/ponto específico no passado.

Clonagem de objetos históricos

Se o objeto de origem não existia no momento/ponto definido na cláusula AT | BEFORE, um erro é retornado.

No exemplo a seguir, uma instrução CREATE TABLE … CLONE tenta clonar a tabela de origem em um ponto no passado (30 minutos antes), quando ela não existia:

CREATE TABLE t_sales (numeric integer) data_retention_time_in_days=1;

CREATE OR REPLACE TABLE sales.public.t_sales_20170522 CLONE sales.public.t_sales at(offset => -60*30);

002003 (02000): SQL compilation error:
Object 'SALES.PUBLIC.T_SALES' does not exist.
Copy

Qualquer objeto filho em um banco de dados ou esquema clonado que não existia no momento/ponto especificado não é clonado.

A operação de clonagem falha nos seguintes cenários:

  • Se o Time Travel especificado estiver além do tempo de retenção de qualquer filho atual do banco de dados ou esquema clonado.

  • Se um objeto de canal com AUTO-INGEST = TRUE definido foi recriado (usando a sintaxe CREATE OR REPLACE PIPE) ou descartado desde o ponto no tempo especificado na cláusula AT | BEFORE. Esta limitação não se aplica a objetos de canal criados para a ingestão manual do Snowpipe usando a API REST (ou seja, com AUTO-INGEST = FALSE).

Clonagem de metadados de objetos históricos

Um clone de objeto herda o nome e a estrutura do objeto de origem atual no momento em que a instrução CREATE <objeto> … CLONE é executada ou em um momento/ponto especificado no passado usando Time Travel. Um clone de objeto herda quaisquer outros metadados, tais como comentários ou chaves de clustering de tabelas, que são atuais no objeto de origem no momento em que a instrução é executada, independentemente do uso do Time Travel.

Nota

Para garantir um comportamento consistente em longas operações de clonagem, quando uma cláusula AT ou BEFORE não é especificada para uma instrução CREATE <objeto> … CLONE, a operação de clonagem define internamente o valor da cláusula AT como o carimbo de data/hora em que a instrução foi iniciada.