This is a multi-part message in MIME format.
--=_NextPart_000_0038_01C393F7.79D233D0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I am restoring a production database onto a test server to a point in = time.
I restore the database from script with no issue, but when I try to = restore the first of 6 logs, I receive the following message;
Server: Msg 4305, Level 16, State 1, Line 1
The log in this backup set begins at LSN 237426000000004300001, which is = too late to apply to the database. An earlier log backup that includes = LSN 237424000000007700001 can be restored.
Server: Msg 3013, Level 16, State 1, Line 1
RESTORE LOG is terminating abnormally.
What am I doing wrong? What does this mean and how do I get my log = restore script to work to get my database restored to a point in time?
Thanx!
--=_NextPart_000_0038_01C393F7.79D233D0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
&
I am restoring a production database onto a test server to a point = in time.
I restore the database from script with no issue, but when I try to = restore the first of 6 logs, I receive the following message;
Server: Msg 4305, Level 16, State 1, Line 1The log in this = backup set begins at LSN 237426000000004300001, which is too late to apply to the = database. An earlier log backup that includes LSN 237424000000007700001 can be restored.Server: Msg 3013, Level 16, State 1, Line 1RESTORE LOG = is terminating abnormally.
What am I doing wrong? What does this mean and how do I get = my log restore script to work to get my database restored to a point in = time?
Thanx!
--=_NextPart_000_0038_01C393F7.79D233D0--JLS
This is telling you that you have a missing log between the database you
restored and the log that you are trying to restore. The message is telling
you that you need the log backup containing:
LSN 237424000000007700001
The log you are attempting to restore starts with:
LSN 237426000000004300001
As you can see, your log start point is greater. If you have no log backups
between the database backup and the 7700001 log backup, then that may mean
that the log was truncated during that period. When the chain of LSNs is
incomplete, you cannot restore past the break.
(In the MSDN, search for "SQL LSN" and you will get some background on
this.)
Russell Fields
"JLS" <judy.shoop@.sartomer.com> wrote in message
news:%23RvzWiBlDHA.2364@.TK2MSFTNGP11.phx.gbl...
I am restoring a production database onto a test server to a point in time.
I restore the database from script with no issue, but when I try to restore
the first of 6 logs, I receive the following message;
Server: Msg 4305, Level 16, State 1, Line 1
The log in this backup set begins at LSN 237426000000004300001, which is too
late to apply to the database. An earlier log backup that includes LSN
237424000000007700001 can be restored.
Server: Msg 3013, Level 16, State 1, Line 1
RESTORE LOG is terminating abnormally.
What am I doing wrong? What does this mean and how do I get my log restore
script to work to get my database restored to a point in time?
Thanx!|||I do a full database backup, then an hour later I start my hourly log
backups.
I think I may need to do a log backup immediately after the database backup
if the log is somehow being truncated after the full backup, and before my
hourly log backup job starts. I need to have a full backup and an hourly
log backup.
The full backup is scheduled for 7:45, then the hourly log backups kick off
at 8:45. The first log backup I am trying to restore is the one right after
the full database backup, therefore, I guess the log is being truncated
somehow in that hour window.
Thanx for the tip on looking this up in MSDN.
--
JUDE
"Russell Fields" <RussellFields@.NoMailPlease.Com> wrote in message
news:%23S2DROClDHA.2772@.TK2MSFTNGP12.phx.gbl...
> JLS
> This is telling you that you have a missing log between the database you
> restored and the log that you are trying to restore. The message is
telling
> you that you need the log backup containing:
> LSN 237424000000007700001
> The log you are attempting to restore starts with:
> LSN 237426000000004300001
> As you can see, your log start point is greater. If you have no log
backups
> between the database backup and the 7700001 log backup, then that may mean
> that the log was truncated during that period. When the chain of LSNs is
> incomplete, you cannot restore past the break.
> (In the MSDN, search for "SQL LSN" and you will get some background on
> this.)
> Russell Fields
>
> "JLS" <judy.shoop@.sartomer.com> wrote in message
> news:%23RvzWiBlDHA.2364@.TK2MSFTNGP11.phx.gbl...
> I am restoring a production database onto a test server to a point in
time.
> I restore the database from script with no issue, but when I try to
restore
> the first of 6 logs, I receive the following message;
> Server: Msg 4305, Level 16, State 1, Line 1
> The log in this backup set begins at LSN 237426000000004300001, which is
too
> late to apply to the database. An earlier log backup that includes LSN
> 237424000000007700001 can be restored.
> Server: Msg 3013, Level 16, State 1, Line 1
> RESTORE LOG is terminating abnormally.
> What am I doing wrong? What does this mean and how do I get my log
restore
> script to work to get my database restored to a point in time?
> Thanx!
>|||Definitely, you don't have to do another log backup
straight after full backup.
When you backup transaction log to the same log backup
file, make sure you use WITH NOINIT option which do not
overwrite the previous backup. Or backup to the different
file name.
When you restore transaction log, you specify WITH FILE=[file no] to specify file number on the file.|||In addition, look in msdb, the backup history tables. These might assist in finding out where the
missing log backups went.
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as ugroup=microsoft.public.sqlserver
"Johnny" <anonymous@.discussions.microsoft.com> wrote in message
news:2d30601c39474$bfb89c90$a601280a@.phx.gbl...
> Definitely, you don't have to do another log backup
> straight after full backup.
> When you backup transaction log to the same log backup
> file, make sure you use WITH NOINIT option which do not
> overwrite the previous backup. Or backup to the different
> file name.
> When you restore transaction log, you specify WITH FILE=> [file no] to specify file number on the file.|||Thanx Johnny, but I am doing everything that you have suggested. I backup
the log to the same backup file as the database, it is the first log file
backup after the full database backup, and when I restore I use WITH FILE
[file no]. The backup most certainly contains WITH NOINIT, until the full
database backup occurs the next night, this is when I INIT.
"Johnny" <anonymous@.discussions.microsoft.com> wrote in message
news:2d30601c39474$bfb89c90$a601280a@.phx.gbl...
> Definitely, you don't have to do another log backup
> straight after full backup.
> When you backup transaction log to the same log backup
> file, make sure you use WITH NOINIT option which do not
> overwrite the previous backup. Or backup to the different
> file name.
> When you restore transaction log, you specify WITH FILE=> [file no] to specify file number on the file.|||Ok, great! I will, because I would actually like to know what has happened.
Thanx!
"Tibor Karaszi" <tibor.please_reply_to_public_forum.karaszi@.cornerstone.se>
wrote in message news:OFpE3dIlDHA.1764@.tk2msftngp13.phx.gbl...
> In addition, look in msdb, the backup history tables. These might assist
in finding out where the
> missing log backups went.
> --
> Tibor Karaszi, SQL Server MVP
> Archive at: http://groups.google.com/groups?oi=djq&as
ugroup=microsoft.public.sqlserver
>
> "Johnny" <anonymous@.discussions.microsoft.com> wrote in message
> news:2d30601c39474$bfb89c90$a601280a@.phx.gbl...
> > Definitely, you don't have to do another log backup
> > straight after full backup.
> >
> > When you backup transaction log to the same log backup
> > file, make sure you use WITH NOINIT option which do not
> > overwrite the previous backup. Or backup to the different
> > file name.
> >
> > When you restore transaction log, you specify WITH FILE=> > [file no] to specify file number on the file.
>
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment