Error al intentar restaurar desde un backup de transacciones

Sebastián:

Cuando restaures el primer log debes dejar la DB en estado No Recovery para
que se puedan anexar los cambios existentes en los logs siguientes.
Si utilizas el EM y has realizado correctamente los backups te recupera la
información en la secuencia correcta y te deja la db en estado operacional.

Sin embargo, si lo realizas manualmente debes:

1) Restaurar el backup Full
2) Restaurar el primer LOG con la opcion WITH NORECOVERY (lo que deja tu DB
en estado inconcistente)
3) Repetir el paso 2 hasta un LOG antes del último
4) Restaurar el último LOG normalmente (lo que dejará la DB nuevamente en
estado consistente.)

Espero que sea de utilidad.

Saludos.



Pablo O. Abbate
MCDBA - MCAD - MCSD - MCT
www.auladat.es




"Sebastian" escribió en el mensaje
news:1119d01c3bf3d$cb927830$

Durante el día se generan 5 respaldos de las transacciones
con la opcion Truncate. Restauro desde el Full, aplico el
primer respaldo del archivo de transacciones y al intentar
aplicar el segundo me da el siguiente error:

" Microsoft SQL-DMO (ODBC SQLState: 42000)

El registro de copia de seguridad empieza en el LSN
1236701000000021300001, demasiado tarde para aplicarlo a
la base de datos.
Se puede restaurar una copia de serguridad del registro
anterior, que incluya el LSN 123618200000009800001.
Fin anómalo de RESTORE LOG "

Gracias, Sebastian

hola!! a ver:

Vos lo que deberias hacer en tu politica de Backup es algo asi como:

Un backup full (por ej por dia)
luego un backup del transaction log que se incremente pero sin truncar el
log.

Te cuento como lo hago aca yo:

1 full diario
1 Transaction log por hora (autoincremental)
1 Transaction log con truncate al finalizar el dia (este esta digamos en el
mismo paso que el full, primero trunco y luego full :-D)

Saludos

Maximiliano Damian Accotto
"Sebastian" escribió en el mensaje
news:1119d01c3bf3d$cb927830$

Durante el día se generan 5 respaldos de las transacciones
con la opcion Truncate. Restauro desde el Full, aplico el
primer respaldo del archivo de transacciones y al intentar
aplicar el segundo me da el siguiente error:

" Microsoft SQL-DMO (ODBC SQLState: 42000)

El registro de copia de seguridad empieza en el LSN
1236701000000021300001, demasiado tarde para aplicarlo a
la base de datos.
Se puede restaurar una copia de serguridad del registro
anterior, que incluya el LSN 123618200000009800001.
Fin anómalo de RESTORE LOG "

Gracias, Sebastian

Hola Pablo (me alegro de leerte por aquí :-))

Todo lo que indicas es correcto para la restauración que se solicita. Sólo
quería hacer una puntualización, y es que también se puede seguir todos esos
pasos desde el Enterprise Manager si en la pestaña opciones marcamos el
opction button correspondiente para que la base de datos no quede operativa
después de la restauración (es decir, lo equivalente a la opción WITH
NORECOVERY, pero desde el Ent. Manager).

Un saludo
Salvador Ramos
Murcia - España

No puedes conseguir software rápidamente disminuyendo su calidad.
En cambio, si que lo consigues aumentando la calidad.

www.helpdna.net (información sobre Windows DNA, SQL Server, .NET, ...)


Microsoft MVP SQL Server
MCP SQL Server
PASS Spanish Group (www.sqlpass.org)


"Pablo O. Abbate" escribió en el mensaje
news:eMyVZ$

Sebastián:

Cuando restaures el primer log debes dejar la DB en estado No Recovery

para

que se puedan anexar los cambios existentes en los logs siguientes.
Si utilizas el EM y has realizado correctamente los backups te recupera la
información en la secuencia correcta y te deja la db en estado

operacional.

Sin embargo, si lo realizas manualmente debes:

1) Restaurar el backup Full
2) Restaurar el primer LOG con la opcion WITH NORECOVERY (lo que deja tu

DB

en estado inconcistente)
3) Repetir el paso 2 hasta un LOG antes del último
4) Restaurar el último LOG normalmente (lo que dejará la DB nuevamente en
estado consistente.)

Espero que sea de utilidad.

Saludos.



Pablo O. Abbate
MCDBA - MCAD - MCSD - MCT
www.auladat.es




"Sebastian" escribió en el mensaje
news:1119d01c3bf3d$cb927830$

Durante el día se generan 5 respaldos de las transacciones
con la opcion Truncate. Restauro desde el Full, aplico el
primer respaldo del archivo de transacciones y al intentar
aplicar el segundo me da el siguiente error:

" Microsoft SQL-DMO (ODBC SQLState: 42000)

El registro de copia de seguridad empieza en el LSN
1236701000000021300001, demasiado tarde para aplicarlo a
la base de datos.
Se puede restaurar una copia de serguridad del registro
anterior, que incluya el LSN 123618200000009800001.
Fin anómalo de RESTORE LOG "

Gracias, Sebastian

Hola Maximiliano, estoy haciendo el full por la noche y
cada 3 hora un backup del transaction log, pero
truncandolo siempre.
Mi idea era restarurar el full, luego desde el primer
respaldo del transaction log (usando no recovery, no da
problemas) hasta el último, pero al intentar restaurar
desde el segudo respaldo de transacciones me da este
error. Gracias de nuevo por la sugerencia, intento hacer
una prueba, saludos

hola!! a ver:

Vos lo que deberias hacer en tu politica de Backup es

algo asi como:

Un backup full (por ej por dia)
luego un backup del transaction log que se incremente

pero sin truncar el

log.

Te cuento como lo hago aca yo:

1 full diario
1 Transaction log por hora (autoincremental)
1 Transaction log con truncate al finalizar el dia (este

esta digamos en el

mismo paso que el full, primero trunco y luego full :-D)

Saludos

Maximiliano Damian Accotto
"Sebastian"

escribió en el mensaje

news:1119d01c3bf3d$cb927830$

Durante el día se generan 5 respaldos de las transacciones
con la opcion Truncate. Restauro desde el Full, aplico el
primer respaldo del archivo de transacciones y al intentar
aplicar el segundo me da el siguiente error:

" Microsoft SQL-DMO (ODBC SQLState: 42000)

El registro de copia de seguridad empieza en el LSN
1236701000000021300001, demasiado tarde para aplicarlo a
la base de datos.
Se puede restaurar una copia de serguridad del registro
anterior, que incluya el LSN 123618200000009800001.
Fin anómalo de RESTORE LOG "

Gracias, Sebastian


.

Es que ahi tenes el problema!! si truncas en tu caso solo podras restaurar
una copia del log, al truncar los datos del log pasan a la BDD, si haces eso
deberias hacer otro full me explico?

no te lo aconsejo!! para mi tenes que cambiar la politica de Backup.

No creo que ahora lo puedas solucionar, solo quedara tu BDD con el full
nomas!!

Esto mismo me ha pasado en un principio, y pregunte a la Ms de como debia
hacerlo y es ahi donde me explicaron y me dijeron lo del Truncate.

Un saludo

Maximiliano Damian Accotto
"Sebastian" escribió en el mensaje
news:112e301c3bf4b$2358cb20$

Hola Maximiliano, estoy haciendo el full por la noche y
cada 3 hora un backup del transaction log, pero
truncandolo siempre.
Mi idea era restarurar el full, luego desde el primer
respaldo del transaction log (usando no recovery, no da
problemas) hasta el último, pero al intentar restaurar
desde el segudo respaldo de transacciones me da este
error. Gracias de nuevo por la sugerencia, intento hacer
una prueba, saludos

hola!! a ver:

Vos lo que deberias hacer en tu politica de Backup es

algo asi como:

Un backup full (por ej por dia)
luego un backup del transaction log que se incremente

pero sin truncar el

log.

Te cuento como lo hago aca yo:

1 full diario
1 Transaction log por hora (autoincremental)
1 Transaction log con truncate al finalizar el dia (este

esta digamos en el

mismo paso que el full, primero trunco y luego full :-D)

Saludos

Maximiliano Damian Accotto
"Sebastian"

escribió en el mensaje

news:1119d01c3bf3d$cb927830$

Durante el día se generan 5 respaldos de las transacciones
con la opcion Truncate. Restauro desde el Full, aplico el
primer respaldo del archivo de transacciones y al intentar
aplicar el segundo me da el siguiente error:

" Microsoft SQL-DMO (ODBC SQLState: 42000)

El registro de copia de seguridad empieza en el LSN
1236701000000021300001, demasiado tarde para aplicarlo a
la base de datos.
Se puede restaurar una copia de serguridad del registro
anterior, que incluya el LSN 123618200000009800001.
Fin anómalo de RESTORE LOG "

Gracias, Sebastian


.