none
"The transaction log for database 'base' is full." O que fazer ? RRS feed

  • Pergunta

  • Pessoal,

    Estou realizando um trabalho aonde estou movendo todos os registros antigos das tabelas relacionadas a pedidos de venda e movendo para tabelas com o mesmo nome com final "_archive" . O meu script faz o insert nesta tabela e depois deleta os registros. Segue abaixo trecho do código:

    ALTER DATABASE base SET AUTO_SHRINK ON;
    ALTER DATABASE base SET RECOVERY SIMPLE WITH NO_WAIT;
    
    DECLARE @DATA DATETIME
    DECLARE @DATA2 DATETIME
    
    SET @DATA = dateadd(dd, 0, datediff(dd, 0, dateadd(m, - 12, getdate())))
    
    /* TB_PEDIDOS */
    PRINT('Inserindo registros na TB_PEDIDOS_ARCHIVE')
    -- Busca todos os pedidos anteriores que foram criados a mais de 12 meses e insere na tabela de arquivo.
    insert into TB_PEDIDOS_ARCHIVE
    select *, getdate() as DataHistorico
    from TB_PEDIDOS (nolock)
    where DataCad < @DATA
    
    -- ... 
    
    PRINT('Deletando registros da TB_PEDIDOS')
    delete TB_PEDIDOS
    where DataCad < @DATA
    
    -- ...
    
    ALTER DATABASE base SET AUTO_SHRINK OFF;
    ALTER DATABASE base SET RECOVERY FULL WITH NO_WAIT;

    Porém está ocorrendo o erro:

    (201840 row(s) affected)
    Deletando registros da TB_PEDIDOS
    Msg 9002, Level 17, State 4, Line 122
    The transaction log for database 'base' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases

    Perguntas:

    1. Mesmo alterando o database para recovery model para simple. Porque está ocorrendo este erro ?
    2. Tem mais alguma outra coisa que eu poderia fazer para não encher o transaction log ?
    3. Como o volume de dados é gigantesco, devo utilizar o begin transaction e commit transaction durante toda a execução do job ou isso vai piorar ainda mas a situação ? 

    Valeu.


    Guilherme Costa
    Email: guilerme18@hotmail.com

    Se esta sugestão for útil, por favor, classifique-a como útil.
    Se ela lhe ajudar a resolver o problema, por favor, marque-a como Resposta.

    quarta-feira, 21 de novembro de 2012 17:33

Respostas

  • Guilherme,

    Algumas possibilidades:

    1 - Para que o seu arquivo de log possa ser desconsiderado realize um backup do seu banco de dados para que o atual arquivo de log seja limpo.

    2 - Realize o encolhimento do arquivo de log através do comando DBCC Shrinkfile.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]

    quarta-feira, 21 de novembro de 2012 17:45

Todas as Respostas

  • Guilherme,

    Algumas possibilidades:

    1 - Para que o seu arquivo de log possa ser desconsiderado realize um backup do seu banco de dados para que o atual arquivo de log seja limpo.

    2 - Realize o encolhimento do arquivo de log através do comando DBCC Shrinkfile.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]

    quarta-feira, 21 de novembro de 2012 17:45
  • Amigão, depois de dar o ALTER DATABASE, na linha logo abaixo, insira um "GO", assim já executa esse trecho do código antes de passar aos demais.

    Sobre o item 3 é interessante você commitar caso o seu processo controle a transação, se você não fez assim desde o inicio então não muda nada.

    E por fim eu faria essa migração de uma outra forma, eu renomearia a tabela atual para o _archive, criaria uma nova tabela na mesma estrutura e puxaria somente os dados mais recentes, respeitando a criação das chaves durante o processo. isso caso a quantidade a permanecer fosse menor que a excluir.

    Outra opção seria trabalhar com tabelas particionadas, se o seu problemas for performance esse pode ser uma boa saída.

    quarta-feira, 21 de novembro de 2012 18:19