INF: Come ridurre il registro transazioni di SQL Server 7.0

Traduzione articoli Traduzione articoli
Identificativo articolo: 256650 - Visualizza i prodotti a cui si riferisce l?articolo.
Questo articolo è stato precedentemente pubblicato con il codice di riferimento I256650
Espandi tutto | Chiudi tutto

In questa pagina

Sommario

Sono diversi i motivi per cui un registro transazioni non risulta ridotto quando si utilizza il comando DBCC SHRINKFILE o DBCC SHRINKDATABASE. Informazioni dettagliate su questi comandi sono riportate nelle sezioni "DBCC SHRINKFILE" e "DBCC SHRINKDATABASE" della documentazione in linea di SQL Server. Di seguito ne viene fornita una breve descrizione.

Informazioni

  • In Microsoft SQL Server 7.0 i comandi SHRINKFILE e SHRINKDATABASE consentono di impostare una dimensione di destinazione per la riduzione. Ciascun file registro viene contrassegnato con questi comandi, tuttavia la riduzione dei file viene in realtà effettuata tramite un backup o un troncamento del registro. Dopo l'uso del comando SHRINKFILE o SHRINKDATABASE è pertanto necessario utilizzare anche un comando che consenta di troncare il registro prima della riduzione.
  • Non è possibile ridurre un registro a una dimensione inferiore a quella consentita dai criteri riportati di seguito:

    • Per ridurre un registro a una dimensione inferiore a quella originale, è necessario ridurre i singoli file con il comando DBCC SHRINKFILE. Non è possibile utilizzare il comando DBCC SHRINKDATABASE per ridurre un registro a una dimensione inferiore a quella originale o a una definita in modo esplicito. Per dimensione originale si intende la dimensione del registro ottenuta dall'esecuzione di CREATE DATABASE nonché da eventuali altri comandi ALTER DATABASE espliciti. La dimensione originale non comprende l'incremento automatico della dimensione del registro.

    • Il file registro fisico non può mai essere inferiore alla quantità di spazio attualmente utilizzata nel file registro. È possibile utilizzare il comando DBCC SQLPERF (LOGSPACE) per monitorare la quantità di spazio utilizzata.

    • La dimensione corrente del registro del database model corrisponde alla dimensione minima per qualsiasi registro di database su tale server. In base all'impostazione predefinita, il registro del database model è inferiore a 1 MB.

    • Poiché i limiti di riduzione di un registro coincidono con quelli dei file virtuali dello stesso tipo, non è possibile ridurre un file registro a dimensioni inferiori rispetto a quelle di un file virtuale dello stesso tipo, anche se lo spazio non è al momento utilizzato. Allo stesso modo, se una parte di un file registro virtuale (VLF) è in uso, non è possibile ridurre file compresi nello spazio di tale VLF. Per ulteriori informazioni, vedere gli argomenti relativi ai file registro virtuali e all'architettura fisica dei registri transazioni nella documentazione in linea di SQL Server.


  • Il registro transazioni è un registro di tipo "wrap-around". Ciò significa che in qualsiasi momento possono esistere file registro virtuali con spazio libero o riutilizzabile all'inizio, al centro e/o alla fine del registro. Per effettuare la riduzione del registro, lo spazio libero deve essere disponibile alla fine del registro e non in un punto qualsiasi. È inoltre possibile ridurre solo file registro virtuali interi. Per ridurre il registro transazioni, i file registro virtuali alla fine del file registro devono essere inattivi e troncati. Per ulteriori informazioni, fare riferimento all'argomento relativo al troncamento e al registro transazioni nella documentazione in linea di SQL Server.
Di seguito sono riportati alcuni consigli.
  • Eseguire sempre il backup del database di sistema e dei database utente prima e dopo aver apportato modifiche che influiscono sul sistema. DBCC SHRINKFILE e DBCC SHRINKDATABASE non sono operazioni registrate, pertanto la relativa esecuzione rende non validi i successivi backup del registro transazioni. È necessario effettuare un backup completo dei database dopo l'esecuzione del comando DBCC SHRINKFILE o DBCC SHRINKDATABASE.

  • Accertarsi che per l'ora in cui è prevista la riduzione non siano pianificati backup.

  • Assicurarsi che non vi siano transazioni vecchie, a lunga esecuzione o non replicate. A tale scopo, utilizzare codice simile a quello riportato di seguito:
    DBCC OPENTRAN (nome_database)
  • Eseguire il comando DBCC SHRINKFILE o DBCC SHRINKDATABASE per contrassegnare un punto di riduzione. In base all'impostazione predefinita, le autorizzazioni per DBCC SHRINKFILE e DBCC SHRINKDATABASE sono in genere assegnate ai membri del ruolo server fisso con privilegi di amministratore oppure al ruolo database fisso db_owner e non sono trasferibili. Per informazioni sulle differenze tra questi comandi, fare riferimento agli argomenti della documentazione in linea di SQL Server riportati di seguito. Si notino i diversi parametri.

    DBCC SHRINKFILE     (nome_file, dimensione_destinazione)
    DBCC SHRINKDATABASE (nome_database, percentuale_destinazione)
  • Creare alcune transazioni fittizie in modo da consentire il "wrap-around" del registro, quindi utilizzare un comando BACKUP per troncarlo. L'istruzione BACKUP è quella che effettivamente prova a ridurre il registro in base alla dimensione di destinazione contrassegnata.

    Di seguito è riportato un esempio relativo alla creazione di una transazione fittizia per il "wrap-around" del registro in un unico file registro logico e che ne provoca il troncamento e la relativa riduzione. Modificare l'esempio come necessario in base al proprio ambiente.
    SET NOCOUNT ON
    DECLARE @LogicalFileName sysname,
            @MaxMinutes INT,
            @NewSize INT
    
    -- *** MAKE SURE TO CHANGE THE NEXT 3 LINES WITH YOUR CRITERIA. ***
    USE     Your_Database_Name              -- This is the name of the database 
    for which the log will be shrunk.
    SELECT  @LogicalFileName = 'Your_log',  -- Use sp_helpfile to identify the logical file name that you want to shrink.
            @MaxMinutes = 10,               -- Limit on time allowed to wrap log.
            @NewSize = 100                  -- in MB
    
    -- Setup / initialize
    DECLARE @OriginalSize int
    SELECT @OriginalSize = size -- in 8K pages
      FROM sysfiles
      WHERE name = @LogicalFileName
    SELECT 'Original Size of ' + db_name() + ' LOG is ' + 
            CONVERT(VARCHAR(30),@OriginalSize) + ' 8K pages or ' + 
            CONVERT(VARCHAR(30),(@OriginalSize*8/1024)) + 'MB'
      FROM sysfiles
      WHERE name = @LogicalFileName
    CREATE TABLE DummyTrans
      (DummyColumn char (8000) not null)
    
    
    -- Wrap log and truncate it.
    DECLARE @Counter   INT,
            @StartTime DATETIME,
            @TruncLog  VARCHAR(255)
    SELECT  @StartTime = GETDATE(),
            @TruncLog = 'BACKUP LOG ' + db_name() + ' WITH TRUNCATE_ONLY'
    -- Try an initial shrink.
    DBCC SHRINKFILE (@LogicalFileName, @NewSize)
    EXEC (@TruncLog)
    -- Wrap the log if necessary.
    WHILE     @MaxMinutes > DATEDIFF (mi, @StartTime, GETDATE()) -- time has not expired
          AND @OriginalSize = (SELECT size FROM sysfiles WHERE name = @LogicalFileName)  -- the log has not shrunk    
          AND (@OriginalSize * 8 /1024) > @NewSize  -- The value passed in for new size is smaller than the current size.
      BEGIN -- Outer loop.
        SELECT @Counter = 0
        WHILE  ((@Counter < @OriginalSize / 16) AND (@Counter < 50000))
          BEGIN -- update
            INSERT DummyTrans VALUES ('Fill Log')  -- Because it is a char field it inserts 8000 bytes.
            DELETE DummyTrans
            SELECT @Counter = @Counter + 1
          END   -- update
        EXEC (@TruncLog)  -- See if a trunc of the log shrinks it.
      END   -- outer loop
    SELECT 'Final Size of ' + db_name() + ' LOG is ' +
            CONVERT(VARCHAR(30),size) + ' 8K pages or ' + 
            CONVERT(VARCHAR(30),(size*8/1024)) + 'MB'
      FROM sysfiles 
      WHERE name = @LogicalFileName
    DROP TABLE DummyTrans
    PRINT '*** Perform a full database backup ***'
    SET NOCOUNT OFF
    Verificare se la dimensione originale del registro è stata ridotta. Ripetere i passaggi precedenti se necessario. Se il registro non è stato ridotto, esaminare il riepilogo delle operazioni nella parte iniziale dell'articolo per verificare la presenza di problemi comuni durante la riduzione del registro.
Dopo la riduzione del registro:
  1. Eseguire un backup completo del database master.
  2. Eseguire un backup completo del database utente. Questa operazione è necessaria in quanto il comando SHRINK non viene registrato e può rendere non validi i successivi backup dei registri transazioni a meno che non venga effettuato un backup completo del database.
Per stabilire la causa dell'incremento della dimensione del registro, è possibile verificare innanzitutto le transazioni aperte, le transazioni a lunga esecuzione, quelle non replicate o che interessano una grande quantità di dati.

RIFERIMENTI

Per ulteriori informazioni, fare clic sui numeri degli articoli della Knowledge Base riportati di seguito (gli articoli con prefisso "Q" contengono informazioni in inglese):
110139 INF: Causes of SQL Transaction Log Filling Up
62866 INFO: Reasons Why SQL Transaction Log Is Not Being Truncated
66057 PRB: Running Out of Log Space When Running Large Bulk Loads
80629 PRB: Transaction Log Partially Truncated
Argomenti della documentazione in linea di SQL Server: "Transaction Log Physical Architecture"; "Optimizing Transaction Log Performance"

Proprietà

Identificativo articolo: 256650 - Ultima modifica: venerdì 13 maggio 2011 - Revisione: 3.0
Le informazioni in questo articolo si applicano a:
Chiavi: 
kbsqlmanagementtools kbinfo kbsqlserv kbsqlserv700 KB256650
LE INFORMAZIONI CONTENUTE NELLA MICROSOFT KNOWLEDGE BASE SONO FORNITE SENZA GARANZIA DI ALCUN TIPO, IMPLICITA OD ESPLICITA, COMPRESA QUELLA RIGUARDO ALLA COMMERCIALIZZAZIONE E/O COMPATIBILITA' IN IMPIEGHI PARTICOLARI. L'UTENTE SI ASSUME L'INTERA RESPONSABILITA' PER L'UTILIZZO DI QUESTE INFORMAZIONI. IN NESSUN CASO MICROSOFT CORPORATION E I SUOI FORNITORI SI RENDONO RESPONSABILI PER DANNI DIRETTI, INDIRETTI O ACCIDENTALI CHE POSSANO PROVOCARE PERDITA DI DENARO O DI DATI, ANCHE SE MICROSOFT O I SUOI FORNITORI FOSSERO STATI AVVISATI. IL DOCUMENTO PUO' ESSERE COPIATO E DISTRIBUITO ALLE SEGUENTI CONDIZIONI: 1) IL TESTO DEVE ESSERE COPIATO INTEGRALMENTE E TUTTE LE PAGINE DEVONO ESSERE INCLUSE. 2) I PROGRAMMI SE PRESENTI, DEVONO ESSERE COPIATI SENZA MODIFICHE, 3) IL DOCUMENTO DEVE ESSERE DISTRIBUITO INTERAMENTE IN OGNI SUA PARTE. 4) IL DOCUMENTO NON PUO' ESSERE DISTRIBUITO A SCOPO DI LUCRO.

Invia suggerimenti

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com