not a valid undo file for database

Hi,
I've restored a database from backup, with STANDBY option.
Now, when I'm trying to apply further Transaction logs to
this database, the restore log command is failing with an
error 'File 'd:\standby.undo' is not a valid undo file for
database 'xyz', database ID 24.
Please let me know how to I avoid this error and restore
logs to this database.
Does the file mentioned in the error message actually exist?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"ykchakri" <anonymous@.discussions.microsoft.com> wrote in message
news:21a001c4aa62$329a33a0$a501280a@.phx.gbl...
> Hi,
> I've restored a database from backup, with STANDBY option.
> Now, when I'm trying to apply further Transaction logs to
> this database, the restore log command is failing with an
> error 'File 'd:\standby.undo' is not a valid undo file for
> database 'xyz', database ID 24.
> Please let me know how to I avoid this error and restore
> logs to this database.
|||Yes, it does. And I've tried renaming this file and then
it gives a different error that the file does not exist.
SO, I'm sure that it is able to access this file, but
something is not right in this file.
What's the purpose of this file anyway ?

>--Original Message--
>Does the file mentioned in the error message actually
exist?
>--
>Tibor Karaszi, SQL Server MVP
>http://www.karaszi.com/sqlserver/default.asp
>http://www.solidqualitylearning.com/
>
>"ykchakri" <anonymous@.discussions.microsoft.com> wrote in
message[vbcol=seagreen]
>news:21a001c4aa62$329a33a0$a501280a@.phx.gbl...
option.[vbcol=seagreen]
to[vbcol=seagreen]
an[vbcol=seagreen]
for
>
>.
>
|||The UNDO file is created when you perform RESTORE using the STANDBY option.
This is because SQL Server will actually perform recovery based on the transaction log when you are
using STANDBY, but as you say you want to be able to perform additional restores, SQL Server will
save the recovery work it performs in this undo file so it can undo the recovery work when you do
the next restore.
SQL Server will remember the name of the undo file so it will automatically find it when next
restore is performed. In this case, SQL Server doesn't recognize the undo file as a valid file.
Perhaps someone deleted the file and just created one through notepad, or picked some other UNDO
file and renamed it? Bottom-line is that SLQ Server *need* a valid UNDO file for the next restore.
You can always re-start all restores from the latest database backup.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"ykchakri" <anonymous@.discussions.microsoft.com> wrote in message
news:2abc01c4ab08$347ecdb0$a501280a@.phx.gbl...[vbcol=seagreen]
> Yes, it does. And I've tried renaming this file and then
> it gives a different error that the file does not exist.
> SO, I'm sure that it is able to access this file, but
> something is not right in this file.
> What's the purpose of this file anyway ?
> exist?
> message
> option.
> to
> an
> for
sql

not a valid undo file for database

Hi,
I've restored a database from backup, with STANDBY option.
Now, when I'm trying to apply further Transaction logs to
this database, the restore log command is failing with an
error 'File 'd:\standby.undo' is not a valid undo file for
database 'xyz', database ID 24.
Please let me know how to I avoid this error and restore
logs to this database.Does the file mentioned in the error message actually exist?
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"ykchakri" <anonymous@.discussions.microsoft.com> wrote in message
news:21a001c4aa62$329a33a0$a501280a@.phx.gbl...
> Hi,
> I've restored a database from backup, with STANDBY option.
> Now, when I'm trying to apply further Transaction logs to
> this database, the restore log command is failing with an
> error 'File 'd:\standby.undo' is not a valid undo file for
> database 'xyz', database ID 24.
> Please let me know how to I avoid this error and restore
> logs to this database.|||Yes, it does. And I've tried renaming this file and then
it gives a different error that the file does not exist.
SO, I'm sure that it is able to access this file, but
something is not right in this file.
What's the purpose of this file anyway ?
>--Original Message--
>Does the file mentioned in the error message actually
exist?
>--
>Tibor Karaszi, SQL Server MVP
>http://www.karaszi.com/sqlserver/default.asp
>http://www.solidqualitylearning.com/
>
>"ykchakri" <anonymous@.discussions.microsoft.com> wrote in
message
>news:21a001c4aa62$329a33a0$a501280a@.phx.gbl...
>> Hi,
>> I've restored a database from backup, with STANDBY
option.
>> Now, when I'm trying to apply further Transaction logs
to
>> this database, the restore log command is failing with
an
>> error 'File 'd:\standby.undo' is not a valid undo file
for
>> database 'xyz', database ID 24.
>> Please let me know how to I avoid this error and restore
>> logs to this database.
>
>.
>|||The UNDO file is created when you perform RESTORE using the STANDBY option.
This is because SQL Server will actually perform recovery based on the transaction log when you are
using STANDBY, but as you say you want to be able to perform additional restores, SQL Server will
save the recovery work it performs in this undo file so it can undo the recovery work when you do
the next restore.
SQL Server will remember the name of the undo file so it will automatically find it when next
restore is performed. In this case, SQL Server doesn't recognize the undo file as a valid file.
Perhaps someone deleted the file and just created one through notepad, or picked some other UNDO
file and renamed it? Bottom-line is that SLQ Server *need* a valid UNDO file for the next restore.
You can always re-start all restores from the latest database backup.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"ykchakri" <anonymous@.discussions.microsoft.com> wrote in message
news:2abc01c4ab08$347ecdb0$a501280a@.phx.gbl...
> Yes, it does. And I've tried renaming this file and then
> it gives a different error that the file does not exist.
> SO, I'm sure that it is able to access this file, but
> something is not right in this file.
> What's the purpose of this file anyway ?
>>--Original Message--
>>Does the file mentioned in the error message actually
> exist?
>>--
>>Tibor Karaszi, SQL Server MVP
>>http://www.karaszi.com/sqlserver/default.asp
>>http://www.solidqualitylearning.com/
>>
>>"ykchakri" <anonymous@.discussions.microsoft.com> wrote in
> message
>>news:21a001c4aa62$329a33a0$a501280a@.phx.gbl...
>> Hi,
>> I've restored a database from backup, with STANDBY
> option.
>> Now, when I'm trying to apply further Transaction logs
> to
>> this database, the restore log command is failing with
> an
>> error 'File 'd:\standby.undo' is not a valid undo file
> for
>> database 'xyz', database ID 24.
>> Please let me know how to I avoid this error and restore
>> logs to this database.
>>
>>.

No truncating.

Hello eveybody !
I have a small problem with my logs on sql server .
Even after a backup (lod and/or db), server seems to not truncate his
logs ... so they're growing each days, and need to be deleted
manually.
Any ideas ?Hi,
After backup the physical LDF file will not get reduced automatcally. But
the logical space will be reduced by looking into
dbcc sqlperf(logspace)
To shrink the physical ldf file after the log backup use dbcc shrinkfile
command. See the dbcc shrinkfile command in boks online.
Thanks
Hari
MCDBA
"Frater" <None@.legioobscurantis.com> wrote in message
news:mb2kg059uld5st2p9tfvsoo34evdfcl3gg@.
4ax.com...
> Hello eveybody !
> I have a small problem with my logs on sql server .
> Even after a backup (lod and/or db), server seems to not truncate his
> logs ... so they're growing each days, and need to be deleted
> manually.
> Any ideas ?|||Can't you just set the database to autoshrink with:
sp_dboption database_name, 'autoshrink' TRUE
In article <#xXRVRhdEHA.3988@.tk2msftngp13.phx.gbl>,
hari_prasad_k@.hotmail.com says...[vbcol=seagreen]
> After backup the physical LDF file will not get reduced automatcally. But
> the logical space will be reduced by looking into
> dbcc sqlperf(logspace)
> To shrink the physical ldf file after the log backup use dbcc shrinkfile
> command. See the dbcc shrinkfile command in boks online.
> "Frater" <None@.legioobscurantis.com> wrote in message
> news:mb2kg059uld5st2p9tfvsoo34evdfcl3gg@.
4ax.com...|||Frater,
Truncating and shrinking are two different things.
Truncating the log (logically) cleans up space which was previously used in
the log so that it can be re-used. The log is a circular file which tries to
re-use the same space over and over. Truncating the log does NOT change the
physical size of the log... If the log is NOT truncated, then space can not
be re-used, so the log will grow to acquire the necessary space. Truncating
the log occurs automatically if the database is in SIMPLE recovery mode. The
log is truncated during a transaction log backup as well..
Shrinking the log can be done AFTER the log has been truncated. Use DBCC
Shrinkdatabase or DBCC Shrinkfile to physical reduce the log file size...
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Frater" <None@.legioobscurantis.com> wrote in message
news:mb2kg059uld5st2p9tfvsoo34evdfcl3gg@.
4ax.com...
> Hello eveybody !
> I have a small problem with my logs on sql server .
> Even after a backup (lod and/or db), server seems to not truncate his
> logs ... so they're growing each days, and need to be deleted
> manually.
> Any ideas ?|||Hi Brad
Shrinking the datasbase will shrink ALL the files, not just the log files,
and the autoshrink option will do this every 30 minutes.
It is incredibly resource intensive, as it tries to move all data in the
files to other places in the files, and all kinds of adjustments to indexes
might need to be done as a result.
Autoshrink is definitely NOT recommended for a production system.
The log file must be managed separately, as per the other suggestions in
this thread.
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"Brad Murray" <brad@.seesigifthere.com> wrote in message
news:MPG.1b73f47b2134b1ff989682@.news...[vbcol=seagreen]
> Can't you just set the database to autoshrink with:
> sp_dboption database_name, 'autoshrink' TRUE
> In article <#xXRVRhdEHA.3988@.tk2msftngp13.phx.gbl>,
> hari_prasad_k@.hotmail.com says...
But[vbcol=seagreen]

No truncating.

Hello eveybody !
I have a small problem with my logs on sql server .
Even after a backup (lod and/or db), server seems to not truncate his
logs ... so they're growing each days, and need to be deleted
manually.
Any ideas ?Hi,
After backup the physical LDF file will not get reduced automatcally. But
the logical space will be reduced by looking into
dbcc sqlperf(logspace)
To shrink the physical ldf file after the log backup use dbcc shrinkfile
command. See the dbcc shrinkfile command in boks online.
Thanks
Hari
MCDBA
"Frater" <None@.legioobscurantis.com> wrote in message
news:mb2kg059uld5st2p9tfvsoo34evdfcl3gg@.4ax.com...
> Hello eveybody !
> I have a small problem with my logs on sql server .
> Even after a backup (lod and/or db), server seems to not truncate his
> logs ... so they're growing each days, and need to be deleted
> manually.
> Any ideas ?|||Can't you just set the database to autoshrink with:
sp_dboption database_name, 'autoshrink' TRUE
In article <#xXRVRhdEHA.3988@.tk2msftngp13.phx.gbl>,
hari_prasad_k@.hotmail.com says...
> After backup the physical LDF file will not get reduced automatcally. But
> the logical space will be reduced by looking into
> dbcc sqlperf(logspace)
> To shrink the physical ldf file after the log backup use dbcc shrinkfile
> command. See the dbcc shrinkfile command in boks online.
> "Frater" <None@.legioobscurantis.com> wrote in message
> news:mb2kg059uld5st2p9tfvsoo34evdfcl3gg@.4ax.com...
> > Hello eveybody !
> >
> > I have a small problem with my logs on sql server .
> >
> > Even after a backup (lod and/or db), server seems to not truncate his
> > logs ... so they're growing each days, and need to be deleted
> > manually.
> >
> > Any ideas ?|||Frater,
Truncating and shrinking are two different things.
Truncating the log (logically) cleans up space which was previously used in
the log so that it can be re-used. The log is a circular file which tries to
re-use the same space over and over. Truncating the log does NOT change the
physical size of the log... If the log is NOT truncated, then space can not
be re-used, so the log will grow to acquire the necessary space. Truncating
the log occurs automatically if the database is in SIMPLE recovery mode. The
log is truncated during a transaction log backup as well..
Shrinking the log can be done AFTER the log has been truncated. Use DBCC
Shrinkdatabase or DBCC Shrinkfile to physical reduce the log file size...
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Frater" <None@.legioobscurantis.com> wrote in message
news:mb2kg059uld5st2p9tfvsoo34evdfcl3gg@.4ax.com...
> Hello eveybody !
> I have a small problem with my logs on sql server .
> Even after a backup (lod and/or db), server seems to not truncate his
> logs ... so they're growing each days, and need to be deleted
> manually.
> Any ideas ?|||Hi Brad
Shrinking the datasbase will shrink ALL the files, not just the log files,
and the autoshrink option will do this every 30 minutes.
It is incredibly resource intensive, as it tries to move all data in the
files to other places in the files, and all kinds of adjustments to indexes
might need to be done as a result.
Autoshrink is definitely NOT recommended for a production system.
The log file must be managed separately, as per the other suggestions in
this thread.
--
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"Brad Murray" <brad@.seesigifthere.com> wrote in message
news:MPG.1b73f47b2134b1ff989682@.news...
> Can't you just set the database to autoshrink with:
> sp_dboption database_name, 'autoshrink' TRUE
> In article <#xXRVRhdEHA.3988@.tk2msftngp13.phx.gbl>,
> hari_prasad_k@.hotmail.com says...
> >
> > After backup the physical LDF file will not get reduced automatcally.
But
> > the logical space will be reduced by looking into
> >
> > dbcc sqlperf(logspace)
> >
> > To shrink the physical ldf file after the log backup use dbcc shrinkfile
> > command. See the dbcc shrinkfile command in boks online.
> >
> > "Frater" <None@.legioobscurantis.com> wrote in message
> > news:mb2kg059uld5st2p9tfvsoo34evdfcl3gg@.4ax.com...
> > > Hello eveybody !
> > >
> > > I have a small problem with my logs on sql server .
> > >
> > > Even after a backup (lod and/or db), server seems to not truncate his
> > > logs ... so they're growing each days, and need to be deleted
> > > manually.
> > >
> > > Any ideas ?

No truncating.

Hello eveybody !
I have a small problem with my logs on sql server .
Even after a backup (lod and/or db), server seems to not truncate his
logs ... so they're growing each days, and need to be deleted
manually.
Any ideas ?
Hi,
After backup the physical LDF file will not get reduced automatcally. But
the logical space will be reduced by looking into
dbcc sqlperf(logspace)
To shrink the physical ldf file after the log backup use dbcc shrinkfile
command. See the dbcc shrinkfile command in boks online.
Thanks
Hari
MCDBA
"Frater" <None@.legioobscurantis.com> wrote in message
news:mb2kg059uld5st2p9tfvsoo34evdfcl3gg@.4ax.com...
> Hello eveybody !
> I have a small problem with my logs on sql server .
> Even after a backup (lod and/or db), server seems to not truncate his
> logs ... so they're growing each days, and need to be deleted
> manually.
> Any ideas ?
|||Can't you just set the database to autoshrink with:
sp_dboption database_name, 'autoshrink' TRUE
In article <#xXRVRhdEHA.3988@.tk2msftngp13.phx.gbl>,
hari_prasad_k@.hotmail.com says...[vbcol=seagreen]
> After backup the physical LDF file will not get reduced automatcally. But
> the logical space will be reduced by looking into
> dbcc sqlperf(logspace)
> To shrink the physical ldf file after the log backup use dbcc shrinkfile
> command. See the dbcc shrinkfile command in boks online.
> "Frater" <None@.legioobscurantis.com> wrote in message
> news:mb2kg059uld5st2p9tfvsoo34evdfcl3gg@.4ax.com...
|||Frater,
Truncating and shrinking are two different things.
Truncating the log (logically) cleans up space which was previously used in
the log so that it can be re-used. The log is a circular file which tries to
re-use the same space over and over. Truncating the log does NOT change the
physical size of the log... If the log is NOT truncated, then space can not
be re-used, so the log will grow to acquire the necessary space. Truncating
the log occurs automatically if the database is in SIMPLE recovery mode. The
log is truncated during a transaction log backup as well..
Shrinking the log can be done AFTER the log has been truncated. Use DBCC
Shrinkdatabase or DBCC Shrinkfile to physical reduce the log file size...
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Frater" <None@.legioobscurantis.com> wrote in message
news:mb2kg059uld5st2p9tfvsoo34evdfcl3gg@.4ax.com...
> Hello eveybody !
> I have a small problem with my logs on sql server .
> Even after a backup (lod and/or db), server seems to not truncate his
> logs ... so they're growing each days, and need to be deleted
> manually.
> Any ideas ?
|||Hi Brad
Shrinking the datasbase will shrink ALL the files, not just the log files,
and the autoshrink option will do this every 30 minutes.
It is incredibly resource intensive, as it tries to move all data in the
files to other places in the files, and all kinds of adjustments to indexes
might need to be done as a result.
Autoshrink is definitely NOT recommended for a production system.
The log file must be managed separately, as per the other suggestions in
this thread.
HTH
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"Brad Murray" <brad@.seesigifthere.com> wrote in message
news:MPG.1b73f47b2134b1ff989682@.news...[vbcol=seagreen]
> Can't you just set the database to autoshrink with:
> sp_dboption database_name, 'autoshrink' TRUE
> In article <#xXRVRhdEHA.3988@.tk2msftngp13.phx.gbl>,
> hari_prasad_k@.hotmail.com says...
But[vbcol=seagreen]

No transaction logs

can you manually backup the transaction log from EM?
Keene
>--Original Message--
>I have a maintenance plan set up on a database to take
transaction log backups every 2 hours. The job runs
successfully everyday, but I do not see any .trn files
generated (and the task pad description shows that no
transaction log backups ever took place).
>Any idea why? I've never seen this problem on any of my
other servers.
>Thank you!
>.
>It's SQL Server 7.0 with a database option of Truncate Log on Checkpoint...d
oes that make a difference?|||Gina,
With truncate log on checkpoint set the log file backups will be =
failing. You cannot do a backup log when this option is set as the =
contents of thye log are effectively destroyed at every checkpoint (ie =
every few minutes).
It sounds like you want this option OFF if you require point-in-time =
recovery.
Mike John
"Gina" <anonymous@.discussions.microsoft.com> wrote in message =
news:A4AC132C-1726-494E-AA0C-952A18EBED8E@.microsoft.com...
> It's SQL Server 7.0 with a database option of Truncate Log on =
Checkpoint...does that make a difference?|||Thank you very much!

No transaction logs

I have a maintenance plan set up on a database to take transaction log backu
ps every 2 hours. The job runs successfully everyday, but I do not see any
.trn files generated (and the task pad description shows that no transaction
log backups ever took plac
e).
Any idea why? I've never seen this problem on any of my other servers.
Thank you!I'd start by double checking the job / maint plan definition, the recovery
model for the databases and then if needed run a profiler trace to see
whether the BACKUP LOG command is submitted. Also, make sure you define a
report file for the maint plan and check that report file for error
messages.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Gina" <anonymous@.discussions.microsoft.com> wrote in message
news:01060BCF-B18D-427F-AFB7-86ECE6A8A9DC@.microsoft.com...
> I have a maintenance plan set up on a database to take transaction log
backups every 2 hours. The job runs successfully everyday, but I do not see
any .trn files generated (and the task pad description shows that no
transaction log backups ever took place).
> Any idea why? I've never seen this problem on any of my other servers.
> Thank you!