Trabalhos elásticos no Banco de Dados SQL do Azure

Aplica-se a:Banco de Dados SQL do Azure

Neste artigo, analisamos as capacidades e detalhes dos trabalhos elásticos para Azure SQL Database.

• Para um tutorial sobre como configurar trabalhos elásticos, veja o tutorial de trabalhos elásticos.
• Saiba mais sobre conceitos de automação nas plataformas de bases de dados Azure.

Visão geral dos trabalhos elásticos

Pode criar e agendar trabalhos elásticos que podem ser executados periodicamente em uma ou várias bases de dados Azure SQL para executar consultas Transact-SQL (T-SQL) e realizar tarefas de manutenção.

Pode definir a base de dados alvo ou grupos de bases de dados onde o trabalho será executado, e também definir agendas para executar um trabalho. Todas as datas e horários em empregos elásticos são no fuso horário UTC.

Um trabalho trata da tarefa de iniciar sessão na base de dados alvo. Também se definem, mantêm e persistem scripts Transact-SQL para serem executados num grupo de bases de dados.

Cada tarefa regista o estado da execução e efetua automaticamente tentativas das operações em caso de falha.

Quando usar trabalhos elásticos

Existem vários cenários em que pode usar automação elástica de trabalhos:

• Automatiza as tarefas de gestão e agenda-as para que corram todos os dias úteis, fora do horário, etc.
  • Implementar alterações de esquema, gestão de credenciais.
  • Recolha de dados de desempenho ou recolha de telemetria do tenant (cliente).
  • Atualize os dados de referência (informação comum a todas as bases de dados).
  • Carregar dados a partir do Azure Blob storage.
• Configure os trabalhos para serem executados numa coleção de bases de dados de forma recorrente, como durante as horas de menor afluência.
  • Colete resultados de consulta de um conjunto de bancos de dados em uma tabela central continuamente.
  • As consultas podem ser executadas continuamente e configuradas para desencadear tarefas adicionais a serem executadas.
• Recolha de dados para relatórios
  • Agregar dados de uma coleção de bancos de dados em uma única tabela de destino.
  • Executar consultas de processamento de dados mais longas em um grande conjunto de bancos de dados, por exemplo, a recolha de telemetria de clientes. Os resultados são recolhidos numa única tabela de destino para posterior análise.
• Movimentação de dados
  • Para soluções desenvolvidas à medida, automação empresarial ou outra gestão de tarefas.
  • Processamento ETL para extrair/processar/inserir dados entre tabelas numa base de dados.

Considere empregos elásticos quando:

• Tenha uma tarefa que precise de ser executada regularmente em agenda, direcionada a uma ou mais bases de dados.
• Ter uma tarefa que precisa de ser executada uma vez, mas em várias bases de dados.
• É necessário executar trabalhos em qualquer combinação de bases de dados: uma ou mais bases de dados individuais, todas as bases de dados num servidor, todas as bases de dados num pool elástico, com a flexibilidade adicional de incluir ou excluir qualquer base de dados específica. As tarefas podem ser executadas em múltiplos servidores, múltiplos pools e até em bases de dados de diferentes subscrições. Servidores e pools são enumerados dinamicamente em tempo de execução, pelo que os trabalhos são executados contra todas as bases de dados que existem no grupo-alvo no momento da execução.
  • Esta é uma diferenciação significativa do SQL Agent, que não pode enumerar dinamicamente as bases de dados alvo, especialmente em cenários de clientes SaaS onde as bases de dados são adicionadas/eliminadas dinamicamente.

Componentes elásticos do trabalho

Agente de emprego elástico

Um agente de trabalho elástico é o recurso Azure para criar, executar e gerir tarefas. O agente de trabalhos elástico é um recurso Azure que crias no portal (Criar e gerir trabalhos elásticos usando PowerShell e API REST também são suportados).

Criar um agente de emprego elástico requer uma base de dados existente no Azure SQL Database. O agente configura esta base de dados Azure SQL existente como base de dados de empregos.

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

Custo do agente de trabalho elástico

A base de dados de empregos é faturada à mesma taxa que qualquer base de dados na Azure SQL Database. O custo do agente de trabalho Elástico baseia-se num preço fixo do nível de serviço selecionado para o agente de trabalho. Consulte a página de preços da Azure SQL Database.

Base de dados de tarefas dinâmicas

A base de dados de trabalhos é usada para definir funções e acompanhar o estado e histórico das execuções de tarefas. Os trabalhos são executados em bases de dados alvo. A base de dados de trabalhos é também usada para armazenar metadados de agentes, registos, resultados, definições de trabalhos, e contém muitos procedimentos armazenados úteis e outros objetos de base de dados para criar, executar e gerir trabalhos usando T-SQL.

Uma base de dados Azure SQL é necessária para criar um agente de emprego elástico. O Job Agent irá armazenar todos os seus metadados relacionados com trabalhos na base de dados de empregos, que deverá ser uma nova base de dados Azure SQL vazia.

O objetivo de serviço recomendado para a base de dados de empregos é DTU S1 ou superior, mas a escolha ótima depende das necessidades de desempenho do(s) seu(s) trabalho(s): o número de passos do trabalho, o número de alvos de trabalho e a frequência com que os trabalhos são executados.

Se as operações contra a base de dados de trabalho forem mais lentas do que o esperado, monitore o desempenho e a utilização de recursos na base de dados de trabalho durante os períodos de lentidão usando o Portal Azure ou o sys.dm_db_resource_stats DMV. Se a utilização de um recurso, como CPU, Data Io ou Log Write, se aproximar dos 100% e se correlacionar com períodos de lentidão, considere escalar incrementalmente a base de dados para objetivos de serviço mais elevados (quer no modelo de compras baseado em DTU , quer no modelo de compras vCore) até que o desempenho da base de dados de trabalhos seja suficientemente melhorado.

A própria base de dados de empregos pode ser o alvo de um trabalho elástico. Neste cenário, a base de dados de empregos é tratada tal como qualquer outra base de dados alvo. O utilizador da tarefa deve ser criado e receber permissões suficientes na base de dados da tarefa, e a credencial com âmbito de base de dados para o utilizador da tarefa também deve existir na base de dados da tarefa, tal como acontece com qualquer outra base de dados alvo.

Quando a própria base de dados de trabalhos é um alvo de uma tarefa, certifique-se de que os seus trabalhos não modificam ou eliminam quaisquer metadados específicos do agente de emprego armazenados nessa base de dados. Devem ser usados apenas job stored procedures ou job views para modificar/consultar informações relacionadas com o trabalho.

Tarefas elásticas e etapas de trabalho

Um trabalho é uma unidade de trabalho executada num horário ou como um trabalho pontual. Um trabalho consiste em um ou mais passos do trabalho.

Cada etapa da tarefa especifica um script T-SQL a executar, um ou mais grupos-alvo contra os quais executar o script T-SQL, e as credenciais que o agente de tarefas precisa para se conectar à base de dados de destino. Cada etapa do trabalho tem políticas personalizáveis de timeout e repetição, podendo opcionalmente 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, através de um grande número de bases de dados, num calendário ou sob demanda. O alvo pode ser qualquer nível da Azure SQL Database.

Pode executar trabalhos agendados contra qualquer combinação de bases de dados: uma ou mais bases de dados individuais, todas as bases de dados num servidor, todas as bases de dados num pool elástico, com a flexibilidade adicional de incluir ou excluir qualquer base de dados específica. Os trabalhos podem ser executados em múltiplos servidores, múltiplos grupos e até em bases de dados em diferentes subscrições. Servidores e pools são enumerados dinamicamente em tempo de execução, pelo que os trabalhos são executados contra todas as bases de dados que existem no grupo-alvo no momento da execução.

A imagem seguinte mostra um agente de empregos a executar trabalhos entre os diferentes tipos de grupos-alvo:

Grupo-alvo

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

• Servidor SQL lógico - se um servidor for especificado, todas as bases de dados que existem no servidor no momento da execução do trabalho fazem parte do grupo. A master credencial da base de dados deve ser fornecida para que o grupo possa ser enumerado e atualizado antes da execução do trabalho. Para mais informações sobre servidores lógicos, veja O que é um servidor lógico na Azure SQL Database e Azure Synapse?
• Pool elástico - se um pool elástico for especificado, todas as bases de dados que estão no pool elástico no momento da execução do trabalho fazem parte do grupo. Quanto a um servidor, a master credencial da base de dados deve ser fornecida para que o grupo possa ser atualizado antes da execução do trabalho.
• Base de dados única - especificar uma ou mais bases de dados individuais para fazer parte do grupo.

Pools e bases de dados individuais podem ser especificados como incluídos ou excluídos do grupo. Isto permite criar um grupo-alvo com qualquer combinação de bases de dados. Por exemplo, pode adicionar um servidor a um grupo-alvo, mas excluir bases de dados específicas num pool elástico (ou excluir um pool inteiro).

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

Os exemplos seguintes mostram como diferentes definições de grupos-alvo são enumeradas dinamicamente no momento da execução do trabalho para determinar quais bases de dados afetar:

• O Exemplo 1 mostra um grupo-alvo que consiste numa lista de bases de dados individuais. Quando um passo de trabalho é executado usando este grupo-alvo, a ação desse passo será executada em cada uma dessas bases de dados.
• O Exemplo 2 mostra um grupo-alvo que contém um servidor como alvo. Quando um passo de trabalho é executado usando este grupo-alvo, o servidor é enumerado dinamicamente para determinar a lista de bases de dados que se encontram atualmente no servidor. A ação da etapa do trabalho será executada em cada uma dessas bases de dados.
• O Exemplo 3 mostra um grupo-alvo semelhante ao do Exemplo 2, mas uma base de dados individual é especificamente excluída. A ação da etapa do trabalho não será executada na base de dados que foi excluída.
• O Exemplo 4 mostra um grupo-alvo que contém um pool elástico como alvo. Semelhante ao Exemplo 2, o pool será enumerado dinamicamente em tempo de execução do job para determinar a lista de bases de dados no pool.

• O Exemplo 5 e o Exemplo 6 mostram cenários avançados onde servidores, pools elásticos e bases de dados podem ser combinados usando regras de incluir e excluir.

Cronogramas de trabalho elásticos

Os trabalhos elásticos são produtos prioritários em nuvem e são concebidos para iniciar mesmo que ocorra um problema transitório de disponibilidade de rede ou serviço no momento do agendamento. Os horários de trabalho elásticos têm em conta a hora de início do horário e os intervalos pedidos. Quando crias um cronograma de trabalho elástico, o trabalho será executado o mais cedo possível após cada evento de intervalo agendado.

Os horários de trabalho detetaram eventos perdidos. Se criar um novo cronograma de tarefas que começa no passado, o trabalho será executado imediatamente quando ativado. Se estiver desativado ou indisponível, o trabalho será executado imediatamente após se tornar ativado ou disponível.

Por exemplo, é atualmente 2 de janeiro, 9h UTC. Configuraste uma nova tarefa com início agendado para esta noite, 2 de janeiro, às 22h30 UTC, para execução diária. O trabalho será executado às 22h30 UTC.

Para evitar que um trabalho comece acidentalmente, crie horários que comecem no futuro. Num exemplo que pode levar ao início acidental de uma tarefa, configuras uma nova tarefa para ser executada diariamente às 22h30 UTC. Desativas o trabalho durante uma semana. Depois, se ativares a tarefa às 8h30 UTC, a tarefa será executada imediatamente, recuperando o evento de intervalo perdido que deveria ter sido executado na noite anterior. Após ser executado, o agente de trabalho não será executado novamente até à próxima execução programada às 22h30 UTC. Para evitar a execução às 8:30 UTC neste cenário, atualize o início do cronograma do trabalho para 8 de janeiro às 22:30 UTC e depois ative o trabalho. Ou, ative a tarefa em um momento em que ela possa ser executada imediatamente.

Authentication

Escolha um método para todos os alvos de um agente de trabalho elástico. Por exemplo, para um único agente de trabalho elástico, não pode configurar um servidor alvo para usar credenciais com âmbito de base de dados e outro para usar autenticação Microsoft Entra ID.

O agente de trabalho elástico pode ligar-se aos servidores/bases de dados especificados pelo grupo-alvo através de duas opções de autenticação:

• Use a autenticação Microsoft Entra (anteriormente Azure Active Directory) com uma identidade gerida atribuída a utilizador (UMI).
• Utilize credenciais com âmbito de base de dados.

Autenticação via identidade gerida atribuída pelo utilizador (UMI)

A autenticação Microsoft Entra (anteriormente Azure Active Directory) via identidade gerida atribuída pelo utilizador (UMI) é a opção recomendada para ligar trabalhos elásticos à Azure SQL Database. Com o suporte ao Microsoft Entra ID, o job agent liga-se às bases de dados alvo (bases de dados, servidores, pools elásticos) e à base de dados de saída usando a UMI.

Opcionalmente, a autenticação Microsoft Entra ID pode também ser ativada no servidor lógico que contém a base de dados elástica de trabalhos, para aceder/consultar essa base de dados através de ligações Microsoft Entra ID. No entanto, o próprio agente de empregos utiliza autenticação interna baseada em certificados para se ligar à sua base de dados de trabalhos.

Podes criar um UMI, ou usar um UMI existente, e atribuir o mesmo UMI a vários agentes de emprego. Só um UMI é suportado por um agente de trabalho. Uma vez atribuído um UMI a um Agente de Trabalho, esse Agente de Trabalho só usará essa identidade para conectar-se e executar trabalhos t-SQL nas bases de dados de destino. A autenticação do SQL não será usada contra o servidor/servidores e bases 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 mais informações sobre UMI na Azure SQL Database, consulte Identidades Geridas para Azure SQL, incluindo os passos necessários e os benefícios de usar uma UMI como identidade lógica do servidor Azure SQL Database. Para obter mais informações, consulte Autenticação do Microsoft Entra para Azure SQL.

A utilização de uma identidade gerida (SMI) atribuída pelo sistema não é suportada.

Autenticação através de credenciais com âmbito de base de dados

Embora a autenticação Microsoft Entra (anteriormente Azure Active Directory) seja a opção recomendada, os jobs podem ser configurados para usar credenciais com âmbito de base de dados para se ligar às bases de dados especificadas pelo grupo-alvo na execução. Antes de outubro de 2023, as credenciais com âmbito de base de dados eram a única opção de autenticação.

Se um grupo-alvo contiver servidores ou pools, estas credenciais com âmbito de base de dados são usadas para se ligar à master base de dados e enumerar as bases de dados disponíveis.

• As credenciais definidas pela base de dados devem ser criadas na base de dados de empregos.
• Todas as bases de dados alvo devem ter um login com permissões suficientes para que o trabalho seja concluído com sucesso (jobuser no diagrama seguinte).
• As credenciais criadas nas bases de dados alvo (LOGIN e PASSWORD for masteruser e jobuser, no diagrama seguinte) devem corresponder às IDENTITY e SECRET nas credenciais criadas na base de dados de empregos.
• As credenciais podem ser reutilizadas entre trabalhos, e as palavras-passe das credenciais são encriptadas e protegidas dos utilizadores que apenas têm acesso de leitura aos objetos de trabalho.

A imagem seguinte foi concebida para ajudar a compreender a configuração das credenciais de trabalho adequadas e como o agente de trabalho elástico se liga usando credenciais de base de dados como autenticação aos logins/utilizadores em servidores/bases de dados alvo.

Endpoints privados de trabalhos elásticos

O agente de trabalho elástico suporta endpoints privados de trabalho elásticos. Criar um endpoint privado de trabalhos elásticos estabelece uma ligação privada entre o trabalho elástico e o servidor alvo. A funcionalidade de endpoints privados do Elastic Jobs é diferente do Azure Private Link.

A funcionalidade elástica de endpoints privados de trabalho suporta ligações privadas a servidores de destino/saída, de modo que o agente de tarefas ainda pode aceder a eles mesmo quando a opção "Negar Acesso Público" está ativada. Usar endpoints privados é também uma possível solução se quiser desativar a opção "Permitir que os serviços e recursos Azure acedam a esse servidor".

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

A funcionalidade elástica de endpoint privado de trabalho permite escolher um endpoint privado gerido por serviços para estabelecer uma ligação segura entre o agente de trabalho e os seus servidores de destino/saída. Um endpoint privado gerido por serviços é um endereço IP privado dentro de uma rede virtual e sub-rede específicas. Quando escolhe usar endpoints privados num dos servidores de destino/saída do seu job agent, é criado um endpoint privado gerido por serviços pela Microsoft. Este ponto de extremidade privado é então usado exclusivamente pelo agente de tarefas para conectar e executar tarefas, ou para escrever a saída nessas bases de dados de destino ou de saída.

Endpoints privados de trabalho elásticos podem ser criados e permitidos através do portal Azure. Os servidores alvo ligados via ligação privada podem estar em qualquer parte do Azure, mesmo em diferentes geografias e subscrições. Deve criar um endpoint privado para cada servidor alvo e para o servidor de destino dos resultados do trabalho, de forma a permitir esta comunicação.

Para um tutorial sobre como configurar um novo endpoint privado gerido por serviços para trabalhos elásticos, veja Configurar o endpoint privado de trabalhos elásticos Azure SQL.

Requisitos para endpoints privados de trabalho elástico

• Para utilizar um endpoint privado de trabalhos elásticos, tanto o agente de trabalho quanto os servidores ou bases 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).
• Microsoft.Network O fornecedor de recursos deve estar registado para as subscrições de host tanto do agente de execução dos trabalhos como dos servidores de destino e de saída.
• Os endpoints privados de trabalho elásticos são criados por servidor de destino/saída. Devem ser aprovados antes de o agente de trabalho elástico poder usá-los. Isto pode ser feito através do painel de Rede desse servidor lógico ou do seu cliente preferido. O agente de trabalho elástico poderá então aceder a quaisquer bases de dados desse servidor usando ligação privada.
• A ligação do agente de empregos elástico à base de dados de empregos não usará endpoint privado. O próprio agente de empregos utiliza autenticação interna baseada em certificados para se ligar à sua base de dados de empregos. Uma ressalva é se adicionares a base de empregos como membro do grupo-alvo. Depois, comporta-se como um destino normal que terias de configurar com endpoint privado conforme necessário.

Permissões elásticas para bases de dados de trabalhos

Durante a criação do agente de emprego, são criados um esquema, tabelas e um papel chamado jobs_reader na base de dados de empregos. A função foi criada com as seguintes permissões e foi concebida para dar aos administradores um controlo de acesso mais apurado para a monitorização do trabalho. Os administradores podem fornecer aos utilizadores a capacidade de monitorizar a execução de trabalhos, adicionando-os ao papel jobs_reader na base de dados de trabalhos.

Monitorizar tarefas elásticas

O agente de emprego elástico tem integração com o Azure Alerts para notificações de estado de trabalho, simplificando a solução para monitorizar o estado e o histórico de execução de tarefas.

O portal Azure também tem novas funcionalidades adicionais para suportar trabalhos elásticos e monitorização de trabalhos. Na página de Visão Geral do agente de trabalhos Elastic, são exibidas as execuções de trabalho mais recentes, como na captura de ecrã seguinte.

Pode criar regras Azure Monitor Alert com o portal Azure, Azure CLI, PowerShell e API REST. A métrica de trabalhos elásticos falhados é um bom ponto de partida para monitorizar e receber alertas sobre a execução de trabalhos elásticos. Além disso, pode optar por ser alertado através de uma ação configurável, como SMS ou email, através da facilidade Azure Alert. Para mais informações, consulte Criar alertas para Azure SQL Database no portal Azure.

Para um exemplo, veja Criar, configurar e gerir trabalhos elásticos.

Saída da tarefa

O resultado dos passos de um trabalho em cada base de dados alvo é registado em detalhe, e a saída do script pode ser capturada numa tabela especificada. Podes especificar uma base de dados para guardar quaisquer dados devolvidos de um trabalho.

Histórico do trabalho

Veja o histórico elástico de execução de trabalhos na base de dados de trabalhos consultando a tabela jobs.job_executions. O trabalho de limpeza do sistema remove o histórico de execução que tem mais de 45 dias. Para remover manualmente o histórico com menos de 45 dias, execute o sp_purge_jobhistory procedimento armazenado na base de dados de trabalhos.

Estado do trabalho

Pode monitorizar execuções elásticas de trabalhos na base de dados de trabalhos consultando a tabela jobs.job_executions.

Melhores práticas

Considere as seguintes boas práticas ao trabalhar com trabalhos de bases de dados elásticas.

Práticas recomendadas de segurança

• Limite o uso das APIs a pessoas de confiança.
• As credenciais devem ter o mínimo de privilégios necessários para realizar a etapa da tarefa. Para mais informações, consulte Autorização e Permissões.
• Ao usar um servidor e/ou membro do grupo-alvo do pool, é altamente recomendado que crie uma credencial separada com direitos sobre a master base de dados para visualizar/listar bases de dados, que seja usada para expandir as listas de bases de dados dos servidores e/ou pools antes da execução do trabalho.

Desempenho elástico no trabalho

Os trabalhos elásticos consomem recursos de computação mínimos enquanto aguardam que os trabalhos de longa duração sejam concluídos.

Dependendo do tamanho do grupo-alvo de bases de dados e do tempo de execução desejado para um trabalho (número de trabalhadores concorrentes), o agente requer diferentes quantidades de cálculo e desempenho da base de dados de trabalhos (quanto mais alvos e maior número de tarefas, maior será a quantidade de cálculo necessária).

Níveis de capacidade concorrente

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

Os incrementos de capacidade indicam o número total de bases de dados alvo concorrentes a que o agente de trabalho pode ligar-se e iniciar um trabalho. Para mais ligações alvo concorrentes para execução de tarefas, atualize o nível de um agente de trabalho a partir do nível padrão JA100, que tem um limite de 100 ligações alvo concorrentes.

A maioria dos ambientes requer menos de 100 trabalhos simultâneos, por isso o JA100 é o valor padrão.

Exceder o nível de capacidade de concorrência do agente de trabalho com as metas de trabalho criará atrasos na fila para algumas bases de dados/servidores alvo. Por exemplo, se iniciares um trabalho com 110 alvos na camada JA100, 10 alvos terão de esperar para começar até que os outros terminem.

O nível ou objetivo de serviço de um agente de trabalho elástico pode ser modificado através do portal Azure, PowerShell ou da API REST dos Agentes de Trabalho. Para um exemplo, consulte Escalar o agente de tarefas.

Limitar o impacto do trabalho nas piscinas elásticas

Para garantir que os recursos não ficam sobrecarregados ao executar trabalhos contra bases de dados num pool elástico Azure SQL Database, os trabalhos podem ser configurados para limitar o número de bases de dados contra as quais um trabalho pode correr ao mesmo tempo.

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

Escritas idempotentes

Os scripts T-SQL de um trabalho elástico têm de ser idempotentes. Idempotente significa que, se o script tiver sucesso e for executado novamente, ocorre o mesmo resultado. Um script pode falhar devido a problemas de rede transitórios. Nesse caso, o trabalho tentará automaticamente executar o script um número prédefinido 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 é 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.

De forma semelhante, um script deve ser capaz de executar com sucesso testando logicamente e contrariando quaisquer condições que encontre.

Limitações

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

Conteúdo relacionado

• Criar, configurar e gerir tarefas elásticas
• Automatizar tarefas de gestão no Azure SQL
• Criar e gerir trabalhos elásticos usando o PowerShell
• Crie e gere trabalhos elásticos usando T-SQL

Próximo passo