Por que DBCC SHRINKFILE trabalhar de forma inconsistente em um trabalho banco de dados?

votos
1

DBCC SHRINKFILE sempre funciona quando eu executá-lo manualmente em um arquivo de log, mesmo quando eu recebo a seguinte mensagem:

'Cannot shrink log file 2 (Claim_Log) because all logical log files are in use.'

Quando eu executá-lo a partir de um trabalho, no entanto, ele só encolhe o log cerca de um terço do tempo. As outras vezes, ele simplesmente continua grande (cerca de 150GB). Nunca há qualquer erro diferente do listado acima. Esta é a afirmação de que eu uso:

DBCC SHRINKFILE (N'Claim_log' , 0, TRUNCATEONLY)

Tenho Incluir saída de etapa na história habilitado na etapa de trabalho. Há outra coisa que eu posso fazer para obter mais informações sobre por que isso não está funcionando?

Edit: Aqui está a mensagem completa a partir do log:

'Executed as user: *. Cannot shrink log file 2 (Claim_Log) because all logical
log files are in use. [SQLSTATE 01000] (Message 9008)  DBCC execution completed. 
If DBCC printed error messages, contact your system administrator. [SQLSTATE 01000]
(Message 2528).  The step succeeded.'

Eu já tentei chutar usuários fora do db e defini-lo para o modo de usuário único.

Publicado 09/12/2008 em 17:27
fonte usuário
Em outras línguas...                            


3 respostas

votos
2

Recentemente, resolveu um problema semelhante, eu descobri que em sys.databases, log_reuse_wait_desc foi igual a 'replicação'. Aparentemente, isso significa algo para o efeito do SQL Server à espera de uma tarefa de replicação para terminar antes que ele possa reutilizar o espaço de log.

No entanto replicação nunca tinha sido utilizado em nosso DB nem no nosso servidor. Você deve ser capaz de limpar o estado executando 'sp_removedbreplication'; no entanto para mim 'sp_removedbreplication' não resolveu a questão. Em vez disso SQL apenas retornou dizendo que o banco de dados não foi parte de uma replicação ...

Eu encontrei a minha resposta aqui:

Basicamente eu tive que criar uma replicação, redefinir todos os ponteiros de replicação a zero; em seguida, excluir a replicação eu tinha acabado de fazer. ou seja

Execute SP_ReplicationDbOption {DBName},Publish,true,1
GO
Execute sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1
GO
DBCC ShrinkFile({LogFileName},0)
GO
Execute SP_ReplicationDbOption {DBName},Publish,false,1
GO
Respondeu 06/07/2011 em 05:10
fonte usuário

votos
2

tente emitir o CHECKPOINT comando em primeiro lugar, em seguida, encolhendo os logs

feita a partir de BOL ( http://msdn.microsoft.com/en-us/library/aa226036(SQL.80).aspx )

Forças todas as páginas sujas para o banco de dados atual a ser gravados no disco. páginas sujas são dados ou páginas de registro modificados depois de inseridos no cache de buffer, mas as modificações ainda não foram gravados no disco. Para mais informações sobre truncamento de log, consulte truncar o log de transações.

Respondeu 09/12/2008 em 18:01
fonte usuário

votos
0

Significa Atualmente, o arquivo de log está em uso e ponto de verificação problema onde Check Point escreve para datfile que não foi escrito para o arquivo de dados a partir de arquivos de log de transações (páginas sujas). Verifique há alguma atividade atual está acontecendo ou não,

Verifique usando para Transação Ativo Em 2005 SELECT * DE sys.dm_tran_session_transactions

2000 DBCC loginfo

fazer bom plano => plano de maintenace 1.Criar para fazer backup do log (Plano Feito).

Respondeu 29/08/2009 em 06:18
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more