1 02/11/2026 9 min

Quando il database log di SCCM Reporting Services cresce troppo, il problema quasi mai è “solo” lo spazio su disco. Di solito c’è un mix di retention troppo generosa, manutenzione insufficiente, transazioni lunghe e report che interrogano tabelle grandi senza filtri adeguati. La prima mossa sensata non è comprimere o cancellare a caso, ma capire perché il log sta aumentando e quanto rapidamente.

Qui l’obiettivo è ridurre la crescita del log senza introdurre effetti collaterali sul reporting. In pratica: individuare il layer che genera il volume, contenere l’impatto con un’azione minima reversibile, poi consolidare il fix strutturale. Se stai lavorando in produzione, considera il database come un componente sensibile: ogni intervento su recovery model, shrink o manutenzione va trattato con attenzione e con un rollback chiaro.

Capire cosa sta facendo crescere il log

La diagnosi parte dallo stato atteso vs osservato. In condizioni normali, il log del database dovrebbe crescere in modo controllato, con picchi temporanei durante carichi di report o attività di manutenzione, ma senza saturare il file o costringere a espansioni continue. Se invece osservi autogrowth frequenti, VLF frammentati o backup del log inefficaci, il problema è strutturale.

Le cause più probabili, in ordine, sono queste:

  1. Transazioni lunghe o non chiuse, spesso legate a job di maintenance, report pesanti o operazioni batch. Si falsifica in pochi minuti controllando le sessioni attive e le transazioni aperte.
  2. Recovery model e backup del log non allineati. Se il database è in FULL ma i backup del log non girano con regolarità, il file log non può riutilizzare spazio liberato. Si verifica con i job di backup e la history di SQL Server Agent.
  3. Query/report inefficienti che generano grandi quantità di log per temp table, update massivi o scansioni inutili. Si conferma guardando wait, durata delle query e I/O su database e tempdb.

Per avere evidenze rapide, il primo controllo utile è la dimensione del log e il suo stato di riutilizzo. Su SQL Server puoi partire da una vista semplice sullo stato del file:

SELECT DB_NAME(database_id) AS database_name, name, type_desc, size * 8 / 1024 AS size_mb, growth, is_percent_growth
FROM sys.master_files
WHERE DB_NAME(database_id) LIKE '%SCCM%';

Se il log cresce e non si stabilizza, verifica anche lo spazio riutilizzabile dentro il log:

DBCC SQLPERF(LOGSPACE);

La colonna da guardare è la percentuale di utilizzo. Se resta alta anche dopo i backup del log, c’è qualcosa che impedisce il truncation. Per capire il motivo, usa:

SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases
WHERE name LIKE '%SCCM%';

Il campo log_reuse_wait_desc è spesso il primo indizio serio. Se vedi LOG_BACKUP, il backup del log manca o non è valido. Se vedi ACTIVE_TRANSACTION, una transazione lunga sta trattenendo il log. Se compare REPLICATION o simili, il problema è un altro layer e va verificato nel flusso di distribuzione o nei componenti collegati.

Ridurre la crescita senza peggiorare la situazione

La prima azione minima reversibile è quasi sempre verificare e sistemare il ciclo di backup del log, se il database è in modalità FULL. È la correzione più sicura perché non altera il contenuto applicativo e può essere annullata semplicemente ripristinando la vecchia policy di backup, se necessario. Il blast radius è limitato al database interessato, ma l’impatto operativo è diretto: se non fai i backup correttamente, il log continuerà a crescere.

  1. Controlla il recovery model del database di reporting.
  2. Verifica che esista un job di backup del log con frequenza adeguata al carico.
  3. Conferma che i backup siano eseguiti e non falliscano per permessi, spazio o destinazione non raggiungibile.

Se il database è in FULL e non hai un backup del log regolare, puoi creare un job dedicato. L’esempio sotto è volutamente minimale: sostituisci il percorso con una destinazione affidabile e con retention coerente con la tua policy.

BACKUP LOG [NOME_DATABASE]
TO DISK = N'E:\SQLBackups\NOME_DATABASE_Log.trn'
WITH INIT, COMPRESSION, STATS = 10;

Subito dopo il backup, ricontrolla lo stato di riutilizzo:

DBCC SQLPERF(LOGSPACE); SELECT name, log_reuse_wait_desc
FROM sys.databases
WHERE name = 'NOME_DATABASE';

Se il log resta alto nonostante backup validi, il passo successivo è individuare la transazione che lo trattiene. Questo è più utile di qualsiasi shrink, perché ti fa vedere la causa reale invece di spostare il problema più avanti.

DBCC OPENTRAN('NOME_DATABASE');

Se la query restituisce una transazione aperta, devi risalire al processo o al job che la mantiene viva. In ambienti SCCM/SSRS è frequente che un report pesante o una procedura di manutenzione lasci il database in attesa. A quel punto la correzione non è sul file log, ma sulla query o sul job che genera il carico.

Controllare i report pesanti e le query che generano log

In un contesto reporting, il log cresce anche per operazioni apparentemente innocue: query con join ampie, aggregazioni su tabelle grandi, export massivi o refresh di dataset non filtrati. Il segnale tipico è una crescita del log che coincide con finestre di utilizzo intense o con l’esecuzione di report specifici.

Per identificare il collo di bottiglia, osserva le sessioni attive e la durata delle query. Se non hai già strumenti di monitoraggio, almeno una vista delle richieste in esecuzione aiuta a capire se il carico è anomalo:

SELECT r.session_id, r.status, r.command, r.cpu_time, r.total_elapsed_time, r.logical_reads, r.writes, DB_NAME(r.database_id) AS database_name, SUBSTRING(t.text, (r.statement_start_offset/2) + 1, ((CASE r.statement_end_offset WHEN -1 THEN DATALENGTH(t.text) ELSE r.statement_end_offset END - r.statement_start_offset)/2) + 1) AS statement_text
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE DB_NAME(r.database_id) = 'NOME_DATABASE';

Se emergono query con writes elevati o tempi lunghi, il fix va cercato nel report o nel dataset, non nel file log. Le azioni tipiche sono:

  1. Ridurre il set di dati restituito con filtri più stretti.
  2. Rivedere indici e colonne usate nei join e nei filtri.
  3. Spezzare i report troppo grandi in più estrazioni.
  4. Eliminare refresh inutili o schedulazioni sovrapposte.

Se il carico è concentrato su un report SSRS preciso, conviene verificarne il piano di esecuzione e la frequenza. In molti casi il problema è una query che funziona bene in test su pochi dati, ma in produzione produce spill su tempdb e transazioni più lunghe del previsto. Il sintomo non è solo la lentezza del report: è anche il log che si riempie durante l’esecuzione.

Quando ha senso toccare recovery model, shrink o autogrowth

Qui serve prudenza. Cambiare recovery model o fare shrink del log non è la soluzione standard; sono strumenti da usare solo se hai chiaro il motivo e il rollback. Un shrink occasionale può liberare spazio dopo una correzione reale, ma se lo usi per inseguire il problema rischi di frammentare il file e aumentare gli autogrowth futuri.

Se devi intervenire sul recovery model, valuta prima l’impatto sul RPO e sulla strategia di disaster recovery. Passare temporaneamente a SIMPLE può ridurre il log, ma comporta la perdita della catena dei log backup: è una scelta che va fatta solo se accetti il rollback operativo e hai un backup completo recente. Il blast radius è alto rispetto a un semplice job di backup.

Se invece il file log è enorme ma ora è stabile e vuoi solo riportarlo a una dimensione più ragionevole, fai prima una manutenzione ordinata:

  1. Assicurati che i backup del log funzionino.
  2. Verifica che non ci siano transazioni aperte.
  3. Esegui un eventuale shrink solo dopo aver chiuso la causa.
  4. Imposta una dimensione iniziale sensata per evitare autogrowth ripetuti.

Per ridimensionare il log in modo controllato, usa un approccio conservativo. Prima identifica il nome logico del file:

SELECT name, type_desc, physical_name
FROM sys.database_files;

Poi, solo se la situazione è sotto controllo, puoi valutare uno shrink mirato. Questo è un intervento con rischio di frammentazione e di crescita successiva se il sizing non viene corretto. Il rollback, in questo caso, non è “annulla shrink” ma ripristinare un sizing adeguato e monitorare la crescita successiva.

DBCC SHRINKFILE (NOME_FILE_LOG, 4096);

Il valore finale non va scelto a caso: va dimensionato sul picco reale osservato, con un margine ragionevole. Se il log si riempie di nuovo nel giro di poche ore, non hai risolto nulla: hai solo spostato il problema.

Manutenzione corretta per evitare che il log ricresca

La parte strutturale è questa: il log non si “riduce” una volta sola, si governa nel tempo. Se gestisci un database usato da SCCM Reporting Services, la manutenzione dovrebbe includere almeno tre elementi: backup del log coerente, monitoraggio della crescita e controllo delle query/report più costosi.

Una baseline utile è monitorare:

  • dimensione del file log e crescita giornaliera;
  • tempo tra backup del log;
  • log_reuse_wait_desc nei momenti di picco;
  • durata e frequenza dei report più pesanti;
  • spazio libero su disco per evitare autogrowth in emergenza.

Se hai accesso a una soluzione di monitoring, imposta alert su crescita anomala del log e su fallimento dei backup. In assenza di un sistema dedicato, almeno una verifica schedulata di queste due condizioni evita di scoprire il problema quando il database è già in sofferenza.

Un accorgimento spesso trascurato è la dimensione dell’autogrowth. Incrementi percentuali su file già grandi producono salti imprevedibili; meglio un incremento fisso, coerente con la capacità del volume e con il carico reale. Questo riduce frammentazione, evita espansioni troppo piccole e rende più prevedibile il comportamento del database.

Sequenza operativa consigliata in produzione

Se devi intervenire adesso, l’ordine corretto è questo:

  1. Verifica log_reuse_wait_desc e lo stato del recovery model.
  2. Conferma che i backup del log siano eseguiti e validi.
  3. Controlla eventuali transazioni aperte con DBCC OPENTRAN.
  4. Individua le query o i report che stanno trattenendo il log.
  5. Solo dopo la correzione, valuta un resize controllato del file log.

Questo approccio riduce il rischio di fare danni e ti dà una traccia verificabile. Se il problema è nei backup mancanti, la correzione è semplice. Se il problema è una query o un job che resta aperto troppo a lungo, il fix va spostato su applicazione, report o scheduling. Se il problema è solo di sizing, allora puoi ribilanciare il file senza toccare il comportamento del database.

Assunzione operativa: il database è in produzione e va trattato come critico finché non hai prova del contrario; ogni modifica al log richiede backup, verifica e un piano di rollback minimo.

In sintesi, ridurre il database log di SCCM Reporting Services non significa “svuotarlo” e basta. Significa capire cosa lo sta trattenendo, correggere il punto di accumulo e poi stabilizzare la crescita con manutenzione coerente. Se fai solo il passo finale, il problema torna. Se lavori sul ciclo completo, il log smette di essere una sorpresa e diventa un parametro governato.