1 31/10/2026 9 min

Classificazione dell’intervento: troubleshooting su database e manutenzione controllata

Quando si parla di “pulizia della tabella ETL” in SCOM, il punto non è cancellare righe a caso per far respirare il database, ma capire quale tabella, quale processo ETL e quale effetto collaterale si vuole evitare. In Operations Manager i database coinvolti possono avere ruoli molto diversi: Operational, Data Warehouse, database di staging o tabelle di supporto usate dai report. Una pulizia fatta male può rompere l’ingestion dei dati, alterare i report storici o generare ulteriori blocchi su SQL Server.

Se l’obiettivo è ridurre crescita anomala, sbloccare una coda ETL o rimuovere dati obsoleti, conviene ragionare come in un incidente controllato: prima si osserva, poi si limita il raggio d’azione, infine si interviene con una modifica reversibile. In SCOM il rischio tipico non è solo il tempo di esecuzione della query, ma anche il carico indotto su tempdb, il log di transazione e gli eventuali job schedulati che riprendono a lavorare appena la tabella torna disponibile.

Prima di toccare la tabella: capire dove sta davvero il problema

La prima domanda è semplice: stai intervenendo su una tabella di staging ETL, su una tabella di history o su una tabella che alimenta direttamente report e dashboard? La risposta cambia tutto. Nel dubbio, non partire dalla cancellazione: parti da schema, volume, età dei dati e dipendenze.

Le verifiche minime da fare prima di ogni pulizia sono queste:

  1. Identifica nome esatto del database e della tabella. In SQL Server, anche una differenza tra schemi può cambiare il significato operativo dell’oggetto.
  2. Verifica la dimensione della tabella e la distribuzione delle righe per data, così capisci se la crescita è lineare o esplosiva.
  3. Controlla quali job ETL o stored procedure scrivono o leggono quella tabella, per evitare di cancellare dati ancora in uso.

Per un controllo rapido puoi usare query come queste, adattando nomi database e schema al tuo ambiente:

USE [NomeDatabase];
GO SELECT s.name AS schema_name, t.name AS table_name, p.rows AS row_count
FROM sys.tables t
JOIN sys.schemas s ON t.schema_id = s.schema_id
JOIN sys.partitions p ON t.object_id = p.object_id
WHERE p.index_id IN (0,1) AND t.name = 'NomeTabella';

Se la tabella ha decine o centinaia di milioni di righe, la pulizia va progettata come operazione a batch, non come cancellazione unica. Se invece il problema è un accumulo anomalo di poche migliaia di record, spesso il vero guasto è a monte: job fallito, retry incontrollati o retention configurata male.

Backup, rollback e impatto operativo: la parte che non si salta

Prima di qualsiasi DELETE, serve un punto di ritorno. In SQL Server questo significa almeno una strategia chiara: backup del database, export delle righe che stai per rimuovere oppure, nei casi più delicati, una tabella di appoggio con i dati da archiviare. La scelta dipende dal volume e dal tempo disponibile per il ripristino.

Il principio è semplice: non cancellare senza poter ricostruire. Se la tabella è piccola, puoi esportare i record interessati in una tabella parallela. Se la tabella è grande, conviene spesso fare un backup logico delle righe da eliminare e conservare lo script di ripristino. In ambienti di produzione, questo è più importante del “fare in fretta”.

Un esempio di approccio prudente è questo:

-- Esempio: copia preventiva delle righe da rimuovere
SELECT *
INTO dbo.NomeTabella_Etl_Archive_20261031
FROM dbo.NomeTabella
WHERE DataColonna < DATEADD(day, -30, GETDATE());

Questa soluzione ha un blast radius limitato, ma va valutata con attenzione: può richiedere spazio aggiuntivo significativo e, su tabelle molto grandi, può generare I/O pesante. Il rollback è chiaro: se la pulizia non è corretta, ripristini i dati dall’archivio creato prima dell’intervento.

Strategia consigliata: pulizia a batch, non cancellazione massiva

Su SQL Server, una cancellazione massiva su tabelle grandi è spesso la scelta peggiore: blocca, frammenta, cresce il log e può degradare il resto dell’istanza. La strada più robusta è una pulizia a batch, con commit progressivi e monitoraggio tra un ciclo e l’altro.

La logica è questa: si eliminano piccoli gruppi di righe, si verifica l’effetto su lock, log e tempi, poi si continua solo se il comportamento resta accettabile. Questo riduce il rischio di saturare il transaction log e limita la durata dei lock esclusivi.

Un pattern pratico:

SET NOCOUNT ON;
DECLARE @BatchSize int = 5000;
DECLARE @Rows int = 1; WHILE @Rows > 0
BEGIN DELETE TOP (@BatchSize) FROM dbo.NomeTabella WHERE DataColonna < DATEADD(day, -30, GETDATE()); SET @Rows = @@ROWCOUNT; WAITFOR DELAY '00:00:02';
END

Questo esempio è intenzionalmente conservativo: batch piccoli e pausa tra i cicli. In ambienti con carico alto, la pausa può fare la differenza tra un intervento quasi invisibile e un picco di contesa. Se il volume è enorme, si può ridurre la dimensione del batch o eseguire l’operazione in finestre orarie meno critiche.

Se la tabella ha una chiave temporale ben indicizzata, la DELETE a batch lavora meglio. Se non c’è indice sulla colonna usata nel filtro, la query può diventare costosa. In quel caso la vera correzione non è solo pulire, ma anche ottimizzare il supporto all’operazione.

Indici, frammentazione e statistiche: cosa controllare dopo la pulizia

La pulizia di una tabella ETL non finisce con la DELETE. Dopo l’intervento, la struttura fisica della tabella può essere peggiore di prima: pagine vuote, frammentazione, statistiche non aggiornate e piani di esecuzione meno efficienti. Su tabelle molto usate, questo si traduce in query più lente proprio nel momento in cui il sistema dovrebbe tornare stabile.

Le verifiche utili sono tre:

  1. Controlla la frammentazione degli indici principali.
  2. Aggiorna le statistiche se il volume di righe è cambiato in modo sostanziale.
  3. Valuta se serve rebuild o reorganize, in base alla dimensione e alla pressione sull’istanza.

Per avere un quadro rapido degli indici puoi usare una query di diagnostica come questa:

SELECT i.name AS index_name, ips.avg_fragmentation_in_percent, ips.page_count
FROM sys.dm_db_index_physical_stats(DB_ID(), OBJECT_ID('dbo.NomeTabella'), NULL, NULL, 'LIMITED') ips
JOIN sys.indexes i ON ips.object_id = i.object_id AND ips.index_id = i.index_id
WHERE i.index_id > 0;

Se la tabella è piccola, il costo dell’ottimizzazione può essere trascurabile. Se invece è grande, ogni operazione di manutenzione va fatta con prudenza perché può generare I/O e blocchi aggiuntivi. Anche in questo caso, il rollback non è tanto “annulla”, quanto “ripristina da backup o architettura di archiviazione se l’intervento ha peggiorato i tempi o rotto il flusso ETL”.

SCOM e dipendenze ETL: dove si rompe davvero la catena

In un contesto SCOM, il dato non vive mai da solo. La tabella ETL può essere alimentata da job SQL Agent, da stored procedure, da servizi di raccolta o da componenti che popolano il Data Warehouse. Se cancelli righe “vecchie” senza verificare il ciclo di vita del dato, puoi compromettere i report, i trend storici o le elaborazioni pianificate.

La cosa giusta da fare è ricostruire il flusso: da dove arriva il dato, quando viene letto, chi lo archivia e quale retention è prevista. Se la retention è configurata male, la pulizia manuale è solo una toppa. Se invece la tabella sta esplodendo per dati duplicati o retry, bisogna capire perché il processo li sta generando.

In pratica, prima di intervenire sul contenuto, controlla questi punti:

  • Job SQL Agent correlati e loro ultimo esito.
  • Stored procedure o package che scrivono sulla tabella.
  • Eventuali code di elaborazione o retry che reinseriscono gli stessi record.
  • Retention e purge già previste dalla piattaforma o dalla personalizzazione locale.

Se non sai quale componente scrive la tabella, fermarti è la scelta corretta. In assenza di questa informazione, qualsiasi pulizia rischia di essere temporanea: il problema si ripresenterà al giro successivo del job.

Un flusso operativo sensato per la manutenzione

Un intervento ben fatto segue quasi sempre questa sequenza:

  1. Misura lo stato iniziale: numero righe, dimensione tabella, uso log, tempi del job ETL.
  2. Esporta o archivia i record che stai per eliminare.
  3. Esegui la pulizia a batch con pause e monitoraggio.
  4. Verifica i risultati: conteggio righe, esiti job, tempi di esecuzione, frammentazione.
  5. Se necessario, applica manutenzione sugli indici e aggiorna statistiche.

Per monitorare gli effetti, non basta guardare che la DELETE termini. Serve verificare almeno tre segnali: il job ETL riparte correttamente, il database non mostra saturazione del log e le query che leggono quella tabella non peggiorano in modo evidente. Se uno di questi tre segnali va male, conviene fermarsi e tornare al punto di rollback.

In un contesto produttivo, la metrica giusta non è “quante righe ho tolto”, ma quanto è migliorata la stabilità del flusso. Se la tabella si svuota ma il processo a monte continua a rigenerarla in poche ore, hai solo spostato il problema più avanti.

Errori comuni da evitare

Il primo errore è cancellare senza filtro temporale o senza una chiara regola di retention. Il secondo è usare una query enorme in un’unica transazione, sperando che SQL Server “regga”. Il terzo è non considerare il costo del log e dei lock. Il quarto, molto frequente, è non verificare che la tabella sia davvero quella giusta: in ambienti complessi, nomi simili producono incidenti molto concreti.

Un altro errore sottovalutato è ignorare il piano di ripristino. Se qualcosa va storto, non devi improvvisare: devi sapere se recuperi da backup, da tabella di archivio o da export preventivo. Senza questo, ogni pulizia è un salto nel buio.

Infine, non assumere che la manutenzione dell’indice risolva tutto. Se la causa è un processo ETL difettoso, o un job che duplica record, la manutenzione del database è solo una parte della correzione. La vera soluzione sta nel rimuovere la causa, non solo il sintomo.

Assunzioni operative

Assunzioni: ambiente SQL Server in produzione, tabella ETL identificata con certezza, disponibilità di finestra di manutenzione e possibilità di fare backup o archiviazione preventiva prima della pulizia.

Se mancano il nome esatto della tabella, il database coinvolto o la regola di retention, il passo corretto non è improvvisare la DELETE: è raccogliere questi dati dal job ETL, dallo schema del database o dalla configurazione dell’applicazione che alimenta SCOM.