Eu tive o mesmo problema
eu fiz
SELECT name, log_reuse_wait_desc FROM sys.databases
e me disse que a causa para não esvaziar o registro era REPLICAÇÃO
Eu tentei
sp_removedbreplication youdbname
e isso resolveu
Eu tenho um banco de dados do SQL Server que não é do Mission Critial DB das 9h às 17h que configurei para fazer backups completos noturnos e fazer backups de log a cada 30 minutos durante o horário comercial. O banco de dados está em recuperação total e, normalmente, não tenho motivos para truncar / encolher registros, a menos que eu faça alguma manutenção pesada. Backups de log gerenciam o tamanho sem problemas. No entanto, não estive nesse cliente por várias semanas e, após a inspeção, notei que o log cresceu para cerca de 10 vezes o tamanho do arquivo .mdf. Eu investiguei os backups que estavam sendo executados e não recebi nenhum alerta de erro de gravidade (email do SQL). Eu tentei colocar DB em recuperação simples e encolher o log, isso não era bom. Eu preceder para tentar um backup de log e eu tenho:
The log was not truncated because records at the beginning of the log are pending replication or Change Data Capture. Ensure the Log Reader Agent or capture job is running or use sp_repldone to mark transactions as distributed or captured.
Reinicie o SQL Server e lave a mesma coisa ...
eu disse ??? A replicação não é nem nunca foi configurada neste banco de dados ou banco de dados / servidor ??? Portanto, os backups de log não estão liberando o arquivo .ldf. Então eu fiz algumas horas de pesquisa e encontrei:
parece ser algum tipo de bug mal documentado ??
A solução parece ter sido executar exec sp_repldone, mais precisley
EXEC sp_repldone @xactid = NULL,
@xact_segno = NULL, @numtrans = 0,
@time= 0, @reset = 1
This procedure can be used in emergency situations to allow truncation of the transaction log when transactions pending replication are present. Using this procedure prevents Microsoft SQL Server 2000 from replicating the database until the database is unpublished and republished. ~ MSDN
Quando faço isso, obtenho o seguinte
Msg 18757, Level 16, State 1, Procedure sp_repldone, Line 1 Unable to execute procedure. The database is not published. Execute the procedure in a database that is published for replication.
O que faz sentido porque o banco de dados nunca foi publicado para replicação.
Eu tenho várias perguntas:
A) Em primeiro lugar, a WTF está acontecendo? O que está causando isso, estou interessado em saber o porquê aqui? Isso é genuinley um bug ou há algum aspecto do backup que não está funcionando corretamente que causa o banco de dados para imitar um estado replicado? Alguém por favor edifique-me sobre isso.
B) Segundo ... Eu realmente tenho que publicar / replicar este DB para executar este SP para corrigir isso ??? Parece loucura ou existe algum T-SQL que eu possa colocar em um estado publicado exec o proc e estar no meu caminho ...
C) Em terceiro lugar, se eu realmente tiver que publicar esse banco de dados para executar o SP para liberar esse log desnecessário replicado / pretendido, para recuperar meu arquivo .ldf e o backup. Como faço para publicar o banco de dados sem um host online que está pedindo ??? Eu geralmente não faço esse tipo de administração de banco de dados e preciso de orientação.
Desculpe se isso é muito detalhado, mas apenas expressar a pergunta me ajuda a esclarecer isso ...
Agradecemos antecipadamente por sua ajuda
Eu tive o mesmo problema
eu fiz
SELECT name, log_reuse_wait_desc FROM sys.databases
e me disse que a causa para não esvaziar o registro era REPLICAÇÃO
Eu tentei
sp_removedbreplication youdbname
e isso resolveu
Tivemos esse problema praticamente exatamente. A replicação ainda não está instalada (SQL 2008) ainda em sys.databases, um dos nossos dbs foi de repente e sem motivo que eu possa encontrar, definido como sendo replicado.
Tivemos que fazer coisas horríveis para recuperar o banco de dados porque o arquivo de log cresceu tão rapidamente e (é claro) processos normais para liberar o log não funcionaram.
Foi um pouco antes de perceber que a configuração de replicação era o problema. Até então, o arquivo de log estava cheio. De forma alarmante, mesmo depois que recuperamos o banco de dados, essa configuração de replicação ainda estava definida.
Isso foi o que removeu essa configuração:
EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @ time = 0, @reset = 1
O CDC habilitado para banco de dados, CDC e replicação usa a mesma tecnologia.
1 Executar select DATABASEPROPERTY ('', 'ISPublished') - deve retornar 0
3 DBCC loginfo - Procure por coluna de status com valores 2
DBCC OPENTRAN - Para verificar se há transações de longa duração.
Mesmo que tudo isso não ajude, talvez seja necessário ativar a replicação e e
Verifique se o banco de dados tinha o CDC (change data capture) ou outro tipo de servidor de leitura de log ativado. Isso geralmente pode causar o mesmo problema. Eu tinha um banco de dados de produção com CDC habilitado que copiei para um servidor de desenvolvimento e continuei correndo para esse problema. Eu também tive servidores de produção habilitados para CDC que tinham esse erro quando o trabalho do agente do CDC não tinha sido executado recentemente. A tarefa do agente do CDC normalmente é executada continuamente, mas se falhar, parará e não será iniciada novamente, a menos que você tenha alterado as configurações.
Espero que isso ajude.
Eu tive exatamente esse mesmo problema, encontrei uma solução mais simples:
(observe, isso é no SQL 2k8)
Tags database sql sql-server