sql >> Base de Datos >  >> RDS >> Sqlserver

¿Cómo se borra el registro de transacciones de SQL Server?

Hacer que un archivo de registro sea más pequeño realmente debería reservarse para escenarios en los que se encontró con un crecimiento inesperado que no espera que vuelva a suceder. Si el archivo de registro vuelve a crecer al mismo tamaño, no se logra mucho al reducirlo temporalmente. Ahora, dependiendo de los objetivos de recuperación de su base de datos, estas son las acciones que debe realizar.

Primero, haz una copia de seguridad completa

Nunca realice cambios en su base de datos sin asegurarse de que puede restaurarla en caso de que algo salga mal.

Si le importa la recuperación puntual

(Y por recuperación de un punto en el tiempo, me refiero a que le importa poder restaurar cualquier cosa que no sea una copia de seguridad completa o diferencial).

Presumiblemente, su base de datos está FULL modo de recuperación. Si no es así, asegúrese de que sea:

ALTER DATABASE testdb SET RECOVERY FULL;

Incluso si realiza copias de seguridad completas periódicas, el archivo de registro crecerá y crecerá hasta que realice un registro. copia de seguridad - esto es para su protección, no para consumir innecesariamente su espacio en disco. Debería realizar estas copias de seguridad de registros con bastante frecuencia, de acuerdo con sus objetivos de recuperación. Por ejemplo, si tiene una regla comercial que establece que no puede permitirse perder más de 15 minutos de datos en caso de desastre, debe tener un trabajo que respalde el registro cada 15 minutos. Aquí hay una secuencia de comandos que generará nombres de archivo con marca de tiempo en función de la hora actual (pero también puede hacer esto con planes de mantenimiento, etc., simplemente no elija ninguna de las opciones de reducción en los planes de mantenimiento, son horribles).

DECLARE @path NVARCHAR(255) = N'\\backup_share\log\testdb_' 
  + CONVERT(CHAR(8), GETDATE(), 112) + '_'
  + REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
  + '.trn';

BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;

Tenga en cuenta que \\backup_share\ debe estar en una máquina diferente que represente un dispositivo de almacenamiento subyacente diferente. Hacer una copia de seguridad de estos en la misma máquina (o en una máquina diferente que use los mismos discos subyacentes, o en una VM diferente que esté en el mismo host físico) no es de gran ayuda, ya que si la máquina explota, habrá perdido su base de datos. y sus copias de seguridad. Dependiendo de la infraestructura de su red, puede tener más sentido hacer copias de seguridad localmente y luego transferirlas a una ubicación diferente en segundo plano; en cualquier caso, desea sacarlos de la máquina de la base de datos principal lo más rápido posible.

Ahora, una vez que tenga copias de seguridad de registros regulares ejecutándose, debería ser razonable reducir el archivo de registro a algo más razonable que lo que sea que haya explotado ahora. Esto no significa ejecutar SHRINKFILE una y otra vez hasta que el archivo de registro ocupe 1 MB; incluso si hace una copia de seguridad del registro con frecuencia, aún debe acomodar la suma de las transacciones simultáneas que pueden ocurrir. Los eventos de crecimiento automático de archivos de registro son costosos, ya que SQL Server tiene que poner a cero los archivos (a diferencia de los archivos de datos cuando la inicialización instantánea de archivos está habilitada), y las transacciones de los usuarios tienen que esperar mientras esto sucede. Usted quiere hacer esta rutina de crecer-reducir-crecer-reducir lo menos posible, y ciertamente no quiere que sus usuarios paguen por ello.

Tenga en cuenta que es posible que deba hacer una copia de seguridad del registro dos veces antes de que sea posible reducirlo (gracias, Robert).

Por lo tanto, debe encontrar un tamaño práctico para su archivo de registro. Nadie aquí puede decirle qué es eso sin saber mucho más sobre su sistema, pero si ha estado reduciendo el archivo de registro con frecuencia y ha vuelto a crecer, una buena marca de agua es probablemente un 10-50% más alta que la más grande. . Digamos que llega a 200 MB y desea que cualquier evento de crecimiento automático posterior sea de 50 MB, luego puede ajustar el tamaño del archivo de registro de esta manera:

USE [master];
GO
ALTER DATABASE Test1 
  MODIFY FILE
  (NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO

Tenga en cuenta que si el archivo de registro es actualmente> 200 MB, es posible que deba ejecutar esto primero:

USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO

Si no le importa la recuperación puntual

Si se trata de una base de datos de prueba y no le importa la recuperación de un punto en el tiempo, debe asegurarse de que su base de datos esté en SIMPLE modo de recuperación.

ALTER DATABASE testdb SET RECOVERY SIMPLE;

Poner la base de datos en SIMPLE el modo de recuperación se asegurará de que SQL Server reutilice partes del archivo de registro (esencialmente eliminando gradualmente las transacciones inactivas) en lugar de crecer para mantener un registro de todo transacciones (como FULL la recuperación lo hace hasta que realiza una copia de seguridad del registro). CHECKPOINT los eventos ayudarán a controlar el registro y se asegurarán de que no necesite crecer a menos que genere mucha actividad de t-log entre CHECKPOINT s.

A continuación, debe asegurarse absolutamente de que este crecimiento del registro realmente se deba a un evento anormal (por ejemplo, una limpieza de primavera anual o la reconstrucción de sus índices más grandes) y no debido al uso diario normal. Si reduce el archivo de registro a un tamaño ridículamente pequeño y SQL Server solo tiene que volver a crecer para adaptarse a su actividad normal, ¿qué gana? ¿Pudiste hacer uso de ese espacio en disco que liberaste solo temporalmente? Si necesita una solución inmediata, puede ejecutar lo siguiente:

USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
DBCC SHRINKFILE(yourdb_log, 200); -- unit is set in MBs
GO

De lo contrario, establezca un tamaño y una tasa de crecimiento adecuados. Según el ejemplo en el caso de recuperación de un punto en el tiempo, puede usar el mismo código y lógica para determinar qué tamaño de archivo es apropiado y establecer parámetros de crecimiento automático razonables.

Algunas cosas que no quieres hacer

  • Haz una copia de seguridad del registro con TRUNCATE_ONLY opción y luego SHRINKFILE . Por un lado, este TRUNCATE_ONLY La opción ha quedado obsoleta y ya no está disponible en las versiones actuales de SQL Server. Segundo, si estás en FULL modelo de recuperación, esto destruirá su cadena de registro y requerirá una nueva copia de seguridad completa.

  • Desconecte la base de datos, elimine el archivo de registro y vuelva a adjuntar . No puedo enfatizar lo peligroso que esto puede ser. Es posible que su base de datos no vuelva a funcionar, que aparezca como sospechosa, que tenga que volver a una copia de seguridad (si tiene una), etc., etc.

  • Utilice la opción "reducir base de datos" . DBCC SHRINKDATABASE y la opción del plan de mantenimiento para hacer lo mismo son malas ideas, especialmente si realmente solo necesita resolver un problema de registro. Apunte al archivo que desea ajustar y ajústelo de forma independiente, usando DBCC SHRINKFILE o ALTER DATABASE ... MODIFY FILE (ejemplos anteriores).

  • Reducir el archivo de registro a 1 MB . Esto parece tentador porque, oye, SQL Server me permitirá hacerlo en ciertos escenarios, ¡y mira todo el espacio que libera! A menos que su base de datos sea de solo lectura (y lo es, debe marcarla como tal usando ALTER DATABASE ), esto conducirá absolutamente a muchos eventos de crecimiento innecesarios, ya que el registro tiene que acomodar las transacciones actuales independientemente del modelo de recuperación. ¿Cuál es el punto de liberar ese espacio temporalmente, solo para que SQL Server pueda recuperarlo lenta y dolorosamente?

  • Cree un segundo archivo de registro . Esto proporcionará un alivio temporal para la unidad que ha llenado su disco, pero esto es como tratar de reparar un pulmón perforado con una curita. Debe tratar el archivo de registro problemático directamente en lugar de simplemente agregar otro problema potencial. Aparte de redirigir parte de la actividad del registro de transacciones a una unidad diferente, un segundo archivo de registro realmente no hace nada por usted (a diferencia de un segundo archivo de datos), ya que solo se puede usar uno de los archivos a la vez. Paul Randal también explica por qué varios archivos de registro pueden morderte más tarde.

Sé proactivo

En lugar de reducir su archivo de registro a una cantidad pequeña y dejar que crezca automáticamente a un ritmo pequeño por sí solo, configúrelo en un tamaño razonablemente grande (uno que se adapte a la suma de su conjunto más grande de transacciones simultáneas) y establezca un crecimiento automático razonable como una alternativa, para que no tenga que crecer varias veces para satisfacer transacciones individuales y para que sea relativamente raro que alguna vez tenga que crecer durante las operaciones comerciales normales.

Las peores configuraciones posibles aquí son 1 MB de crecimiento o 10% de crecimiento. Curiosamente, estos son los valores predeterminados para SQL Server (del que me quejé y pedí cambios en vano):1 MB para archivos de datos y 10% para archivos de registro. El primero es demasiado pequeño hoy en día, y el último conduce a eventos cada vez más largos (digamos, su archivo de registro es de 500 MB, el primer crecimiento es de 50 MB, el próximo crecimiento es de 55 MB, el próximo crecimiento es de 60,5 MB , etc. etc. - y en E/S lentas, créame, realmente notará esta curva).

Lecturas adicionales

Por favor, no se detenga aquí; Si bien muchos de los consejos que ve sobre la reducción de archivos de registro son intrínsecamente malos e incluso potencialmente desastrosos, hay algunas personas que se preocupan más por la integridad de los datos que por liberar espacio en el disco.

Una publicación de blog que escribí en 2009, cuando vi que surgían algunas publicaciones "aquí se explica cómo reducir el archivo de registro".

Una publicación de blog que Brent Ozar escribió hace cuatro años, señalando varios recursos, en respuesta a un artículo de SQL Server Magazine que no han sido publicados.

Una publicación de blog de Paul Randal que explica por qué el mantenimiento de t-log es importante y por qué tampoco debería reducir sus archivos de datos.

Mike Walsh también tiene una excelente respuesta que cubre algunos de estos aspectos, incluidas las razones por las que es posible que no pueda reducir su archivo de registro de inmediato.