Ciao Sorintiani!

Sono di nuovo io, Leonardo Ludovico Ponnamperumage, Database Administrator dei Sircle DB.X e di Intesa Fideuram Roma.

Negli ultimi anni stiamo assistendo a una trasformazione importante nel nostro modo di lavorare. L'Intelligenza Artificiale non rappresenta soltanto una nuova tecnologia da studiare, ma uno strumento concreto che può supportarci nelle attività di tutti i giorni, soprattutto in contesti operativi complessi come quello della Database Administration.

Questo articolo nasce a partire da un estratto del sondaggio “Storie di Successo” di Sorint.lab e da un successivo confronto sul tema delle competenze necessarie all’interno dei team. In particolare, la discussione ha portato a riflettere su cosa contraddistingua realmente un profilo Junior da un profilo Senior e su come sviluppare e formare i nuovi profili/professionisti del team, anche alla luce dell’evoluzione introdotta dall’Intelligenza Artificiale.

È proprio da questa prospettiva che nasce il percorso raccontato nelle pagine successive: non “usare l’AI per fare il lavoro del DBA”, ma utilizzare l’AI per trasformare attività ripetitive e frammentate in un processo più strutturato, verificabile e scalabile.

L'obiettivo è raccontare come l'integrazione a 360 gradi degli strumenti dell'ecosistema Google Workspace (Gemini, Docs, Sheets, Gmail, Drive ecc...) uniti all'Intelligenza Artificiale generativa possa rivoluzionare il lavoro quotidiano del Database Administrator. Non si tratta di una trattazione teorica, ma di un racconto operativo sul campo per mostrare come l'automazione possa diventare un alleato strategico nell'infrastruttura Enterprise.

Chi lavora quotidianamente con database enterprise sa bene che il nostro lavoro non consiste solamente nell'eseguire query o monitorare sistemi, ma richiede una continua attività di analisi, verifica, documentazione e gestione operativa su ambienti eterogenei. Nel mio caso, mi trovo spesso a operare contemporaneamente su diverse tecnologie — SQL Server, Oracle, PostgreSQL, Redis, MongoDB, Cassandra e DB2 — ciascuna con caratteristiche, procedure e modalità operative differenti.

Proprio questa eterogeneità rappresentava una delle principali sfide. Molte attività richiedevano ancora un elevato grado di manualità: dall'analisi dei ticket alla verifica di backup e repliche, fino alla produzione di documentazione tecnica e checklist operative. Si tratta di operazioni fondamentali per garantire la stabilità dei sistemi, ma che possono diventare molto dispendiose in termini di tempo, soprattutto quando si lavora con SLA stringenti e attività time-sensitive.

Un altro aspetto critico era la standardizzazione. Ogni collega possiede il proprio approccio e il proprio metodo di lavoro, ma mantenere procedure uniformi tra ambienti differenti non è sempre immediato. Questo può generare inconsistenze operative, duplicazione degli sforzi e una maggiore probabilità di errore nelle attività ripetitive.

Leggendo recentemente la storia di una collega sulla Quality Assurance Automation, ho ritrovato un parallelismo profondo con la nostra operatività infrastrutturale. Raccontava la frustrazione iniziale di navigare a vista su un'applicazione priva di documentazione, e di come l'IA le abbia permesso di compiere un salto di qualità: non una "scatola nera" che sostituisce lo specialista, ma uno strumento per passare dal lavoro manuale estenuante a una metodologia strutturata, restituendole il tempo strategico.

Nel mondo dei database il percorso è identico. Per questo motivo ho iniziato a integrare gli strumenti di Google Workspace con il supporto dell'Intelligenza Artificiale all'interno delle attività quotidiane di Database Administration. L'obiettivo non era sostituire il lavoro del DBA, bensì automatizzare le attività a basso valore aggiunto per concentrarci su ciò che conta davvero: analizzare, progettare, migliorare e innovare.

Dal Ticket alla Query: l'IA e Workspace come Copiloti Diagnostici in SQL Server

Nel quotidiano dell'amministrazione di Microsoft SQL Server, una delle trappole più comuni è la gestione superficiale delle segnalazioni del Service Desk. Un ticket tipico arriva quasi sempre impoverito del contesto tecnico:

"L'applicativo è in timeout, la risposta del DB_FINANCE_PROD è lentissima o bloccata, verificate le sessioni."

L'errore metodologico consiste nel chiedere subito all'IA "Come risolvo i timeout su SQL Server?". Un DBA Senior utilizza invece l'IA e Google Workspace per strutturare la fase di triage: prende il testo esteso del ticket, lo stack trace o le righe dell'Event Viewer, e fa estrarre all'IA i parametri chiave (Istanza, Database, Timestamp, Codice Errore nativo e SPID impattati), organizzando poi i dati su Google Sheets per tracciare la reportistica e individuare pattern di errore ricorrenti.

Il riferimento supremo per la sintassi e la sicurezza restano sempre i manuali ufficiali Microsoft. L'IA agisce da catalizzatore per assemblare rapidamente lo script diagnostico necessario senza introdurre lock concorrenti sulle tabelle di sistema.

Caso Reale: Incident Management su Transaction Log Saturo e SPID Bloccati

Consideriamo uno scenario critico reale: il volume dischi riservato ai file .ldf di un database SQL Server in FULL Recovery Model raggiunge il 99% di occupazione.

Un approccio ingenuo spingerebbe a chiedere all'IA lo script per eseguire un DBCC SHRINKFILE. In produzione, fare uno shrink su un log saturo senza capire perché non stia eseguendo la truncation significa spezzare la log chain dei backup o causare una ri-espansione immediata con forte frammentazione del filesystem.

L'interazione avanzata consiste nel farsi generare una sequenza di indagine multi-livello per isolare la causa radice:

Attraverso questo approccio, il DBA legge l'output della diagnostica guidata:

1. Se log_reuse_wait_desc restituisce LOG_BACKUP, la causa radice è il fallimento del job di backup del log transazionale. L'azione corretta è l'immediata esecuzione di un backup del log per consentire la truncation.
2. Se restituisce ACTIVE_TRANSACTION, lo script mostra esattamente lo session_id (SPID) che ha aperto una transazione senza eseguire il COMMIT o il ROLLBACK, identificando la query applicativa responsabile del blocco prima di prendere qualsiasi decisione invasiva.

Il Caso Operativo: Quando l'AI Suggerisce la Scorciatoia Pericolosa (KILLED/ROLLBACK)

Durante una release applicativa notturna sul database DB_FINANCE_PROD, un job di manutenzione batch è andato in collisione con una transazione di aggiornamento massivo. Di fronte al blocco della tabella principale, il primo suggerimento generato dall'AI è stato immediato: KILL <SPID>.

Un DBA Senior sa che eseguire un KILL spietato su una sessione che ha già modificato milioni di righe senza analizzare lo stato del processo è un rischio enorme. Eseguendo il comando senza verifiche, la sessione entra immediatamente nello stato d'attesa KILLED/ROLLBACK: SQL Server è costretto ad annullare a ritroso ogni singola operazione, occupando il 100% delle risorse di I/O del disco e bloccando l'istanza per ore.

In questo contesto, l'approccio corretto — che l'AI non aveva considerato — è stato quello di analizzare preventivamente la percentuale di avanzamento del rollback tramite la DMV di sistema:

Grazie a questa verifica, si è evitato il crash dell'istanza, gestendo il ripristino in modo controllato.

L'IA ha velocizzato la scrittura delle join tra le Dynamic Management Views (sys.dm_tran_active_transactions e sys.dm_exec_requests), ma la decisione strategica sul da farsi rimane saldamente nelle mani del DBA.

L'amministrazione dei database in ambienti mission-critical insegna una lezione fondamentale, spesso imparata a proprie spese: non si lancia mai in produzione un comando suggerito dall'AI senza averne prima verificato la sintassi, l'impatto sui lock e la compatibilità con la versione specifica del motore. L'AI propone, la documentazione ufficiale certifica, il DBA decide ed esegue.

Continua nella parte 2...