Considerações sobre clonagem¶

Clonagem e esquemas de acesso gerenciado¶

Se você clonar um esquema e especificar a cláusula WITH MANAGED ACCESS, os privilégios necessários dependerão de o esquema de origem ser gerenciado ou não gerenciado. Para detalhes, consulte os privilégios CREATE SCHEMA.

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

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 tabelas de eventos¶

Ao clonar uma tabela de eventos, você pode clonar apenas de e para tabelas de eventos. Em outras palavras, você não pode clonar de uma tabela normal para uma tabela de eventos, nem de uma tabela de eventos para uma tabela normal.

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 alertas¶

Quando um banco de dados ou esquema que contém alertas é clonado, os alertas no clone são suspensos por padrão.

Para retomar um alerta suspenso, você pode usar o comando ALTER ALERT … 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:

• Clonagem de tabelas externas e políticas de mascaramento.

• Clonagem de tabelas externas e políticas de acesso a linhas.

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.

Clonagem e funções de banco de dados¶

Você pode clonar uma função de banco de dados usando o comando CREATE DATABASE ROLE … CLONE se a função de banco de dados ainda não existir no banco de dados de destino. Para obter mais detalhes, consulte CREATE <objeto> … CLONE.

Clonagem e UDFs de Java¶

Uma UDF de Java pode ser clonada quando o banco de dados ou esquema contendo a UDF de Java é clonado. Para ser clonada, a UDF de Java deve satisfazer determinadas condições. Para obter mais informações, consulte Limitações da clonagem.

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.

  Como solução alternativa para objetos filhos que foram eliminados do Time Travel, use o parâmetro IGNORE TABLES WITH INSUFFICIENT DATA RETENTION do comando CREATE <objeto> … CLONE. Para obter mais informações, consulte Objetos filhos e tempo de retenção de dados.

• 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.