Spesso bisogna monitorare l’avanzamento del backup o del restore di un db, con la query sotto è possibile monitorare tutti i processi di tale tipo.

SELECT session_id as SPID, command, a.text AS Query, start_time, percent_complete, dateadd(second,estimated_completion_time/1000, getdate()) as estimated_completion_time
FROM sys.dm_exec_requests r CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) a
WHERE r.command in (‘BACKUP DATABASE’,’RESTORE DATABASE’)

 

La query è inoltre utile se si riceve il messaggio:

Backup and file manipulation operations (such as ALTER DATABASE ADD FILE) on a database must be serialized. Reissue the statement after the current backup or file manipulation operation is completed.

durante le operazioni di manipolazione dei file di un DB. Con tale query è possibile identificare il processo bloccante.

 

Su una installazione SQL 2005, mi è capitato di aver esaurito lo spazio disco, a causa della crescita abnorme del file di log. Ogni tentativo di troncare il log è fallitto, così ho deciso di utilizzare un rimedio estremo: effettuare la detach del DB, poi cancellare il file di log e rimontare il solo file dati, facendo ricreare un nuovo file di log. Putroppo, per, all’atto del rimontaggio, SQL mi ha avvisato che c’erano problemi con il file dati e che era necessario individuare il file di log, purtroppo già cancellato e sovrascritto. In SQL 2000 esiste il comando DBCC REBUILD_LOG(‘MyDatabase’,’C:\MyDatabase.ldf’) che permette di ricreare un file di log nuovo per un dato DB, ma purtroppo in SQL 2005 tale comando è stato rimosso. Dopo vari tentativi di recuperare il file (ovviamente senza passare attraverso una lunga restore del db dainastri di backup), l’unica procedura che ha funzionato è stata:

  1. creare un nuovo db con lo stesso nome del vecchio db;
  2. fermare il server SQL;
  3. sostituire il file dati (mdf) del db creato con il file mdf danneggiato;
  4. riavviare il server SQL;
  5. a questo punto il db risulta dannegiato, eseguire il comando DBCC checkdb con lo switch REPAIR_ALLOW_DATA_LOSS;

A questo punto il db ha ripreso a funzionare senza problemi.