Reducción del registro de transacciones de una base de datos reflejada de SQL Server 2005

StackOverflow https://stackoverflow.com/questions/1033158

Pregunta

He estado buscando en Internet y no puedo encontrar una solución aceptable para mi problema, me pregunto si incluso hay una solución sin compromiso ...

No soy un DBA, pero soy un equipo de un solo hombre que trabaja en un gran sitio web sin fondos adicionales para cuerpos adicionales, así que estoy haciendo lo mejor que puedo.

Nuestro plan de respaldo apesta, y me está costando mucho mejorarlo. Actualmente, hay dos servidores que ejecutan SQL Server 2005. Tengo una base de datos duplicada (sin testigos) que parece estar funcionando bien. Hago una copia de seguridad completa al mediodía y a la medianoche. Nuestro proveedor de servicios realiza copias de seguridad en cinta todas las noches, y grabo los archivos de copia de seguridad en DVD semanalmente para mantener a mano los registros antiguos. Eventualmente, me gustaría cambiar al envío de registros, ya que la duplicación parece un poco inútil sin un servidor testigo.

El problema es que el registro de transacciones está creciendo sin parar. De la investigación que he hecho, parece que no puedo truncar un archivo de registro de una base de datos reflejada. Entonces, ¿cómo puedo evitar que el archivo crezca?

Basado en esta página web , probé esto: 

USE dbname
GO
CHECKPOINT
GO
BACKUP LOG dbname TO DISK='NULL' WITH NOFORMAT, INIT, NAME = N'dbnameLog Backup', SKIP, NOREWIND, NOUNLOAD
GO
DBCC SHRINKFILE('dbname_Log', 2048)
GO

Pero eso no funcionó. Todo lo demás que encontré dice que necesito deshabilitar el espejo antes de ejecutar el comando de registro de respaldo para que funcione.

Mi pregunta (TL; DR)

¿Cómo puedo reducir mi archivo de registro de transacciones sin desactivar el espejo?

¿Fue útil?

Solución 3

Pensé que debería responder a esto ya que se me olvidó.

Resulta que no puede reducir un t-log si la base de datos está duplicada a menos que desactive la duplicación. Si me equivoco, corrígeme, ¡pero no he encontrado una solución que funcione!

El envío de registros es el camino a seguir si solo tiene dos servidores. La duplicación es casi inútil sin un servidor testigo, porque la única forma de conmutación por error es desde el principal ... un poco derrota el propósito de tener un espejo si no se puede conmutar por error cuando el principal falla.

Si a alguien le interesa compartir más información o sugerencias sobre este asunto, seré bienvenido a escucharlas.

Otros consejos

Bueno, técnicamente es posible reducir un LOG reflejado. Lo que está haciendo problemas es hacer una copia de seguridad del registro con truncate_only. La duplicación no lo acepta. Entonces, una forma es realizar un registro de respaldo en el disco: 

use [DATABASE_NAME]
checkpoint
BACKUP LOG [DATABASE_NAME] TO DISK =  'C:\LOG_BACKUPS\DATABASE_NAME'
dbcc shrinkfile(DATABASE_NAME_Log,1)

Esto es parte de nuestro plan de mantenimiento actual y ha estado funcionando sin problemas durante aproximadamente 2 años.

Si la instancia del servidor espejo se queda atrás de la instancia del servidor principal, la cantidad de espacio de registro activo crecerá. En este caso, es posible que deba detener la creación de reflejo de la base de datos, realizar una copia de seguridad de registro que trunca el registro, aplicar esa copia de seguridad de registro a la base de datos reflejada y reiniciar la creación de reflejo, no la respuesta que esperaba, lo sé = (

Para reducir nuestros archivos, puede probar el siguiente script:

exec sp_dboption DBName, 'trunc. iniciar sesión en chkpt. ', verdadero control DBCC SHRINKFILE (DBNameFileName, 500); exec sp_dboption DBName, 'trunc. iniciar sesión en chkpt. ', falso

Espero que esto ayude.

Es posible reducir el archivo de transacción para una base de datos con espejo, la copia de seguridad debe realizarse ya que hay archivos de registro virtuales activos: http: / /www.xoowiki.com/Article/SQL-Server/tronquer-journal-de-log-sur-base-en-miroir-499.aspx

  1. Desactive el socio espejo usando .. ALTER [DatabaseName] SET PARTNER OFF
  2. Realice una copia de seguridad del registro de transacciones en el principal .. BACKUP LOG [DatabaseName] TO DISK = 'Drive: \ DatabaseName_log_datetime.trn'
  3. Copie este DatabaseName_log_datetime.trn a cualquier ubicación en Mirror Server.
  4. Restaure este registro transaccional con la opción NoRecovery en la base de datos reflejada. RESTORE LOG [DatabaseName] FROM DISK = 'Unidad: \ DatabaseName_log_datetime.trn'
  5. Reducir archivo de registro en principal & amp; servidor espejo.
  6. Nuevamente, realice una copia de seguridad del registro de transacciones en el principal ... y restaure este registro de transacciones con la opción Sin recuperación ... en la base de datos reflejada en el servidor espejo.
  7. Configurar la seguridad de duplicación.

Probé algunas sugerencias en esta publicación, descubrí que, después de la copia de seguridad completa, el comando del punto de control y la copia de seguridad del registro de transacciones, el tamaño del registro de transacciones de la base de datos principal puede reducirse. El tamaño del registro de transacciones de la base de datos espejo se sincroniza con el tamaño principal reducido. 

USE [DATABASE_NAME];
BACKUP DATABASE [DATABASE_NAME] TO DISK='E:\Backup\DATABASE_NAME_FULL.bak' WITH FORMAT;
CHECKPOINT;
WAITFOR DELAY '00:00:02';
BACKUP LOG [DATABASE_NAME] TO DISK = 'E:\Backup\DATABASE_NAME_TL.trn';
WAITFOR DELAY '00:00:02';
DBCC SHRINKFILE('DATABASE_NAME_log', 500);

Use OSQL puede ejecutar los comandos SQL anteriores en lote DOS, el RETARDO WAITFOR es imprescindible si se ejecuta en lote, por ejemplo 

C:\Program Files\Microsoft SQL Server\100\Tools\Binn\osql.exe -E -S "DATABASE_SERVER" -Q "USE [DATABASE_NAME]; BACKUP DATABASE [DATABASE_NAME] TO DISK='E:\Backup\DATABASE_NAME_FULL.bak' WITH FORMAT;"

Creo que la copia de seguridad diferente también debería funcionar, pero no prueba. El siguiente comando de copia de seguridad diff agregará los datos en lugar de sobrescribirlos. 

BACKUP DATABASE [DATABASE_NAME] TO DISK='E:\Backup\DATABASE_NAME_DIFF.bak' WITH DIFFERENTIAL;

la única forma: 1) Deja de duplicar 2) reducir archivos en el principal 3) copia de seguridad completa del principal, + transacción jrnl 4) detener el servidor espejo, eliminar mdf y ldf de mirrorDatabase 5) inicie mirrorser y elimine mirrorDatabase 6) restaurar sin copias de seguridad de recuperación de 3) en mirroServer 7) reinstalar la duplicación ¡Ouf!

Es cierto que no puede reducir el registro de la base de datos una vez que es demasiado grande; en ese momento, creo que su única opción es romper el espejo, reducir y volver a crear. Además, a pesar de los problemas de si ought está usando la duplicación con solo dos servidores, lo que puedo decir es que si lo hace, haga una copia de seguridad del registro de transacciones con regularidad. El espacio se liberará, permitiendo así que MSSQL reutilice el espacio muerto dentro del archivo de registro. Esto no reduce nada, pero cumple con el requisito de detener su crecimiento.

Entonces, todo lo que necesita hacer es eliminar regularmente las copias de seguridad de los archivos. Por ejemplo, podría hacer esto: 

USE your_database
GO
BACKUP LOG your_database TO DISK = 'x:\your_backup_filepath\your_database.tlog'
GO

Hazlo fuera de horario si puedes.

No sé por qué esto funciona, solo que sí funciona. Ejecuto esto como un bloque en una ventana de consulta. Úselo a su propia discreción. Seguro que sería bueno si un microsoftie comentara. 

use my_database
dbcc shrinkfile ( my_database_log, 1000 )
use my_database
dbcc shrinkfile ( my_database_log, 1000 )
alter database my_database
  modify file ( 
    name = my_database_log, 
    size = 1000MB
  )

Realmente no puede hacer nada en una base de datos reflejada sin sacarla del espejo, siempre que no sea la base de datos principal.

Lo que debería funcionar es si hace una copia de seguridad de sus bases de datos en el servidor principal o luego hace una reducción. Es decir, su plan de mantenimiento debe incluir un trabajo reducido. Esos cambios deberían pasar al servidor secundario (espejo) automáticamente mediante la sincronización.

Si desea hacer una reducción que solo reduce el archivo de transacción, puede usar el siguiente T-SQL: 

USE [your_db_name]
GO
DBCC SHRINKFILE (N'your_db_name_logfile' , 0, TRUNCATEONLY)
GO

Luego, simplemente use ese fragmento para cada base de datos y ejecútelo inmediatamente después de que se haya ejecutado su copia de seguridad.

Eso debería mantener el archivo de registro pequeño en el servidor principal y, por lo tanto, en el servidor secundario / espejo.

Espero que esto ayude.

Por cierto. Si ha llegado al punto en el que no queda espacio en el disco para los archivos de registro, la única opción es sacarlo del modo espejo, configurar la base de datos en modo de recuperación simple, reducir el archivo de registro y configurarlo como completo modo de recuperación nuevamente y configure el espejo nuevamente (usando copias de seguridad de la base de datos og archivo de registro para restaurar en el servidor espejo).

Además, puede usar un SQL Express como servidor testigo, si el problema es la licencia. No debería requerir demasiados recursos, por lo que podría usar un servidor web, si se trata de una aplicación web. Solo recuerde mirar los archivos de registro del servidor testigo también.

** la reducción se puede hacer en espejo, lo que no podemos hacer es truncar el registro, ya que el registro es lo que se envía al servidor espejo y luego el principal espera el reconocimiento.

Una solución al problema es hacer una copia de seguridad del registro sin truncar y luego reducir el archivo de registro, o incluso puede ignorar la reducción. Si eso no funciona, intente un punto de control antes de hacer una copia de seguridad de su registro. Esto debería funcionar ...

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top