SQL Server (2005/2008): la copia de seguridad completa trunca el registro en modo de recuperación completa

Acabo de leer mucha documentación de MSDN y creo que entiendo los diferentes modelos de recuperación y el concepto de una cadena de respaldo. Todavía tengo una pregunta:

¿Una copia de seguridad completa de la base de datos trunca el registro de transacciones (usando el modo de recuperación completa)?

• En caso afirmativo: ¿Dónde se menciona esto en el MSDN? Todo lo que pude encontrar fue que solo BACKUP LOG trunca el registro.

• Si no: ¿por qué? Dado que una copia de seguridad completa de la base de datos inicia una nueva cadena de copia de seguridad, ¿cuál es el punto de mantener las transacciones que fueron finalizadas antes de que la copia de seguridad completa esté activa en el registro?

No, definitivamente no. Lo único que permite que el registro se borre / trunca en los modelos de recuperación FULL o BULK_LOGGED es una copia de seguridad del registro, sin excepciones. Tuve este argumento hace un tiempo y publiqué una publicación larga y detallada en el blog con una explicación y un guión que puede usar para probarlo en Conceptos erróneos sobre el registro y las copias de seguridad del registro: cómo convencerse .

Siéntase libre de seguir con más preguntas. Por cierto, también vea el largo artículo que escribí para TechNet Magazine sobre Comprender el registro y la recuperación en SQL Server .

Gracias

Una copia de seguridad completa NO trunca el registro, debe realizar una operación de registro de copia de seguridad. Una copia de seguridad completa NO restablece la cadena de registro; eso arruinaría totalmente la replicación / envío de registros, etc.

Tendría que observar de cerca cómo SQL Server realiza copias de seguridad, pero sepa que las transacciones en curso / de ejecución prolongada no están incluidas en la copia de seguridad (de lo contrario, la copia de seguridad nunca se completará), por lo que no es del todo exacto decir que una copia de seguridad completa de un La base de datos en línea garantiza que la próxima copia de seguridad del registro sea obsoleta.

http://msdn.microsoft.com/en-us/library/ms175477.aspx

Según tengo entendido, lo único que trunca el registro de transacciones es una copia de seguridad del registro .

Una copia de seguridad completa solo copia lo suficiente del registro para que sea transaccionalmente consistente, ya que la operación de copia de seguridad tarda un tiempo en completarse y, en ese momento, las páginas copiadas pueden haber cambiado.

Todavía necesita sus copias de seguridad de registros para la recuperación en un momento determinado.

No tengo MSDN para vincular, pero puedo vincularlo al blog de Paul Randal , que fue desarrollador del equipo de SQL Server, escribió DBCC CHECKDB y partes de Books Online.

También responde preguntas en este foro, por lo que sería una autoridad aún mejor que la información de segunda / tercera mano de mí :)

La gente a menudo tiene una idea errónea sobre la copia de seguridad completa y las copias de seguridad de registro. Para que la copia de seguridad funcione en FULLel modelo de recuperación de la copia de seguridad, se deben usar los registros t, ya que durante las copias de seguridad todavía puede haber transacciones en la base de datos (a menos que realice una llamada COLDcopia de seguridad cuando cierre la base de datos). Oracle usa el mismo concepto cuando tiene una base de datos en ARCHIVELOGmodo. La secuencia de una copia de seguridad se reduce a esto:

1. Iniciar copia de seguridad: suspenda todas las acciones en archivos reales y escriba en t-logs.
2. Realice una copia de seguridad: todas las transacciones continúan, pero no se escriben en archivos reales, se escriben en t-logs
3. Finalizar copia de seguridad: reanuda la escritura de transacciones de bases de datos en archivos reales.
4. Si es necesario, descargue lo que está en los registros T en los archivos reales.

Esa es la razón por la cual los registros t-t no se truncan / encogen por defecto, ya que son una parte vital de la continuación de la transacción durante la fase de respaldo.

No confunda truncar el registro con reducir el registro.

• TRUNCATE es eliminar las transacciones en el registro que están antes del último punto de control (el punto de control es cuando las transacciones se vuelcan a la base de datos). Esto se hace usando el comando BACKUP.

• SHRINK el registro es reducir el tamaño real del archivo de registro. Esto se hace usando los comandos DBCC.

Básicamente, no necesita reducir automáticamente el registro de transacciones automáticamente porque los registros de transacciones necesitan espacio para funcionar y si se trunca automáticamente, se mantendrá casi del mismo tamaño.