Trabalhos elásticos no Banco de Dados SQL do Azure

Aplica-se a:Banco de Dados SQL do Azure

Neste artigo, analisamos os recursos e os detalhes de trabalhos elásticos do 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 podem ser executados periodicamente em um ou vários bancos de dados SQL do Azure para executar consultas T-SQL (Transact-SQL) e executar tarefas de manutenção.

É possível definir o banco de dados de destino ou grupos de bancos de dados em que o trabalho será executado e também 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 fazer logon no banco de dados de destino. Você também define, mantém e persiste scripts T-SQL que serão executados em um grupo de bancos de dados.

Cada trabalho registrará o status de execução e também repetirá as operações se ocorrer uma falha.

Quando usar trabalhos elásticos

Há vários cenários nos quais você pode usar a automação de trabalhos elásticos:

• Automatizar tarefas de gerenciamento e, em seguida, agendá-las para serem executadas a todo dia da semana, após horas etc.
  • Implantar alterações de esquema, gerenciamento de credenciais.
  • Coleta de dados de desempenho ou coleta de telemetria de locatários (clientes).
  • Atualizar dados de referência (informações comuns a todos os bancos de dados).
  • Carregamento de dados do Armazenamento de Blobs do Azure.
• Configure trabalhos para serem executados em um conjunto de bancos de dados de modo recorrente, por exemplo, fora dos horários de pico.
  • Coletar resultados de consulta de um conjunto de bancos de dados em uma tabela central em uma base contínua.
  • Consultas podem ser executadas continuamente e configuradas para disparar tarefas adicionais a serem executadas.
• Coletar dados para relatórios
  • Agregue dados de uma coleção de bancos de dados em uma tabela de destino único.
  • Executar consultas de processamento de dados mais longas em um grande conjunto de bancos de dados, por exemplo, a coleta de telemetria do cliente. 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/processar/inserir dados entre tabelas em um banco de dados.

Considere usar trabalhos elásticos quando:

• Você tem uma tarefa que precisa ser executada regularmente com base em um agendamento, direcionada a um ou mais bancos de dados.
• Você tem uma tarefa que precisa ser executada uma única 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 é 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 bancos de dados são adicionados/excluídos dinamicamente.

Componentes do trabalho elástico

Agente de trabalho elástico

Um agente de trabalho elástico é o recurso do Azure para criar, executar e gerenciar trabalhos. O agente de trabalho elástico é um recurso do Azure que você cria no portal (há suporte também para PowerShell e 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 usa a mesma taxa que qualquer banco de dados no Banco de Dados SQL do Azure. Para obter o custo do agente de trabalho elástico, consulte a Calculadora de preços do Azure.

Banco de dados de trabalho elástico

O banco de dados de trabalhos é usado para definir os trabalhos e rastrear o status e o histórico das execuções de trabalho. Trabalhos são executados em bancos de dados de destino. O banco de dados de trabalhos também é usado para armazenar metadados de agente, logs, resultados e definições de trabalho. Além disso, ele contém muitos procedimentos armazenados úteis e outros objetos de banco de dados usados para criar, executar e gerenciar trabalhos usando o T-SQL.

Um banco de dados existente no Banco de Dados SQL do Azure (S1 ou superior) é recomendado para criar um agente de trabalho elástico.

O banco de dados de trabalhos deve ser um objetivo de serviço limpo, vazio, S1 ou superior no Banco de Dados SQL do Azure.

O objetivo de serviço recomendado do banco de dados de trabalhos é S1 ou superior, mas a opção ideal depende das necessidades de desempenho dos 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 se correlacionar com períodos de lentidão, considere a possibilidade de dimensionar de maneira incremental o banco de dados para objetivos de serviço superiores (no modelo de DTU ou no modelo de vCore) até que o desempenho do banco de dados de trabalhos seja suficientemente aprimorado.

Trabalhos elásticos e etapas de trabalho

Um trabalho é uma unidade de trabalho executada com agendamento ou como um único trabalho. 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 no qual executar o script T-SQL e as credenciais de 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 permitem executar um ou mais scripts T-SQL em paralelo, em um grande número de bancos de dados, seja com agendamento ou sob demanda. O destino pode ser qualquer nível do Banco de Dados SQL do Azure.

É possível 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.

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 será executada. Um grupo de destino pode conter qualquer quantidade ou combinação dos seguintes itens:

• Servidor SQL lógico: se um servidor for especificado, todos os bancos de dados existentes no servidor no momento da execução do trabalho farão parte do grupo. A credencial do banco de dados master deve ser fornecida para que o grupo possa ser enumerado e atualizado antes da execução do trabalho. Para obter mais informações sobre servidores lógicos, confira O que é um servidor no Banco de Dados SQL do Azure e no Azure Synapse Analytics?.
• Pool elástico: se um pool elástico for especificado, todos os bancos de dados presentes no pool elástico no momento da execução do trabalho farão parte do grupo. Assim como ocorre para servidores, a credencial do banco de dados master deve ser fornecida para que o grupo possa ser atualizado antes da execução do trabalho.
• Banco de dados único: especifica um ou mais bancos de dados individuais como parte do grupo.

É possível incluir ou excluir pools e bancos de dados individuais do grupo. Isso permite a criação de 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 definições de grupo-alvo diferentes são enumeradas dinamicamente no momento da execução do trabalho para determinar em quais bancos de dados o trabalho será executado:

• O exemplo 1 mostra um grupo de destino que consiste em uma lista de bancos de dados individuais. Quando uma etapa de trabalho é executada usando esse grupo de destino, a ação da etapa do trabalho é executada em cada um dos bancos de dados.
• O Exemplo 2 mostra um grupo de destino que contém um servidor como destino. Quando uma etapa de trabalho é executada usando 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 será 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 de trabalho não será 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 será 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.

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 no escopo do banco de dados e outro para usar a autenticação com ID do Microsoft Entra.

O agente de trabalho elástico pode se conectar aos servidores/bancos de dados especificados pelo grupo de destino por meio de 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 com o Microsoft Entra (o antigo Azure Active Directory) por meio de uma identidade gerenciada atribuída pelo usuário (UMI) é a opção recomendada para conectar trabalhos elásticos ao Banco de Dados SQL do Azure. Com o suporte à ID do Microsoft Entra, o agente de trabalho poderá se conectar a bancos de dados de destino (bancos de dados, servidores, pools elásticos) e bancos de dados de saída usando a UMI.

Opcionalmente, a autenticação com ID do Microsoft Entra também pode ser habilitada no servidor lógico que contém o banco de dados de trabalhos elásticos, para acessar/consultar esse banco de dados por meio de conexões de ID do Microsoft Entra. No entanto, o próprio agente de trabalho usa autenticação interna baseada em certificado para se conectar ao banco de dados de trabalhos.

Você pode criar uma UMI ou usar uma UMI existente e atribuir a mesma UMI a vários agentes de trabalhos. Apenas uma UMI tem suporte por agente de trabalho. Depois que uma UMI for atribuída a um agente de trabalho, este usará essa identidade apenas para conectar e executar trabalhos T-SQL nos bancos de dados de destino. A Autenticação SQL não será usada no servidor/bancos de dados de destino desse agente de trabalho.

O nome da UMI deve começar com uma letra ou um número e ter um comprimento entre 3 e 128. Ele pode conter os caracteres - e _.

Para obter mais informações sobre a UMI no Banco de Dados SQL do Azure, consulte Identidades gerenciadas para 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 Usar o Microsoft Entra (o antigo Azure Active Directory) para autenticar em plataformas SQL do Azure.

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

Autenticação por meio de credenciais no escopo do banco de dados

Embora a autenticação com Microsoft Entra (o antigo Azure Active Directory) seja a opção recomendada, os trabalhos podem ser configurados para usar credenciais no escopo do 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 no escopo do banco de dados eram a única opção de autenticação.

Se um grupo de destino contém servidores ou pools, essas credenciais no escopo do banco de dados são usadas para conexão com o banco de dados master, a fim de enumerar os bancos de dados disponíveis.

• As credenciais no escopo do banco de dados devem ser criadas 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 criadas nos bancos de dados de destino (LOGIN e PASSWORD para masteruser e jobuser, no diagrama a seguir) devem corresponder a IDENTITY e SECRET nas credenciais criadas no banco de dados de trabalhos.
• As credenciais podem ser reutilizadas entre os trabalhos e as senhas de credencial são criptografadas e protegidas contra usuários que têm acesso somente leitura a objetos de trabalho.

A imagem a seguir foi projetada para ajudar a entender a configuração das credenciais de trabalho adequadas e como o agente de trabalhos elásticos se conecta usando credenciais de banco de dados como autenticação para logons/usuários em servidores/bancos 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 pontos de extremidade privados de trabalhos elásticos oferece suporte a conexões privadas com servidores de destino/saída, de forma que o agente de trabalho ainda pode acessá-los mesmo quando a opção "Negar acesso público" está habilitada. Usar pontos de extremidade privados também é uma solução possível se você deseja 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 escolher um ponto de extremidade privado gerenciado por serviço para estabelecer uma conexão segura entre o agente de trabalho e seus servidores de destino/saída. Um ponto de extremidade privado gerenciado pelo serviço é um endereço IP privado em uma rede virtual e uma sub-rede específicas. Quando você opta por usar pontos de extremidade privados em um dos servidores de destino/saída do agente de trabalho, um ponto de extremidade privado gerenciado por serviço é criado pela Microsoft. Esse ponto de extremidade privado é usado exclusivamente pelo agente de trabalho para conectar e executar trabalhos ou gravar a saída do trabalho nesses bancos de dados de destino/saída.

Pontos de extremidade privados de trabalhos elásticos podem ser criados e permitidos 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/bancos de dados de destino devem estar hospedados no Azure (regiões iguais ou diferentes) e no mesmo tipo de nuvem (por exemplo, na nuvem pública ou na nuvem governamental).
• O provedor de recursos Microsoft.Network deve ser registrado para as assinaturas de host do agente de trabalho e dos servidores de destino/saída.
• Pontos de extremidade privados de trabalhos elástico são criados por servidor de destino/saída. Eles devem ser aprovados antes que o agente de trabalho elástico possa usá-los. Isso pode ser feito por meio do painel Rede desse servidor lógico ou do seu cliente preferido. O agente de trabalho elástico poderá acessar qualquer banco de dados nesse servidor usando uma conexão privada.
• A conexão do agente de trabalho elástico com o banco de dados de trabalhos não usará o 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. Uma ressalva é se você adicionar o banco de dados de trabalhos como membro do grupo de destino. Ele se comportará como um destino regular que você então precisaria configurar com ponto de extremidade privado, conforme necessário.

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, projetada para oferecer aos administradores um controle de acesso mais rígido para monitoramento de trabalho, tem a seguinte permissão. Os administradores podem fornecer aos usuários a capacidade de monitorar a execução de trabalhos adicionando-os à função jobs_reader no banco de dados de trabalhos.

Monitorar trabalhos elásticos

A partir de outubro de 2023, o agente de trabalho elástico tem integração com Alertas do Azure para notificações de status de trabalhos, simplificando a solução para monitorar o status e o histórico de execuções de trabalhos.

O portal do Azure também tem novos recursos adicionais para oferecer suporte a trabalhos elásticos e monitoramento de trabalhos. Na página Visão geral do agente de trabalho elástico, as execuções de trabalho mais recentes são exibidas, como 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 específica. Você pode especificar um banco de dados para salvar os dados retornados de um trabalho.

Histórico de trabalho

Visualize o histórico de execução de trabalhos elásticos no banco de dados de trabalhos consultando a tabela jobs.job_executions. Um trabalho de limpeza do sistema limpa o histórico de execuções com mais de 45 dias. Para remover o histórico de menos de 45 dias manualmente, execute o procedimento armazenado sp_purge_jobhistory no banco de dados de trabalhos.

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.
• As credenciais devem ter os privilégios mínimos necessários para executar a etapa do trabalho. Para mais informações, confira Autorizações e permissões.
• Ao usar um servidor e/ou um membro do grupo de destino de pool, é altamente recomendável criar uma credencial separada com direitos sobre o banco de dados master para exibir/listar bancos de dados que será usada para expandir as listas de banco de dados dos servidores e/ou pools antes da execução do trabalho.

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 mais conexões de destino simultâneas para execução de trabalhos, atualize o nível 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.

Exceder o nível de capacidade de simultaneidade do agente de trabalhos com destinos de trabalho criará atrasos de enfileiramento para alguns bancos de dados/servidores de destino. Por exemplo, se você iniciar um trabalho com destino 110 no nível JA100, 10 trabalhos aguardarão para iniciar até que outros terminem.

A camada ou o objetivo de serviço de um agente de trabalhos elásticos pode ser modificado por meio do portal do Azure, do PowerShell ou da API REST de Agentes de Trabalhos. Para obter um exemplo, consulte Dimensionar o agente de trabalhos.

Limitar o impacto dos trabalhos em pools elásticos

Para que os recursos não fiquem sobrecarregados ao executar trabalhos em bancos de dados em um pool elástico do Banco de Dados SQL do Azure, os trabalhos podem ser configurados para limitar o número de bancos de dados em que o trabalho pode ser executado simultaneamente.

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. Idempotente significa que, se o script tiver êxito e for executado novamente, o mesmo resultado ocorrerá. Um script pode falhar devido a problemas de rede transitórios. Nesse caso, o trabalho repetirá automaticamente a execução do script por 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. Veja a seguir um exemplo 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 realizar a execução com êxito testando e combatendo logicamente quaisquer condições que encontrar.

Limitações

Essas são as limitações atuais para o serviço de trabalhos elásticos. Estamos trabalhando ativamente para excluir o máximo de limitações.

Conteúdo relacionado

• Criar, configurar e gerenciar trabalhos elásticos
• 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

Próxima etapa