Processi elastici per il database SQL di Azure

Si applica a:Database SQL di Azure

Questo articolo esamina le funzionalità e i dettagli dei processi elastici per il database SQL di Azure.

• Per un'esercitazione sulla configurazione dei processi elastici, vedere l'esercitazione sui processi elastici.
• Ulteriori informazioni sui concetti di automazione nelle piattaforme di database di Azure.

Panoramica dei lavori elastici

È possibile creare e pianificare processi elastici eseguiti periodicamente su uno o più database SQL di Azure. I processi eseguono query Transact-SQL (T-SQL) ed eseguono attività di manutenzione.

È possibile definire database di destinazione o gruppi di database in cui viene eseguito il processo. È anche possibile definire pianificazioni per l'esecuzione di un processo. Tutti i riferimenti relativi a data e orari nei processi elastici sono nel fuso orario UTC.

Un job gestisce il compito di autenticarsi al database di destinazione. È anche possibile definire, gestire e rendere persistenti gli script Transact-SQL da eseguire in un gruppo di database.

Ogni processo registra lo stato di esecuzione e ripete automaticamente le operazioni in caso di errore.

Quando usare i lavori elastici

Usare l'automazione delle attività elastiche negli scenari seguenti:

• Automatizzare le attività di gestione e pianificarle per l'esecuzione ogni giorno feriale o dopo l'orario lavorativo, ad esempio.
  • Distribuire le modifiche dello schema e gestire le credenziali.
  • Raccogliere i dati sulle prestazioni o i log del tenant (cliente).
  • Aggiornare i dati di riferimento, ad esempio informazioni comuni tra tutti i database.
  • Caricare dati da archiviazione BLOB di Azure.
• Configurare i processi per l'esecuzione su un insieme di database su base ricorrente, ad esempio durante gli orari di minore attività.
  • Raccogliere i risultati di query da un set di database in una tabella centrale su base costante.
  • Le query possono essere eseguite continuamente e configurate per attivare attività aggiuntive.
• Raccogliere i dati per i report
  • Aggregare i dati di una raccolta di database in una singola tabella di destinazione.
  • Eseguire query di elaborazione dati in un set di database di grandi dimensioni, ad esempio la raccolta di log dei clienti. I risultati vengono raccolti in una tabella di destinazione singola per ulteriori analisi.
• Spostamento dei dati
  • Per soluzioni sviluppate su misura, automazione aziendale o altre attività di gestione.
  • Elaborazione ETL per estrarre, trasformare e caricare dati tra tabelle in un database.

Prendi in considerazione i lavori elastici se:

• Disporre di un'attività che deve essere eseguita regolarmente in base a una pianificazione, destinata a uno o più database.

• Avere un'attività che deve essere eseguita una sola volta, ma in più database.

• Si ha necessità di eseguire processi su qualsiasi combinazione di database: uno o più database individuali, tutti i database su un server, tutti i database in un pool elastico, con in più la possibilità di includere o escludere database specifici. Le attività possono essere eseguite su più server, in più pool e anche con database di iscrizioni differenti. I server e i pool vengono enumerati in modo dinamico in fase di esecuzione, quindi i processi vengono eseguiti su tutti i database esistenti nel gruppo di destinazione al momento dell'esecuzione.

  • Questa funzionalità è una differenziazione significativa rispetto a SQL Agent, che non può enumerare dinamicamente i database di destinazione, soprattutto negli scenari dei clienti SaaS in cui i database vengono aggiunti o eliminati in modo dinamico.

Componenti per lavori elastici

Componente	Descrizione
Agente di attività elastica	Risorsa di Azure creata per eseguire e gestire i processi.
Database di lavoro	Un database in Azure SQL Database che l'agente di lavoro utilizza per memorizzare dati relativi ai lavori, definizioni di lavori e altro ancora.
Mansione	Un lavoro è un'unità di lavoro costituita da una o più fasi di lavoro. I passaggi del processo specificano lo script T-SQL da eseguire e altri dettagli necessari.
Gruppo di destinazione	Il set di server, pool e database su cui eseguire un processo.

Agente di lavoro elastico

Un agente di processo elastico è la risorsa di Azure per creare, eseguire e gestire i processi. L'agente di processi elastici viene creato come risorsa di Azure nel portale (sono supportati anche creare e gestire processi elastici usando PowerShell e l'API REST).

La creazione di un agente di processo elastico richiede un database esistente in database SQL di Azure. L'agente configura il database SQL di Azure esistente come database di processo.

È possibile avviare, disattivare o annullare un processo tramite il portale di Azure. Il portale di Azure permette anche di visualizzare le definizioni dei processi e la cronologia di esecuzione.

Costo dell'agente di lavoro elastico

Il database dei processi viene fatturato alla stessa tariffa di qualsiasi altro database in SQL di Azure. Il costo dell'agente job elastico si basa sui prezzi fissi del livello di servizio selezionato per l'agente job. Per altre informazioni, vedere la pagina dei prezzi del database SQL di Azure.

Database dei processi elastici

Usare il database delle attività per definire le attività e monitorare lo stato e la cronologia delle esecuzioni delle attività. Le attività vengono eseguite nei database di destinazione. Il database del processo archivia anche i metadati dell'agente, i log, i risultati e le definizioni dei processi. Contiene molte stored procedure utili e altri oggetti di database per la creazione, l'esecuzione e la gestione dei processi tramite T-SQL.

Per creare un agente di processo elastico, è necessario un database SQL di Azure. L'agente di processo archivia tutti i metadati correlati al processo nel database del processo, che deve essere un nuovo database SQL di Azure vuoto.

L'obiettivo di servizio consigliato del database del processo è DTU S1 o superiore, ma la scelta ottimale dipende dalle esigenze di prestazioni dei processi: il numero di passaggi del processo, il numero di destinazioni di processo e la frequenza di esecuzione dei processi.

Se le operazioni eseguite sul database dei processi sono più lente del previsto, monitorare le prestazioni del database e l'utilizzo delle risorse nel database dei processi durante i periodi di lentezza usando il portale di Azure o la DMV sys. dm_db_resource_stats. Se l'utilizzo di una risorsa, ad esempio CPU, I/O dati o scrittura log, si avvicina al 100% ed è correlato a periodi di lentezza, valutare il ridimensionamento incrementale del database a obiettivi di servizio più elevati (nel modello di acquisto basato su DTU o nel modello di acquisto vCore) fino a quando le prestazioni del database delle attività non sono sufficientemente migliorate.

Il database di lavoro stesso può essere la destinazione di un lavoro elastico. In questo scenario, trattare il database del processo esattamente come qualsiasi altro database di destinazione. È necessario creare l'utente del processo e concedere autorizzazioni sufficienti nel database del processo. Le credenziali con ambito database per l'utente del processo devono esistere anche nel database del processo, come per qualsiasi altro database di destinazione.

Quando il database del processo è una destinazione di un processo, assicurarsi che i processi non modifichino o eliminino metadati specifici dell'agente di processo archiviati nel database. Utilizzare solo le stored procedure del job o le viste del job per modificare o eseguire query sulle informazioni correlate ai job.

Importante

Non modificare gli oggetti esistenti o creare nuovi oggetti nel database di lavoro, anche se è possibile leggere dalle tabelle per reportistica e analisi.

Job elastici e passaggi del job

Un processo è un'unità di lavoro eseguita in base a una pianificazione o come processo monouso. Una attività è composta da uno o più passaggi.

Ogni passaggio del processo specifica uno script T-SQL da eseguire, uno o più gruppi di destinazione per eseguire lo script T-SQL e le credenziali su cui l'agente del processo deve connettersi al database di destinazione. Ogni passaggio del processo ha criteri di timeout e ripetizione personalizzabili e può eventualmente specificare parametri di output.

Obiettivi dei carichi di lavoro elastici

I processi elastici possono eseguire uno o più script T-SQL in parallelo, in un numero elevato di database, in base a una pianificazione o su richiesta. La destinazione può essere qualunque livello di database SQL di Azure.

È possibile eseguire processi pianificati su qualsiasi combinazione di database: uno o più database singoli, tutti i database in un server o tutti i database in un pool elastico, con la maggiore flessibilità per includere o escludere qualsiasi database specifico. I processi di lavoro possono essere eseguiti su più server e più pool e possono persino essere eseguiti contro database in abbonamenti diversi. I server e i pool vengono enumerati in modo dinamico in fase di esecuzione, quindi i processi vengono eseguiti su tutti i database esistenti nel gruppo di destinazione al momento dell'esecuzione.

La figura seguente mostra un agente di lavoro che esegue compiti tra diversi tipi di gruppi di destinazione.

Gruppo di destinazione

Un gruppo di destinazione definisce il set di database in cui viene eseguito un passaggio di processo. Un gruppo di destinazione può contenere qualsiasi numero e combinazione dei tipi seguenti:

• Server SQL logico: se si specifica un server, tutti i database presenti nel server al momento dell'esecuzione del processo fanno parte del gruppo. È necessario specificare le credenziali del master database in modo che il gruppo possa essere enumerato e aggiornato prima dell'esecuzione del processo. Per ulteriori informazioni sui server logici, vedere Informazioni sul server logico nel database SQL di Azure e in Azure Synapse Analytics.

• Pool elastico: se si specifica un pool elastico, tutti i database presenti nel pool elastico al momento dell'esecuzione del processo fanno parte del gruppo. Come per un server, è necessario fornire le credenziali del master database in modo che il gruppo possa essere aggiornato prima dell'esecuzione del processo.

• Database singolo: specificare uno o più database singoli da includere nel gruppo.

Suggerimento

Al momento dell'esecuzione del processo, l'enumerazione dinamica rivaluta il set di database nei gruppi di destinazione che includono server o pool. L'enumerazione dinamica assicura che i processi vengano eseguiti in tutti i database esistenti nel server o nel pool al momento dell'esecuzione. La rivalutazione dell'elenco di database in fase di esecuzione è utile per scenari in cui l'appartenenza al pool o al server cambia di frequente.

I pool e i database singoli possono essere inclusi o esclusi dal gruppo. È possibile creare un gruppo di destinazione con qualsiasi combinazione di database. È ad esempio possibile aggiungere un server a un gruppo di destinazione, ma escludere database specifici di un pool elastico o escludere un intero pool.

Un gruppo di destinazione può includere database in più sottoscrizioni e in più aree. Le esecuzioni tra più aree hanno una latenza maggiore rispetto alle esecuzioni nella stessa area.

Gli esempi seguenti illustrano in che modo diverse definizioni di gruppi di destinazione vengono enumerate dinamicamente al momento dell'esecuzione del processo per determinare quali database influire:

• L'esempio 1 mostra un gruppo di destinazione costituito da un elenco di singoli database. Quando una fase del lavoro utilizza questo gruppo di destinazione, l'azione della fase viene eseguita in ciascuno di questi database.

• L'esempio 2 mostra un gruppo di destinazione contenente un server come target. Quando un passaggio del processo usa questo gruppo di destinazione, il server viene enumerato dinamicamente per determinare l'elenco di database attualmente presenti nel server. L'azione della fase del processo viene eseguita in ognuno di questi database.

• L'esempio 3 mostra un gruppo di destinazione simile a quello dell'esempio 2, ma con l'esclusione specifica di un singolo database. L'azione del passaggio del processo non viene eseguita nel database escluso.

• L'esempio 4 mostra un gruppo di destinazione contenente un pool elastico come destinazione. Analogamente all'esempio 2, il pool viene enumerato dinamicamente in fase di esecuzione del processo per determinare l'elenco di database nel pool.

• L'esempio 5 e l'esempio 6 mostrano scenari avanzati in cui server, pool elastici e database possono essere combinati usando regole di inclusione e di esclusione.

Pianificazioni dei lavori scalabili

Le attività elastiche sono prodotti orientati al cloud. Sono progettati per avviarsi anche in caso di un problema temporaneo di disponibilità di rete o servizio al momento della pianificazione. Le pianificazioni elastiche tengono conto dell'orario di inizio e degli intervalli richiesti. Quando si crea una pianificazione dei processi elastici, il processo viene eseguito il prima possibile dopo ogni evento di intervallo pianificato.

Importante

Come procedura consigliata, creare pianificazioni dei processi che iniziano in futuro.

Le pianificazioni dei processi rilevano eventi mancanti. Se si crea una nuova pianificazione di un'attività che inizia nel passato, l'attività viene eseguita immediatamente una volta abilitata. Se un processo è disabilitato o non disponibile, viene eseguito immediatamente dopo che è stato abilitato o reso disponibile.

Ad esempio, è attualmente il 2 gennaio alle 9:00 UTC. Hai programmato un nuovo processo con l'ora di inizio pianificata per stasera, 2 gennaio, alle 10:30 di sera (UTC), da eseguire quotidianamente. Il lavoro viene eseguito alle 10:30 PM (UTC).

Per impedire l'avvio accidentale di un'attività, creare pianificazioni che hanno inizio in una data futura. In un esempio che potrebbe causare l'avvio accidentale di un'attività, si configura una nuova attività da eseguire ogni giorno alle 22:30 UTC. Si disabilita l'attività per una settimana. Quindi, se si abilita il processo alle 8:30 UTC, il processo viene eseguito immediatamente, recuperando l'evento di intervallo perso che dovrebbe essere stato eseguito ieri notte. Dopo l'esecuzione, l'agente del processo non viene eseguito di nuovo fino alla successiva esecuzione pianificata alle 10:30 UTC. Per impedire l'esecuzione alle 8:30 UTC in questo scenario, aggiornare l'orario di inizio del processo programmato all'8 gennaio alle 10:30 UTC e poi abilitare il processo. In alternativa, abilitare il processo ad un orario in cui può essere eseguito immediatamente.

Autenticazione

Scegliere un metodo per tutti gli obiettivi di un agente di lavoro elastico. Ad esempio, per un singolo agente di processo elastico, non è possibile configurare un server di destinazione per l'uso delle credenziali con ambito database e un altro per l'uso dell'autenticazione MICROSOFT Entra ID.

L'agente di processo elastico può connettersi ai server e ai database specificati dal gruppo di destinazione usando due opzioni di autenticazione:

• Usare l'autenticazione di Microsoft Entra (in precedenza Azure Active Directory) con un'identità gestita assegnata dall'utente (UMI).
• Usare credenziali limitate all'ambito del database.

Autenticazione tramite l'identità gestita assegnata dall'utente (UMI)

L'autenticazione di Microsoft Entra tramite l'identità gestita assegnata dall'utente (UMI) è l'opzione consigliata per connettere processi elastici al database SQL di Azure. Con il supporto di Microsoft Entra ID, l'agente di processo si connette ai database di destinazione (database, server, pool elastici) e al database di output usando l'messaggistica unificata.

Facoltativamente, è possibile abilitare l'autenticazione di Microsoft Entra ID nel server logico che contiene il database di processi elastici per l'accesso e l'esecuzione di query su tale database tramite le connessioni Microsoft Entra ID. Tuttavia, l'agente lavori usa l'autenticazione interna basata su certificati per connettersi al database lavori.

È possibile creare una UMI o usarne una esistente e assegnare la stessa UMI a più agenti di processo. Ogni agente di lavoro supporta un solo UMI. Dopo aver assegnato un UMI a un agente processo, l'agente di processo usa questa identità per connettersi ed eseguire processi T-SQL nei database di destinazione. L'agente di lavoro non usa l'autenticazione SQL nei confronti del server o dei database di destinazione.

Il nome UMI deve iniziare con una lettera o un numero e avere una lunghezza compresa tra 3 e 128 caratteri. Può contenere trattini (-) e caratteri di sottolineatura (_).

Per altre informazioni sulla messaggistica unificata nel database SQL di Azure, vedere Identità gestite per Azure SQL, inclusi i passaggi necessari e i vantaggi dell'uso di un'messaggistica unificata come identità del server logico del database SQL di Azure. Per altre informazioni, vedere Autenticazione di Microsoft Entra per SQL di Azure.

Importante

Quando si usa l'autenticazione di Microsoft Entra ID, creare l'utente jobuser da quell'ID Microsoft Entra in ogni database di destinazione. Concedere all'utente le autorizzazioni necessarie per eseguire i processi in ogni database di destinazione.

L'uso di un'identità gestita assegnata dal sistema non è supportata.

Autenticazione mediante credenziali con ambito database

Mentre l'autenticazione di Microsoft Entra (in precedenza Azure Active Directory) è l'opzione consigliata, è possibile configurare i processi in modo da usare le credenziali con ambito database per connettersi ai database specificati dal gruppo di destinazione al momento dell'esecuzione. Prima di ottobre 2023, le credenziali con ambito database erano l'unica opzione di autenticazione.

Se un gruppo di destinazione contiene server o pool, queste credenziali con ambito database si connettono al master database per enumerare i database disponibili.

• Creare le credenziali con ambito database nel database del job.

• Per completare correttamente il processo, tutti i database di destinazione devono avere un account di accesso con autorizzazioni sufficienti (jobuser nel diagramma seguente).

• Le credenziali che crei nei database di destinazione (LOGIN e PASSWORD per masteruser e jobuser, nel diagramma seguente) devono corrispondere con IDENTITY e SECRET nelle credenziali create nel database del processo.

• È possibile riutilizzare le credenziali tra i processi. Le password delle credenziali vengono crittografate e protette da accessi degli utenti che dispongono di autorizzazioni di sola lettura agli oggetti di processo.

L'immagine seguente consente di comprendere come configurare le credenziali del processo appropriate e come l'agente di processi elastici si connette usando le credenziali del database come autenticazione per gli account di accesso e gli utenti nei server e nei database di destinazione.

Nota

Quando si usano credenziali con ambito database, ricordarsi di creare l'utente jobuser per ogni database di destinazione.

Endpoint privati dei processi di lavoro elastici

L'agente di processo elastico supporta endpoint privati dei processi elastici. La creazione di un endpoint privato per i job elastici consente di stabilire un collegamento privato tra il job elastico e il server di destinazione. La funzionalità degli endpoint privati per i processi elastici è diversa dall'Azure Private Link.

La funzionalità dei punti di connessione privati per i processi elastici supporta le connessioni private ai server di destinazione e ai server di output, in modo che l'agente dell'attività possa raggiungerli, anche quando è abilitata l'opzione Nega accesso pubblico. L'uso di endpoint privati è anche una possibile soluzione se si vuole disabilitare l'opzione Consenti ai servizi e alle risorse di Azure di accedere a tale server .

Gli endpoint privati dei processi elastici supportano tutte le opzioni di autenticazione dell'agente di processo elastico.

La funzionalità di endpoint privato di processo elastico consente di scegliere un endpoint privato gestito dal servizio per stabilire una connessione sicura tra l'agente di processo e i relativi server di destinazione e di output. Un endpoint privato gestito dal servizio è un indirizzo IP privato all'interno di una rete virtuale e di una subnet specifiche. Quando si sceglie di usare endpoint privati su uno dei server di destinazione e output dell'agente di processo, Azure crea un endpoint privato gestito direttamente dal servizio. Questo endpoint privato viene quindi usato esclusivamente dall'agente di processo per la connessione e l'esecuzione di processi o per la scrittura dell'output del processo nei database di destinazione e di output.

È possibile creare e permettere endpoint privati per i processi elastici tramite il portale di Azure. I server di destinazione connessi tramite il collegamento privato possono trovarsi ovunque in Azure, anche in aree geografiche e sottoscrizioni diverse. Per abilitare questa comunicazione, è necessario creare un endpoint privato per ogni server di destinazione desiderato e per il server di output del processo.

Per un'esercitazione su come configurare un nuovo endpoint privato per i processi elastici gestito dal servizio, vedere Configurare l'endpoint privato dei processi elastici di Azure SQL.

Requisiti degli endpoint privati dei processi elastici

• Per usare un endpoint privato per i processi elastici, sia l'agente di processo che i database di destinazione devono essere ospitati in Azure (stesse o aree diverse) e nello stesso tipo di cloud (ad esempio, sia nel cloud pubblico che in entrambi i cloud per enti pubblici).

• Il Microsoft.Network provider di risorse deve essere registrato per le sottoscrizioni host dell'agente di processo e dei server di destinazione e di output.

• Azure crea endpoint privati per job elastici per ciascun server di destinazione e di output. È necessario approvarli prima che l'agente di lavori elastici possa usarli. È possibile approvarli tramite il riquadro Rete del server logico o del client preferito. L'agente di processo elastico può quindi raggiungere tutti i database in tale server usando una connessione privata.

• La connessione dall'agente di processi elastici al database dei lavori non usa l'endpoint privato. L'agente di job stesso utilizza un'autenticazione interna basata su certificati per connettersi al proprio database dei job.

  • Se si aggiunge il database dei lavori come membro del gruppo di destinazione, si comporta come un normale target. È necessario configurare un endpoint privato in base alle esigenze.

Autorizzazioni per il database dei processi elastici

Durante la creazione di un agente di processo vengono creati uno schema, delle tabelle e un ruolo denominato jobs_reader nel database dei processi. Il ruolo viene creato con la seguente autorizzazione ed è progettato per fornire agli amministratori un controllo di accesso più preciso per il monitoraggio dei processi. Gli amministratori possono fornire agli utenti la possibilità di monitorare l'esecuzione dei processi aggiungendoli al jobs_reader ruolo nel database del processo.

Nome ruolo	Autorizzazioni per schema jobs	Autorizzazioni per schema jobs_internal
jobs_reader	SELECT	None

Attenzione

Non aggiornare le viste del catalogo interne nel job database, ad esempio jobs.target_group_members. La modifica manuale delle viste del catalogo può danneggiare il database dei processi e provocare un errore. Queste viste sono destinate solo all'esecuzione di query di sola lettura. È possibile usare le stored procedure nel database del processo per aggiungere o eliminare membri e gruppi di destinazione, ad esempio jobs.sp_add_target_group_member.

Considerare le implicazioni di sicurezza prima di concedere un accesso elevato al database dei lavori. Un utente malintenzionato con autorizzazioni per creare o modificare processi potrebbe creare o modificare un processo che usa credenziali archiviate per connettersi a un database sotto il controllo dell'utente malintenzionato. Questa vulnerabilità potrebbe consentire all'utente malintenzionato di determinare la password delle credenziali o eseguire comandi dannosi.

Monitorare lavori elastici

L'agente di processo elastico si integra con Avvisi di Azure per le notifiche sullo stato del processo, semplificando la soluzione per il monitoraggio dello stato e della cronologia dell'esecuzione del processo.

Il portale di Azure include funzionalità aggiuntive per supportare processi elastici e monitoraggio dei processi. Nella pagina Panoramica dell'agente processo elastico vengono visualizzate le esecuzioni dei processi più recenti, come illustrato nello screenshot seguente.

È possibile creare regole di avviso del Monitoraggio di Azure con il portale di Azure, l'interfaccia della riga di comando di Azure, PowerShell e l'API REST. La metrica Processi elastici non riusciti è un buon punto di partenza per monitorare e ricevere avvisi sull'esecuzione dei processi elastici. Inoltre, è possibile scegliere di ricevere un avviso tramite un'azione configurabile, ad esempio SMS o posta elettronica, dalla funzionalità avvisi di Azure. Per ulteriori informazioni, vedere Creare avvisi per il database SQL di Azure nel portale di Azure.

Per un esempio, vedere Creare, configurare e gestire processi elastici.

Output del processo

Il risultato dei passaggi di un processo in ogni database di destinazione viene registrato in dettaglio e l'output dello script può essere acquisito in una tabella specificata. È possibile specificare un database per salvare i dati restituiti da un lavoro.

Storico delle attività

È possibile visualizzare la cronologia di esecuzione dei processi elastici nel database del processo eseguendo una query sulla tabella .jobs.job_executions Un processo di pulizia del sistema elimina la cronologia di esecuzione precedente a 45 giorni. Per rimuovere manualmente la cronologia degli ultimi 45 giorni, eseguire la sp_purge_jobhistory stored procedure nel database dei job.

Stato del lavoro

È possibile monitorare le esecuzioni dei processi elastici nel database dei processi eseguendo una query sulla tabella jobs.job_executions.

Procedure consigliate

Quando si utilizzano processi di database elastici, considerare le seguenti procedure consigliate.

Procedure consigliate per la sicurezza

• Limitare l'utilizzo delle API a utenti attendibili.

• Concedere alle credenziali i privilegi minimi necessari per eseguire una fase di un processo. Per ulteriori informazioni, vedere Autorizzazioni e permessi.

• Quando si usa un membro del gruppo di destinazione del server o del pool, creare credenziali separate con diritti sul master database per visualizzare ed elencare i database. Questa credenziale espande gli elenchi di database dei server e dei pool prima dell'esecuzione del processo.

Prestazioni delle attività elastiche

I processi elastici usano risorse di calcolo minime, in attesa del completamento dei processi di lunga durata.

A seconda delle dimensioni del gruppo di database di destinazione e del tempo di esecuzione desiderato per un processo (numero di processi simultanei), l'agente richiede prestazioni e risorse di calcolo differenti per il database dei processi (maggiore è il numero di destinazioni e di processi, maggiore sarà la quantità di risorse di calcolo necessarie).

Livelli di capacità simultanei

A partire da ottobre 2023, l'agente di lavoro elastico dispone di più livelli di prestazioni per consentire un aumento della capacità.

Gli incrementi di capacità indicano il numero totale di database di destinazione simultanei a cui l'agente di processo può connettersi e avviare un processo. Per ottenere più connessioni di destinazione simultanee per l'esecuzione del processo, è necessario aggiornare il livello dell'agente di processo dal livello predefinito JA100, che ha un limite di 100 connessioni di destinazione simultanee.

La maggior parte degli ambienti richiede meno di 100 processi simultanei in ogni momento, quindi JA100 è l'impostazione predefinita.

Livello agente di lavori scalabile	Numero massimo di compiti simultanei
JA100	100
JA200	200
JA400	400
JA800	800

Il superamento del livello di capacità di concorrenza dell'agente di lavoro con destinazioni di lavoro comporta ritardi nella coda per alcuni database e server di destinazione. Ad esempio, se si avvia un processo con 110 obiettivi nel livello JA100, 10 obiettivi attendono l'avvio fino al completamento degli altri.

È possibile modificare il livello o l'obiettivo di servizio di un agente di processi elastico tramite il portale di Azure, PowerShell o l'API REST degli agenti di processo. Per un esempio, vedere Ridimensionare l'agente di lavoro.

Limitare l'impatto delle attività sui pool elastici

Per assicurarsi che le risorse non vengano sovraccaricate durante l'esecuzione di processi nei database in un pool elastico del database SQL di Azure, configurare i processi per limitare il numero di database in cui viene eseguito un processo contemporaneamente.

Impostare il numero di database simultanei in cui viene eseguito un processo impostando il parametro sp_add_jobstep della stored procedure @max_parallelism in T-SQL.

Script idempotenti

Gli script T-SQL di un processo elastico devono essere idempotenti, ovvero se lo script ha esito positivo e viene eseguito di nuovo, si verifica lo stesso risultato. Uno script potrebbe non andare a buon fine a causa di problemi di rete temporanei. In tal caso, il job ritenta automaticamente l'esecuzione dello script un numero di volte preimpostato prima di desistere. Uno script idempotente ha lo stesso risultato anche se è stato eseguito due volte (o più).

Una semplice strategia consiste nel verificare l'esistenza di un oggetto prima di crearlo. L'esempio seguente è ipotetico:

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.

Analogamente, uno script deve poter essere eseguito correttamente verificando in modo logico e risolvendo qualsiasi condizione trovata.

Limiti

Queste sono le limitazioni attuali del servizio di lavori elastici. Il team del prodotto sta lavorando attivamente per rimuovere il maggior numero possibile di queste limitazioni.

Problema	Descrizione
L'agente di lavoro elastico deve essere ricreato e avviato nella nuova area dopo un failover o dopo essere stato spostato in una nuova area di Azure.	Il servizio di processi elastici archivia tutti gli agenti di processo e i metadati dei processi nel database dei processi. Qualsiasi failover o spostamento delle risorse di Azure in una nuova area di Azure sposta anche il database dei processi, l'agente di processi e i metadati del processo nella nuova area di Azure. Tuttavia, l'agente di processi elastici è una risorsa esclusivamente di calcolo che deve essere ricreata in modo esplicito e avviata nella nuova regione prima che i processi inizino a essere eseguiti di nuovo. Dopo l'avvio, l'agente di lavoro elastico riprende l'esecuzione dei lavori nella nuova area secondo la precedente pianificazione dei lavori.
Log di controllo SQL eccessivi dal database dei job	L'agente di lavori elastici opera eseguendo un polling costante del database dei lavori per controllare l'arrivo di nuovi lavori e altre operazioni CRUD. Se il controllo è abilitato nel server che ospita un database dei processi, il database dei processi può generare un numero elevato di log di controllo. È possibile attenuare questo problema filtrando questi log di controllo usando il Set-AzSqlServerAudit comando con un'espressione di predicato. Ad esempio: 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'" Questo comando filtra solo l'agente di processo per i log di controllo del database dei processi, non l'agente di processo per i log di controllo dei database di destinazione.
Uso di un database Hyperscale come database dei lavori	L'uso di un database Hyperscale come database dei job non è supportato. Tuttavia, i processi elastici possono avere come destinazione i database Hyperscale allo stesso modo di qualsiasi altro database SQL di Azure.
Database senza server con sospensione automatica e attività elastiche.	Il database serverless abilitato per la sospensione automatica non è supportato come database dei processi. I database serverless destinati ai processi elastici supportano la sospensione automatica e le connessioni di processo le riprendono.
Esportare un database di lavoro in un file BACPAC	L'esportazione di un database dei processi in un file BACPAC non è supportata. Se SQL Server contenente un database di processo deve essere esportato, eliminare il database del processo prima di esportare il server.

Passaggio successivo

Esercitazione: Creare, configurare e gestire processi elastici

Contenuto correlato

• Automatizzare le attività di gestione con Azure SQL
• Creare e gestire processi elastici usando PowerShell
• Creare e gestire processi elastici usando T-SQL