Trabalhos elásticos no Banco de Dados SQL do Azure

Aplica-se a:Banco de Dados SQL do Azure

Este artigo analisa os recursos e os detalhes de trabalhos elásticos para o Banco de Dados SQL do Azure.

• Para obter um tutorial sobre como configurar trabalhos elásticos, consulte o tutorial de trabalhos elásticos.
• Saiba mais sobre conceitos de automação em plataformas de banco de dados do Azure.

Visão geral de trabalhos elásticos

Você pode criar e agendar trabalhos elásticos que são executados periodicamente em um ou muitos bancos de dados SQL do Azure. Os trabalhos executam consultas Transact-SQL (T-SQL) e realizam tarefas de manutenção.

Você pode definir bancos de dados de destino ou grupos de bancos de dados em que o trabalho é executado. Você também pode definir agendas para executar um trabalho. Todas as datas e horas em trabalhos elásticos estão no fuso horário UTC.

Um trabalho lida com a tarefa de autenticação no banco de dados de destino. Você também define, mantém e persiste Transact-SQL scripts a serem executados em um grupo de bancos de dados.

Cada trabalho registra o status da execução e repete automaticamente as operações se ocorrer alguma falha.

Quando usar trabalhos elásticos

Use a automação de trabalho elástico nos seguintes cenários:

• Automatize as tarefas de gerenciamento e agende-as para serem executadas todos os dias da semana ou após o expediente, por exemplo.
  • Implantar alterações de esquema e gerenciar credenciais.
  • Colete dados de desempenho ou registros de cliente.
  • Atualizar dados de referência (informações comuns a todos os bancos de dados).
  • Carregar dados do Azure Blob Storage.
• Configure trabalhos para serem executados em uma coleção de bancos de dados de forma recorrente, como durante o horário fora de pico.
  • Coletar resultados de consulta de um conjunto de bancos de dados em uma tabela central em uma base contínua.
  • As consultas podem ser executadas continuamente e configuradas para disparar tarefas adicionais.
• Coletar dados para relatórios
  • Agregue dados de uma coleção de bancos de dados em uma tabela de destino único.
  • Execute consultas de processamento de dados em um grande conjunto de bancos de dados, por exemplo, a coleção de logs de clientes. Resultados são coletados em uma única tabela de destino para análise posterior.
• Movimentação de dados
  • Para soluções desenvolvidas sob medida, automação comercial ou outros gerenciamentos de tarefas.
  • Processamento de ETL para extrair, transformar e carregar dados entre tabelas em um banco de dados.

Considere trabalhos elásticos quando:

• Tenha uma tarefa que precisa ser executada regularmente em um cronograma, tendo como alvo um ou mais bancos de dados.

• Tenha uma tarefa que precisa ser executada uma vez, mas em vários bancos de dados.

• Necessidade de executar trabalhos agendados em qualquer combinação de bancos de dados: um ou mais bancos de dados individuais, todos os bancos de dados em um servidor, todos os bancos de dados em um pool elástico, com a flexibilidade extra de poder incluir ou excluir qualquer banco de dados. Os trabalhos podem ser executados em diversos servidores e pools, até mesmo em bancos de dados presentes em assinaturas diferentes. Os servidores e pools são enumerados dinamicamente no runtime e, portanto, os trabalhos são executados em todos os bancos de dados existentes no grupo de destino no momento da execução.

  • Essa funcionalidade é uma diferenciação significativa do SQL Agent, que não pode enumerar dinamicamente os bancos de dados de destino, especialmente em cenários de clientes SaaS em que os bancos de dados são adicionados ou excluídos dinamicamente.

Componentes do trabalho elástico

Componente	Descrição
Agente de trabalho elástico	O recurso do Azure que você cria para executar e gerenciar trabalhos.
Banco de dados de trabalhos	Um banco de dados no Banco de Dados SQL do Azure que o agente de trabalho usa para armazenar dados relacionados ao trabalho, definições de trabalho e muito mais.
Trabalho	Um trabalho é uma unidade de trabalho composta de uma ou mais etapas de trabalho. As etapas de trabalho especificam o script T-SQL a ser executado e outros detalhes necessários.
Grupo de destino	O conjunto de servidores, pools e bancos de dados nos quais o trabalho é executado.

Agente de tarefas escalável

Um agente de trabalho elástico é o recurso do Azure para criar, executar e gerenciar trabalhos. Você cria o agente de trabalho elástico como um recurso do Azure no portal (também há suporte para criar e gerenciar trabalhos elásticos usando o PowerShell e a API REST).

A criação de um agente de trabalho elástico requer um banco de dados existente no Banco de Dados SQL do Azure. O agente configura esse Banco de Dados SQL do Azure existente como o banco de dados de trabalhos.

Você pode iniciar, desabilitar ou cancelar um trabalho por meio do portal do Azure. O portal do Azure também permite visualizar definições de trabalho e o histórico de execuções.

Custo do agente de trabalhos elásticos

O banco de dados de trabalhos é cobrado à mesma taxa que qualquer banco de dados no Banco de Dados SQL do Azure. O custo do agente de trabalho elástico é baseado no preço fixo do nível de serviço selecionado para o agente de trabalho. Para obter mais informações, consulte a página de preços do Banco de Dados SQL do Azure.

Banco de dados de trabalho elástico

Use o banco de dados de trabalho para definir trabalhos e acompanhar o status e o histórico de execuções de trabalho. Trabalhos executados em bancos de dados de destino. O banco de dados de trabalho também armazena metadados do agente, logs, resultados e definições de trabalho. Ele contém muitos procedimentos armazenados úteis e outros objetos de banco de dados para criar, executar e gerenciar trabalhos usando o T-SQL.

Você precisa de um Banco de Dados SQL do Azure para criar um agente de trabalho elástico. O agente de trabalho armazena todos os metadados relacionados ao trabalho no banco de dados de trabalho, que deve ser um banco de dados SQL do Azure novo e vazio.

O objetivo de serviço recomendado do banco de dados de trabalho é DTU S1 ou superior, mas a opção ideal depende das necessidades de desempenho de seus trabalhos: o número de etapas de trabalho, o número de destinos de trabalho e a frequência com que os trabalhos são executados.

Se as operações no banco de dados de trabalhos forem mais lentas do que o esperado, monitore o desempenho do banco de dados e a utilização de recursos no banco de dados de trabalhos durante períodos de lentidão usando o portal do Azure ou a DMV sys.dm_db_resource_stats. Se a utilização de um recurso, como CPU, E/S de dados ou gravação de log, se aproximar de 100% e estiver correlacionada com períodos de lentidão, considere escalar o banco de dados incrementalmente para objetivos de serviço mais altos (seja no modelo de compra baseado em DTU ou no modelo de compra baseado em vCore) até que o desempenho do banco de dados do trabalho seja suficientemente melhorado.

O próprio banco de dados de trabalho pode ser o alvo de um trabalho elástico. Nesse cenário, trate o banco de dados de trabalho como qualquer outro banco de dados de destino. Você deve criar o usuário do trabalho e conceder permissões suficientes no banco de dados de trabalho. A credencial com escopo de banco de dados para o usuário do trabalho também deve existir no banco de dados do trabalho, assim como para qualquer outro banco de dados de destino.

Quando o banco de dados de trabalho for um destino de um trabalho, certifique-se de que seus trabalhos não modifiquem ou excluam metadados específicos do agente de trabalho armazenados nesse banco de dados. Use somente procedimentos armazenados de trabalho ou exibições de trabalho para modificar ou consultar informações relacionadas ao trabalho.

Importante

Não modifique os objetos existentes ou crie novos objetos no banco de dados de trabalho, embora você possa ler das tabelas para relatórios e análises.

Trabalhos elásticos e etapas de trabalho

Um trabalho é uma unidade de trabalho que é executada de acordo com um cronograma ou como um trabalho único. Um trabalho consiste em uma ou mais etapas de trabalho.

Cada etapa de trabalho especifica um script T-SQL a ser executado, um ou mais grupos de destino para executar o script T-SQL e as credenciais que o agente de trabalho precisa para se conectar ao banco de dados de destino. Cada etapa de trabalho tem tempo limite e políticas de repetição personalizáveis e pode, opcionalmente, especificar parâmetros de saída.

Destinos de trabalho elástico

Trabalhos elásticos podem executar um ou mais scripts T-SQL em paralelo, em um grande número de bancos de dados, em um agendamento ou sob demanda. O destino pode ser qualquer nível do Banco de Dados SQL do Azure.

Você pode executar trabalhos agendados em qualquer combinação de bancos de dados: um ou mais bancos de dados individuais, todos os bancos de dados em um servidor ou todos os bancos de dados em um pool elástico, com a flexibilidade adicional para incluir ou excluir qualquer banco de dados específico. Os trabalhos podem ser executados em vários servidores e pools, e podem até mesmo ser executados em bancos de dados em assinaturas diferentes. Os servidores e pools são enumerados dinamicamente no runtime e, portanto, os trabalhos são executados em todos os bancos de dados existentes no grupo de destino no momento da execução.

A imagem a seguir mostra um agente de trabalho executando trabalhos em diferentes tipos de grupos de destino:

Grupo de destino

Um grupo de destino define o conjunto de bancos de dados em que uma etapa de trabalho é executada. Um grupo de destino pode conter qualquer número e combinação dos seguintes tipos:

• SQL Server lógico: se você especificar um servidor, todos os bancos de dados que existem no servidor no momento da execução do trabalho fazem parte do grupo. Você deve fornecer a credencial do master banco de dados para que o grupo possa ser enumerado e atualizado antes da execução do trabalho. Para obter mais informações sobre servidores lógicos, consulte O que é um servidor lógico no Banco de Dados SQL do Azure e no Azure Synapse?

• Pool elástico: se você especificar um pool elástico, todos os bancos de dados que estão no pool elástico no momento da execução do trabalho fazem parte do grupo. Assim como acontece com um servidor, você deve fornecer a credencial de master banco de dados para que o grupo possa ser atualizado antes da execução do trabalho.

• Banco de dados individual: especifique um ou mais bancos de dados individuais para fazer parte do grupo.

Dica

No momento da execução do trabalho, a enumeração dinâmica reavalia o conjunto de bancos de dados em grupos de destino que incluem servidores ou pools. A enumeração dinâmica garante que os trabalhos serão executados em todos os bancos de dados existentes no servidor ou pool no momento da execução do trabalho. Reavaliar a lista de bancos de dados em runtime é útil para cenários em que a associação de pool ou servidor é alterada com frequência.

Pools e bancos de dados individuais podem ser incluídos ou excluídos do grupo. Você pode criar um grupo de destino com qualquer combinação de bancos de dados. Por exemplo, você pode adicionar um servidor a um grupo de destino, mas excluir bancos de dados específicos em um pool elástico (ou excluir um pool inteiro).

Um grupo de destino pode incluir bancos de dados em várias assinaturas e em várias regiões. Execuções entre regiões têm maior latência do que as execuções dentro da mesma região.

Os exemplos a seguir mostram como diferentes definições de grupo de destino são enumeradas dinamicamente no momento da execução do trabalho para determinar quais bancos de dados afetarão:

• O exemplo 1 mostra um grupo de destino que consiste em uma lista de bancos de dados individuais. Quando uma etapa de trabalho usa esse grupo de destino, a ação da etapa de trabalho é executada em cada um desses bancos de dados.

• O Exemplo 2 mostra um grupo de destino que contém um servidor como destino. Quando uma etapa de trabalho usa esse grupo de destino, o servidor é enumerado dinamicamente para determinar a lista de bancos de dados que estão atualmente no servidor. A ação da etapa de trabalho é executada em cada um desses bancos de dados.

• O exemplo 3 mostra um grupo de destino semelhante ao do exemplo 2, mas o banco de dados individual é especificamente excluído. A ação da etapa do trabalho não é executada no banco de dados excluído.

• O exemplo 4 mostra um grupo de destino que contém um pool elástico como destino. Semelhante ao Exemplo 2, o pool é enumerado dinamicamente no tempo de execução do trabalho para determinar a lista de bancos de dados no pool.

• O Exemplo 5 e o Exemplo 6 mostram cenários avançados em que os servidores, os pools elásticos e os bancos de dados podem ser combinados usando regras de inclusão e exclusão.

Agendamentos de trabalho elástico

Trabalhos elásticos são produtos voltados para a nuvem. Eles são projetados para serem iniciados mesmo que ocorra um problema transitório de disponibilidade de rede ou serviço no momento em que estão agendados. Os agendamentos de trabalho elástico levam em conta a hora de início da agenda e os intervalos solicitados. Quando você cria um agendamento de trabalho elástico, o trabalho é executado assim que possível após cada evento de intervalo agendado.

Importante

Como prática recomendada, crie agendas de trabalho que comecem no futuro.

Os agendamentos de trabalho detectam eventos perdidos. Se você criar um novo agendamento de trabalho que comece no passado, o trabalho será executado imediatamente quando habilitado. Se estiver desabilitado ou de outra forma indisponível, o trabalho será executado imediatamente quando for habilitado ou disponível.

Por exemplo, atualmente é 2 de janeiro, 9:00 UTC. Você configurou um novo trabalho para ter horário de início agendado para hoje à noite, 2 de janeiro, às 22h30 (UTC), para ser executado diariamente. O trabalho é executado às 22h30 (UTC).

Para impedir que um trabalho inicie acidentalmente, crie agendas que comecem no futuro. Em um exemplo que poderia levar a um início acidental do trabalho, você configurou um novo trabalho para ser executado diariamente às 22h30 UTC. Você desativa o trabalho por uma semana. Em seguida, se você habilitar o trabalho às 8h30 UTC, ele será executado imediatamente, compensando o evento de intervalo perdido que deveria ter ocorrido ontem à noite. Após a execução, o agente de trabalho não é executado novamente até a próxima execução agendada às 22h30 UTC. Para impedir a execução às 8h30 UTC nesse cenário, atualize o início do agendamento de trabalho para 8 de janeiro às 22h30 UTC e habilite o trabalho. Ou habilite o trabalho em um momento em que o trabalho possa ser executado imediatamente.

Autenticação

Escolha um método para todos os destinos de um agente de trabalho elástico. Por exemplo, para um único agente de trabalho elástico, você não pode configurar um servidor de destino para usar credenciais com escopo de banco de dados e outro para usar autenticação do Microsoft Entra ID.

O agente de trabalho elástico pode se conectar aos servidores e bancos de dados especificados pelo grupo de destino usando duas opções de autenticação:

• Use a Autenticação com o Microsoft Entra (o antigo Azure Active Directory) com uma identidade gerenciada atribuída pelo usuário (UMI).
• Use Credenciais no escopo do banco de dados.

Autenticação por meio de identidade gerenciada atribuída pelo usuário (UMI)

A autenticação do Microsoft Entra por meio da UMI (identidade gerenciada) atribuída pelo usuário é a opção recomendada para conectar trabalhos elásticos ao Banco de Dados SQL do Azure. Com o suporte ao Microsoft Entra ID, o agente de trabalho conecta-se a bancos de dados de destino, como bancos de dados, servidores e pools elásticos, além do banco de dados de saída usando a UMI.

Opcionalmente, você pode habilitar a autenticação da ID do Microsoft Entra no servidor lógico que contém o banco de dados de trabalho elástico, para acessar e consultar esse banco de dados por meio de conexões de ID do Microsoft Entra. No entanto, o agente de trabalho usa a autenticação interna baseada em certificado para se conectar ao banco de dados de trabalho.

Você pode criar uma UMI ou usar uma UMI existente e atribuir a mesma UMI a vários agentes de trabalhos. Cada agente de trabalho suporta apenas um UMI. Depois de atribuir uma UMI a um agente de trabalho, o agente de trabalho usará essa identidade para se conectar e executar trabalhos T-SQL nos bancos de dados de destino. O agente de trabalho não usa a Autenticação SQL no servidor de destino ou nos bancos de dados.

O nome UMI deve começar com uma letra ou um número e ter um comprimento entre 3 e 128 caracteres. Pode conter caracteres de hífen (-) e sublinhado (_).

Para obter mais informações sobre a UMI no Banco de Dados SQL do Azure, consulte Identidades gerenciadas para o SQL do Azure, incluindo as etapas necessárias e os benefícios de usar uma UMI como a identidade do servidor lógico do Banco de Dados SQL do Azure. Para obter mais informações, consulte Microsoft Entra autenticação para SQL do Azure.

Importante

Ao usar a autenticação com Microsoft Entra ID, crie seu usuário a jobuser partir dessa Microsoft Entra ID em cada banco de dados de destino. Conceda a esse usuário as permissões necessárias para executar seus trabalhos em cada banco de dados de destino.

Não há suporte para o uso de uma SMI (identidade gerenciada) atribuída pelo sistema.

Autenticação por meio de credenciais com escopo de banco de dados

Embora a autenticação do Microsoft Entra (antigo Azure Active Directory) seja a opção recomendada, você pode configurar trabalhos para usar credenciais com escopo de banco de dados para se conectar aos bancos de dados especificados pelo grupo de destino após a execução. Antes de outubro de 2023, as credenciais com escopo de banco de dados eram a única opção de autenticação.

Se um grupo de destino contiver servidores ou pools, essas credenciais com escopo de banco de dados se conectarão ao master banco de dados para enumerar os bancos de dados disponíveis.

• Crie as credenciais com escopo de banco de dados no banco de dados de trabalhos.

• Todos os bancos de dados de destino devem ter um logon com permissões suficientes para que o trabalho seja concluído com êxito (jobuser no diagrama a seguir).

• As credenciais que você cria em bancos de dados de destino (LOGIN e PASSWORD para masteruser e jobuser, no diagrama a seguir) devem corresponder ao IDENTITY e SECRET nas credenciais que você cria no banco de dados de trabalho.

• Você pode reutilizar credenciais em tarefas. As senhas de credenciais são criptografadas e protegidas contra usuários que têm acesso somente para leitura a objetos de tarefa.

A imagem a seguir ajuda você a entender como configurar as credenciais de trabalho adequadas e como o agente de trabalho elástico se conecta usando credenciais de banco de dados como autenticação para logons e usuários em servidores e bancos de dados de destino.

Observação

Ao usar credenciais no escopo do banco de dados, lembre-se de criar seu usuário jobuser em cada banco de dados de destino.

Pontos de extremidade privados de trabalhos elásticos

O agente de trabalho elástico oferece suporte a pontos de extremidade privados de trabalhos elásticos. A criação de um ponto de extremidade privado de trabalhos elásticos estabelece um link privado entre o trabalho elástico e o servidor de destino. O recurso de pontos de extremidade privados de trabalhos elásticos é diferente do Link Privado do Azure.

O recurso de terminais privados de trabalho elástico oferece suporte a conexões privadas com servidores de destino e de saída, para que o agente de trabalho possa alcançá-los mesmo quando a opção Negar acesso público estiver habilitada. Usar pontos de extremidade privados também é uma solução possível se você quiser desabilitar a opção Permitir que serviços e recursos do Azure acessem esse servidor.

Pontos de extremidade privados de trabalhos elásticos oferecem suporte a todas as opções de autenticação de agente de trabalhos elásticos.

O recurso de ponto de extremidade privado de trabalho elástico permite que você escolha um ponto de extremidade privado gerenciado pelo serviço para estabelecer uma conexão segura entre o agente de trabalho e seus servidores de destino e saída. Um ponto de extremidade privado gerenciado pelo serviço é um endereço IP privado em uma rede virtual específica e uma sub-rede específica. Quando você opta por usar pontos de extremidade privados em um dos servidores de destino e saída do agente de trabalho, o Azure cria um ponto de extremidade privado gerenciado pelo serviço. Este ponto de extremidade privado é então utilizado exclusivamente pelo agente de trabalho para ligar e executar trabalhos, ou para escrever a saída do trabalho nesses bancos de dados de destino e de saída.

Você pode criar e permitir pontos de extremidade privados de trabalho elástico por meio do portal do Azure. Os servidores de destino conectados por meio de um link privado podem estar em qualquer lugar no Azure, mesmo em diferentes áreas geográficas e assinaturas. Você deve criar um ponto de extremidade privado para cada servidor de destino desejado e o servidor de saída de trabalhos para habilitar essa comunicação.

Para obter um tutorial para configurar um novo ponto de extremidade privado gerenciado por serviço para trabalhos elásticos, consulte Configurar um ponto de extremidade privado de trabalhos elásticos do SQL do Azure.

Requisitos para pontos de extremidade privados de trabalhos elásticos

• Para usar um ponto de extremidade privado de trabalhos elásticos, tanto o agente de trabalho quanto os servidores ou bancos de dados de destino devem estar hospedados no Azure (na mesma região ou em regiões diferentes) e no mesmo tipo de nuvem (por exemplo, ambos na nuvem pública ou ambos na nuvem governamental).

• O provedor de recursos Microsoft.Network deve estar registrado para as assinaturas de host tanto do agente de trabalho quanto dos servidores de destino e de saída.

• O Azure cria pontos de extremidade privados de trabalhos elásticos por servidor de destino e de saída. Você deve aprová-los antes que o agente de trabalho elástico possa usá-los. Você pode aprová-los por meio do painel Rede desse servidor lógico ou de seu cliente preferencial. Em seguida, o agente de trabalho elástico pode acessar todos os bancos de dados nesse servidor usando a conexão privada.

• A conexão do agente de tarefas elástico com o banco de dados de tarefas não usa um ponto de extremidade privado. O próprio agente de trabalho usa autenticação interna baseada em certificado para se conectar ao banco de dados de trabalhos.

  • Se você adicionar o banco de dados de trabalhos como um membro do grupo de destino, ele se comportará como um destino regular. Você precisa configurar o ponto de extremidade privado conforme necessário.

Perímetro de segurança de rede (versão prévia)

Um perímetro de segurança de rede (prévia) controla o tráfego de entrada e saída de rede para um servidor lógico. Um agente de trabalho elástico se conecta externamente a cada servidor de destino para executar etapas de trabalho, portanto, um perímetro avalia essas conexões.

Configurações suportadas

Os trabalhos elásticos funcionam tanto no modo de transição quanto no modo imposto, e com um servidor de destino que está no mesmo perímetro que o agente de trabalho, em um perímetro vinculado ou em nenhum perímetro. Em todos os casos, o perímetro do agente de tarefas deve permitir o acesso de saída ao servidor alvo.

Ambos os métodos de autenticação são suportados. A autenticação SQL funciona em todas essas configurações. Uma identidade gerenciada atribuída pelo usuário funciona quando o agente de trabalho e o alvo estão no mesmo perímetro ou em perímetros vinculados, e você concede à identidade as permissões necessárias no banco de dados alvo.

Configurar regras de acesso para Elastic Jobs

1. Associe o servidor lógico que hospeda o agente de trabalho ao perímetro.
2. No perfil desse servidor, adicione uma regra de acesso de saída para cada servidor alvo. Defina o tipo de destino para FQDN e use o domínio totalmente qualificado do servidor alvo.
3. Se um servidor alvo estiver no mesmo perímetro ou perímetro vinculado e você usar autenticação SQL, adicione uma regra de acesso de entrada no perfil do servidor alvo que permita o servidor do agente de trabalho.
4. Se você usar uma identidade gerenciada atribuída pelo usuário, atribua-a ao agente de trabalho e conceda permissões no banco de dados de destino.
5. Servidores alvo que não estão associados a um perímetro não precisam de configuração extra.

Limitações e diferenças de comportamento

• O perímetro é verificado em tempo de execução, quando o agente de trabalho se conecta a um alvo. Um trabalho pode ser criado com sucesso e depois falhar durante a execução porque uma regra está faltando ou foi alterada posteriormente.
• Mudar regras ou associações de perímetro não interrompe conexões que já estão em andamento. A mudança se aplica a execuções posteriores de trabalhos.
• Os modos de transição e imposto se comportam da mesma maneira, exceto que o modo imposto bloqueia uma conexão não compatível, enquanto o modo de transição a registra e a permite.
• Um servidor alvo em um perímetro diferente que não está vinculado ao perímetro do agente de trabalho não é uma configuração suportada.

Erros quando um perímetro bloqueia um trabalho

As cadeias exatas de erro variam de acordo com o cliente e o driver. Duas falhas são comuns:

• Uma mensagem dizendo que a conexão foi bloqueada pelo perímetro de segurança da rede significa que a regra de saída do servidor do agente de trabalho para o servidor alvo está ausente ou errada. Atualize as regras de saída.
• Uma falha de login para um usuário ou identidade gerenciada significa que o perímetro permitiu a conexão, mas as permissões em nível de banco de dados estão ausentes. Conceda ao usuário SQL ou à identidade gerenciada as permissões de que precisam no banco de dados alvo.

Permissões do banco de dados de trabalho elástico

Durante a criação do agente de trabalho, um esquema, tabelas e uma função chamada jobs_reader são criados no banco de dados de trabalhos. A função é criada com a seguinte permissão e é projetada para oferecer aos administradores um controle de acesso mais preciso para o monitoramento de trabalhos. Os administradores podem fornecer aos usuários a capacidade de monitorar a execução de tarefas adicionando-os à função jobs_reader no banco de dados de tarefas.

Nome da função	Permissões do esquema jobs	Permissões do esquema jobs_internal
jobs_reader	SELECT	Nenhum

Cuidado

Não atualize as visualizações do catálogo interno no banco de dados de trabalho, como jobs.target_group_members. A alteração manual dessas exibições do catálogo pode corromper o banco de dados de trabalhos e causar falhas. Esses modos de exibição são apenas para consulta em modo de leitura. Você pode usar os procedimentos armazenados no banco de dados de trabalho para adicionar ou excluir grupos e membros de destino, como jobs.sp_add_target_group_member.

Considere as implicações de segurança antes de conceder qualquer acesso elevado ao banco de dados de trabalhos. Um usuário mal-intencionado com permissões para criar ou editar trabalhos pode criar ou editar um trabalho que usa uma credencial armazenada para se conectar a um banco de dados sob o controle do usuário mal-intencionado. Essa vulnerabilidade pode permitir que o usuário mal-intencionado determine a senha da credencial ou execute comandos mal-intencionados.

Monitorar trabalhos elásticos

O agente de trabalho elástico integra-se aos Alertas do Azure para notificações de status do trabalho, simplificando a solução para monitorar o status e o histórico de execução do trabalho.

O portal do Azure inclui recursos extras para dar suporte a trabalhos elásticos e monitoramento de trabalho. Na página Visão geral do agente de trabalho elástico, as execuções de trabalho mais recentes são exibidas, conforme mostrado na captura de tela a seguir.

Você pode criar regras de Alerta do Azure Monitor com o portal do Azure, a CLI do Azure, o PowerShell e a API REST. A métrica Trabalhos elásticos com falha é um bom ponto de partida para monitorar e receber alertas sobre a execução de trabalhos elásticos. Além disso, você pode optar por receber alertas por meio de uma ação configurável, como SMS ou email, pelo recurso Alerta do Azure. Para obter mais informações, consulte Criar alertas para o Banco de Dados SQL do Azure no portal do Azure.

Para ver um exemplo, consulte Criar, configurar e gerenciar trabalhos elásticos.

Saída do trabalho

O resultado das etapas de um trabalho em cada banco de dados de destino é registrado em detalhes e a saída do script pode ser capturada em uma tabela especificada. Você pode especificar um banco de dados para salvar os dados retornados de um trabalho.

Histórico de trabalho

Você pode exibir o histórico de execução de trabalho elástico no banco de dados do trabalho consultando a tabela jobs.job_executions. Um trabalho de limpeza do sistema remove o histórico de execução com mais de 45 dias. Para remover o histórico com menos de 45 dias manualmente, execute o sp_purge_jobhistory procedimento armazenado no banco de dados de trabalho.

Status do trabalho

É possível monitorar execuções de trabalhos elásticos no banco de dados de trabalhos consultando a tabela jobs.job_executions.

Práticas recomendadas

Considere as seguintes melhores práticas ao trabalhar com trabalhos de banco de dados elástico:

Melhores práticas de segurança

• Limite o uso das APIs somente a pessoas confiáveis.

• Conceda às credenciais os privilégios mínimos necessários para executar uma etapa de trabalho. Para mais informações, confira Autorizações e permissões.

• Ao usar um servidor ou membro do grupo de destino do pool, crie uma credencial separada com direitos no banco de dados master para exibir e listar bancos de dados. Essas credenciais expandem as listas de banco de dados dos servidores e pools antes da execução da tarefa.

Desempenho de trabalhos elásticos

Trabalhos elásticos usam o mínimo de recursos de computação enquanto aguardam a conclusão dos trabalhos de longa execução.

Dependendo do tamanho do grupo de destino de bancos de dados e do tempo de execução desejado para um trabalho (número de trabalhos simultâneos), o agente requer quantidades diferentes de computação e desempenho do banco de dados de trabalhos (quanto mais destinos e trabalhos, maior será a quantidade de computação necessária).

Níveis de capacidades simultâneas

A partir de outubro de 2023, o agente de trabalho elástico tem vários níveis de desempenho para permitir o aumento da capacidade.

Os incrementos de capacidade indicam o número total de bancos de dados de destino simultâneos aos quais o agente de trabalho pode se conectar e iniciar um trabalho. Para obter conexões de destino mais simultâneas para execução de trabalho, atualize a camada de um agente de trabalho da camada JA100 padrão, que tem um limite de 100 conexões de destino simultâneas.

A maioria dos ambientes requer menos de 100 trabalhos simultâneos a qualquer momento e, portanto, JA100 é o padrão.

Nível do agente de trabalhos elásticos	Máximo de trabalhos simultâneos
JA100	100
JA200	200
JA400	400
JA800	800

Exceder a capacidade de concorrência do agente de tarefas com destinos de tarefas cria atrasos de enfileiramento para alguns bancos de dados e servidores de destino. Por exemplo, se você iniciar uma tarefa com 110 destinos no nível JA100, 10 destinos aguardarão para iniciar até que outros terminem.

Você pode modificar a camada ou o objetivo de serviço de um agente de trabalho elástico por meio do portal do Azure, do PowerShell ou da API REST dos Agentes de Trabalho. Para obter um exemplo, consulte Escalar o agente de tarefas.

Limitar o efeito da tarefa em pools elásticos

Para garantir que os recursos não sejam sobrecarregados ao executar trabalhos em bancos de dados em um pool elástico do Banco de Dados SQL do Azure, configure trabalhos para limitar o número de bancos de dados em que um trabalho é executado ao mesmo tempo.

Defina o número de bancos de dados simultâneos em que um trabalho será executado, definindo o parâmetro do sp_add_jobstepprocedimento armazenado@max_parallelism no T-SQL.

Scripts idempotentes

Os scripts T-SQL de um trabalho elástico devem ser idempotentes, ou seja, se o script for bem-sucedido e ele for executado novamente, o mesmo resultado ocorrerá. Um script pode falhar devido a problemas de rede transitórios. Nesse caso, a tarefa tenta executar o script automaticamente um número predefinido de vezes antes de desistir. Um script idempotente tem o mesmo resultado, mesmo que tenha sido executado com êxito duas vezes (ou mais).

É uma tática simples para testar a existência de um objeto antes de criá-lo. O exemplo a seguir é hipotético:

IF NOT EXISTS (SELECT *
               FROM sys.objects
               WHERE [name] = N'some_object')
    PRINT 'Object does not exist'; -- Create the object
ELSE
    PRINT 'Object exists'; -- If it exists, drop the object before recreating it.

Da mesma forma, um script deve ser capaz de executar com êxito, testando e lidando logicamente com quaisquer condições que encontrar.

Limitações

Essas são as limitações atuais para o serviço de trabalhos elásticos. A equipe do produto está trabalhando ativamente para remover o máximo possível dessas limitações.

Problema	Descrição
O agente do trabalho elástico precisa ser recriado e iniciado na nova região após um failover ou uma migração para uma nova região do Azure.	O serviço de trabalhos elásticos armazena todos os seus metadados de trabalho e agente de trabalho no banco de dados de trabalhos. Qualquer failover ou migração de recursos do Azure para uma nova região do Azure também move o banco de dados de tarefas, o agente de tarefas e os metadados de tarefas para a nova região do Azure. No entanto, o agente de trabalhos elásticos é um recurso exclusivo para computação que precisa ser recriado explicitamente e iniciado na nova região antes que os trabalhos comecem a ser executados novamente. Uma vez iniciado, o agente de trabalho elástico retoma a execução de trabalhos na nova região de acordo com o agendamento de trabalho definido anteriormente.
Excesso de logs de auditoria SQL do banco de dados de trabalhos	O agente de trabalhos elásticos opera consultando constantemente o banco de dados de tarefas para verificar a chegada de novas tarefas e outras operações CRUD. Se a auditoria estiver habilitada no servidor que abriga um banco de dados de trabalhos, o banco de dados de trabalhos poderá gerar um grande número de logs de auditoria. Você pode atenuar esse problema filtrando esses logs de auditoria usando o Set-AzSqlServerAudit comando com uma expressão de predicado. Por exemplo: Set-AzSqlServerAudit -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -BlobStorageTargetState Enabled -StorageAccountResourceId "/subscriptions/7fe3301d-31d3-4668-af5e-211a890ba6e3/resourceGroups/resourcegroup01/providers/Microsoft.Storage/storageAccounts/mystorage" -PredicateExpression "application_name <> 'Microsoft Azure SQL Database elastic jobs'" Este comando filtra apenas os logs de auditoria do agente de trabalhos para o banco de dados de trabalhos, não os logs de auditoria do agente de trabalhos para quaisquer bancos de dados de destino.
Uso de um banco de dados Hyperscale como banco de dados de trabalhos	Não há suporte para o uso de um banco de dados de Hiperescala como banco de dados de trabalhos. No entanto, os trabalhos elásticos podem direcionar os bancos de dados de Hiperescala da mesma forma que qualquer outro banco de dados no Banco de Dados SQL do Azure.
Bancos de dados sem servidor e pausa automática com tarefas elásticas.	Um banco de dados sem servidor com pausa automática não é compatível como um banco de dados de tarefa. Bancos de dados sem servidor direcionados por trabalhos elásticos suportam pausa automática e as conexões de trabalhos as retomam.
Exportar um banco de dados de trabalhos para um arquivo BACPAC	Não há suporte para a exportação de um banco de dados de trabalho para um arquivo BACPAC. Se o SQL Server que contém um banco de dados de trabalho precisar ser exportado, solte o banco de dados de trabalho primeiro antes de exportar o servidor.

Próxima etapa

Tutorial: criar, configurar e gerenciar trabalhos elásticos

Conteúdo relacionado

• Automatizar tarefas de gerenciamento no SQL do Azure
• Criar e gerenciar trabalhos elásticos usando o PowerShell
• Criar e gerenciar trabalhos elásticos usando o T-SQL
• Perímetro de segurança de rede para Banco de Dados SQL do Azure (versão prévia)