Trabalhos elásticos no Banco de Dados SQL do Azure (visualização)

Aplica-se a:Banco de Dados SQL do Azure

Neste artigo, analisamos os recursos e os detalhes dos 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 os conceitos de automação nas plataformas de banco de dados do Azure.

Nota

Os trabalhos elásticos estão em pré-visualização. As funcionalidades atualmente em pré-visualização estão disponíveis em termos de utilização suplementares, rever os termos legais que se aplicam às funcionalidades do Azure que estão em pré-visualização. A Base de Dados SQL do Azure fornece pré-visualizações para lhe dar a oportunidade de avaliar e partilhar comentários com o grupo de produtos sobre funcionalidades antes de estas se tornarem disponíveis ao público (GA).

Visão geral dos 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 Transact-SQL (T-SQL) e executar tarefas de manutenção.

Pode definir uma base de dados ou grupos de bases de dados de destino onde a tarefa será executada e, além disso, definir horários para executar uma tarefa. Todas as datas e horas em trabalhos elásticos estão no fuso horário UTC.

Uma tarefa processa a tarefa de início de sessão na base de dados de destino. Também pode definir, manter e persistir os scripts Transact-SQL para serem executados num grupo de bases de dados.

Cada tarefa regista o estado de execução e, além disso, repete as operações automaticamente caso ocorra alguma falha.

Quando usar trabalhos elásticos

Há vários cenários em que você pode usar a automação de trabalho elástico:

• Automatize as tarefas de gestão e programe-as para serem executadas todos os dias da semana, fora de horas, etc.
  • Implantar alterações de esquema, gerenciamento de credenciais.
  • Coleta de dados de desempenho ou coleta de telemetria do locatário (cliente).
  • Atualize dados de referência (informações comuns em todas as bases de dados).
  • Carregue dados do armazenamento de Blob do Azure.
• Configure trabalhos para serem executados em uma coleção de bancos de dados de forma recorrente, como fora do horário de pico.
  • Recolha os resultados da consulta a partir de um conjunto de bases de dados numa tabela central de forma contínua.
  • As consultas podem ser continuamente executadas e configuradas para acionar tarefas adicionais a serem executadas.
• Coletar dados para relatórios
  • Agregar dados de uma coleção de bancos de dados em uma única tabela de destino.
  • Execute consultas de processamento de dados de execução mais longa num grande conjunto de bases de dados, por exemplo, a coleção de telemetria de cliente. Os resultados são recolhidos para uma tabela de destino única para análise adicional.
• Movimento de dados
  • Para soluções desenvolvidas sob medida, automação comercial ou outro gerenciamento de tarefas.
  • Processamento ETL para extrair/processar/inserir dados entre tabelas em um banco de dados.

Considere trabalhos elásticos quando:

• Tenha uma tarefa que precisa ser executada regularmente em um cronograma, visando 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 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 adicional para incluir ou excluir qualquer banco de dados específico. As tarefas podem ser executadas em vários servidores, vários conjuntos e podem até ser executadas em bases de dados em subscrições diferentes. Os servidores e os conjuntos são dinamicamente enumerados em runtime, para que as tarefas sejam executadas em todas as bases de dados que existem 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 os bancos de dados são adicionados/excluídos dinamicamente.

Componentes de trabalho elásticos

Componente	Description
Agente de trabalho elástico	O recurso do Azure que cria para executar e gerir tarefas.
Base de dados da tarefa	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, etc.
Tarefa	Um trabalho é uma unidade de trabalho que é composta por uma ou mais etapas do trabalho. Os passos de tarefa especificam o script T-SQL a executar, bem como outros detalhes necessários para executar o script.
Grupo de destino	O conjunto de servidores, pools e bancos de dados contra os quais executar um trabalho.

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 (PowerShell e API REST também são suportados).

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

Pode iniciar, desativar ou cancelar um trabalho através do portal do Azure. O portal do Azure também permite exibir definições de trabalho e histórico de execução.

Custo do agente de trabalho elástico

O agente de trabalho elástico é gratuito para a visualização atual. Os cartões de cobrança no portal do Azure durante a visualização mostrarão uma estimativa (em dólares americanos) do custo com base na camada de capacidade de simultaneidade selecionada. Atualmente, isso é apenas para fins de estimativa de custos avançada.

O banco de dados de trabalho é cobrado na mesma taxa que qualquer banco de dados no Banco de Dados SQL do Azure.

Banco de dados de trabalho elástico

O banco de dados de trabalhos é usado para definir trabalhos e acompanhar o status e o histórico de execuções de trabalho. Os trabalhos são executados em bancos de dados de destino. O banco de dados de tarefas também é usado para armazenar metadados de agentes, logs, resultados, definições de trabalho e também contém muitos procedimentos armazenados úteis e outros objetos de banco de dados para criar, executar e gerenciar trabalhos usando T-SQL.

Para a visualização atual, 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 tarefas deve ser um objetivo de serviço limpo, vazio, S1 ou superior do Banco de Dados SQL do Azure.

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

Se as operações no banco de dados de tarefas 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 tarefas durante períodos de lentidão usando o portal do Azure ou o sys.dm_db_resource_stats DMV. 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 dimensionar incrementalmente o banco de dados para objetivos de serviço mais altos (no modelo DTU ou no modelo vCore) até que o desempenho do banco de dados de trabalho seja suficientemente melhorado.

Importante

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

Trabalhos elásticos e etapas do trabalho

Uma tarefa é uma unidade de trabalho que é executada com base num agendamento ou como uma tarefa ocasional. Uma tarefa é composta por um ou mais passos de tarefa.

Cada passo de tarefa especifica um script T-SQL a executar, um ou mais grupos de destino onde executar o script T-SQL e as credenciais de que o agente de tarefa precisa para ligar à base de dados de destino. Cada passo de tarefa tem políticas de repetição e de tempo limite personalizáveis e, opcionalmente, pode especificar parâmetros de saída.

Metas de trabalho elásticas

Os trabalhos elásticos oferecem a capacidade de executar um ou mais scripts T-SQL em paralelo, em um grande número de bancos de dados, em um cronograma ou sob demanda. O destino pode ser qualquer camada 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, todos os bancos de dados em um pool elástico, com a flexibilidade adicional para incluir ou excluir qualquer banco de dados específico. As tarefas podem ser executadas em vários servidores, vários conjuntos e podem até ser executadas em bases de dados em subscrições diferentes. Os servidores e os conjuntos são dinamicamente enumerados em runtime, para que as tarefas sejam executadas em todas as bases de dados que existem no grupo de destino no momento da execução.

A imagem seguinte mostra um agente de tarefa a executar tarefas nos diferentes tipos de grupos de destino:

Grupo de destino

Um grupo de destino define o conjunto de bases de dados onde será executado um passo de tarefa. Um grupo de destino pode conter qualquer número e combinação dos seguintes elementos:

• 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 master credencial do banco de dados 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, consulte O que é um servidor no Banco de Dados SQL do Azure e no Azure Synapse Analytics?.
• Conjunto elástico - se for especificado um conjunto elástico, todas as bases de dados que estão no conjunto elástico no momento da execução da tarefa fazem parte do grupo. Quanto a um servidor, a credencial do master banco de dados deve ser fornecida para que o grupo possa ser atualizado antes da execução do trabalho.
• Base de dados individual - especifique uma ou mais bases de dados individuais para fazerem parte do grupo.

Gorjeta

No momento da execução da tarefa, a enumeração dinâmica reavalia o conjunto de bases de dados nos grupos de destino que incluem servidores ou conjuntos. A enumeração dinâmica garante que as tarefas são executadas em todas as bases de dados que existem no servidor ou conjunto no momento da execução da tarefa. A reavaliação da lista de bases de dados em runtime é especificamente útil para cenários em que a associação do conjunto ou do servidor muda com frequência.

Os conjuntos e as bases de dados individuais podem ser especificados como estando incluídos ou excluídos do grupo. Isto permite criar um grupo de destino com qualquer combinação de bases de dados. Por exemplo, pode adicionar um servidor a um grupo de destino, mas excluir bases de dados específicas num conjunto elástico (ou excluir um conjunto completo).

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

Os seguintes exemplos mostram como as diferentes definições de grupo de destino são enumeradas dinamicamente no momento da execução do trabalho, de modo a determinar as bases de dados que o trabalho vai executar:

• O Exemplo 1 mostra um grupo de destino que consiste numa lista de bases de dados individuais. Quando é executado um passo do trabalho com este grupo de destino, a ação desse passo será executada em cada uma dessas bases de dados.
• O Exemplo 2 mostra um grupo de destino que contém um servidor como destino. Quando é executado um passo do trabalho com este grupo de destino, o servidor é enumerado dinamicamente para determinar a lista de bases de dados que estão, atualmente, no servidor. A ação desse passo será executada em cada uma dessas bases de dados.
• O Exemplo 3 mostra um grupo de destino semelhante ao do Exemplo 2, mas é excluída especificamente uma base de dados individual. A ação do passo deste trabalho não será executada na base de dados excluída.
• O Exemplo 4 mostra um grupo de destino que contém um conjunto elástico como o destino. Tal como no Exemplo 2, o conjunto será enumerado dinamicamente no momento de execução do trabalho para determinar a lista de bases de dados contidas no mesmo.

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

Nota

O próprio banco de dados de tarefas pode ser o destino de um trabalho. Nesse cenário, o banco de dados de tarefas é tratado como qualquer outro banco de dados de destino. O usuário de trabalho deve ser criado e receber permissões suficientes no banco de dados de trabalho, e a credencial de escopo de banco de dados para o usuário de trabalho também deve existir no banco de dados de trabalho, assim como acontece com qualquer outro banco de dados de destino.

Autenticação

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

O agente de trabalho elástico pode se conectar ao(s) servidor(es)/banco(s) de dados especificado(s) pelo grupo-alvo por meio de duas opções de autenticação:

• Use a autenticação do Microsoft Entra (anteriormente Azure Ative Directory) com uma identidade gerenciada atribuída pelo usuário (UMI).
• Use credenciais com escopo de banco de dados. (Anteriormente, este era o único método de autenticação.)

O nome do Azure Ative Directory mudou para Microsoft Entra ID, a partir de 2023.

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

A autenticação do Microsoft Entra (anteriormente Azure Ative Directory) 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 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 do Microsoft Entra ID também pode ser habilitada no servidor lógico que contém o banco de dados de trabalho elástico, para acessar/consultar esse banco de dados por meio de conexões do Microsoft Entra ID. No entanto, o próprio agente de trabalho usa autenticação interna baseada em certificado para se conectar ao seu banco de dados de tarefas.

Você pode criar uma UMI ou usar uma UMI existente e atribuir a mesma UMI a vários agentes de trabalho. Apenas um UMI é suportado por agente de trabalho. Depois que um UMI é atribuído a um agente de trabalho, esse agente de trabalho só usará essa identidade para se 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 UMI deve começar com uma letra ou um número e com um comprimento entre 3 e 128. Pode conter os - caracteres e _ .

Para obter mais informações sobre 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 um 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 (anteriormente Azure Ative Directory) para autenticar em plataformas SQL do Azure.

Importante

Ao usar a autenticação do Microsoft Entra ID, crie seu jobuser usuário a partir desse ID do Microsoft Entra em cada banco de dados de destino. Conceda a esse usuário as permissões necessárias para executar o(s) seu(s) trabalho(s) em cada banco de dados de destino.

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

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

Embora a autenticação do Microsoft Entra (anteriormente Azure Ative Directory) seja a opção recomendada, os trabalhos podem ser configurados para usar credenciais de escopo de banco de dados para se conectar aos bancos de dados especificados pelo grupo de destino durante 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 de escopo de banco de dados serão usadas para se conectar ao master banco de dados e enumerar os bancos de dados disponíveis.

• As credenciais de escopo do banco de dados devem ser criadas no banco de dados de tarefas.
• Todos os bancos de dados de destino devem ter um login com permissões suficientes para que o trabalho seja concluído com êxito (jobuserno diagrama a seguir).
• As credenciais criadas nos bancos de dados de destino (LOGIN e para masteruser e jobuserPASSWORD , no diagrama a seguir) devem corresponder às IDENTITY e SECRET nas credenciais criadas no banco de dados de tarefas.
• As credenciais podem ser reutilizadas em trabalhos e as senhas de credenciais são criptografadas e protegidas de 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 trabalho elástico se conecta usando credenciais de banco de dados como autenticação para logons/usuários em servidores/bancos de dados de destino.

Nota

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

Pontos de extremidade privados de trabalho elástico

O agente de trabalho elástico suporta pontos de extremidade privados de trabalho elástico. A criação de um ponto de extremidade privado de trabalhos elásticos estabelece um vínculo 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 trabalho elástico suporta conexões privadas com servidores de destino/saída, de modo que o agente de trabalho ainda possa alcançá-los mesmo quando a opção "Negar acesso público" estiver ativada. Usar pontos de extremidade privados também é uma solução possível se você quiser desabilitar a opção "Permitir que os serviços e recursos do Azure acessem esse servidor".

Os endpoints privados de trabalho elástico suportam todas as opções de autenticação de agente de trabalho elástico.

O recurso de ponto de extremidade privado de trabalho elástico permite que você escolha 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 por serviço é um endereço IP privado dentro de uma rede virtual e 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 para gravar a saída do trabalho nesses bancos de dados de destino/saída.

Os pontos de extremidade privados de trabalho elástico podem ser criados e permitidos por meio do portal do Azure. Os servidores de destino conectados por meio do link privado podem estar em qualquer lugar no Azure, mesmo em diferentes geografias e assinaturas. Você deve criar um ponto de extremidade privado para cada servidor de destino desejado e o servidor de saída de trabalho 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 ponto de extremidade privado de trabalhos elásticos SQL do Azure.

Requisitos para pontos de extremidade privados de trabalho elástico

• Para usar um ponto de extremidade privado de trabalhos elásticos, o agente de trabalho e os servidores/bancos de dados de destino devem ser hospedados no Azure (mesmas regiões ou regiões diferentes) e no mesmo tipo de nuvem (por exemplo, ambos na nuvem pública ou ambos na nuvem governamental).
• Microsoft.Network O provedor de recursos deve estar registrado para as assinaturas de host do agente de trabalho e dos servidores de destino/saída.
• Os pontos de extremidade privados de trabalho 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 através do painel Rede desse servidor lógico ou do seu cliente preferido. O agente de trabalho elástico poderá então acessar quaisquer bancos de dados sob esse servidor usando conexão privada.
• A conexão do agente de trabalho elástico com o banco de dados de trabalhos não usará ponto de extremidade privado. O próprio agente de trabalho usa autenticação interna baseada em certificado para se conectar ao seu banco de dados de trabalhos. Uma ressalva é se você adicionar o banco de dados de trabalhos como um membro do grupo-alvo. Em seguida, ele se comporta como um destino regular que você precisaria configurar com o 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 é criada com a seguinte permissão e foi projetada para dar aos administradores um controle de acesso mais fino para monitoramento de tarefas. 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 de esquema "jobs"	permissões de esquema "jobs_internal"
jobs_reader	SELECIONAR	None

Atenção

Você não deve atualizar exibições de catálogo interno no banco de dados de tarefas, como jobs.target_group_members. Alterar manualmente essas exibições de catálogo pode corromper o banco de dados de tarefas e causar falhas. Esses modos de exibição são somente para consulta somente leitura. Você pode usar os procedimentos armazenados em seu banco de dados de trabalho para adicionar/excluir grupos/membros de destino, como jobs.sp_add_target_group_member.

Importante

Considere as implicações de segurança antes de conceder qualquer acesso elevado ao banco de dados de tarefas. 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, o que pode permitir que o usuário mal-intencionado determine a senha da credencial ou execute comandos mal-intencionados.

Monitorar trabalhos elásticos

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

O portal do Azure também tem recursos novos e adicionais para dar suporte a trabalhos elásticos e monitoramento de tarefas. 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 ser alertado 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 obter um exemplo, consulte Criar, configurar e gerenciar trabalhos elásticos (visualização).

Saída da tarefa

O resultado dos passos de uma tarefa em cada base de dados de destino é registado pormenorizadamente e a saída do script pode ser capturada numa tabela especificada. Pode especificar uma base de dados para guardar os dados devolvidos por uma tarefa.

Histórico de tarefas

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

Estado da tarefa

Você pode monitorar execuções de trabalho elástico no banco de dados de trabalho consultando a tabela jobs.job_executions.

Melhores práticas

Considere as seguintes práticas recomendadas ao trabalhar com trabalhos de banco de dados elástico.

Melhores práticas de segurança

• Limite a utilização das APIs a pessoas de confiança.
• As credenciais devem ter o mínimo de privilégios necessários para executar o passo de tarefa. Para obter mais informações, consulte Autorização e permissões.
• Ao usar um servidor e/ou membro do grupo-alvo do pool, é altamente recomendável criar uma credencial separada com direitos no master banco de dados para exibir/listar bancos de dados que é usada para expandir as listas de banco de dados do(s) servidor(es) e/ou pool(s) antes da execução do trabalho.

Desempenho elástico do trabalho

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

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

Níveis de capacidade simultâneos

A partir de outubro de 2023, o agente de trabalho elástico terá 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 mais conexões de destino simultâneas para execução de tarefas, 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, portanto, JA100 é o padrão.

Camada de agente de trabalho elástico	Máximo de trabalhos simultâneos
JA100	100
JA200	200
JA400	400
JA800	800

Exceder a camada de capacidade de simultaneidade do agente de trabalho com destinos de trabalho criará atrasos de fila para alguns bancos de dados/servidores de destino. Por exemplo, se você iniciar um trabalho com destino 110 na camada JA100, 10 trabalhos aguardarão para começar até que outros terminem.

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

Limitar o impacto do trabalho 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, os trabalhos podem ser configurados para limitar o número de bancos de dados em que um trabalho pode ser executado ao mesmo tempo.

Defina o número de bancos de dados simultâneos em que um trabalho é executado definindo o sp_add_jobstep parâmetro do @max_parallelism procedimento armazenado em T-SQL.

Scripts Idempotent

Os scripts T-SQL de um trabalho elástico devem ser idempotentes. Idempotent significa que, se o script for bem-sucedido e for executado novamente, o mesmo resultado ocorre. Um script pode falhar devido a problemas de rede transitórios. Nesse caso, a tarefa repetirá automaticamente a execução do script um número predefinido de vezes antes de desistir. Um script idempotente tem o mesmo resultado, mesmo que tenha sido executado com sucesso duas vezes (ou mais).

Uma tática simples consiste em testar a existência de um objeto antes de o criar. Segue-se 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 tem de poder ser executado com êxito ao testar logicamente e refutar as condições que encontrar.

Limitações

Estas são as limitações atuais para o serviço de trabalhos elásticos. Estamos trabalhando ativamente para remover o maior número possível dessas limitações.

Problema	Description
O agente de trabalho elástico precisa ser recriado e iniciado na nova região após um failover/mudança para uma nova região do Azure.	O serviço de trabalhos elásticos armazena todo o seu agente de trabalho e metadados de trabalho no banco de dados de trabalhos. Qualquer failover ou movimentação de recursos do Azure para uma nova região do Azure também moverá o banco de dados de trabalhos, o agente de trabalho e os metadados de trabalhos para a nova região do Azure. No entanto, o agente de trabalho elástico é um recurso somente de computação e precisa ser explicitamente recriado e iniciado na nova região antes que os trabalhos comecem a ser executados novamente na nova região. Uma vez iniciado, o agente de trabalho elástico retomará a execução de trabalhos na nova região de acordo com o cronograma de trabalho definido anteriormente.
Excesso de logs de auditoria do banco de dados de trabalhos	O agente de trabalho elástico opera pesquisando constantemente o banco de dados de trabalhos para verificar a chegada de novos trabalhos e outras operações CRUD. Se a auditoria estiver habilitada no servidor que hospeda um banco de dados de trabalhos, um grande número de logs de auditoria poderá ser gerado pelo banco de dados de trabalhos. Isso pode ser atenuado 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 "database_principal_name <> '##MS_JobAccount##'" Este comando filtrará apenas o agente de trabalho para logs de auditoria de banco de dados de trabalhos, não o agente de trabalho para quaisquer logs de auditoria de bancos de dados de destino.
Uso de um banco de dados Hyperscale como banco de dados de tarefas	Não há suporte para o uso de um banco de dados Hyperscale como um banco de dados de trabalho. No entanto, os trabalhos elásticos podem direcionar bancos de dados Hyperscale da mesma maneira que qualquer outro banco de dados no Banco de Dados SQL do Azure.
Bancos de dados sem servidor e pausa automática com trabalhos elásticos.	O banco de dados sem servidor habilitado para pausa automática não é suportado como um banco de dados de trabalho. Os bancos de dados sem servidor direcionados por trabalhos elásticos oferecem suporte à pausa automática e serão retomados por conexões de trabalho.
Exportando um banco de dados de trabalhos para um arquivo BACPAC	Não há suporte para a exportação de um banco de dados de trabalhos para um arquivo BACPAC. Se o SQL Server que contém um Banco de Dados de Trabalho precisar ser exportado, o Banco de Dados de Trabalho deverá ser descartado primeiro antes de exportar o servidor.

Conteúdos relacionados

• Criar, configurar e gerenciar trabalhos elásticos (visualização)
• Automatizar tarefas de gerenciamento no Azure SQL
• Criar e gerenciar trabalhos elásticos usando o PowerShell (visualização)
• Criar e gerenciar trabalhos elásticos usando T-SQL (visualização)

Próximo passo

Tutorial: Criar, configurar e gerenciar trabalhos elásticos (visualização)