none
File LOG cresciuto a dismisura e non riesco a troncarlo RRS feed

  • Domanda

  • Salve,
    chiedo il vostro aiuto perché non riesco a risolvere un grosso problema. 

    Scenario:

    Installazione SQL Server 2005 Standard Edition
    Database composto da unico file mdf ed unico file log
    Modello di recupero = FULL
    Log Shipping attivo
    Troncamento del log schedulato ogni notte
    Piano di Manutenzione che esegue ogni notte in questa sequenza RINDEX, AGGIORNAMENTO STATISTICHE e BACKUP FULL

    Il file log del DB era da mesi costantemente attestato ad una dimensione di circa 22 Gigabyte. Improvvisamente, la settimana scorsa, ci siamo accorti che il log era salito a 42 Gigabyte. Non conosciamo ancora la causa di tale incremento ma per ora ci siamo concentrati sul tentativo di ridimensionare il file log, tentativo che fin'ora non ha prodotto risultati. 
    Negli ultimi 4 gg. il fle log è ulteriormente cresciuto fino a raggiungere l'assurda dimensione di 100 Gigabyte, non riusciamo a ridimensionarlo nè tanto meno riusciamo a capire il motivo della sua crescita. Siamo riusciti soltanto a rilevare che c'è un considerevole incremento delle dimensioni del log fra prima e dopo i processi di  REINDEX ed AGGIORNAMENTO STATISTICHE.

    I nostri tentativi di ridimensionamento si sono limitati all'esecuzione di istruzioni di DBCC SHRINKFILE. 

    Come si può ben capire non siamo particolarmente esperti in materia di amministrazione di database e quindi chiediamo il vostro aiuto per tamponare questa situazione.

    Grazie in anticipo!



    venerdì 26 novembre 2010 14:48

Risposte

  • Ciao, prima dovete eseguire un FULL backup del database, poi eseguire lo SHRINK.

    avete provato?

    Ciao Diego,

    Con un Full Backup NON otterrà l'effetto desiderato, ma occorre eseguire un BACKUP LOG.

    La maggior parte delle attività di modifica dei dati e metadati (reindex, update statistics, ecc.) viene loggata nel t-log, pertanto è normale che cresca di dimensioni con un recovery model a FULL se non vengono mai eseguiti backup del t-log.

    Se non si ha l'esigenza di recuperare i dati all'ultima transazione in caso di crash ma ci si accontenta dell'ultimo full backup + eventuali differenziali, è possibile configurare a Simple il recovery model, evitando queste "crescite incontrollate", divesamente occorre rivedere le policy di backup :-)

    Ciao!


    Lorenzo Benaglia
    Microsoft MVP - SQL Server
    http://blogs.dotnethell.it/lorenzo
    http://social.microsoft.com/Forums/it-IT/sqlserverit
    • Proposto come risposta Diego Castelli venerdì 26 novembre 2010 15:59
    • Contrassegnato come risposta Anca Popa martedì 30 novembre 2010 14:09
    venerdì 26 novembre 2010 15:54
    Moderatore
  • Vi ringrazio per le info. 

    Siamo riusciti a risolvere eseguendo questo script

    DECLARE @dbn varchar(255)
    DECLARE @dbnl varchar(255)

    USE MyDB

    SET @dbn = DB_NAME()
    SET @dbnl = 'MyDB_Log'
    DBCC SHRINKFILE (@dbnl)
    BACKUP LOG @dbn WITH NO_LOG
    DBCC SHRINKFILE ( @dbnl)
    GO

     

    L'errore che commettevamo era eseguire soltanto l'istruzione DBCC SHRINKFILE (MyDB)

    • Contrassegnato come risposta Anca Popa martedì 30 novembre 2010 14:09
    venerdì 26 novembre 2010 16:13

Tutte le risposte

  • Ciao, prima dovete eseguire un FULL backup del database, poi eseguire lo SHRINK.

    avete provato?


    Diego Castelli - MCSA 2003, MCP ISA 2004, MCTS Forefront. ITA: Questo post è fornito "così com'è". Non conferisce garanzie o diritti di alcun tipo. Ricorda di usare la funzione "segna come risposta" per i post che ti hanno aiutato a risolvere il problema e "deseleziona come risposta" quando le risposte segnate non sono effettivamente utili. Questo è particolarmente utile per altri utenti che leggono il thread, alla ricerca di soluzioni a problemi similari. ENG: This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    venerdì 26 novembre 2010 15:36
  • Ciao, prima dovete eseguire un FULL backup del database, poi eseguire lo SHRINK.

    avete provato?

    Ciao Diego,

    Con un Full Backup NON otterrà l'effetto desiderato, ma occorre eseguire un BACKUP LOG.

    La maggior parte delle attività di modifica dei dati e metadati (reindex, update statistics, ecc.) viene loggata nel t-log, pertanto è normale che cresca di dimensioni con un recovery model a FULL se non vengono mai eseguiti backup del t-log.

    Se non si ha l'esigenza di recuperare i dati all'ultima transazione in caso di crash ma ci si accontenta dell'ultimo full backup + eventuali differenziali, è possibile configurare a Simple il recovery model, evitando queste "crescite incontrollate", divesamente occorre rivedere le policy di backup :-)

    Ciao!


    Lorenzo Benaglia
    Microsoft MVP - SQL Server
    http://blogs.dotnethell.it/lorenzo
    http://social.microsoft.com/Forums/it-IT/sqlserverit
    • Proposto come risposta Diego Castelli venerdì 26 novembre 2010 15:59
    • Contrassegnato come risposta Anca Popa martedì 30 novembre 2010 14:09
    venerdì 26 novembre 2010 15:54
    Moderatore
  • sry per l'errore..

    Diego Castelli - MCSA 2003, MCP ISA 2004, MCTS Forefront. ITA: Questo post è fornito "così com'è". Non conferisce garanzie o diritti di alcun tipo. Ricorda di usare la funzione "segna come risposta" per i post che ti hanno aiutato a risolvere il problema e "deseleziona come risposta" quando le risposte segnate non sono effettivamente utili. Questo è particolarmente utile per altri utenti che leggono il thread, alla ricerca di soluzioni a problemi similari. ENG: This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    venerdì 26 novembre 2010 16:00
  • Vi ringrazio per le info. 

    Siamo riusciti a risolvere eseguendo questo script

    DECLARE @dbn varchar(255)
    DECLARE @dbnl varchar(255)

    USE MyDB

    SET @dbn = DB_NAME()
    SET @dbnl = 'MyDB_Log'
    DBCC SHRINKFILE (@dbnl)
    BACKUP LOG @dbn WITH NO_LOG
    DBCC SHRINKFILE ( @dbnl)
    GO

     

    L'errore che commettevamo era eseguire soltanto l'istruzione DBCC SHRINKFILE (MyDB)

    • Contrassegnato come risposta Anca Popa martedì 30 novembre 2010 14:09
    venerdì 26 novembre 2010 16:13