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 S0 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 le credenziali per l'esecuzione del processo nel database del processo usando PowerShell o T-SQL.

  2. Definire il gruppo di destinazione (i database su 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.

Attualmente, l'anteprima è limitata a 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.

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

Procedure consigliate per la creazione di processi

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