Prima la piattaforma, poi lo strumento

L’automazione è il dominio in cui la domanda “su quale piattaforma?” decide la risposta prima ancora del “come”. SQL Server Agent è un componente dell’istanza: esiste su SQL Server (macchina virtuale Azure o on-premises) e su Azure SQL Managed Instance, che conserva quasi tutta la superficie di SQL Server. Su Azure SQL Database, PaaS a livello di database, SQL Server Agent non esiste: non c’è un servizio da avviare né un’istanza da amministrare, e qualsiasi opzione che proponga “un job di SQL Server Agent” su un database singolo è sbagliata per costruzione. Su Managed Instance l’Agent c’è ma non è identico a quello di SQL Server: alcuni tipi di step non sono supportati e le notifiche richiedono Database Mail configurato esplicitamente verso un SMTP relay raggiungibile. Sulla VM invece controlli il sistema operativo, quindi l’Agent è quello classico, con la sola responsabilità aggiuntiva di gestirne servizio, patch e account.

Anatomia di un job e troubleshooting

Un job è un contenitore di step eseguiti in sequenza, ciascuno con un tipo (T-SQL, PowerShell, comando del sistema operativo, pacchetto SSIS), un’azione in caso di successo e una in caso di errore, e una politica di retry. Le schedule sono oggetti riusabili e possono essere condivise fra job; gli operator sono i destinatari delle notifiche.

Il punto più interrogato è il contesto di esecuzione. Uno step T-SQL gira per default nel contesto dell’account che possiede il job; uno step non-T-SQL gira sotto l’account di servizio dell’Agent, a meno che non si associ un proxy collegato a una credential con i permessi giusti. Da qui il sintomo classico: il job fallisce da pianificazione ma funziona quando lo lanci a mano, perché a mano usi le tue credenziali. La diagnosi parte sempre dalla job history, che indica quale step è fallito e con quale messaggio; per gli step che producono output conviene scrivere su file o su tabella, perché la history tronca i messaggi lunghi.

Elastic job e le alternative su Azure SQL Database

Su Azure SQL Database la risposta nativa sono gli elastic job. Servono tre oggetti concettuali: l’elastic job agent, risorsa Azure associata a un job database che ne conserva metadati e cronologia; i target group, che definiscono su cosa eseguire (un server intero, un elastic pool, singoli database, con possibilità di esclusioni esplicite); e le credenziali con cui l’agent si connette ai target. Il valore degli elastic job è il fan-out: la stessa istruzione T-SQL su decine o centinaia di database, anche distribuiti su server logici diversi, con esecuzione parallela e retry. Proprio per il retry, lo script deve essere idempotente.

Quando il compito non è T-SQL ma un’operazione di control plane — scalare un service tier a orari fissi, avviare o fermare risorse, orchestrare più servizi — lo strumento è Azure Automation (runbook) o Azure Functions con trigger temporale. Su Managed Instance e su VM, invece, SQL Server Agent resta la scelta naturale anche per manutenzione, backup custom e integrity check.

Alert e notifiche

Su Agent gli alert reagiscono a un numero di errore specifico, a una severità (tipicamente 19 e superiori, che segnalano errori gravi) o a una performance condition, e come risposta possono notificare un operator o eseguire un job. Su Azure SQL Database questo meccanismo non c’è: si usa Azure Monitor, con metric alert sulle metriche della risorsa, log alert sui dati inviati a Log Analytics tramite le diagnostic setting, e activity log alert per gli eventi di piattaforma. La consegna passa sempre dagli action group, che instradano verso email, SMS, webhook, Logic App o runbook. database watcher aggiunge monitoraggio gestito e storico approfondito su Azure SQL.

Trappole tipiche d’esame

  • Stessa procedura di manutenzione su centinaia di database in Azure SQL Database → elastic job: SQL Server Agent non esiste su questa piattaforma e creare uno script per database non scala; un elastic job agent con target group a livello di server copre anche server logici diversi.
  • Job pianificato su Azure SQL Managed Instance → SQL Server Agent: qui la trappola è inversa, l’elastic job è una complicazione inutile perché l’istanza ha già l’Agent.
  • Il job funziona lanciato a mano ma fallisce da pianificazione → permessi del contesto di esecuzione: verifica account di servizio dell’Agent, owner del job e proxy/credential dello step, non la schedule.
  • Serve scalare il service tier o mettere in pausa risorse a orari fissi → Azure Automation o Azure Functions: sono operazioni sul control plane Azure, non T-SQL, quindi l’elastic job non è lo strumento.
  • Email a un team quando compare un errore di severità alta → alert dell’Agent con operator su MI e VM, Azure Monitor con action group su Azure SQL Database: la risposta corretta dipende ancora una volta dalla piattaforma.
  • I database creati in futuro devono essere inclusi automaticamente → target group a livello di server: elencare i database uno per uno costringe a manutenere la lista a ogni provisioning.