Creare, configurare e gestire processi elastici (anteprima)

  • Articolo
  • 5 minuti per la lettura

Si applica a: Database SQL di Azure

Questo articolo illustra come creare, configurare e gestire processi elastici.

Se non sono stati usati processi elastici, vedere concetti relativi all'automazione dei processi in Azure SQL Database.

Creare e configurare l'agente

  1. Creare o identificare un database S1 vuoto o superiore. Questo database verrà usato come database di processo durante la creazione dell'agente di processo elastico.

  2. Creare un agente processo elastico nel portale o con PowerShell.

    Creazione dell'agente di processo elastico

Creare, eseguire e gestire i processi

  1. Creare una credenziale per l'esecuzione del processo nel database del processo usando PowerShell o T-SQL.

  2. Definire il gruppo di destinazione (i database in cui si vuole eseguire il processo) usando PowerShell o T-SQL.

  3. Creare una credenziale di agente di processo in ogni database in cui verrà eseguito il processo, aggiungendo l'utente (o il ruolo) a ogni database del gruppo. Per un esempio, vedere l'esercitazione di PowerShell.

  4. Creare un processo usando PowerShell o T-SQL.

  5. Aggiungere passaggi di processo usando PowerShell o T-SQL.

  6. Eseguire un processo usando PowerShell o T-SQL.

  7. Monitorare lo stato di esecuzione del processo usando il portale, PowerShell o T-SQL.

    Portale

Credenziali per l'esecuzione di processi

I processi usano credenziali con ambito database per la connessione ai database specificati dal gruppo di destinazione al momento dell'esecuzione. Se un gruppo di destinazione contiene server o pool, queste credenziali con ambito database vengono usate per connettersi al master database per enumerare i database disponibili.

La configurazione delle credenziali corrette per l'esecuzione di un processo può essere poco chiara, quindi tenere a mente i punti seguenti:

  • Le credenziali con ambito database devono essere create nel database del processo.
  • Per completare correttamente il processo, tutti i database di destinazione devono avere un account di accesso con autorizzazioni sufficienti (jobuser nello schema seguente).
  • Le credenziali create nei database di destinazione (LOGIN e PASSWORD per masteruser e jobuser nel diagramma successivo) devono corrispondere all'identità e al segreto nelle credenziali create nel database del processo.
  • Le credenziali possono essere riutilizzate in tutti i processi e le password delle credenziali vengono crittografate e protette dagli utenti che hanno accesso in sola lettura agli oggetti del processo.

L'immagine seguente è progettata per comprendere la configurazione delle credenziali del processo appropriate. Ricordarsi di creare l'utente in ogni database (tutti i database utente di destinazione) in cui è necessario eseguire il processo.

Credenziali dei processi elastici

Procedure consigliate per la sicurezza

Alcune considerazioni sulle procedure consigliate per l'uso dei processi elastici:

  • Limitare l'utilizzo delle API a utenti attendibili.
  • Le credenziali devono avere i privilegi minimi necessari per eseguire il passaggio del processo. Per altre informazioni, vedere Autorizzazione e autorizzazioni.
  • Quando si usa un membro del gruppo di destinazione del server e/o del pool, è consigliabile creare credenziali separate con diritti per il master database per visualizzare/elencare i database usati per espandere gli elenchi di database dei server e/o dei pool prima dell'esecuzione del processo.

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.

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.

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

Limitazioni note

Si tratta delle limitazioni correnti per il servizio Processi elastici. Stiamo lavorando attivamente per rimuovere il maggior numero possibile di queste limitazioni.

Problema Descrizione
L'agente processo elastico deve essere ricreato e avviato nella nuova area dopo un failover o lo spostamento in una nuova area di Azure. Il servizio Processi elastici archivia tutti i metadati dell'agente processo e del processo 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 dei processi nella nuova area di Azure. Tuttavia, l'agente processo elastico è una risorsa di calcolo e deve essere ricreato in modo esplicito e avviato nella nuova area prima che i processi inizino a essere eseguiti nuovamente nella nuova area. Dopo l'avvio, l'agente processo elastico riprenderà l'esecuzione dei processi nella nuova area in base alla pianificazione dei processi definita in precedenza.
Limite di processi simultanei. Attualmente, l'anteprima è limitata a 100 processi simultanei.
Log di controllo eccessivi dal database dei processi L'agente processo elastico opera eseguendo costantemente il polling del database processo per verificare l'arrivo di nuovi processi e altre operazioni CRUD. Se il controllo è abilitato nel server che ospita un database processi, è possibile che nel database processi venga generata una grande quantità di log di controllo. Questo problema può essere risolto 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 "database_principal_name <> '##MS_JobAccount##'"

Questo comando filtra solo l'agente processi ai log di controllo del database dei processi, non all'agente processo per i log di controllo dei database di destinazione.
Gli endpoint privati non sono supportati Gli agenti di processo elastici non possono attualmente connettersi a database e pool elastici che limitano le connessioni agli endpoint privati.
Uso di un database Hyperscale come database del processo L'uso di un database Hyperscale come database job non è supportato. Tuttavia, i processi elastici possono essere destinati a database Hyperscale nello stesso modo di qualsiasi altro database in Azure SQL Database.
Database serverless e sospensione automatica con processi elastici. Il database serverless abilitato per la sospensione automatica non è supportato come database del processo. I database serverless di destinazione dei processi elastici supportano la sospensione automatica e verranno ripresi dalle connessioni di processo.

Procedure consigliate per la creazione di processi

Quando si utilizzano processi di database elastici, tenere presenti le procedure consigliate seguenti:

Script idempotenti

Gli script T-SQL di un processo devono essere idempotenti. Idempotente significa che se lo script ha esito positivo e viene eseguito di nuovo, lo stesso risultato si verifica. Uno script potrebbe non riuscire a causa di problemi di rete temporanei. In tal caso, il processo ritenterà automaticamente l'esecuzione dello script per un numero di volte predefinito 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. Di seguito è riportato un esempio 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.

Passaggi successivi