Creare, configurare e gestire processi elastici (anteprima)

Si applica a: Database SQL di Azure

In questo articolo si apprenderà come creare, configurare e gestire processi elastici.

Se non si sono mai usati processi elastici, vedere altre informazioni sui concetti di automazione dei processi nel database SQL di Azure.

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 database master ed 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 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 semplifica la comprensione e la configurazione delle credenziali di processo corrette. 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 server e/o un membro del gruppo di destinazione del pool, è consigliabile creare una credenziale separata con diritti per il database master per visualizzare/elencare i database, usata per espandere gli elenchi dei 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 I database e i pool elastici destinati ai processi elastici devono avere l'impostazione "Consenti ai servizi e alle risorse di Azure di accedere a questo server" abilitata a livello di server nell'anteprima corrente. Se questa impostazione non è abilitata, l'agente processo elastico non sarà in grado di eseguire processi in tali destinazioni.

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, si ottiene lo stesso risultato. 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 correttamente 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