Pacote 2022_08¶

Editar integrações de segurança SAML2: aplicação das datas de validade de certificados X.509¶

Ao definir uma integração de segurança SAML2 para permitir um login único, o administrador de segurança especifica um certificado X.509 usando o parâmetro SAML2_X509_CERT.

Snowflake agora impõe as datas de validade destes certificados X.509 de modo que certificados vencidos resultem em autenticação falhada. Certificados com uma data NotBefore que ainda não tenha ocorrido também falham na autenticação. A imposição das datas de validade não pode ser desativada.

Anteriormente:

Snowflake não verificou a data de validade de um certificado X.509 para verificar se ele estava expirado ou se a data NotBefore ainda não tinha ocorrido.

Atualmente:

Snowflake impõe as datas de validade de um certificado X.509. Se a data atual não se enquadrar nas datas de validade do certificado, a autenticação falhará.

Bancos de dados e esquemas: descarte ou substituição não permitida se isso resultar em referências pendentes para políticas de senhas e políticas de sessão¶

O comportamento das operações DROP SCHEMA, DROP DATABASE, CREATE OR REPLACE DATABASE e CREATE OR REPLACE SCHEMA com relação a uma política de senhas e política de sessão mudou da seguinte forma:

Anteriormente:

Snowflake permitiu as operações DROP e REPLACE no esquema/base de dados que continham a política quando a política foi definida na conta Snowflake contendo a política ou quando a política foi definida em um usuário na mesma conta.

Atualmente:

Snowflake permite as operações DROP e REPLACE no esquema/base de dados que contém a política quando a política é definida na conta Snowflake que contém a política ou quando a política é definida em um usuário na mesma conta.

Como resultado, o comportamento dos mesmos quatro comandos mudou.

• DROP DATABASE

• DROP SCHEMA

• CREATE OR REPLACE DATABASE

• CREATE OR REPLACE SCHEMA

Dependendo da operação, Snowflake retorna uma das seguintes mensagens de erro:

Política definida em um usuário:

DROP DATABASE e CREATE OR REPLACE DATABASE:

Não é possível descartar o banco de dados porque a política 'MYDB.MYSCHEMA.POLICY1' está definida no usuário 'JSMITH'. Remova a definição da política 'MYDB.MYSCHEMA.POLICY1' e depois tente a operação de descarte novamente.

DROP SCHEMA e CREATE OR REPLACE SCHEMA:

Não é possível descartar o esquema porque a política 'MYDB.MYSCHEMA.POLICY1' está definida no usuário 'JSMITH'. Remova a definição da política 'MYDB.MYSCHEMA.POLICY1' e depois tente a operação de descarte novamente.

Política definida na conta:

DROP DATABASE e CREATE OR REPLACE DATABASE:

Não é possível descartar o banco de dados porque a política 'MYDB.MYSCHEMA.POLICY1' está definida na conta 'MYACCOUNT'. Remova a definição da política 'MYDB.MYSCHEMA.POLICY1' e depois tente a operação de descarte novamente.

DROP SCHEMA e CREATE OR REPLACE SCHEMA:

Cannot drop schema because policy 'MYDB.MYSCHEMA.POLICY1' is set on account 'MYACC

Comando SHOW FUNCTIONS: nova coluna na saída¶

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

Para ajudar a minimizar o impacto desta adição, a coluna foi adicionada como a última coluna na saída.

Comando SHOW VIEWS: nova coluna na saída¶

A saída SHOW VIEWS inclui agora uma nova coluna CHANGE_TRACKING. A coluna indica se o rastreamento de alterações está habilitado na exibição.

A coluna exibe um dos seguintes valores para exibições individuais:

• ON: o rastreamento de alterações está habilitado. Você pode consultar estes dados de rastreamento de alterações usando fluxos ou a cláusula CHANGES para instruções SELECT.

• OFF: o rastreamento de alterações estará atualmente desabilitado, mas poderia ser habilitado.

Para ajudar a limitar o impacto desta mudança, a coluna foi adicionada como a última coluna na saída.

Função GET_DDL: suporte adicionado para tags e políticas¶

A função GET_DDL agora oferece suporte a tags e políticas da seguinte forma:

• Quando uma tag é definida em uma tabela, exibição ou exibição materializada, a saída de chamada da função GET_DDL incluirá as atribuições da tag na instrução CREATE.

• Quando uma ou mais tags são definidas em um esquema ou banco de dados, a saída de chamada da função GET_DDL inclui as seguintes instruções para atribuir as tags:

  • Uma instrução ALTER DATABASE quando a tag é definida no banco de dados.

  • Uma instrução ALTER SCHEMA quando a tag é definida no esquema.

  • Uma instrução ALTER DATABASE e uma instrução ALTER SCHEMA quando a tag é definida tanto no banco de dados quanto no esquema.

• Quando uma tag é criada em um esquema e este mesmo esquema é especificado ao chamar a função GET_DDL, a saída incluirá uma instrução CREATE OR REPLACE para gerar a tag.

  O mesmo vale para uma tag criada em um banco de dados: especificar o banco de dados ao chamar a função GET_DDL incluirá a instrução CREATE OR REPLACE para gerar a tag.

• Se uma política de acesso a linhas estiver definida em uma tabela ou exibição ou uma política de mascaramento estiver definida na coluna, chamar a função GET_DDL na tabela ou exibição adicionará a palavra-chave WITH para indicar que a política está definida na tabela, exibição ou coluna na instrução CREATE.

  Observe que se você fosse criar manualmente uma tabela, especificar a palavra-chave WITH é opcional ao definir uma política de acesso a linhas na tabela ou exibição ou uma política de mascaramento em uma coluna.

Exibições de uso de Data Sharing: mudanças na coluna nas exibições¶

Todas as exibições no esquema DATA_SHARING_USAGE (no banco de dados compartilhado SNOWFLAKE) mudaram como se segue:

Anteriormente:

Os dados exibidos na coluna SNOWFLAKE_REGION nas exibições foram exibidos como <região de> <nuvem>, com todas as letras minúsculas (por exemplo, aws us_west_2). Isto foi inconsistente com os valores exibidos para a região do Snowflake na saída SHOW REGIONS.

Exibições impactadas:

• LISTING_ACCESS_HISTORY

• LISTING_CONSUMPTION_DAILY

• LISTING_EVENTS_DAILY

• LISTING_TELEMETRY_DAILY

Atualmente:

Nas exibições listadas acima, os valores na coluna SNOWFLAKE_REGION são exibidos agora como <região da>_<nuvem> com todas as letras maiúsculas. Isto é consistente com a saída SHOW REGIONS.

Por exemplo, a região us_west_2 em AWS é agora exibida como AWS_US_WEST_2.

Exibições de uso de Data Sharing: nova coluna nas exibições¶

Este anúncio foi adicionado em 13 de fevereiro de 2023.

A coluna REGION_GROUP foi adicionada às seguintes exibições no esquema DATA_SHARING_USAGE:

• LISTING_ACCESS_HISTORY

• LISTING_CONSUMPTION_DAILY

• LISTING_EVENTS_DAILY

• LISTING_TELEMETRY_DAILY

Para ajudar a minimizar o impacto desta adição, a coluna REGION_GROUP foi adicionada como a última coluna na saída.

Exibição ACCESS_HISTORY (Account Usage): novas colunas na exibição¶

As seguintes colunas foram adicionadas à exibição ACCESS_HISTORY (no esquema ACCOUNT_USAGE):

• object_modified_by_ddl

• policies_referenced

Para ajudar a minimizar o impacto desta adição, essas colunas foram adicionadas como as últimas colunas na saída.

Observe que estas colunas são placeholders e serão preenchidas em um próximo lançamento.

Exibição FUNCTIONS (Information Schema): nova coluna na exibição¶

A seguinte coluna foi adicionada à exibição FUNCTIONS do Information Schema (no esquema INFORMATION_SCHEMA):

Para ajudar a minimizar o impacto desta adição, a coluna foi adicionada como a última coluna na exibição.

Exibição TABLE_CONSTRAINTS (Account Usage): nova coluna na exibição¶

A seguinte nova coluna foi adicionada à exibição TABLE_CONSTRAINTS (no esquema ACCOUNT_USAGE):

Exibição USAGE_IN_CURRENCY_DAILY (Organization Usage): nova coluna na exibição¶

A exibição USAGE_IN_CURRENCY_DAILY (no esquema ORGANIZATION_USAGE) agora inclui uma nova coluna BALANCE_SOURCE.

Para ajudar a limitar o impacto desta mudança, a coluna foi adicionada como a última coluna na exibição.

Exibição USERS (Account Usage): nova coluna na exibição¶

A exibição USERS (no esquema ACCOUNT_USAGE) foi atualizada para incluir uma nova coluna USER_ID.

Consumidores: comandos SHOWretornam erro se a conta tiver sido revogada do compartilhamento¶

O comportamento dos comandos SHOW <objetos> em uma conta de consumidor para a qual um compartilhamento foi revogado mudou da seguinte forma:

Anteriormente:

Se uma conta de consumidor montou dois ou mais compartilhamentos contendo os mesmos objetos do provedor e mais tarde o provedor revoga a conta de apenas um dos compartilhamentos, os dados foram devolvidos quando comandos SHOW foram executados na conta de consumidor no banco de dados ou esquema montado no(s) compartilhamento(s) restante(s).

Por exemplo, share1 e share2 contendo os mesmos objetos do provedor foram montados na conta do consumidor xy12345 e depois o provedor removeu a conta de share2:

alter share share2 remove accounts = xy12345;

Copy

Quando qualquer um dos seguintes comandos tiver sido executado na conta do consumidor, os dados válidos foram devolvidos:

SHOW <objects> IN DATABASE <revoked_mounted_db>;

SHOW <objects> IN SCHEMA <revoked_mounted_db>.<schema>;

Copy

Atualmente:

Se o mesmo cenário ocorrer, um erro semelhante ao seguinte é retornado ao executar os comandos SHOW descritos acima:

SQL compilation error: <detalhes do erro específico>.

Políticas de redes: referências pendentes para políticas com replicação e failover/failback¶

O comportamento das políticas de replicação e redes, juntamente com as políticas de failover/failback e de redes, mudou da seguinte forma:

Anteriormente:

Com políticas de redes e suas referências (ou seja, atribuições à conta principal e usuários na conta principal):

• Especifique POLICIES de USERS e NETWORK no grupo de replicação/failover quando houver políticas de redes em nível de usuário.

• Especifique POLICIES de NETWORK no grupo de replicação/failover quando houver somente políticas de redes em nível de conta.

• A replicação e o failover/failback ocorreram mesmo que o resultado tenha sido uma referência pendente na conta de destino.

Uma referência suspensa significa que um objeto na conta secundária faz referência a um objeto que não existe na mesma conta. Por exemplo:

• Um usuário/nome de usuário na conta secundária faz referência a uma política de redes que não está na conta secundária. Este cenário ocorre quando uma política de redes é atribuída a um usuário na conta principal e o grupo de replicação/failover especifica POLICIES de USERS, mas não de NETWORK.

• Uma política de redes é anexada à conta primária e o grupo de replicação/failover não inclui NETWORK POLICIES.

Atualmente:

O comportamento atual mudou da seguinte forma:

• Especifique POLICIES de PARAMETERS de ACCOUNT, USERS e NETWORK no grupo de replicação/failover quando houver políticas de redes em nível de usuário.

• Especifique POLICIES de PARAMETERS de ACCOUNT e NETWORK no grupo de replicação/failover quando houver apenas políticas de redes em nível de conta.

• A replicação e o failover/failback falham na conta secundária se o resultado for uma referência suspensa.

Por exemplo, se a conta principal tiver um conjunto de políticas de redes definido em nível de conta e uma política de redes definida em nível de usuário e referências suspensas seriam criadas na conta de destino tanto para o parâmetro em nível de conta quanto para o usuário:

Dangling references in the snapshot. Correct the errors before refreshing again. The following references are missing (referred entity <- [referring entities]):

ACCOUNT PARAMETERS <- [NETWORK POLICIES]. Add ACCOUNT PARAMETER into the replication group to fix it.

NETWORK_POLICY 'MYACCOUNT.P2' <- [USER 'MYACCOUNT.USERNAME']

Copy

Caso contrário, a mensagem de erro especifica a instrução do parâmetro da conta ou a instrução do usuário, dependendo de como o grupo de replicação está configurado e qual seria o resultado na conta de destino.

Grupos de replicação: limitar objetos de conta à associação em um único grupo¶

A replicação de conta permite a replicação de objetos de conta em um grupo de replicação ou de failover. Os objetos de conta podem incluir parâmetros de conta, funções, objetos de segurança e usuários. Para obter uma lista completa dos objetos suportados, consulte Objetos replicados.

Atualmente, se uma conta não tiver um grupo de failover que inclua tipos de objetos de conta, diferentes tipos de objetos de conta podem ser incluídos em mais de um grupo de replicação. O comportamento mudou da seguinte forma:

Anteriormente:

Tipos de objetos de conta poderiam ser incluídos em mais de um grupo de réplicas.

Atualmente:

Os tipos de objetos de conta são limitados a um grupo de replicação.

Grupos de replicação: parâmetros de contas somente leitura em contas de destino¶

Quando um tipo de objeto de conta for incluído em um grupo de replicação ou de failover, o tipo de objeto será somente de leitura na conta de destino. Por exemplo, se as funções forem replicadas para uma conta de destino, as funções não poderão ser criadas ou modificadas na conta de destino.

Os parâmetros da conta podem ser incluídos em um grupo de replicação ou de failover a ser replicado em uma conta de destino. Alguns parâmetros (por exemplo, STATEMENT_TIMEOUT_IN_SECONDS) podem ser definidos em vários níveis (por exemplo, no nível da conta e por usuário). A replicação do parâmetro de conta replica apenas a configuração de nível de conta para um parâmetro.

O comportamento para replicação do parâmetro da conta mudou da seguinte forma:

Anteriormente:

Se PARAMETERS de ACCOUNT forem incluídos na lista OBJECT_TYPES para um grupo de replicação ou de failover, os parâmetros secundários de nível de conta nas contas de destino poderiam ser modificados.

Atualmente:

Se PARAMETERS de ACCOUNT estiverem incluídos na lista OBJECT_TYPES para um grupo de replicação ou de failover, os parâmetros secundários de nível de conta nas contas de destino serão somente leitura.

Comando SHOW REPLICATIONGROUPS: mudanças na saída¶

O comando SHOW REPLICATION GROUPS inclui uma coluna next_scheduled_refresh em sua saída que exibe a data e a hora da próxima atualização programada para um grupo de failover ou de replicação secundário com uma programação da replicação. Esta coluna será NULL para grupos de replicação secundária ou failover com uma programação de replicação se não estiver na região atual.

O comportamento mudou da seguinte forma:

Anteriormente:

A coluna next_scheduled_refresh era NULL para grupos de réplica secundária ou failover com uma programação de replicação que não se encontrava na região atual.

Atualmente:

A coluna next_scheduled_refresh inclui a data e a hora para a próxima atualização programada para todos os grupos de replicação e failover secundários com uma programação de replicação.