Mi archivo de registro en SQL Server agotó todo el espacio de mi disco. Ejecuto copias de seguridad completas todas las noches, pero el archivo de registro sigue creciendo. ¿Que puedo hacer?Mi archivo de registro es demasiado grande
En la mayoría de los sistemas ocupados, debe consultar las copias de seguridad del registro de planificación a lo largo del día y luego su copia de seguridad completa nocturna. Esta es una práctica bastante común.
¿Eliminar el archivo de registro?
Editar: Al parecer, borrar el archivo de registro es malo, es sólo solo un registro en el servidor SQL. Dejo esto para reiterar lo que no debo hacer.
Eliminar el archivo de registro sería realmente malo para un servidor sql ... Contiene la información para recuperar de un error difícil. –
Puede usar algún tipo de rotación de registros, y mantener solo el registro de una cantidad fija de tiempo, por ejemplo, los últimos 7 días. Esto debería ser más que suficiente. O puede reiniciar el registro todas las noches, porque debe tenerlo en su copia de seguridad.
Tienes que copia de seguridad de seguridad de los registros, así como la base de datos principal
Esto debería reducir su tamaño:
dbcc shrinkfile('databasename_log', 0)
probar esto:
dump transaction <dbname> with no_log
y luego reducir el tamaño del archivo de registro mediante el establecimiento la opción autoshrink en la configuración del servidor sql o por.
Creo que puedes usar dbcc para reducirlo también, pero no recuerdo la sintaxis.
Si tiene un trabajo programado para realizar copias de seguridad completas, esto es bueno y debe ser su punto de partida, sin embargo, también debe realizar copias de seguridad periódicas de los registros de transacciones.
Hacer una copia de seguridad del registro de transacciones hace que se vuelva a invocar el espacio. Una vez que haya definido su calendario de copia de seguridad de registro de transacciones habitual, es probable que esté en una posición de considerar reducir el registro de transacciones a un tamaño más apropiado. Como ya no crecerá indefinidamente.
La estrategia de copia de seguridad para una recuperación completa se compone de:
* Database backups.
* Differential backups (optional).
* Transaction log backups.
sugiero que consulte la siguiente referencia Microsoft.
http://msdn.microsoft.com/en-us/library/aa173551(SQL.80).aspx
En algunos casos es posible encontrar el archivo de registro no se truncará adecuadamente a pesar de que se ejecuta una copia de seguridad del registro. Puede hacer una copia de seguridad con TRUNCATE_ONLY para verificarlo. Cuando se ejecuta este debe truncar el registro de transacciones:
BACKUP LOG dbname WITH TRUNCATE_ONLY
La causa de este problema es una transacción abierta en una parte anterior del tronco. SQL no truncará el registro después de esta transacción, lo que podría causar un registro grande y cada vez mayor. Necesita averiguar qué transacciones se dejan abiertas y por qué.Usted puede monitorear su espacio de registro con:
DBCC SQLPERF (LOGSPACE)
información sobre las transacciones de larga ejecución se puede encontrar utilizando:
DBCC OPENTRAN
O:
select * from sys.dm_tran_database_transactions
Hola, ten en cuenta que usar la opción WITH TRUNCATE_ONLY no hará una copia de seguridad del registro de transacciones. Perderá la capacidad de restaurar a un punto en el tiempo y, por lo tanto, debe realizar un seguimiento inmediato de esta acción con una copia de seguridad completa, una vez que se resuelvan los problemas del registro de transacciones. –
Es mejor agregar las copias de seguridad de registro de transacciones a tu agenda.
BACKUP LOG database TO DISK = 'D:/database_log.bak'
Tenga en cuenta que en los modelos completos o de registro masivo de recuperación se trunca registro de transacciones cuando se hace la copia de seguridad de registro de transacciones, es necesario para la copia de seguridad del registro con regularidad con el fin de administrar el tamaño de la transacción Iniciar sesión. De lo contrario, el archivo de registro de transacciones crecerá hasta que no quede más espacio.
Si no es necesario en la recuperación puntual y los cambios en la base de datos son poco frecuentes, es mejor utilizar un modelo de recuperación simple (sin registros de transacciones). En este caso, el registro de transacciones se trunca automáticamente para eliminar cualquier archivo de registro virtual inactivo. En el modelo de recuperación simple, el truncamiento del registro de transacciones tiene lugar después de cada punto de control.
Esta es una pregunta de administrador de DB. No es una pregunta de programación. – EBGreen
Creo que debería permanecer abierto, muchas pequeñas empresas los programadores tienen que actuar como administradores de DB. –
De hecho. Algunas personas están demasiado "muy felices" :) –