INF: Como reduzir o log de transações do SQL Server 7.0

Traduções deste artigo Traduções deste artigo
ID do artigo: 256650 - Exibir os produtos aos quais esse artigo se aplica.
Expandir tudo | Recolher tudo

Neste artigo

Sumário

Há alguns motivos comuns por que um log de transação não pode reduzir ao usar o comando DBCC SHRINKDATABASE ou DBCC SHRINKFILE. Os tópicos SQL Server Books Online "DBCC SHRINKFILE" e "DBCC SHRINKDATABASE" fornecem informações detalhadas, mas segue um breve resumo.

Mais Informações

  • No Microsoft SQL Server 7.0, os comandos SHRINKFILE e SHRINKDATABASE definem um tamanho de destino para reduzindo. Cada arquivo de log é marcado por esses comandos, mas é realmente um backup do log ou o truncamento de log que tenta reduzir os arquivos. Portanto, após você usar o SHRINKFILE ou SHRINKDATABASE comando que você deve também emitir um comando que trunca o log antes de há uma chance de que ele será reduzido.
  • Você não pode reduzir um log para um tamanho menor do que o que é permitido por estes critérios:

    • Para reduzir um log menor do que seu tamanho original, você deve reduzir arquivos individuais com DBCC SHRINKFILE. Não é possível usar DBCC SHRINKDATABASE para reduzir um log para um tamanho menor do que seu tamanho original ou explicitamente definido. O tamanho original é definido como o tamanho do log devido ao criar banco de dados além de qualquer comando ALTER DATABASE explícito. O tamanho original não inclui o crescimento automático do log.

    • O arquivo de log físico nunca pode ser menor do que a quantidade de espaço atualmente usado no arquivo de log. Você pode usar o comando DBCC SQLPERF (LOGSPACE) para monitorar a quantidade de espaço usado.

    • O tamanho atual do log do banco de dados modelo é o tamanho mínimo para log do qualquer banco de dados no servidor. Por padrão, o log do banco de dados modelo é menor do que 1 MB.

    • Porque um log pode ser reduzido somente para um limite de (VLF) do arquivo de log virtual, não é possível reduzir um arquivo de log para um tamanho menor do que um VLF mesmo se o espaço não está sendo usado. Da mesma forma, se uma parte de um VLF estiver em uso não é possível reduzir o espaço em que VLF qualquer. Para obter mais informações, consulte os tópicos "Virtual Log Files" e "Transaction log físico arquitetura" nos manuais online do SQL Server.


  • O log de transações é um log "em volta". Isso significa que em qualquer momento pode haver VLFs com espaço "livre" ou "reutilizáveis" no início, meio e/ou final do log. Para reduzir o log existe deve ser "livre" espaço no final do log, não apenas liberar espaço em qualquer lugar no log. Além disso, você somente pode reduzir VLFs inteiros. Para reduzir a transação log VLFs no final do arquivo de log deve estar inativa e truncado. Para obter informações mais detalhadas, consulte o tópico "Truncar o log de transação" nos manuais online do SQL Server.
Eis algumas coisas em mente:
  • Sempre execute backups de banco de dados de banco de dados e de usuário do sistema antes e depois de fazer alterações que afetam o sistema. DBCC SHRINKFILE e DBCC SHRINKDATABASE não são operações registradas e executá-los mais invalida backups do log de transações. Você deve fazer um backup completo do banco de dados depois de executar o DBCC SHRINKFILE ou o DBCC SHRINKDATABASE comandos.

  • Verifique se não nenhum backup agendado para ocorrer durante o período que de redução deve para ocorrer.

  • Verifique se não nenhum antigas, de longa ou unreplicated transações. Para fazer isso, usar código semelhante ao:
    DBCC OPENTRAN (database_name)
    					
  • Execute o comando DBCC SHRINKDATABASE ou DBCC SHRINKFILE para marcar um shrinkpoint. DBCC SHRINKFILE e DBCC SHRINKDATABASE permissões padrão para membros de sysadmin fixa db_owner ou função de servidor fixo de função de banco de dados e não são transferíveis. Para obter informações sobre as diferenças entre esses comandos, consulte os seguintes tópicos no manuais online do SQL (Observe os parâmetros diferentes):

    DBCC SHRINKFILE     (file_name, target_size)
    DBCC SHRINKDATABASE (database_name, target_percent)
    					
  • Crie alguns transações fictícios para fazer o log seja disposto ao redor e, em seguida, emitir um comando BACKUP para truncar o log. A instrução BACKUP é o que realmente tenta reduzir o log para o tamanho de destino marcada.

    Eis aqui um exemplo de como criar um transações fictício que encapsula o log para um único arquivo de log lógicos e faz com que ele truncar, permitindo a redução. Modifique o exemplo conforme necessário para o seu ambiente.
       SET NOCOUNT ON
       DECLARE @LogicalFileName sysname,
               @MaxMinutes INT,
               @NewSize INT
    
       -- *** MAKE SURE TO CHANGE THE NEXT 4 LINES WITH YOUR CRITERIA. ***
       USE     [Test DB]              -- This is the name of the database
                                      -- for which the log will be shrunk.
       SELECT  @LogicalFileName = 'Test DB 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    = 10       -- 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
    					
    as etapas de verificação para ver se o log foi reduzida de seu original size.Repeat precedente se necessário. Se o log não está reduzindo, novamente o resumo na parte superior do artigo para ver se você estiver encontrando algum dos problemas comuns com reduzindo o log.
Depois que o log reduz:
  1. Execute um backup completo do banco de dados do banco de dados mestre.
  2. Execute um backup completo do banco de dados do banco de dados de usuário. Isso é necessário porque o comando de REDUÇÃO não está conectado e invalida backups de log de transações futuras, a menos que um backup completo do banco de dados é concluído.
Para determinar por que o log está crescendo tão grande em primeiro lugar, você pode verificar transações abertas, transações de longa duração, transações unreplicated ou transações tocam uma grande quantidade de dados.

REFERÊNCIAS

Para obter informações adicionais, clique nos números abaixo para ler os artigos na Base de dados de Conhecimento da Microsoft:
110139INF: Causas de log de transações SQL Filling backup
62866INFO: Motivos por log de transações do SQL não está sendo truncado
66057PROBLEMA: Executando fora do espaço de log ao executar grandes em massa carrega
80629PROBLEMA: Log de transações parcialmente truncado
Manuais online do SQL Server; tópicos: "Transaction log arquitetura física"; "Otimizando o desempenho de log de transações"

Propriedades

ID do artigo: 256650 - Última revisão: terça-feira, 10 de dezembro de 2002 - Revisão: 1.3
A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 7.0 Standard Edition
Palavras-chave: 
kbmt kbinfo kbsqlserv kbsqlserv700 KB256650 KbMtpt
Tradução automática
IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 256650

Submeter comentários

 

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