Automatizzare le attività del database per la scalabilità

  • 7 minuti

Quando si usa l'automazione da SQL Server, è comune usare SQL Agent per pianificare i processi a scopo di automazione. Anche se Istanza gestita di SQL di Azure e SQL Server in esecuzione in una macchina virtuale di Azure dispongono ancora questa opzione, Azure SQL Database non la supporta. Di conseguenza, potrebbe essere necessario ricorrere a metodi di automazione alternativi per ottenere risultati simili.

Automazione di Azure

Automazione di Azure consente di automatizzare i processi, gestire la configurazione, eseguire un'integrazione completa con le opzioni della piattaforma Azure, ad esempio il controllo degli accessi in base al ruolo e Microsoft Entra ID, e gestire le risorse di Azure e locali.

Con Automazione di Azure è possibile controllare facilmente le risorse sia in Azure che in macchine virtuali locali. Ad esempio, è possibile usare runbook ibridi per automatizzare attività come l'avvio di una macchina virtuale, l'esecuzione di un backup SQL Server e l'arresto della macchina virtuale, rendendo il processo conveniente ed efficiente.

Automazione di Azure viene comunemente usato anche per le operazioni di manutenzione periodica, ad esempio l'eliminazione di dati non aggiornati od obsoleti o la reindicizzazione di un database SQL.

Componenti

Automazione di Azure supporta sia le attività di automazione che di gestione della configurazione. Si esamineranno i componenti di automazione, ma è possibile usare Automazione di Azure anche per gestire gli aggiornamenti del server e le configurazioni.

Componente Descrizione
Runbook I runbook sono l'unità di esecuzione in Automazione di Azure. I runbook possono essere categorizzati in uno dei seguenti tre tipi: un runbook grafico basato su PowerShell, uno script di PowerShell o uno script di Python. I runbook di PowerShell sono usati più di frequente per gestire le risorse di Azure SQL.
Modulo Automazione di Azure definisce un contesto di esecuzione per il codice di PowerShell o Python in esecuzione nel runbook. Per eseguire il codice, è necessario importare i moduli di supporto. Ad esempio, se si deve eseguire il cmdlet di PowerShell Get-AzSqlDatabase, è necessario importare il modulo Az.SQL di PowerShell nell'account di automazione.
credenziali Le credenziali archiviano le informazioni sensibili che possono essere usate da runbook e configurazioni in fase di esecuzione.
Calendario Le pianificazioni sono collegate ai runbook e attivano un runbook in un momento specifico.

Per altre informazioni sull'interfaccia della riga di comando di Azure e sui comandi di PowerShell disponibili per la gestione del database SQL di Azure e delle risorse di Istanza gestita di SQL di Azure, vedere i collegamenti seguenti: modulo PowerShell per SQL di Azure e interfaccia della riga di comando di Azure per Azure SQL.

Lavori elastici

Uno dei motivi per cui molti DBA hanno acquisito familiarità con Automazione di Azure è che il database SQL di Azure inizialmente non aveva funzionalità specifiche per i processi pianificati.

Questa limitazione ha comportato che gli amministratori di database cercassero soluzioni alternative per gestire in modo efficiente queste attività essenziali. Automazione di Azure si è rivelato uno strumento prezioso in questo scenario, offrendo i mezzi per creare e gestire processi pianificati, automatizzare i processi di migrazione del database ed eseguire attività di manutenzione ordinaria.

Architettura

La funzionalità processi elastici consente di eseguire un set di script T-SQL su una raccolta di server o database come processo monouso o usando una pianificazione definita. I processi elastici funzionano in modo simile ai processi di SQL Server Agent, tranne per il fatto che sono limitati all'esecuzione di T-SQL. I processi possono essere usati a tutti i livelli del database SQL di Azure.

Screenshot che mostra il diagramma dell'architettura dei processi elastici.

Per configurare Processi elastici, è necessario avere un agente del processo e un database dedicato alla gestione dei processi. Il livello di servizio consigliato per il database dei processi è S1 o superiore e il livello di servizio ottimale dipende dal numero di processi in esecuzione e dalla frequenza dei processi.

Esaminiamo i componenti dei processi elastici:

  • Agente del processo elastico: la risorsa di Azure per l'esecuzione e la gestione dei processi.
  • Database dei lavori: un database dedicato a gestire i tuoi lavori.
  • Gruppo di destinazione : raccolta di server, pool elastici e database singoli in cui verrà eseguito un processo.
  • Processo: uno o più script T-SQL che costituiscono un passaggio del processo.

Se un server o un pool elastico è la destinazione, è necessario creare delle credenziali nel database master del server o del pool in modo che l'agente processo possa enumerare i database al suo interno. Per un singolo database, sono necessarie solo le credenziali del database. Le credenziali devono disporre dei privilegi minimi necessari per eseguire il passaggio del processo.

Screenshot che mostra la pagina di creazione dell'agente di processi elastici.

È possibile creare un agente del processo elastico usando il portale di Azure. Nella pagina Agente processo elastico assicurarsi di specificare un nome per l'agente e specificare un database SQL per il database dei processi.

Lo script di PowerShell seguente crea un processo elastico denominato MyFirstElasticJob aggiunge un passaggio di processo ed esegue un comando SQL per creare una tabella se non esiste nel database.

Write-Output "Creating a new job..."
$jobName = "MyFirstElasticJob"
$job = $jobAgent | New-AzSqlElasticJob -Name $jobName -RunOnce

Write-Output "Creating job steps for $($jobName) job..."
$sqlText1 = "IF NOT EXISTS (SELECT * FROM sys.tables WHERE object_id = object_id('MyTable')) CREATE TABLE [dbo].[MyTable]([Id] [int] NOT NULL);"

$job | Add-AzSqlElasticJobStep -Name "Step1" -TargetGroupName $serverGroup.TargetGroupName -CredentialName $jobCred.CredentialName -CommandText $sqlText1

Infine, eseguire il processo elastico MyFirstElasticJob.

Write-Output "Start the job..."
$jobExecution = $job | Start-AzSqlElasticJob
$jobExecution

Scenari di casi d'uso

I processi elastici possono essere usati negli scenari seguenti:

  • Automatizzare le attività di gestione da eseguire in una pianificazione specifica.
  • Distribuire le modifiche dello schema.
  • Spostamento dati.
  • Raccogliere e aggregare i dati per la creazione di report o per altri scopi.
  • Caricare dati da archiviazione 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.
  • Elaborazione dei dati su un numero elevato di database, ad esempio la raccolta dei dati di telemetria. I risultati vengono raccolti in una tabella di destinazione singola per ulteriori analisi.

Eseguire la migrazione dei processi di SQL Agent ai processi elastici

Anche se è possibile creare script personalizzati per la migrazione dei processi di SQL Agent a processi elastici, esiste un'alternativa più pratica. È disponibile uno script che può essere scaricato per facilitare la copia dei processi di SQL Agent esistenti nei processi elastici.

Lo script funge da strumento che automatizza la conversione di questi processi, evitando il dispendio di tempo e sforzo che sarebbe altrimenti necessario per ricostruirli manualmente nel nuovo ambiente.

Il file è una cartella compressa che contiene lo script e la documentazione associata. Per usarlo, scaricare il file e seguire le istruzioni.

Dopo aver immesso tutti i parametri elencati nelle istruzioni, verrà visualizzato l'elenco di processi. Lo script creerà quindi ogni processo singolarmente in uno stato disabilitato, presupponendo che non sia già presente. Dopo aver creato un processo, i relativi passaggi vengono inseriti mantenendo gli stessi ID, testo del comando, numero di tentativi e intervallo in secondi tra i tentativi iniziali. Il database collegato al passaggio del processo sarà il gruppo di destinazione. Se il gruppo di destinazione non esiste, verrà creato automaticamente. La copia non include pianificazioni, avvisi e notifiche.

Eseguire la migrazione di processi di SQL Agent a SQL Agent in Azure

La migrazione di processi da un SQL Server locale a Istanza gestita di SQL di Azure o SQL Server in esecuzione nella macchina virtuale segue un procedimento che dovrebbe risultare familiare alla maggior parte degli amministratori di database.

In questo scenario, supponiamo di eseguire la migrazione del SQL Server locale a Istanza gestita di SQL di Azure. È necessario eseguire la migrazione e modificare diversi processi di SQL Agent in modo che funzionino senza problemi nell'ambiente di Azure.

  • Valutare le dipendenze: Identificare il processo di SQL Agent di cui si vuole eseguire la migrazione. Elencare eventuali dipendenze, ad esempio server collegati, credenziali e database, su cui si basa il processo

  • Creare uno script per il processo di SQL Agent: Creare uno script per il processo di SQL Agent in SQL Server come script SQL. A tale scopo, fare clic con il pulsante destro del mouse sul processo in SQL Server Management Studio (SSMS) e scegliere "Script processo come" -> "CREATE in" -> "Nuova finestra dell'Editor di query".

  • Modificare le dipendenze del processo: Esaminare lo script SQL e modificare eventuali dipendenze del processo che potrebbero essere state modificate a causa della migrazione. Ad esempio, se il processo fa riferimento a un server collegato o a un percorso di file nel server locale, è necessario aggiornarlo in modo che corrisponda al nuovo ambiente.

  • Creazione di attività in Azure SQL MI: Aprire SSMS o Azure Data Studio e connettersi alla Azure SQL Managed Instance. Creare un nuovo processo di SQL Agent usando lo script generato in precedenza.

  • Creare dipendenze su Azure SQL MI: Se il processo SQL Agent dipende da server o credenziali collegati, creare tali elementi nell'ambiente di Azure SQL MI. Assicurarsi che corrispondano alla configurazione di SQL Server locale.

  • Pianificare il processo: configurare la pianificazione del processo in Istanza gestita di database SQL di Azure utilizzando SQL Server Agent. È possibile creare una nuova pianificazione e collegarla al processo.

  • Test: testare accuratamente il processo di SQL Agent nell'ambiente di Istanza gestita di database SQL di Azure per assicurarsi che venga eseguito come previsto. Verificare la presenza di eventuali errori o problemi che potrebbero emergere a causa delle differenze tra SQL Server locali e Istanza gestita di database SQL di Azure.

  • Monitoraggio e manutenzione: monitorare le prestazioni del processo e assicurarsi che continui a soddisfare i requisiti nell'ambiente di Istanza gestita di database SQL di Azure. Modificare le configurazioni o le pianificazioni in base alle esigenze.