¿Por qué DBCC SHRINKFILE funciona de manera incoherente en un trabajo de base de datos?

votos
1

DBCC SHRINKFILE siempre funciona cuando lo ejecuto manualmente en un archivo de registro, incluso cuando recibo el siguiente mensaje:

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

Cuando lo ejecuto desde un trabajo, sin embargo, solo reduce el registro aproximadamente un tercio del tiempo. Las otras veces, sigue siendo grande (alrededor de 150 Gb). Nunca hay ningún error que no sea el mencionado anteriormente. Esta es la declaración que uso:

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

Tengo Incluir paso de salida en el historial habilitado en el paso de trabajo. ¿Hay algo más que pueda hacer para obtener más información sobre por qué esto no funciona?

Editar: Aquí está el mensaje completo del registro:

'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.'

Ya he intentado expulsar a los usuarios del archivo db y configurarlo en modo de usuario único.

Publicado el 09/12/2008 a las 17:27
fuente por usuario
En otros idiomas...                            


3 respuestas

votos
2

He resuelto recientemente un problema similar, he encontrado que en sys.databases, log_reuse_wait_desc era igual a 'replicación'. Al parecer, esto quiere decir algo en el sentido de SQL Server en espera de una tarea de replicación para terminar antes de que pueda volver a utilizar el espacio de registro.

Sin embargo la replicación nunca había sido utilizado en nuestra base de datos ni en nuestro servidor. Usted debe ser capaz de limpiar el estado ejecutando 'sp_removedbreplication'; Sin embargo para mí 'sp_removedbreplication' no resolvió el problema. En lugar de SQL acaba de regresar diciendo que la base de datos no era parte de una réplica ...

He encontrado mi respuesta aquí:

Básicamente tuve que crear una réplica, restablecer todos los punteros de replicación a cero; a continuación, eliminar la replicación que acababa de hacer. es decir

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
Respondida el 06/07/2011 a las 05:10
fuente por usuario

votos
2

intente emitir el comando CHECKPOINT primero y luego reducir los registros

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

Obliga a escribir en el disco todas las páginas sucias de la base de datos actual. Las páginas sucias son páginas de datos o de registro modificadas después de entrar en la memoria caché del búfer, pero las modificaciones aún no se han escrito en el disco. Para obtener más información sobre el truncamiento de registros, vea Truncar el registro de transacciones.

Respondida el 09/12/2008 a las 18:01
fuente por usuario

votos
0

Medios Actualmente, el archivo de registro está en uso y emitir un punto de verificación donde el punto de verificación escribirá en el archivo de datos que no se escribió en el archivo de datos desde el archivo de registro de transacciones (páginas sucias). Compruebe si hay actividad actual o no,

Comprobar utilizando para Transacción activa En 2005 SELECCIONAR * FROM sys.dm_tran_session_transactions

2000 DBCC LOGINFO

hacer un buen Plan => 1. Crear un plan de mantenimiento Para Hacer una copia de seguridad del registro (Plan Hecho).

Respondida el 29/08/2009 a las 06:18
fuente por usuario

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