ALTER ALERT¶

Modifica as propriedades de um alerta existente e suspende ou reinicia um alerta existente.

Consulte também:: CREATE ALERT , DESCRIBE ALERT, DROP ALERT , SHOW ALERTS , EXECUTE ALERT

Sintaxe¶

ALTER ALERT [ IF EXISTS ] <name> { RESUME | SUSPEND };

ALTER ALERT [ IF EXISTS ] <name> SET
  [ WAREHOUSE = <string> ]
  [ SCHEDULE = '{ <number> MINUTE | USING CRON <expr> <time_zone> }' ]
  [ COMMENT = '<string_literal>' ]

ALTER ALERT [ IF EXISTS ] <name> SET TAG <tag_name> = '<tag_value>' [ , <tag_name> = '<tag_value>' ... ]

ALTER ALERT <name> UNSET TAG <tag_name> [ , <tag_name> ... ]

ALTER ALERT [ IF EXISTS ] <name> UNSET COMMENT

ALTER ALERT [ IF EXISTS ] <name> MODIFY CONDITION EXISTS (<condition>)

ALTER ALERT [ IF EXISTS ] <name> MODIFY ACTION <action>

Copy

Parâmetros¶

name

Identificador do alerta a ser alterado. Se o identificador contiver espaços ou caracteres especiais, toda a cadeia de caracteres deverá ser delimitada por aspas duplas. Os identificadores delimitados por aspas duplas também diferenciam letras maiúsculas de minúsculas.

{ RESUME | SUSPEND }

Especifica a ação a ser executada no alerta:

RESUME torna ativo um alerta suspenso.
SUSPEND coloca o alerta em um estado «Suspenso».

Se a programação do alerta for definida como um intervalo (isto é, num MINUTE), então para evitar ambiguidade, o tempo de intervalo base para a programação será redefinido para a hora atual quando o alerta é retomado.

O tempo de intervalo base inicia o contador de intervalo a partir da hora atual do relógio. Por exemplo, se um alerta for criado com 10 MINUTE e o alerta for retomado às 9:03h AM, então o alerta será executado às 9:13h AM, 9:23h AM, e assim por diante. Note que fazemos o melhor para assegurar precisão absoluta, mas apenas garantimos que os alertas não sejam executados antes que seu intervalo definido ocorra (por exemplo, no exemplo atual, o alerta poderia ser executado primeiro às 9:14h AM, mas definitivamente não será executado às 9:12h AM).

SET ...

Especifica uma (ou mais) propriedades a serem definidas para o alerta (separadas por espaços em branco, vírgulas ou novas linhas).

WAREHOUSE = warehouse_name

Especifica o warehouse virtual que fornece recursos de computação para a execução deste alerta.

SCHEDULE ...

Especifica o cronograma para avaliar periodicamente a condição do alerta.

Você pode especificar o cronograma de uma das seguintes maneiras:

USING CRON expr time_zone

Especifica uma expressão cronológica e um fuso horário para avaliar periodicamente a condição do alerta. Oferece suporte a um subconjunto de sintaxe de utilitário cron padrão.

A expressão cron consiste nos seguintes campos:

# __________ minute (0-59)
# | ________ hour (0-23)
# | | ______ day of month (1-31, or L)
# | | | ____ month (1-12, JAN-DEC)
# | | | | _ day of week (0-6, SUN-SAT, or L)
# | | | | |
# | | | | |
  * * * * *

Copy

Os seguintes caracteres especiais são suportados:

Caractere especial	Descrição
`*`	Curinga. Quando especificado para um determinado campo, o alerta é executado a cada unidade de tempo desse campo. Por exemplo, `*` no campo mês especifica que o alerta é executado todos os meses.
`L`	Significa “último”. Quando usado no campo do dia da semana, permite especificar construções como “a última sexta-feira” (“5L”) de um determinado mês. No campo do dia do mês, ele especifica o último dia do mês.
`/n`	Indica a `n` enésima instância de uma determinada unidade de tempo. Cada quanta de tempo é computada independentemente. Por exemplo, se `4/3` estiver especificado no campo do mês, a avaliação da condição está programada para abril, julho e outubro (ou seja, a cada 3 meses, começando com o quarto mês do ano). O mesmo cronograma é mantido nos anos seguintes. Ou seja, a condição não está programada para ser avaliada em janeiro (3 meses após a execução de outubro).

Caractere especial

Descrição

*

Curinga. Quando especificado para um determinado campo, o alerta é executado a cada unidade de tempo desse campo.

Por exemplo, * no campo mês especifica que o alerta é executado todos os meses.

L

Significa “último”. Quando usado no campo do dia da semana, permite especificar construções como “a última sexta-feira” (“5L”) de um determinado mês. No campo do dia do mês, ele especifica o último dia do mês.

/n

Indica a n enésima instância de uma determinada unidade de tempo. Cada quanta de tempo é computada independentemente.

Por exemplo, se 4/3 estiver especificado no campo do mês, a avaliação da condição está programada para abril, julho e outubro (ou seja, a cada 3 meses, começando com o quarto mês do ano).

O mesmo cronograma é mantido nos anos seguintes. Ou seja, a condição não está programada para ser avaliada em janeiro (3 meses após a execução de outubro).

Nota

Atualmente, a expressão cron avalia apenas em relação ao fuso horário especificado. Alterar o valor do parâmetro TIMEZONE para a conta (ou definir o valor no nível do usuário ou da sessão) não altera o fuso horário para o alerta.
A expressão cron define todas as horas válidas para a avaliação da condição do alerta. O Snowflake tenta avaliar a condição com base nesse cronograma; no entanto, qualquer tempo de execução válido é ignorado se uma execução anterior não tiver sido concluída antes do próximo tempo de execução válido começar.
Quando tanto um dia específico do mês como um dia da semana são incluídos na expressão cron, a avaliação da condição é programada em dias que satisfaçam o dia do mês ou o dia da semana. Por exemplo, SCHEDULE = 'USING CRON 0 0 10-20 * TUE,THU UTC' programa uma avaliação no horário 0AM em qualquer dia de 10 a 20 e também em qualquer terça-feira ou quinta-feira fora dessas datas.

num MINUTE

Especifica um intervalo (em minutos) de espera inserido entre as avaliações do alerta. Aceita apenas números inteiros positivos.

Também oferece suporte à sintaxe num M.

Para evitar ambiguidade, um tempo de intervalo base é definido quando o alerta é retomado (usando ALTER ALERT … RESUME).

O tempo de intervalo base inicia o contador de intervalo a partir da hora atual do relógio. Por exemplo, se um alerta for criado com 10 MINUTE e o alerta for retomado às 9:03h AM, então a condição do alerta será avaliada às 9:13h AM, 9:23h AM, e assim por diante. Note que fazemos o melhor para assegurar precisão absoluta, mas apenas garantimos que as condições não sejam avaliadas antes que seu intervalo definido ocorra (por exemplo, no exemplo atual, a condição poderia ser avaliada primeiro às 9:14h AM, mas definitivamente não será às 9:12h AM).

Nota

O valor máximo suportado é 11520 (8 dias). Os alertas que têm um valor maior de num MINUTE nunca têm suas condições avaliadas.

COMMENT = 'string_literal'

Especifica um comentário para o alerta.

TAG tag_name = 'tag_value' [ , tag_name = 'tag_value' , ... ]

Especifica o nome da tag e o valor da cadeia de caracteres dela.

O valor de tag é sempre uma cadeia de caracteres, e o número máximo de caracteres do valor da tag é 256.

Para obter informações sobre como especificar tags em uma instrução, consulte Cotas de tags para objetos e colunas.

UNSET ...

Especifica uma ou mais propriedades/parâmetros a serem desativados para o alerta, o que os restaura aos seus padrões:

TAG tag_key [ , tag_key ... ]
COMMENT

MODIFY CONDITION EXISTS (condition)

Especifica a instrução SQL que deve representar a condição para o alerta. Você pode usar os seguintes comandos:

Se a instrução retornar uma ou mais linhas, a ação de alerta será executada.

MODIFY ACTION action

Especifica a instrução SQL que deve ser executada se a condição retornar uma ou mais linhas.

Para enviar uma notificação por e-mail, você pode chamar o procedimento armazenado SYSTEM$SEND_EMAIL().

Requisitos de controle de acesso¶

A execução deste comando SQL exige funções com os seguintes privilégios no mínimo:

Para retomar um alerta:
- A função com o privilégio OWNERSHIP no alerta também deve ter o privilégio global EXECUTE ALERT.
- A função executando ALTER ALERT deve ter o privilégio OPERATE ou OWNERSHIP no alerta.
Para suspender um alerta, a função executando ALTER ALERT deve ter o privilégio OPERATE ou OWNERSHIP no alerta.
Para modificar as propriedades do alerta, a função executando ALTER ALERT deve ter o privilégio OWNERSHIP no alerta.

Observe que operar em qualquer objeto de um esquema também requer o privilégio USAGE no banco de dados e esquema principais.

Para instruções sobre como criar uma função personalizada com um conjunto específico de privilégios, consulte Criação de funções personalizadas.

Para informações gerais sobre concessões de funções e privilégios para executar ações de SQL em objetos protegíveis, consulte Visão geral do controle de acesso.

Notas de uso¶

Quando um alerta é retomado, o Snowflake verifica se a função com o privilégio OWNERSHIP no alerta também tem o privilégio USAGE no warehouse atribuído ao alerta, assim como o privilégio global EXECUTE ALERT; caso contrário, um erro será gerado.
Somente os administradores de conta (usuários com a função ACCOUNTADMIN) podem conceder o privilégio EXECUTE ALERT a uma função. Para facilitar o uso, recomendamos a criação de uma função personalizada (por exemplo, alert_admin) e a atribuição do privilégio EXECUTE ALERT a esta função. Qualquer função que possa conceder privilégios (por exemplo, SECURITYADMIN ou qualquer função com o privilégio MANAGE GRANTS) pode então conceder esta função personalizada a qualquer função de proprietário do alerta para permitir a alteração de seus próprios alertas. Para instruções sobre como criar funções e hierarquias de funções personalizadas, consulte Configuração do controle de acesso.

Ao executar CREATE ALERT ou ALTER ALERT, algumas verificações de validação não são executadas nas instruções da condição e da ação, incluindo:
- A resolução dos identificadores de objetos.
- A resolução dos tipos de dados das expressões.
- A verificação do número e tipos de argumentos em uma chamada de função.
Os comandos CREATE ALERT e ALTER ALERT não falham se a instrução SQL para uma condição ou ação especificar um identificador inválido, tipo de dados incorreto, número e tipos incorretos de argumentos de função etc. Em vez disso, a falha ocorre quando o alerta é executado.

Para verificar falhas em um alerta existente, use a função de tabela ALERT_HISTORY.

Para evitar esses tipos de falhas, antes de especificar as condições e ações para alertas, verifique as expressões e instruções SQL para essas condições e ações.

Em relação aos metadados:

Atenção

Os clientes devem garantir que nenhum dado pessoal (exceto para um objeto do usuário), dados sensíveis, dados controlados por exportação ou outros dados regulamentados sejam inseridos como metadados ao usar o serviço Snowflake. Para obter mais informações, consulte Campos de metadados no Snowflake.

Exemplos¶

Consulte Suspensão e retomada de um alerta.