Automatizzare le attività di gestione usando processi elastici (anteprima)

SI APPLICA A: Database SQL di Azure

È possibile creare e pianificare processi elastici che possono essere eseguiti periodicamente in uno o più database Azure SQL per eseguire query Transact-SQL (T-SQL) ed eseguire attività di manutenzione.

È possibile definire il database o i gruppi di database di destinazione in cui verrà eseguito il processo, nonché le pianificazioni per l'esecuzione. Un processo gestisce l'attività di accesso al database di destinazione. È anche possibile definire, gestire e mantenere script Transact-SQL da eseguire su un gruppo di database.

Ogni processo registra lo stato di esecuzione e ripete automaticamente le operazioni se si verificano errori.

Quando usare i processi elastici

Esistono diversi scenari in cui è possibile usare l'automazione dei processi elastici:

  • Automatizzare le attività di gestione e quindi pianificare l'esecuzione in ogni giorno feriale, fuori orario lavorativo e così via.
    • Distribuire le modifiche dello schema, la gestione delle credenziali, la raccolta dei dati sulle prestazioni o la raccolta dei dati di telemetria del tenant (cliente).
    • Aggiornare i dati di riferimento (ossia le informazioni comuni tra tutti i database) e caricare dati dall'archivio BLOB di Azure.
  • Configurare i processi per l'esecuzione in una raccolta di database su base periodica, ad esempio durante le fasce orarie non di punta.
    • Raccogliere i risultati di query da un set di database in una tabella centrale su base costante. Le query di prestazione possono essere eseguite continuamente e configurate per l'esecuzione di attività aggiuntive di trigger.
  • Raccogliere i dati per i report
    • Aggregare i dati di una raccolta di database in una singola tabella di destinazione.
    • Eseguire query di elaborazione dei dati più lunghe per una vasta serie di database, ad esempio la raccolta della telemetria del cliente. I risultati vengono raccolti in una tabella di destinazione singola per ulteriori analisi.
  • Spostare dati

Automazione in altre piattaforme

Si considerino le tecnologie di pianificazione dei processi seguenti in piattaforme diverse:

  • I processi elastici sono servizi di pianificazione dei processi che eseguono processi personalizzati in uno o più database database SQL di Azure.
  • SQL Agent processi vengono eseguiti dal servizio SQL Agent che continua a essere usato per l'automazione delle attività in SQL Server ed è incluso anche Azure SQL istanze gestite. I processi di SQL Agent non sono disponibili in Database SQL di Azure.

I processi elastici possono essere Azure SQL database, database SQL di Azure pool elasticie Azure SQL database in mappe partizioni.

  • Per l'automazione dei processi di script T-SQL in SQL Server e Istanza gestita di SQL di Azure, prendere in considerazione SQL Agent.

  • Per l'automazione dei processi di script T-SQL in Azure Synapse Analytics, prendere in considerazione le pipelinecon trigger ricorrenti, basati su Azure Data Factory.

È opportuno notare le differenze tra SQL Agent (disponibile in SQL Server e come parte di SQL Istanza gestita) e l'agente processo elastico del database (che può eseguire T-SQL in database o database Azure SQL in SQL Server e Istanza gestita di SQL di Azure, Azure Synapse Analytics).

Processi elastici SQL Agent
Ambito Qualsiasi numero di database di Database SQL di Azure e/o di data warehouse nello stesso cloud di Azure dell'agente di processo. Le destinazioni possono trovarsi in server, sottoscrizioni e/o aree differenti.

I gruppi di destinazione possono essere costituiti da singoli database o data warehouse o da tutti i database in un server, un pool o una mappa partizioni (enumerati dinamicamente in fase di esecuzione del processo).
Qualsiasi database singolo nella stessa istanza di SQL Agent. La funzionalità Amministrazione multi server di SQL Server Agent consente alle istanze master/di destinazione di coordinare l'esecuzione del processo, anche se questa funzionalità non è disponibile nell'istanza gestita di SQL.
API e strumenti supportati Portale, PowerShell, T-SQL, Azure Resource Manager T-SQL, SQL Server Management Studio (SSMS)

Destinazioni dei processi elastici

I processi elastici consentono di eseguire uno o più script T-SQL in parallelo, in un numero elevato di database, in base a una pianificazione o su richiesta.

È possibile eseguire processi pianificati in qualsiasi combinazione di database: uno o più database singoli, tutti i database in un server, tutti i database in un pool elastico o una mappa partizioni, con la maggiore flessibilità per includere o escludere qualsiasi database specifico. I processi possono essere eseguiti in più server, in più pool e anche in database di sottoscrizioni 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.

La figura seguente mostra un agente di processo che esegue processi tra diversi tipi di gruppi di destinazione:

Modello concettuale dell'agente di processo elastico

Componenti dei processi elastici

Componente Descrizione (altri dettagli sono disponibili sotto la tabella)
Agente di processo elastico Risorsa di Azure creata per eseguire e gestire i processi.
Database di processo Un database di Database SQL di Azure usato dall'agente di processo per archiviare dati, definizioni e così via correlati ai processi.
Gruppo di destinazione Il set di server, pool, database e mappe delle partizioni in cui eseguire un processo.
Processo Un processo è un'unità di lavoro costituita da uno o più passaggi. I passaggi del processo specificano lo script T-SQL da eseguire, nonché altri dettagli necessari per eseguirlo.

Agente processo elastico

Un agente di processo elastico è la risorsa di Azure per la creazione, l'esecuzione e la gestione dei processi. L'agente di processo elastico è una risorsa di Azure che viene creata nel portale (sono anche supportati PowerShell e REST).

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

L'agente di processo elastico è gratuito. Il database di processo viene fatturato alla stessa tariffa di qualsiasi database di Database SQL di Azure.

Database dei processi elastici

Il database di processo viene usato per definire i processi e tracciare lo stato e la cronologia delle esecuzioni dei processi. Il database di processo viene anche usato per archiviare metadati dell'agente, log, risultati e definizioni dei processi e contiene anche molte utili stored procedure e altri oggetti del database per creare, eseguire e gestire i processi con T-SQL.

Per l'anteprima corrente, per creare un agente di processo elastico, è necessario un database esistente di Database SQL di Azure (S0 o superiore).

Il database del processo deve essere un obiettivo di servizio pulito, vuoto, S0 o superiore database SQL di Azure. L'obiettivo di servizio consigliato per il database di processo è S1 o superiore, ma la scelta ottimale dipende dalle prestazioni richieste dai processi, ovvero numero di passaggi del processo, numero di obiettivi del processo e frequenza delle esecuzioni.

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 DTU o nel modello vCore) finché le prestazioni del database del processo non sono sufficientemente migliorate.

Autorizzazioni del database dei processi elastici

Durante la creazione di un agente di processo vengono creati uno schema, tabelle e un ruolo denominato jobs_reader nel database di processo. Il ruolo viene creato con l'autorizzazione seguente ed è progettato per fornire agli amministratori un controllo di accesso più preciso per il monitoraggio dei processi:

Nome del ruolo Autorizzazioni per lo schema "jobs" Autorizzazioni per lo schema 'jobs_internal'
jobs_reader SELECT nessuno

Importante

Prima di concedere l'accesso al database di processo come amministratore del database, considerare le implicazioni per la sicurezza. 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, che potrebbe consentire all'utente malintenzionato di determinare la password della credenziale.

Gruppo di destinazione

Un gruppo di destinazione definisce il set di database sui quali verrà eseguito un passaggio di processo. Un gruppo di destinazione può contenere qualsiasi numero e una combinazione degli elementi seguenti:

  • Server logico di SQL Server: se è specificato un server, tutti i database presenti al suo interno al momento dell'esecuzione del processo fanno parte del gruppo. È necessario fornire le credenziali del database master in modo che il gruppo possa essere enumerato e aggiornato prima dell'esecuzione del processo. Per altre informazioni sui server logici, vedere Che cos'èun server in database SQL di Azure e Azure Synapse Analytics? .
  • Pool elastico: se è specificato 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 database master 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.
  • Mappa partizioni: database di una mappa partizioni.

Suggerimento

Al momento dell'esecuzione del processo, l'enumerazione dinamica rivaluta il set dei 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. Rivalutare l'elenco dei database in fase di esecuzione è particolarmente utile per gli scenari in cui l'appartenenza al pool o al server cambia frequentemente.

I pool e i database singoli possono essere specificati come inclusi o esclusi dal gruppo. Ciò consente di 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. Si noti che le esecuzioni tra più aree hanno una latenza maggiore rispetto alle esecuzioni nella stessa area.

Gli esempi seguenti illustrano come diverse definizioni del gruppo destinazione vengono enumerate in modo dinamico al momento dell'esecuzione del processo per determinare i database che verranno eseguiti:

Esempi di gruppi di destinazione

L'esempio 1 mostra un gruppo di destinazione costituito da un elenco di singoli database. Quando un passaggio del processo viene eseguito usando questo gruppo di destinazione, l'azione del passaggio verrà eseguita in ognuno di tali database.
L'esempio 2 mostra un gruppo di destinazione contenente un server. Quando un passaggio del processo viene eseguito usando questo gruppo di destinazione, il server viene enumerato in modo dinamico per determinare l'elenco dei database attualmente presenti nel server. L'azione del passaggio del processo verrà eseguita in ognuno di tali 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 verrà eseguita nel database escluso.
L'esempio 4 mostra un gruppo di destinazione contenente un pool elastico come destinazione. Analogamente all'esempio 2, il pool verrà enumerato in modo dinamico in fase di esecuzione del processo per determinare l'elenco dei database nel pool.

Altri esempi di gruppi di destinazione

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.
L'esempio 7 mostra che in fase di esecuzione del processo possono essere valutate anche le partizioni in una mappa delle partizioni.

Nota

Il database del processo stesso può essere la destinazione di un processo. In questo scenario, il database del processo viene considerato come qualsiasi altro database di destinazione. È necessario aver creato l'utente del processo a cui concedere autorizzazioni sufficienti nel database del processo e nel database del processo devono anche esistere le credenziali con ambito database per l'utente del processo, come per qualsiasi altro database di destinazione.

Processi elastici e passaggi di processo

Un processo è un'unità di lavoro che viene eseguita in una pianificazione o come processo occasionale. Un processo è costituito da uno o più passaggi.

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

Output del processo

Il risultato dei passaggi di un processo in ciascun database di destinazione vengono registrati nei dettagli e l'output dello script può essere acquisito in una tabella specifica. È possibile specificare un database per salvare i dati restituiti da un processo.

Cronologia dei processi

Visualizzare la cronologia di esecuzione del processo elastico nel database del processo tramite query sulla tabella jobs.job_executions. Un processo di pulizia del sistema elimina la cronologia dei processi eseguiti oltre 45 giorni prima. Per rimuovere la cronologia di meno di 45 giorni, chiamare il sp_purge_jobhistory stored procedure nel database del processo.

Stato processo

È possibile monitorare le esecuzioni di processi elastici nel database job tramite query sulla tabella jobs.job_executions.

Prestazioni, capacità e limitazioni degli agenti

I processi elastici usano risorse di calcolo minime in attesa del completamento di 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 di processo: maggiore è il numero di destinazioni e di processi, maggiore sarà la quantità di risorse di calcolo necessarie.

Attualmente, il limite è 100 processi simultanei.

Impedire ai processi di ridurre le prestazioni del database di destinazione

Per garantire che le risorse non siano sovraccariche quando si eseguono processi sul database in un pool elastico SQL, è possibile configurare i processi in modo da limitare il numero di database in cui un processo può essere eseguito contemporaneamente.

Passaggi successivi